Managing Product Development

I’m still catching up on posting links where either I or other people had aha moments:

TMI’s One-on-Ones discusses a bunch of things about one-on-ones, something Esther and I have been talking about forever (as well as in Behind Closed Doors.)

David Carlton explains how he adapted one-on-ones. (For the record, I love it when people say they adapt my suggestions to make it fit for them. I caught up with David earlier this month when I was at SD West, and he explained in person how he’d adapted them. I was thrilled then and thrilled now.)

Arnon talks about sticky planning vs project scheduling tools in Sticky notes vs. the computer. I have to admit, I don’t think I’ve ever explicitly said,  that sticky notes provide you “constant visibility.” (Arnon’s quote.) I wish I had. Maybe in the next edition of Manage It!

I’ve written before about getting organized, especially when it comes to cleaning up my office. My breakthrough came the last time, when I realized I’m the kind of person who needs to see everything out that I’m working on. Same with my to-do list. (See
Cleaning Up the Office, Round 3.)

I use paper for my to-do list. I need to see the whole thing, so I can make those small priority changes throughout the day or the week. I don’t use software (although, when OmniFocus is available, I might try that). Paper works for me.

I’m coaching a manager who was organized as a technical person–he knew what he had to do, he knew when he had to do it, and he got everything done. He became a manager, and started floundering after about a year. He was still getting things done, but the personal cost was too high–too many hours at work, too much stress. As a manager, the number of tasks he had to track was higher and broader than as a technical contributor.

A manager’s work is different than a technical person. A manager’s span of influence is much broader, so managers tend to have more (smaller) tasks, especially tasks that move across the organization. For me, and for my colleague, that requires a different set of organizing skills.

Once you’re managing several people, you need a low-level project portfolio. See Courage Required. That way you can see what everyone is working on, and resolve any context-switching (so technical people get their work done more quickly). You’ll need one-on-ones to check in with folks on a regular basis, so you know if their work is at risk. These two organizing “tools” allow you to see all the work people are doing, so you know if you need to change what you’re doing.

Don’t think you can manage the management tasks with a project scheduling tool–that’s the wrong tool for disparate tasks of varying sizes with no interdependencies except for you. As with any system, first decide how you need to organize and manage the tasks manually, and then you can see if an electronic tool will help.

If you’re a manager, acknowledge that your list of things to do is different and allow yourself to see how you need to manage it differently than you managed your list when you were not a manager.

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.

Via Keith’s A Few Good Posts by Ed Gibbs, I read Better Feedback Loops With One on Ones. Sounds like one-on-ones are helping Ed and his team.

Last week, I had dinner with a manager (also using Scrum) who has had great results with one-on-ones. It’s always nice to hear positive news about a technique that has brought me great results.

But I’m having a conversation with a manager who’s not having great results with one-on-ones. If I can understand more about why, I’ll post those problems and what happened. Could take a while.

For information on one-on-ones, see Use One-on-One Meetings to See People’s State. Esther and I are planning a workshop the week of July 10, 2006 to help managers learn how to do one-on-ones and other techniques. Stay tuned for real information in a week or so.

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.

In his comment, Rich explains, “I am directly managing 12 employees and 14 contractors doing application support and maintenance for something like 12 or 15 software products. I have most of my old team, and 6 other teams. I have been asked to develop a plan to cross train these individuals to build out a mega-support team.” He goes on to say, “Most of my staff are the “do-ers” hard-working salt-of-the-earth analysts but not interested in or obviously capable of leadership.”

The first action I would take is to ask each person in a one-on-one if he or she wants to take on technical leadership in an area (or two). Maybe Rich has already done that (since he left his comment a couple of weeks ago before I was caught up). He could be pleasantly surprised. One thing I’ve learned: don’t assume you know what people want to do with their careers. Each of his people could be waiting to be asked to take on more responsibility. And, before any of us slam people for waiting to be asked, remember, there are many organizations where sticking your head and asking for more work/different work is a great way to have no work.

Some of you are saying, “26 one-on-one’s! How the heck is he going to do that?” Not easily. I’d start with the employees, and see where I was. If none of the employees want lead positions, I’d move to the contractors and see if any of them want an employee position as a lead. If not, I would sit down with my current org chart and say, “What do I really need?” (The strategy chapter in the Hiring the Best… book talks about how to do this.) But remember, if we can assume all of these folks are performing well at the individual contributor level, it’s easier (and more effective and cheaper) to move them around a little, rather than hire more managers who don’t know the products. (It’s incredibly difficult to hire technical leads who need to be trained by their staff. Ouch.)

In conjunction with the one-on-ones, I’d also spend time with my boss and make sure I know what my boss wants out of the group. There may be service level agreements, there may be other demands for time-based response. I’d also make sure I have to support all the products Rich talks about. Sometimes, organizations want to keep supporting products when it makes no sense to do so.

So, Rich’s first actions are: understand what all the work is, and understand what people want to do. I suspect he knows what to do once he has the answers to those questions. But, he’ll want to make sure he doesn’t end up in a position like this again, which is why this blog entry talks about coaching and succession planning. As part of his new role, Rich has to groom a few people to take over his job eventually. Depending on his ambition and the company’s growth, that could be sooner rather than later. I’ll deal with coaching and succession planning in my next blog entries.

Last week at the Software Development conference, I met a software director. His group, a total of about 30-40 people (I’ve forgotten the exact number) is responsible for all the software his company produces. He has two managers managing those folks. He’s busy, so although he requests that his managers have one-on-ones with their staff, he doesn’t keep his one-on-ones with his two managers.

After my lessons learned presentation, he came up to me and told me I was right, that one-on-ones are necessary. And now that he’s canceled his one-on-ones with his managers so often, they ignore the times he thinks he’s set aside for their one-on-ones. Since this was Thursday, the last day of the conference, I asked him if he was going to have one-on-ones on Friday when he went back to work. He sighed and said that since he was off for a two-week trip to Asia, he’d wanted to stay home and take care of his life for a day. Can’t say I blame him.

However, he’s noticed a problem in his department. This director’s managers no longer trust him to have one-on-ones. They don’t even bother to come to his office when it is one-on-one time. The directors is allowing his managers to run open-loop, without feedback on their decisions or performance. The director doesn’t know anything about the value of his managers’ work. And when it comes time for performance evaluations, the director and the managers may all be surprised if the director is unhappy with some aspect of their work.

Managers leverage the work of other people. When managers make mistakes, the mistakes are magnified through the other people’s work. The answer isn’t to make fewer decisions, but to obtain more feedback on those decisions. If you manage managers, make sure you maintain your one-on-one schedule with your staff. They need feedback as much as the technical staff do. Maybe more.

In case you’re wondering, I suggested the director have a phone one-on-one with each of his managers and to ask them for help scheduling one-on-ones when he returns from his trip.

I’m a big fan of one-on-one meetings between the manager (or project manager) and the employee. Private meetings provide the manager a chance to see project and personal status in a way that group meetings and email status reports don’t. I wrote an article for Software Development about one-on-ones.

BTW, if you’re using group meetings to share everyone’s status, stop right now. Those meetings are a waste of time, because they’re serial one-on-one meetings. Boring for everyone else, and they don’t elicit the information you as a manager needs to know.

Here’s my recipe for successful one-on-one meetings:

1. Ask about the employee’s current state. Ask to see evidence of progress, especially if the employee tries to tell you something is 80% done. You both know it’s not 80%. It might be 40% or 90%, but it’s not 80%. Without evidence of progress, you can’t tell what is complete and what’s not complete. Neither can the employee.
2. Ask if there are obstacles you need to remove.
   • If you’re the employee’s personnel manager, talk about career development.
   • If you’re the project manager, ask if the employee what they see about the project. (”What stands out for you, about this project?”) Make sure you’re asking an open-ended question.
3. Ask the employee if they have issues to discuss.

Esther Derby and I are running a teleclass on how to create successful one-on-ones, starting May 28. The first session is free. Email me if you’d like to join us.