Managing Product Development

Two different colleagues wrote me with similar conundrums. Their managers wants a “technical” project manager. One colleague was a hardware person, the other was a tester. They have both been managing software projects for several years. No one has told them they were ineffective. (I’ve discussed this issue before: here and here and here.)

Senior managers frequently ask me this question when I do assessments, too: How technical do the managers or project managers need to be? The answer I give is: The managers and PMs need to understand the dynamics of the area or projects they are managing. They need to evaluate risks, they need to make good process decisions, and they need to be able to hire people for their areas or projects. But, they don’t (in general) need deep technical understanding of the project. (Sometimes they do need that technical expertise for managing functional areas.) I discuss the notion of problem-space and solution-space domain expertise with these managers, to see what they really need.

Here’s what I suggested to my colleagues:

• Ask the manager what his/her concerns are.
• Ask the manager what data, risks, problems he/she would have seen earlier with a technical project manager.
• Ask yourself how you could have provided data, escalated risks, or solved problems earlier.
• Ask other people on the project what else they would like from a project manager.

Project management and people management is about managing people issues: the flow of work, identifying and solving problems, recognizing when the work is on/off course, steering the work back on course, providing feedback and coaching. Real project management is not about making architectural decisions. If you have a highly risky project, it’s worth having a technical lead/architect work hand-in-hand with a PM, so that the two people together can see the state of the project. But once a technical person starts doing real project management or people management, it’s not possible for the great majority of people to remain highly technical. I know one person who seems to be highly technical and is a senior manager, but he’s not managing projects, and he has only two direct reports. He freely admits that if he was managing projects at his company (about 20 people per project), he could not retain the technical depth he has.

I agree that managers of technical projects and technical people need more than just an appreciation of the technical work — they need to understand the dynamics of the project work, so they can effectively manage the projects or the project portfolio. But I have yet to see a purely technical project manager succeed — unless they gave up technical expertise to concentrate on the people issues.

Clarke Ching’s post, Functional Blindess, reminded me to post the ways I know about how to see the current state in a project or in an organization. For projects:

• Ask to see a demo. Can you see anything at all? If you can’t see the results of prototype tests, unit tests, some kind of working software (even if it’s not all put together), don’t believe your schedule. It’s possible your schedule is still correct, but there’s no way to tell at all.
• Ask what’s left to do. I tend to use charts that discuss what we planned and what we still have left to do, a type of burndown/burnup chart. (See Brian Marick’s summaryand SprintBurndownChart, and Big Visible Charts for more charts.) I use charts that show a running total of what’s accomplished and what’s left, so that if people add more things to the project, the line goes up, and as the project team finishes work, the line goes down. Up = more to do, Down = less to do.
• Ask for obstacles. If a PM asks about obstacles to completing the project, people are more likely to explain what’s preventing them from finishing the work.
• Perform an interim retrospective to really see what’s happening. (See below).
• Gather data about what’s important to you. Make sure you’re gathering multi-dimensional data. (See Single Dimension Measurements for my thoughts about measuring people’s output in a single dimension. The same thing applies to projects. If you only measure the date, you’ll meet the dates, but the features won’t be there, and/or they won’t work.

Seeing in the small is one thing. Seeing in the large(r) is another. Some ideas to understand your product development issues:

• Perform a retrospective of a just-completed project. If you’re the PM or somehow involved in the projects, you can’t facilitate this; you need to participate, not facilitate. I use Kerth’s questions to drive retrospectives:
  • What did we do well, that if we don’t discuss we might forget?
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?

I facilitate interim retrospectives in a few hours, and post-project retrospectives in 1-2 days. In 2 days, you will be amazed at what you can see.

• Perform an assessment to see the problems and what caused them. Again, someone outside the organization needs to perform this.

People in the project and in the organization have blind spots. They can’t help it (and neither can you). So consciously look for techniques to become aware of the blind spots, so you can fix them.

Roy Osherove taped my talk, “Nine Steps to Becoming More Agile” at the Israel Agile group meeting a couple of weeks ago. I was pleasantly surprised by how good the quality of the recording is. The recording isn’t perfect, because I walk back and forth across the room when I speak. I didn’t remember to repeat all the questions — I only repeated the ones people in the room couldn’t hear. And, I was surprised. I said “uh” way too many times. I thought I’d cured myself of that habit. I’ll have to tape more until I cure again.

Note, this is not a talk about how to use a specific agile lifecyle, this is a talk about how to use some of the agile practices in projects. Enjoy!

I returned from my wonderful around-the-world trip last Friday afternoon. I didn’t try to work until Monday, but I realized today that I was still Asleep at the Wheel. I attempted to use a new-to-me configuration management system (Subversion). In my befuddled state, I managed to use some CVS commands instead of the Subversion commands. It’s ok, go ahead and laugh. The real problem was that I didn’t know what was wrong until today, two days later. I was unable to diagnose the problem because my brain hadn’t caught up with my body. I was unable to think clearly.

Here are my new guidelines for international travel:

• If possible, avoid sitting among the charming teenagers who take flash pictures before I’m awake, and who are coughing and spreading many germs. (This is more luck than planning.
• Give myself a couple of days on either end to do cleanup work, not new development.
• Whatever I do develop, especially once I return, make sure I obtain review.
• Don’t be afraid to ask for help. When I’m tired and not thinking clearly, I tend to be more defensive. If I hadn’t asked for help with my mistake, I would still be wondering what the heck I’d done.
• Avoid scheduling trips longer than two weeks. I find it difficult to do substantive writing on a long trip, especially one with many time zones, like this one. I also find it difficult to keep up with my normal reading and writing.
• I can take much less in my carry-on bag. I normally fly with enough reading material, snacks, and water to keep myself healthy on long trips. But carriers outside of the US, even on their domestic flights, seemed to provide healthy snacks and sufficient water. I will certainly check with each airline the next time.
• Look into rolling briefcases that weigh less than the one I have. I ran into trouble with some carriers who have carry-on weight allowances. Surprised me!
• Don’t plan on doing any work for the first couple of days back.

I normally give myself a day on either side of a trip to get ready and to recover. But when I change lots of time zones (more than three or four), I need more than one day to recover. I suspect I’m not the only one. I was talking with Andy Hunt this morning, who says it takes him about a week to recover. Actually, he said something like, “It takes me about a week for all the giblets to settle down into the right place,” or something equally colorful

I love to meet people in out other countries. I love the teaching and consulting. So I’ll keep traveling. But I’ll plan my returns and commitments a bit differently in the future. My guidelines might help you on a future trip. But what I hope you take away from this post is this: travel takes a toll on each of us. Don’t expecting someone who’s been traveling to think clearly when she returns from a trip. The longer the trip, the more time she’ll need to recover. And, for you big strong men, this applies to you too.

I was reading You Are Possibly Very Annoying and realized I hadn’t posted Esther’s and my six steps to effective feedback. (This is in the management book, starting publisher editing.) Here they are:

1. Make sure you’re giving feedback about the work or the working relationships. Especially avoid clothes and other personal appearance issues (unless they interfere with work), choice of romantic interest, religion, child-raising.
2. Gather specific examples of observed behavior or results. When you gather specific examples, you’re likely to say “The last three times you checked in code, this, this, and that, your code broke the build.” If you say “You always break the build,” all the other person needs is one example of a time he or she didn’t. There goes the conversations.
3. Determine the outcome you desire. Sometimes you want some joint problem solving. Sometimes, you want to explain a narrow band of acceptable behavior.
4. Deliver feedback privately. Unless other people are in danger, or the behavior is unacceptable for your culture, have a private conversation.
5. If you have some specific action or result you want, say it. If you’re open to a range of possible solutions, engage in joint problem solving.
6. Agree how you’ll follow up.

When Esther and I ran a Feedback Lab at AYE a few years ago, people loved the chance to practice. Take the chance to practice yourself. That way you (and I can avoid being possibly annoying.