Managing Product Development

The full title of this management myth is: “If I just do a great job, the organization will run like a well-oiled machine.”

Nothing like setting yourself up for failure, eh? Let’s unpack this myth.

First, organizations are made up of people. And, let’s assume that they all come to work wanting to do a good job. And that they’re capable of doing a good job. But things happen. Just this morning, the keyboard on my laptop stopped working. Now, there is a way to use a software keyboard and mouse-click on every letter you want to type. And I’m so patient, I can do that right? WRONG. So I spent my morning at the Apple store, where the geniuses (hey, that’s their title!) confirmed that yes, my keyboard was broken, and yes, they had one in stock, and yes, they could install it. So instead of my normal 3 hours or so of work this morning, I was lucky to use 20 minutes of useful work this morning. Things like this happen all the time. Usually to different people.

And it doesn’t have to be broken equipment. It could be a lousy commute, or the dog being sick, or a sinking feeling the milk in your cereal was not good enough to use this morning, but you did anyway. All of the things that make us human prevent us from running an organization like a well-oiled machine.

Another tip-off is that word “just.” Just is one of those lullaby words. (See Jerry’s article or the wikidiscussion. In fact, Dale Emery said it very well:

… lullaby words because they draw our attention away from important information about the complexity of the situation, while simultaneously suggesting that the situation is simple.

Being a great manager is hard. I find it much easier to write code or test. (But I enjoy the management more.) If we could “just” be great managers, some messy things will still happen. So don’t expect the organization to run like a well-oiled machine. Managers deal with people, who are not deterministic systems. But with great management, you can accomplish great things.

I remember when I became a manager, I wished that I could be injected with everything I needed to know. For the first few years, when I thought I should be omnipotent, I’d come home and whine (sorry, but that’s what I was doing) to Mark.

I finally realized that I needed training — even more than the technical staff did. And the reason I needed training was because I was making decisions (daily) that affected thousands of dollars of company investment. (Assume a technical-person day is roughly $500. It doesn’t take too many people and too many days before you’re dealing with many thousands of dollars of company investment.)

Managers need training. Sometimes, they need training in how to help projects. Some managers also act as PMs and they need project management training (which is different from being a sponsor or helping a project). Most managers need communications training, but not in how to be nice or assertive They need training like the coaching Ken gave a manager in Taking Your Group to Dinner. They need training in how to provide and ask for feedback. And in how to make the most of evaluations, even though most processes for evaluations stink. They need training in how to define and manage the portfolio of work. They need to learn how to ask for status and what to do with the information once they have it.

In my experience, once I coach people on how to ask for what they want, and how to use that information, they don’t need so much coaching on how to be nice or assertive, but some of us still have rough edges. I’m still working on my rough edges (and probably will be forever). But because I understand what I need and how to ask for it, I’m much better than I was.

I recently met someone who said that when he was a manager at a very large company, the company arranged for 2 weeks of management training each year. All the managers got together, had some training, and more importantly, talked with each other about their concerns and how to deal with them.

Management training doesn’t have to be formal. It can take the form of coaching. It can take the form of networking with other managers. (Esther and I are discussing how to facilitate some of those more casual conversations.) Maybe even reading a management book once a month and discussing it with an in-house book club might work. But if you’re not planning and implementing some form of management training each year, your managers aren’t growing enough to continue to be great managers.

According to Capers Jones, Barry Boehm, and Watts Humphrey, poor management is a leading cause of failed projects. I would go farther than that, and say that poor management is the leading cause of failed companies. And as we’ve seen recently in the press, that’s criminal.

So think about what you want for management training this year. Ok, a not-subtle-at-all plug: Esther and I think you should buy our book :-). But even if you don’t do that, make a plan for management training and implement it. You and your staff will be happier and more productive.

Too many technical managers think that if they assign people to good work and leave them alone, people will be happy. It’s true that people need challenging and interesting work. And it’s true that micromanagement or other interference is not helpful. But people, even the most introverted people, need a relationship with their manager in order to stay at the company.

Here’s why. An employee’s relationship with his/her manager colors an employee’s work experience. Great managers meet with their staff weekly or biweekly, and continue to build rapport, to learn about the people in their groups — their strengths,
weaknesses, desires, and pressures. The more knowledge a manager has, the more likely the manager can provide effective feedback and coaching, as well as help each person find work that fits for the person.

So, yes, management is at least partially about the work: about organizing the work, assigning people to the work (they may self-assign), and delivering results. But great managers know that they work with people. Great managers work on building a relationships, not just managing the work.

This one hooks me all the time. I certainly try to be my best at all times. And, when I’ve worked for companies, I want to make them the best, too. But here’s the sad truth: you don’t have to be the best. You just need to be better than your competition.

That said, how do you know if you’re better than your competition? That where data helps:

• How many customers are you acquiring?
• How many customers do you retain?
• How many of the strategically important projects do you complete with some degree of success?
• How long does it take you to complete those projects?

There are other metrics, but these help me start. Notice that a technical manager can’t directly affect the customer metrics, except with the completing of important work. That’s where knowing (or defining) your group’s mission is critical.

Here are some missions managers have explained to me:

• From a development manager: Provide for the care and feeding of the developers.
• From a test manager: Find the Big Bad Bugs before the customers do.
• From a test manager: Know the state of the system under test and be able to report on it at a moment’s notice.
• From a documentation manager: Reduce the number of calls to support by half.
• From a development manager: Ship the darn product.

Once a manager knows his/her mission, it’s possible to make reasonable decisions about what work to do and not do. The development manager whose mission is to “Ship the darn product” is not about to do the same amount of coaching that the development manager whose mission is to “Provide for the care and feeding of the developers.”

Missions that lead to illegal or unethical behavior aren’t reasonable. But any other mission that leads the company to a better situation than the current one is a reasonable mission. And if you don’t know your mission, you can’t help the company become the best.

Remember, it’s not about being the best. It’s about being operationally savvy so you can be better than your competition. That will help you be the best.

I’m crazy-busy with the finishing of Behind Closed Doors, so I’m starting another series of blog posts, this time about management myths. (When I’m in a series of posts, it’s easier for me to stay focused on writing a post every or every other day.)

I’ve worked with many managers and teams who think there is One Right Way to manage. Nope. There are as many ways to manage as there are managers and people to manage. But there are handful of practices that make sense:

• Learn what people are doing and learn where they are stuck.
• Provide feedback and coaching to reinforce great work and develop new capabilities.
• Prioritize the work and complete the strategically important work first.

We (Esther and I) recommend managers use one-on-one meetings and project portfolio management techniques to accomplish these goals. But every person in unique, and the best advice we have is to get to know your people so you can determine how to accomplish this.

Here’s an excerpt from the book’s preface:

If you don’t know what people are doing, you can’t organize the project portfolio. And if you can’t organize the project portfolio, you can’t know whether the work is being done well and on time, or if your group can take on more work, or if you need more people. You just don’t know. And that’s just not acceptable for a manager.

If you’re a manager, how adaptable are you? Can you manage each person individually and fairly, and still perform a manager’s work: deliver results and develop capacity? It’s hard. And necessary.

I’m in Israel this week, continuing an assessment I started last week. For those of you in the US, sit down. The people who have offices on an outside wall have windows that open. Yup, they do. The A/C and the heat know to shut off when the window is open. (I think they do, it seemed that way to me.) It’s a great way to regulate the freshness of the air, not just the temperature.

Esther just called me from the Orlando airport to tell me she heard a fascinating rumor: Supposedly, she and I aren’t talking! After I was done laughing out loud, we examined this a little.

We’ve facilitated sessions together at previous year’s STAR conferences, but I’ve been unable to attend last fall’s STAR and this spring’s STAR. So, Esther facilitated the sessions we’d previously done together with other people (with my enthusiastic agreement). I know that when I facilitate with other people, I learn from them, so my facilitation is richer after having practiced with others. I wasn’t worried about the other facilitators taking anything away from me; I hoped other people would enrich the problem-solving technique we taught.

Esther and I are colleagues and good friends. And our relationship (both professional and personal) doesn’t preclude us from entering into relationships with other people. For example, Esther’s working on a new book with Diana Larsen. I’m working on my PM book alone. Who knows what will happen after we write these books? We don’t know. And, I’m not worried. We will be honest with each other about how we work together in the future. (BTW, we’re planning to work together in the future. We’re starting to define the workshops we want to offer once Behind Closed Doors is released.)

Rumors get started when people notice something they don’t expect. People make meaning out of these small and large noticings. Those events can be managers closing the doors to their offices or a consultant missing a conference. If people don’t know why the event has occured, they will make some meaning out of the event.

Because people make meaning out of what they’ve noticed and don’t understand, we recommend that managers (and technical leads) ask for rumors on a regular basis. I’ve been doing this for many years (close to 20, I think), and have learned all kinds of things. Rumors help you hear what people are concerned about, and what meanings they make of it. People generally put the worst possible interpretation on what they notice.

I’m honored that at least one person noticed I wasn’t at the conference and was concerned enought to make meaning out of it. My absence from the conference was just a case of bad timing. But if you’re not asking for rumors on a regular basis, you’re allowing people to notice things that may seem out of the ordinary or threatening, and allowing them to make some meaning out of the “facts” that they see. People don’t know that they’re missing some vital piece of information; they will make meaning out of what they do see.

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.

In one of my classes earlier this week, one project manager explained that he spent an entire day each week working the Gantt chart in a scheduling tool. He has a project of roughly 20 developers, a few testers, and a few other people (I’ve forgotten the details).

I asked if he had one-on-ones with everyone every week, even just an informal checkin to see how things were going. No, he depends on his technical leads (4 or 5 of them) to do that. He then integrates everything into the humungous WBS.

That’s not my style. I’d much rather have a less detailed schedule in the scheduling tool (or hire some administrator kind of person to manage the WBS) and spend time with the people. When I spend time with the people on the project, they are less likely to stretch the truth about their real status. I can see demos or other visible progress. And, I’m much more likely to hear bad news early.

This fellow seems to be succeeding, but I don’t think spending a day a week on a WBS is a scalable idea. I prefer to do rolling wave planning and only plan for a few weeks at a time, and block out the rest of the schedule, and keep talking to the people. And, when I work for people who require a long detailed WBS, I hire a project administrator, who has a full-time job keeping the schedule.

My first choice (and second and third choice is to manage the project in a way that the WBS works for me, not the other way around. And I choose to work for the people on the project, not the schedule.

I’m in lovely Perth, Australia this weekend, staying with some friends of mine. The husband was explaining how he makes sure his department buys coffee, tea, milk, sugar for everyone in the department. “It costs us about $2000 to supply the department for a year. In return, people congregate around the coffee, discussing work. They feel as if the department cares for them as people.” Contrast that with a friend of mine whose company (in the US) who doesn’t supply coffee. “I make coffee, paying out of my own pocket. People used to come in when I was in a meeting, and sneak coffee from my supply. I finally had to go to a single-serving coffee maker.”

Here’s the scoop (sorry, pun intended). When companies make a reasonable effort to make the workplace easier to work in, their employees appreciate it. Coffee, tea, and water are the minimum requirements. Providing juice and soft drinks is nice, and can be quite expensive. And, when you stop providing it, people grumble. “The company is changed, they don’t love us anymore,” is a comment I heard at one client.

If you’re organizing a workplace, consider how people will drink their morning’s hot/cold drinks and where they will eat lunch. Companies who plan for a place where people can congregate to get coffee and eat their lunches will have the extra benefit of people continuing to work through lunch — but in a way that benefits the whole company’s productivity, not a single person’s.

When you provide a local (on every floor) coffee station (ok, for those of you in tea-drinking countries, a tea station), you’ve provided easy access to something people will spend time acquiring anyway. When you make it easy to get that cup of coffee or tea, you’ve reduced the non-working time. And, you might find that people talk about work at the coffee station. Sure, they’ll talk about sports too, but in my experience, the work conversations outnumber the sports conversations.

A cafeteria is even more important. When people have a place to eat together, they tend to discuss the funny things that happened on their projects, or the pieces of work that were challenging, or they’ll take the time to explain how something works to someone in another group. When I was a developer, I had lunch with other developers who told me about their gotcha’s. In one company where I was a tester, I always had lunch with the developers, who frequently told me something interesting that I could use for my testing work. When I was a project and people manager, other people would take me aside and let me know things they didn’t want to tell me in my office.

So, don’t let the price of tea and coffee and water prevent you from supplying it to your staff. And, if you can, create a lunchroom for people to congregate. You’ll find overall productivity goes up. Who wouldn’t want that?