Managing Product Development

I read RadioShack employees get pink slip via e-mail and at first thought I must have read it wrong. I was stunned to think that anyone would think an email notification of a layoff was acceptable. What were the managers thinking?

Since Esther and I started advertising our One-on-One workshop, I’ve been hearing wonderful stories about how managers and team members have benefited from one-on-one meetings. Here are some:

• A tester said he’d been ready to give notice when his manager started doing regular one-on-ones. WIth the advent of one-on-ones, his relationship with his manager changed. And, he started testing in a variety of ways–using techniques that helped him get a job on a project he enjoyed for a couple of years.
• A manager was “phoning it in” as he explained, not investing in himself or in his staff. He started doing one-on-ones and was re-energized.
• A developer who was doing well and had no complaints used one-on-ones to determine a career path with her manager so that she could do something new and the manager had a way to backfill her position.
• One manager who’s started using Scrum to manage his projects put starting one-on-ones in his timeline of important events at work. He’s found that he better understands what people are doing. They trust him more–and he trusts them more. He’s finding it a great complement to the iterative/incremental lifecycle.

One-on-ones work. If you want to practice doing them better, please join us in July. Here’s the One-on-One workshop link. If you want, call or email me.

A new-to-a-company manager explained this situation to me recently. She’d overheard something like this recently from one of her team members.

So you’re working in a place where it seems as if all the managers are Bozos. But you like the work and you like the people, and you know nothing lasts forever. After a couple years of insanity, all the managers change. And I do mean all, from the CEO down to the first level. Some of the people who were working to reverse the insanity were promoted, and a bunch of people are new, including your manager. But you’re no idiot; you know this manager’s as bad as the others.

This new-to-the-company manager asked how to get people to give her and her ideas a chance.

She’s talking about flipping the Bozo bit back to a neutral position. (In Behind Closed Doors, Esther and I talk about one variety of flipping the Bozo bit. There are as many varieties of Bozo bits as there are people

I know of only one way to flip the Bozo bit back to neutral: to have your team trust you. There are lots of ways to help your team learn to trust you:

• Make all decisions transparent. You’re still the manager; you’re in charge. But explain your rationale to your team about the decision.
• Consider using consensus or limited consensus to make more participative decisions so people have a say in the future of the team.
• Institute weekly one-on-ones with each person each week. If you spend 20 minutes a week privately with each person, you will get to know each person as a human being. During the one-on-ones, don’t be afraid to take action items and resolve them during the following week.
• Take action on the difficult people problems. Maybe you have a person who’s not pulling his or her weight on the team. Maybe someone else is impossible to work with. Deal with those problems now.
• Develop and maintain a project portfolio for the team, so everyone can see who’s working on what.

Flipping the Bozo Bit back to neutral is not impossible, but it will take a while. As people begin to become more comfortable with you and trust you, they will see you as a reasonable manager, not a Bozo.

Alan Weiss, author of Million Dollar Consulting, advises consultants to drop the bottom 10% of their work every year. That way you have to force yourself to grow and offer new (frequently more lucrative) offerings. The same advice applies to managers.

When I teach management, I explain that managers have three responsibilities:

1. To deliver results
2. To develop their people (so that the manager and the group can continue to deliver results)
3. Improve capacity of their organizations

Yes, it’s true that developing new capacity may feel close to impossible. But it’s just the barrier to entry of being a great manager. Great managers develop their people (winning their trust, building a team). And, great managers realize that when they develop people, they can improve the capacity of their organizations.

That capacity improvement is what allows you (and your group) to drop the bottom 10% of your work. Here’s an example of how I do this as part of my goals for projects. When I work with a project team that doesn’t have a lot of automated testing, I analyze the product and see where automated testing would help. Then I work with the project team to introduce the idea of automated smoke tests or regression tests for that part of the project. We make the tests project goals, not project requirements. We timebox and see how much progress we make. Then we replan, making sure we accomplish the project requirements, not just the goals.

What would you have to do to drop the bottom 10% of your work?

Recently, I gave a talk about useful practices–things to consider adopting/adapting in your organization. (I don’t believe in best practices, the idea that something could be best in all situations is just not credible. See UsefulPractices for more discussion.

One of the techniques I discussed was creating smoke tests for the build. We started discussing how to do that. It’s a web-based client-server system, with a data-dependent dynamically built client side. It’s not a trivial problem to create smoke tests (or any other automated tests).

But what I heard was fascinating. The organization is flat-out, trying to keep up with all the demands for new features, defect fixes, and responses to customers. The managers, each with at least 6-9 people, expect to participate in the coding. They’re smart enough to keep themselves off the critical path, so the projects don’t directly suffer from their continual multi-tasking. But what does suffer is the managers’ ability to strategically think about changing the work they do.

One of a manager’s jobs is to continually increase the capacity of the group he or she is managing. If everyone works the same way they’ve been working, the manager cannot increase capacity without hiring more people. It’s possible some groups don’t need an increase in capacity, but I haven’t met one yet. When managers are totally consumed with the day-to-day tactical work, they have no time to think strategically about their work and their group’s work.

I don’t know enough about this group’s product to know how to solve this problem of smoke tests. It’s possible that the problem is not worth the time or money it might take to completely solve it–but the managers don’t know that. They might not even need to completely solve it. Frequently, when dealing with difficult problems like this, a partial solution is good enough for some time. But the managers must take the time to think about how their groups perform their work.

Managers don’t have to know all the technical details of the work. They do need a deep understanding of how the people the perform work. But that understanding is not enough. Effective managers realize that things could change, and must take the time to think about what might make sense to change. That’s what I mean by strategic thinking, and why it’s necessary for anyone who leads people in work to know not just where the next step is (the tactical work), but to also consider the longer term steps (the strategic thinking). That’s the only way to increase the group’s capacity.

I met someone at the Software Development conference this week who told me he had too many people to meet with them all–even on a biweekly basis. I asked him how many people he managed. “30.” That’s not a typo; that’s the number between 29 and 31. I asked why he had so many people reporting directly to him. “My manager believes in flat organizations.” And how many people report to his manager? “4.” Sure, the manager can believe in flat organization; he’s got a reasonable number of direct reports.

I don’t have a recipe for the number of people you can manage. New, unseasoned managers can manage 3 or 4 people. More seasoned managers can easily manage 6 or 7 people. If you’re also the project manager–assigning work, making sure people make progress on the work, coordinating the work of multiple people, it’s possible to manage somewhere around 9-12 people. That’s hard, but possible. Of course, all you can do is manage; there’s no room for any kind of technical contribution once you’re past three people.

If you’re the functional manager and you assign people to projects with talented project managers, maybe you can manage 15-16 people. I’ve managed up to 15 people that way.

It’s not possible for one person to directly manage 30 people and still perform the management role for each person. I’m sure that there are informal technical leads in that group. But since those roles are informal, the communication issues must be extraordinary. I bet there are lots of people who aren’t getting the work done when they need to get it done, because the communication through one group of 30 people is too complex.

If you have lots of people, formally create sub-project managers or technical leads. Define their roles, including who will provide frequent feedback and coaching. And make sure your manager understands the consequences of choosing a flat organization: that you will be the bottleneck, that work will take longer, and that the most important management work will not get done–personal career development, feedback, and coaching. If you don’t create the leads or sub-project managers, there’s a good bet a bunch of project work won’t be done either, just because the coordination of effort among 30 people is a non-trivial effort.

Managers perform a valuable role in the organization, creating an environment in which people can deliver results. Organizations with a manager for every three people probably has too many managers. But an organization that averages over 12 people per manager probably has too few managers. When considering how many managers you need, consider how much feedback, coaching, hiring, and coordinating the manager needs to accomplish. Those considerations will help you decide how flat the organization needs to be.

I met a manager recently who relayed his technique for making sure his testers stayed focused on their jobs. “Our defect-tracking system logs people off after 30 minutes of idle time. If they’re logged off, I know they’re not working.”

This was a new one for me. I’ve heard of counting lines of code. I’ve heard of counting cars in the parking lot at 7pm. I’ve heard of counting number of defects found or fixed (depending on whether you’re a tester or developer). All of which are incredibly stupid measures. But this is the first time I heard a manager use a necessary tool to determine who was working.

I can think of lots of reasons a person might not be actively working in the tool. I played the bounce-back game with a developer many years ago (”it’s a defect”… “No it’s not” … “yes it is” … “No it’s not”…) until I finally decided that what the developer was really saying was “I can’t see the damn defect, so it’s up to you to make it obvious to me.” Took me 4 hours to create the simple test case (I’d already written up the complex test case). In that time, I referred to the defect on my screen, brought up other apps, made notes, tried a few things on my machine, done research in the lab, talked to a few people, and finally, 4 hours later, wrote the 5 steps into the defect report.

I was working the entire time. And if my manager had used licenses as a way to log me out, I’d have had to change context to get back to the defect I’d been working on before the system logged me out. I’m sure it would have taken me longer.

When I asked him why he allowed the system to log off the testers, he explained that they didn’t have enough licenses for all the developers and all the testers to have the defect tracking system open at all times. How much was a license? $1500. Each licenses costs 3 person-days. How many person-days do you think they’ve wasted because someone couldn’t get a license or someone was logged off? A prime example of being penny-wise and pound-foolish.

If you need to keep the costs of development down, use agile lifecycles, or at least agile techniques. If the developers test code before they check code in, you might not even need a defect-tracking system. (Index cards will do.) But don’t keep the cost of development down by not providing all your technical staff with the tools they need. One manager’s salary (and there’s almost always a surfeit of managers in organizations like this) will pay for all the tools you need.

To track work, track completed, deliverable work (features/requirements implemented, tested, built, and able to be delivered to a customer). There is no other substitute.

I’ve been watching, reading, and listening to the Katrina coverage over the past week. And the one thing that stands out for me is my perception that there was a lack of disaster planning.

I’m not going to play the blame game–there’s plenty to go around. But here are the questions I would have assumed the managers in charge of planning would have asked:

• What’s likely occurrence? After a hurricane, we can plan on no electricity, which means impaired communications, no air conditioning, people needing to use generators, and at some point, a lack of water. How long is this likely occurrence going to happen?
• What’s an unlikely, but not out-of-the-realm-of-possibility occurrence? This is where I’d assume the electricity would be out for several days, maybe a week. Remember, all of our systems need electricity to continue to run.
• What would be a disastrous occurrence? This is the flooding scenario, where pumping out the water is impossible until after the levees are fixed.

The value a manager brings to a project or to an organization is planning the work and preparing for risks. Risk management is not a one-time planning event, but starts with planning (risk discovery) and continues as the project and/or the organization continues.

The one conclusion I’m drawing is that too few people performed risk discovery and developed mitigation plans. Don’t let that happen to your project or organization. You don’t have to be paralyzed by risks, but the more aware you are of the potential risks and the more you plan for dealing with those risks, the better off your project or organization will be.

I don’t know how many managers tend to be extraverts (in the Meyers-Briggs sense of the word), but I suspect more managers tend to be more extraverted than introverted. If you’re not sure which one you are, ask yourself this question: Do you need to speak in order to think (extravert) or to think before you speak (introvert)? If you’re the kind of person who says, “Let talk it out,” chances are good you’re an extravert. If you’re the kind of person who wants to think about a problem before discussing it, you’re probably an introvert. YMMV.

Especially for less technical managers (see Management Myth #6), it’s easy to confuse speaking ability with competence. But facility with language does not reflect technical ability.

As a manager, you will have to judge how well people are doing, and you may have to evaluate them. Your weekly one-on-ones will help you judge how well a person is doing, where you look for data, not just conversation about status. You can provide feedback (and we recommend that you appreciate something every week). If a person needs coaching, you can coach in your one-on-ones. (The evaluation part will be those dreaded yearly reviews. Blech.)

Don’t let someone’s ability to speak well confuse your judgment of their technical abilities. (And if you’re not a technical manager, learn the product and how the product is created so you can have reasonable conversations about how your staff is working.) Listen to what people say in your one-on-ones. See what they accomplish and when. See when they are stuck. Use this kind of data to determine how well a person is succeeding. Then you’ll know if all they have is hot air, or if they are competent.

Technical people and their managers get caught in this myth all the time. And there’s a good reason for it. For the first few years of a technical person’s career — in fact until the person moves into management — each technical person is evaluated on their technical skills. When a star technical person moves into management, many people find it difficult to change their perspective of how they provide value to the organization. It’s not just a perception problem for the manager; sometimes it’s a problem for the technical staff.

I started a new job at the Director level in a relatively young startup. I was supposed to raise the general technical level of the testers and initiate a true Quality Assurance group. When I started, there were three testers, two of whom were highly technical. One of the technical testers was also supposed to be the test manager. He was fine as a manager with two other people, because he could still do some technical work. And the other two people were self-directed. But as his group grew to 5 and then 6 people, he stopped being able to perform the management work.

I gave him feedback and coached him. He decided he didn’t want to be a manager. That was fine, and we defined a transition for him to Test Architect, a role he was perfect for. About a month later, we met because he had a “serious” problem to discuss. He asked me a detailed implementation question that I couldn’t answer. In fact, no one he’d asked had yet been able to answer. I suggested some places to read the code and one other person to talk to. My architect told me I wasn’t doing my job. I was stunned. I asked what he thought my job was. According to him, the manager (at whatever level) should be the technical star.

I was relieved and dismayed. Relieved because I knew I could discuss this with him. Dismayed because I was sure I couldn’t change his mind, at least not for a few years. After we spoke for a while, I asked him if he thought he was supposed to be the technical star when he was a manager. He said yes, that’s what he had been trying to do.

It’s not possible to be a technical star and be an effective manager of more than 3 people. (Esther and I have a sidebar in the book about why that is.) I’m not sure it’s possible to be a technical star and manage three people, but I’ll admit that if you’re already intimately familiar with the system and the people are self-managing, you’ve got at least a shot.

I wish I could tell you precisely how technical a manager has to be. (I have an it depends answer for project managers.) But each organization is different, and each group of people is different. I do believe a manager of technical people needs to know at least:

• The dynamics of how people perform their work
• Enough about the internals of the system (the architecture) and enough about the problems the system is attempting to solve so that the manager can make good management decisions
• How to determine where the opportunities and black holes (that suck up all available resources) are, and how to tell the difference

There’s a lot of gray area there.

If you’re a manager of technical people and you’re not technical, try these guidelines:

• Know your knowledge boundaries, and especially what you don’t know.
• Don’t pretend to be more technical than you are.
• Focus on the management, especially the project portfolio management.
• Decide how you’re going to learn enough technical detail.

Once you become a manager, the technical work is ripe for delegation. Focus on the management, and delegate the hands-on technical work. Become a management star, not a technical star.