Managing Product Development

Last week, when I was on vacation, my most recent Stickyminds column went up. I somehow expected more comments. Maybe other people were on vacation, too?

Tweet This Post

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

I’ve been working with several management teams recently. They realize they need to change how they are organized in order to really make the agile teams even more productive.

For example, what good is a functional manager? If functional managers don’t need to assign tasks and check on how the work is going (the team does this), the functional manager needs to build a trusting relationship with people, and provide career development. The manager sets the mission/purpose of the group. The manager needs to see when the team (or teams) need more people, and to start and lead the hiring process. The functional manager may act in what I think a technical lead role is: to help uncover other ways of working, whether that is specifics (extend the design this way, test that way) or to coach the person into recognizing where to look for help. And, the big decision that managers make: which project to work on now. (Of course, there is also strategic planning, customer visits, etc.)

Project managers/Scrum Masters/whomever is charged with protecting the team’s process can’t do this work. Managers need to do this management work. But should there be development and test managers anymore? I think not.

Now, I can’t tell if my background is coloring my opinion here (of course it is, JR!). I was a development manager and a test manager at the first and mid-levels. I ran several departments, both in product companies and in IT. When I was a manager, first of development, we didn’t have professional testers. We did our own testing. We were ok at it, because we tested each other’s pieces of the product. As a test manager, I knew what the developers were going through, because I’d been a developer and a development manager. And, because I focused the test group on discovering more information (that’s the mission/purpose thing at work), the testers’ information became ever-more-valuable to the developers. I was a better manager because I understood what was going on between development and testing. By that time, I also understood the writers, even though I had not been a writer or managed writers. When I managed an entire engineering group of 80 or so people, I found that the bulk of my work was helping the functional managers understand the pressures on the other managers so they could work in a way that made sense for the entire organization.

In a technical agile organization, everyone is organized into cross-functional teams who deliver working chunks of functionality every few weeks. If the teams don’t have specialists, why should the managers be specialists? Isn’t that an outmoded way of thinking?

I should explain that Mary Poppendieck probably disagrees with me. We were talking about the role of the matrixed functional manager on an agile team while we were in Vancouver at Much Ado About Agile. I’ve been thinking since then, and working with my clients. I still disagree that the functional manager needs to provide specific-to-the-function technical leadership. I agree that coaching is necessary, but that doesn’t require a test manager for testers or a development manager for developers. It requires a true manager who can coach and help find the answers.

If we are asking the technical staff to be better at a wider variety of tasks, we need to ask managers the same thing.

Tweet This Post

I recently wrote an article on how to say No, and a twitter follower wanted to know what to do when your manager can’t hear no.

First, understand why your manager can’t hear no.

1. Is it because the business pressures are so great that the cost of saying no seems insurmountable? Managers are people too, and if the cost seems overwhelming, it may be that your manager can’t see how to make small steps that ease the problem.
2. Is it because your manager only thinks you and he/she are working when emergencies exist? If your work is invisible, use the project portfolio to make it visible.
3. Is it because no one else says no? Other people may not know how. You might be the first.
4. Is it because he/she does not believe you? Oh boy.

Once you understand why a manager can’t hear no, you can choose how to act. For the first three reasons, your manager may not know about how to or is not willing to manage the project portfolio. In that case, you can manage your project portfolio.

Gather all your work into your project portfolio. Break your tasks into small chunks, so you can complete something in a morning or an afternoon. If you finish some task, can you get to a wait state on that project, waiting for others to get back to you?

If so, you can repeat, ranking and reranking as you proceed. It’s better to have a one-on-one with your manager and make sure you are working on the most important work. If your manager cannot help you rank, don’t worry. Show your manager that it’s possible to make a decision, make some progress, and then re-evaluate that decision based on more data.

If your manager doesn’t believe you, you may have a different problem. Is it a case of Queen of Denial, or is it something more basic, such as lack of trust? If it’s the schedule game, eventually your manager will encounter reality. If it’s lack of trust, that’s another whole problem and another blog post.

Most managers can’t hear no if they literally cannot imagine how to work themselves out from under the pile of work. Show them.

Tweet This Post

I’m a member of a panel Jul 23 for the Boston Agile Bazaar meeting, and am attempting to articulate my two-minute position statement to the question:

How would you characterize your approach to handling people problems on agile teams?

My problem is that I don’t do anything any differently for agile or non-agile teams. I still provide feedback. I still offer coaching. I coach or teach how to give feedback and coach. I sometimes offer mentoring, if that’s appropriate and requested. I still help people break their tasks into smaller chunks (new-to-agile people tend to have a lot of problems with that, unless they are practiced at inch-pebbles). I still help people see the process and ask whether they are using the process to their advantage. To me, it doesn’t matter what lifecycle people use, I do similar things, although the process is different.

So, what’s different about agile teams and the people issues? For me, it’s the transparency. People can hide in a serial lifecycle. There’s less hiding in other lifecycles, but only in agile do you get the transparency that helps everyone see what the people issues are.

At the team level, the daily standups, burnups, burndowns, and cumulative flow diagrams all show you if there’s a person-problem, an interpersonal problem, a  team-problem, or a project problem.

Agile doesn’t just show project-level problems; it’s also exposes management problems.

• Emergency projects could be a sign of insufficient project portfolio management, as well as technical debt (what does done mean?).
• Not knowing which project to devote your energies to is a lack of strategic direction or a lack of project portfolio management. It shows up in projects as many unrelated tasks on cards, or just plain interruptions.
• Teams with obstacles that they can’t remove because the obstacle is imposed by management, or the furniture police, or corporate policy is a management problem. Don’t kid yourself–this is a people problem.
• Teams that never quite have enough people–and there are open reqs–have a management problem that is a person-problem.

Management problems are people problems. I work in the realm of management problems. Most managers don’t know what they need to do: decide which products to deliver when;  take the lead on strategic planning, manage the project portfolio, create an environment in which people can do their best job, and take the  lead on hiring. This is hard work. And, if you’re accustomed to command-and-control, you may not have done these things before. At the very least, you did them differently than you need to do them now.

I’d love your comments: is this coherent to you? Does it make sense? Did I leave anything out that you’ve heard me say/write before? Thank you.

Tweet This Post

In the Small Steps and Plunge In posts, I said projects should transition to agile all the way. But does it work the same way for the entire organization?

Nope. I recommend a gradual approach to moving to agile. Not all project teams are ready for the self-discipline agile requires. But, even more importantly, too often management is not ready for the discipline agile requires.

Agile requires the discipline to move projects through teams. Multitasking is nuts in agile. Moving team members around to have the “best” specialist available for a particular team is nuts. Performance reviews for individuals is nuts. Managers have to change everything they do, if they want to move the organization to agile. Managers need to see the problems exposed by any given project’s transition to agile and work to remove those obstacles before transitioning to agile.

Transitioning to agile often means also looking at lean approaches to management. Many managers are unable or unwilling to do that.

Managers, dip your toe into agile. That means committing to agile for a team or a project. I hope it means committing to a lean and agile approach to managing the project portfolio. And, it means that all of your systems are ripe for change. If you don’t have performance reviews, what do the HR people do?? (Plenty!) If you take an agile or lean approach to procurement, how does that affect purchasing? Accounts payable and receivable?

Moving to agile for the entire organization is a non-trivial problem. The zeroth step is the project. The first step is the project portfolio. Then comes the really hard work: the human systems are the next step. Once you’ve moved the human systems back to helping the employees, now you can attack the money systems. (One of my clients is trying to do the money systems first, and that’s not working. There may be some give-and-take here, with the money and human systems.)

Managers, it’s ok to dip your toe into agile for the management systems, as long as you take a coherent piece and commit to agile or lean for that piece. It’s not ok to dip your toe for a given project–commit to agile for a project, if that’s right for you. And, commit to learning about agile and lean management.

Tweet This Post

I’ve discussed this situation with several managers recently. The manager says, “I have a wonderful developer, who can code circles around everyone else. If he doesn’t like someone else’s code, he rewrites it over the weekend. If he sees a hole, he writes a ton of code over the weekend He starts work early and works late. But, I have a tiny little problem. I can’t keep people who might be just as good. I can keep people who are not as talented, but can’t retain people who are not quite as good. But that’s ok, isn’t it? After all, don’t I have the most productive employee?”

Let’s review what productive means for software. It means the most number of features per unit time per team. Personal productivity is meaningless. Keeping everyone busy is meaningless. But having one employee who is a bottleneck, or one employee who prevents a team from increasing their overall capacity (running tested features per unit time), that’s a problem.

One manager who had this problem has a bottleneck employee, one who prevents other people from doing their work, by interrupting others from finishing their work. (See Retrain Your Code Czar for an article I wrote about this a number of years ago.) Bottleneck employees are frustrating to the rest of the team and prevent everyone from accomplishing work–except the work they want to accomplish.

Another manager has the problem of one person bringing down the expertise of the entire group by being an indispensable employee. Indispensable employees prevent other people from learning because they take care of things for other people. Other smart people don’t want to work with the indispensable employee because they don’t get the challenge of solving the problem themselves.  Indispensable employees are quite dangerous to the longterm health and success of your group.

If you are faced with one really productive employee and some not-so-hot folks, reexamine your situation. Do you have a bottleneck or an indispensable employee? If so, fix the situation. They are not helping you.

Tweet This Post

I was talking with a new manager recently, and she was explaining what she had to tell a new employee (a co-op, but an employee). “I told him he had to be here by 9am every day he works. He can eat lunch from 12 to 1, and then he should be back at his desk. I then told him if he ran out of work, he should talk to me, and that he could leave between 5:30 and 6:00.”

We were chuckling, and I told her the story of one of the first co-ops I hired. I had to tell him to brush his teeth, take a shower every day, wear different clothes every day, and make sure to use deodorant. After he got into the rhythm of work, about a month later, he thanked me. I was curious, and asked why he’d been so unaware all these years before this job. He said, “Well, I was smart enough to coast by on my brains. But all the work I did, I did from my room. I never had to see anyone or work with anyone before. This is a huge difference for me. And, my social life is improving!”

I’ve had a number of funny-strange conversations, and many of them are about feedback. If you have to give someone feedback about body odor or halitosis, remember how:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using “I” language.
• Make a request for changed behavior.

Take a look at With Feedback, It’s Kind to be Firm for an example. As long as we have geeky people in high tech, managers will have to have these conversations. Make them helpful conversations, and you’ll have an employee that’s loyal to you forever.

Tweet This Post

Both David Maister, in Compensation Systems, and George Dinwiddie, in Agile Compensation, have useful comments about compensation systems. There’s something implicit in both pieces, that the criteria to move from position to position (as well as from one salary to another) have to be explicit. For years, I called this expertise criteria.

You develop expertise criteria by defining what’s critical about a position. If you’ve done a hiring strategy and a job analysis for each level of the jobs that report to you, you can develop expertise criteria. Take your 5-7 essential skills (most of these are non-technical), and rank them across the top of a table. Do NOT include number of years of experience or the educational level. Those two things are for HR, not for promoting or compensating people.

Down the side, list the levels. If you have developers and testers, and they similar essential skills (likely in an Agile team), list the levels of developers and testers together. That is developer level 1 and tester level1 are on the same line. Now fill in the matrix. (I know, this is hard work.)

When I did this for my engineering group many years ago, these were the essential skills across the top: Technical knowledge and methods, Initiative, Independence, Responsibility/Judgment, Scope, Complexity. Down the side, I listed positions from associate engineer, engineer, senior engineer, principal engineer/manager, consulting engineer/group manager, senior consulting engineer, director, vp.

I found it relatively easy to fill in the matrix for the first 4 levels. It was much harder for the last 3 levels. But without expertise criteria, I don’t see how you can have an entire conversation about compensation. You get stuck in “did you do this practice” as in George’s post, rather than “did you better the project or the organization?” (George argues against the “did you do this practice” thinking.)

For me, the expertise criteria gives a level of transparency that I think David Maister is trying to get to, but doesn’t actually say. (He does say the system needs to be fair.)

Many of my clients do not have expertise criteria charts. If you’re a manager, consider making one just for your group, and see if your performance evaluations and compensation discussions are easier. I bet they will be.

Links you might want to read:

Hiring Strategy #1: More People for Similar Work. (There are 7 hiring strategy posts. I will categorize all of them at some point.) Avoid Shot-in-the-Dark Job Analysis. There are more job analysis posts. I gotta get to this categorization :-)

Tweet This Post

Bob Sutton has an intriguing post, A Surprising Study of Infant Mortality Rates: Evidence-Based Management Meets Evidence Medicine. One of the surprising conclusions:

One kind of collaboration was linked to higher mortality rates. When front-line employees became more involved in unit governance — doing things like being involved in decisions about who was hired and fired, the creation of new positions, scheduling, and budget allocation decisions – mortality rates WENT UP.
[...]
I would also speculate that the staff who were involved in those decisions might have been distracted from their jobs – taking care of sick little babies – and that in some cases (although they were given lots of information) they may have been given a greater voice in decisions that they lacked expertise about.

It’s critical to consider where and how people collaborate. I bet some of those folks were not interested in budget allocation, especially if budgeting in hospitals is the sham it is in many of the organizations I work with. (The senior managers have already determined the budget. Why do they make managers do more work??)

I don’t know the answer to how much collaboration is the right amount. If the collaboration is about how we as a group work together, what work we do, how do we know when we’re done–that’s all ripe for collaboration. Even for hiring, the team needs to be involved in the interviewing and in the hire/don’t hire decision, but not necessarily about the hiring strategy or the planning, offer, or first day parts. If it’s about paperwork, get someone else to do it. It really depends on who makes the decision.

If the decision is already made, don’t involve the team. If the team can’t influence the decision, don’t involve the team.  But if the team can influence or make the decisions, and the decisions affect how they do their work, then that decision is likely ripe for collaboration.

It’s certainly worth thinking about.

Tweet This Post