Managing Product Development

The December Harvard Business Review has an article, Is the Rookie Ready? (You have to subscribe and pay to read the whole thing.) The story is this: Kristen is the new project manager, reporting to Tim. The old PM left because Tim, who’d been her manager for 6 months didn’t know how to work with her. Tim hears from an old customer two weeks before Christmas, “Please help us and send a team down to install your software, the stuff we rejected a year ago because it was too expensive. Oh, and we need it by Jan 1.”

Tim agrees (Big Red Flag here). He asks Kristen to go install and make the standard software work (no customizations) and to take whomever she needs. Kristen doesn’t think this is a such a good idea, but Tim tells her it’s her job to make it happen. He tells her to tell the team ‘we’re going to do this.’

The question to the famous commentators is, “Is the Rookie Ready?”

Wrong question. Michael Schrage suggests hiring back the old PM. But, then he says “Kristen is in over her head.”  NO. KRISTEN IS NOT IN OVER HER HEAD. TIM IS A TERRIBLE MANAGER. We can’t tell if Kristen is in over her head.

Sorry for yelling, but I just couldn’t take it. (You should have heard me while I was reading the article :-) Anyone would be in over his or her head, because the only way to solve this problem is to have someone intimate with the product install it. Even then, this is a 6-week project. Why would Tim agree to a 2-week install? Sure, the customer wants it. Customers want all kinds of things. They can’t always get what they want, when they want, for the price they want.

Tim is a terrible manager, because he keeps taking the best programmers and making them managers (part of the story I didn’t summarize). If they want to be managers, that’s fine. But it’s not clear Kristen wants to be a manager. And, he doesn’t even push back on the customer. And, Tim has allowed a standard product without a standard install.  (Ok, it’s a big product. Maybe a standard, unattended install isn’t possible. Maybe it really does need 6 weeks to install. So, why isn’t there an install group that does this??)

Why would Tim agree to do a special install over the holidays without asking for more money? Why would Tim even think this is acceptable to do without asking the team who will do it? Because Tim isn’t the one giving up his vacation. The fact that he even thinks this is acceptable behavior just astonishes me.

It’s time to ask if this project is strategic to the company. (Where are all the other managers? Why is Tim getting this call? HBR, I can write a more realistic story than this.) Maybe this is not even a project to take on.

If they’d asked me to comment on this story, here’s what I would suggest:

1. Decide if the project is strategic to the organization. Why has the customer changed their mind on what’s too expensive? What is an acceptable fee for doing this project in their time frame?
2. At the same time, before committing anything to the customer, ask the team if they are willing to make this happen in the requested time frame. If not, what is an acceptable time frame? Would that time frame change if they had the experienced project manager back? What would make the time frame decrease?
3. If the project is strategically important, and the team is ready to commit to something, negotiate that with the customer. Never assume it’s fine to commit your team to work they haven’t committed to.
4. Organize timeboxes of work starting now and through the final deliverable, so there is transparency about the project’s progress. If the project falters, you still have the option of getting the experienced PM back and see if that makes a difference.

Tim is creating management debt by making bad decisions. He’s not managing the project portfolio–what other projects are now crises? He’s not managing the people. He’s certainly not building a trusting relationship with his people. What the heck is he doing?

I’m so worked up about this because I worked for a jerk like this once. He committed all kinds of deliverables on behalf of my project to the customer. Half the time, he didn’t even tell me. He never once thought what was good for the organization or even the customer.

Managers like Tim kill an organization. They create management debt by not managing people correctly, by not managing the project portfolio correctly, and by not managing the customer correctly.

The question is not whether the rookie is ready. As Paul Muller, one of the experts who commented said, “Every manager has a first crisis, whether it’s three days or three years after assuming the role.”

The question is not “Is the rookie ready?” The question is why is Tim employed at the organization? Why has no one seen the messes he has made?

Tweet This Post

Dave and Bob have great comments on my post, Might Three Backlogs Be Better Than One?. Dave is describing situations where management is making reasonable decisions, not incurring management debt, and by extension, technical debt. Bob and I have experience with significant management debt. (Take a look at Musings About Management Debt for more information about what I mean by management debt.)

Let me provide a little more perspective on these situations. The clients range from large systems of up to a million lines of code (but still software-in-the-small) to software-in-the-large systems of 14, 15, 16 million lines of code. These systems have been in existence for more than 5 or 6 years. They are the flagship, and sometimes only, product that creates revenue. In each case, management is fairly new. The product owner players are new. Many of the technical people are new.

No one knows enough to make good decisions. Yes, they should have one backlog, and they don’t know how to prune the defect list. When you’re talking about more than a few thousand defects, the number is just too big. When your builds take longer than one day, when you have no automated tests, when you’re using a configuration management system from the ’70s (ok, not quite that bad, but close), and you don’t know how to break down the work into small chunks, it’s all overwhelming. Oh, and don’t forget the customers breathing down your neck for not just the defects you need to fix yesterday, but the features the sales people promised tomorrow.

One VP told me he could not make the decisions. He was concerned about who he needed (“do I need all of Engineering??”) and the time to rank into one backlog (“We’ll be here all day and we won’t be able to trade off against features and defects”).

He’s inherited a situation not of his making. He knows that if he can get people to start working in an agile way, they could make progress and finish some work. That would make their decision-making easier. But he has no roadmaps for feature sets for the product to see into the short-term or long-term future. He doesn’t know how many of the 1000’s of defects are still valid. (He thinks more than he wants.) Everybody is nervous. No one feels as if he or she can make a decision alone. The notion of a product owner as a “single, wringable neck” (do I credit Mike Dwyer or someone else with that phrase?) is not something they are ready for. They wanted a committee. I did manage to talk them into a committee of 2: one technical person and one marketing person. That technical person is the erstwhile project manager and the marketing person is talking himself into being a product owner.

I don’t claim these folks are agile. I don’t think they would either. They are working in timeboxed iterations. They are trying to finish valuable chunks of work in those timeboxes. They are struggling with how to make their decisions.

One thing I know about decisions is that the smaller the decision, the easier it is to make it. When you have to make tons of decisions that last forever, it’s really difficult, especially if you think you don’t know enough. At first, they all thought their technical debt was too huge to make inroads. But when I explained how to break down their technical debt into user stories, and that they didn’t have to tackle everything at once, that if they could just get the build to take less than a day they would already be ahead of the game. They didn’t need to stop developing features or fixing problems to address their technical debt.

As we see more people who have used a phased approach to development for years, and have not had tremendous success move to agile approaches, we will see people who may not be ready for real agile, but are ready (desperate?) to try something else that will provide value. We need to help them move from their previous insufficient decision-making to decision-making that will work. I do like baby steps. (See  Small Steps Are Good; Be Careful What You Call Those Steps).

I do worry about the issue of three backlogs. In the face of no decisions, I still think it’s better to make some decisions even if the outcome of those decisions is not one backog. Maybe other people have had better results nudging decision-free organizations to decisions faster than I have. I do think that the visibility of the different kinds of work can help people out of their defeatist attitude of “We have so much to do, we can never finish it.” One of these clients is actually pruning their defect list this week. The reason they can do that is because they took one story off the technical debt list, finished it, made so much more progress in just two weeks that the person-who-might-be-called-the-product-owner-but-is-resisting-the-role asked if they could finish a few defects in the next iteration, and how many did they really have anyway? They have bought themselves room to breathe.

Agile–real agile–is about making decisions based on business value, and delivering valuable chunks of work in a small timebox. If you have an organization that can’t decide on business value, you are in trouble. If you have better ideas, I’d love to hear them.

Tweet This Post

I’m editing the project portfolio book. Yes, I’m trying to get ready for beta. No, I have no idea when I will be ready. I’ll have more information before Wednesday, if you want to know.

I realized that when managers don’t make ranking decisions about the project portfolio, when they don’t fully commit to a project, when they don’t collaborate across the organization to make sure everyone is working for the good of the organization, the managers incur management debt. And, these actions all create technical debt.

I suspect that these managers don’t know they are supposed to do these things–they’ve never seen good management before.

You can see management debt in these ways:

• Managers revisit decisions again and again and again and again…
• People stay blocked on problems because they need management input
• No one removes obstacles for the team
• Many emergency projects
• Everyone feels as if they are slogging through the day, even though managers are rushing around like crazy, using their smart phones and pagers and email.

What do you think? Do you like the term management debt? Did I miss any other symptoms of management debt (I’m sure I did!)?

Tweet This Post