Visibly Valuable

In these unsettled times, you can spend time worrying about things you can't control, or you can take action on things that are within your control.

Here are 10 things you can do as a developer to make yourself more visibly valuable, which may keep you off the RIF list.

1. Understand what is most important to work on. List those items in rank order. Work on the most important thing until it is done, or until you are stuck. Move to item two. Repeat.

How will you know what is most important? Ask your manager. Do not accept “everything is important” or “they are all number one priorities” as an answer. Those are not answers, they are signs that your manager is pressured, stressed, and isn’t taking time to think clearly.

Ask your boss some questions that will help him think.

• If you were doing this work, which would you work on first?

• Which has to be done soonest?

• Which one will bring in/save the most money?

• Which one will help you most?

2. Get more done by doing fewer things at once. Finish one task or project before you start the next (in priority order, of course). I currently have 4 handcraft projects in progress. I work on the green sweater for awhile, then I switch to the gold quilt, until I want to work on the blue hat, and then I skitter off to the purple quilt. I’m having a great time, I’m busy, and ain’t none of my projects getting done.

It’s quite clear to most people (including me) that I could get one of these project finished faster if I concentrated my effort on that project rather than switching back and forth. Some how, many managers forget this when they go to work and hope that multitasking will actually work. But it doesn't, so don’t even try to do everything at once. It doesn’t work, and actually slows down progress.

3. Understand your own capacity before you commit. Track where your time goes for a couple of weeks. How much time do you spend checking email, answering questions, going to meetings? Look for ways to reduce interruptions and reduce the biggest unproductive use of your time. (Taking breaks is not an unnecessary use of your time. We all know that we do better if we take a little breather from time to time.)

4. Review all the meeting you attend on a regular basis. Notice which meetings have stated goals (that match what actually happens) and which have a published agenda (that’s actually followed). Decline to attend meetings that don’t have a real purpose and a plausible agenda. They will waste your time.

5. Make commitments based on your known capacity, rather than on an ideal 40 hour week. You will become known as some one who meets her commitments, rather than some one who is always late or overly optimistic in her estimates.

6. Work in inch pebbles. Break down projects into tasks that you can complete in a day or two. When you do this, you can report tangible progress at least twice every week. You will become known as someone who gets work done.

7. Test as you go. Check in code at the very least once a day, and run all your tests for that piece of code each time you check in. That way, you will avoid having a false assessment of progress by deferring knowledge of problems until the (false) end of the task.

8. Peer review all fixes. A defect is a clue that the code is difficult to understand or poorly written. So you will avoid breaking something else by having another set of eyes look at the fix.

9. Write tests for the defect fix, and then write a half-dozen tests (at least) in the code around the defect. Defects tend to cluster, so you will be strengthening your code and your feedback system by writing additional tests.

10. Work at a sustainable pace. Tired people make mistakes and write or miss defects. You don’t want to be known as someone who makes mistakes. For most people, a sustainable pace is somewhere between 40-50 hours a week.

I'll write a list for managers, perhaps next week.

Three Myths about Teams

Myth #1: All a team needs to get them working well together is a clear goal and sufficient pressure to perform. I’ve never seen a team without a clear and compelling goal gel; but I’ve seen plenty of teams who did have a clear goal flail and fail. Until a group of people decides to work as a team and decides to agree, they won’t function well as a team.

Myth #2: A manager can discern individual contributions to team results. While a manager can tell certain things about the way a team is functioning, in most cases, it’s impossible to tease out individual contribution. And when managers try to assess who has made the biggest contributions, they are often wrong. Taking action on an incorrect assessment can have devastating effects on the team, and makes the manager look foolish.

Myth #3: If the team isn’t struggling or working long hours they aren’t working hard. Teams that are working well together make the work look easy. They work at a purposeful, yet relaxed pace. They even look like they are having fun.

Three Pillars of Executive Support

I hear people talk about getting executive support for Agile adoptions (or other organizational changes). But I seldom hear people talk about what that support looks like. It's more than money and speeches.

Want to know how to really help your organization change? Three Pillars of Executive Support for Agile Adoption on AgileJournal.com.

system blindness

One of the big problems I see in organizations is that managers who want to improve productivity pull the wrong levers.

For example, one company I know of decided to improve performance by ranking everyone in the company from 1...n, and firing the bottom 10%. Not surprisingly (to me at least), performance didn't get better. But the managers were surprised (when they noticed at all).

Individual performance is important, but it's often not the primary lever to improve organizational performance--it's the work system that needs improvement.

In the company that tried ranking to improve performance, there was no clear product direction, priorities shifted weekly, and teams where broken and reformed every few months. Improving any of those factors would have had a much bigger over all improvement effect than forced ranking and culling.

We like to believe that people succeed or fail by their own efforts. I don't discount individual effort....but focusing only on individual effort blinds us to system effects.

Meeting Madness

Seth Godin blogs about Three Kinds of Meetings:

There are only three kinds of classic meetings:

Information. This is a meeting where attendees are informed about what is happening (with or without their blessing). While there may be a facade of conversation, it's primarily designed to inform.

Discussion. This is a meeting where the leader actually wants feedback or direction or connections. You can use this meeting to come up with an action plan, or develop a new idea, for example.

Permission. This is a meeting where the other side is supposed to say yes but has the power to say no.

PLEASE don't confuse them. Confused meeting types are the number one source of meeting ennui. One source of confusion is that a meeting starts as one sort of meeting and then magically morphs into another kind. The reason this is frightening is that one side or the other might not realize that's actually occurring.

Indeed.

People waste countless hours in meetings with murky goals. Worse, each person may come out of such a meeting with different conclusions, spreading the confusion further in the organization.

Even when a meeting has a clear purpose, if there's no clear way to achieve that purpose, the meeting will not be as effective (or short) as it could be. Another waste of time.

People, people, people.

Improving the quality of meetings is a small intervention that can bring significant improvements to an organization. So don't overlook it even if improving meetings isn't shiny or sexy. Be a master of the obvious. Get the basics right, and you'll have a stronger foundation for the fancy stuff.

More ideas on how to improve meetings:

How to Improve Meetings When You are Not in Charge

The ROTI Method of Gauging Meeting Effectiveness