Three Myths and Three Tips

Vol 8, #8: Three Myths and Three Tips

I have been fortunate this year to be working and speaking internationally. And, almost everywhere I go, some manager or project manager takes me aside. “Johanna, can I ask you a crazy question?” I always answer that I'm sure the question is not crazy.

The manager shakes his or her head, convinced he or she is the only one with this problem. “Everything is changing so fast. I don't know how to keep up. How do I keep the right people assigned to the right projects? It doesn't seem as if I should move them around all the time, but I have to keep the experts on the projects, don't I? And, some projects don't need so many people all the time. I don't want to overstaff projects that don't need it. But, I don't want to understaff projects, either. Some days, I can't win.”

Managers, your instincts are correct. You have some tough problems. And, they are interconnected, so let's take them one at a time and dispell the myths and provide some tips for you.

Myth #1: “If we plug just the right resources into the projects at just the right times, we can make the projects work.”

People are not resources. Money is a resource. Desks are resources. Lab equipment is a resource. Software might be a resource. You can plug resources into other places and they don't complain. But people? People are part of teams, and when you take a person out of one team and attempt to “plug” that person into another team, you might get lucky and have the second team absorb the person and not stumble. But don't count on it. That's because people are not resources. They are living, breathing, wonderful humans.

Tip #1: Flow work through teams.

If you have teams who are working well together, great. Keep the teams together. Give the entire team projects, one project at a time. Don't worry if they don't have the expertise. (See Myth #2.) They will finish the work or ask for help—as a team.

Myth #2: “Only an expert can do this work”

We have many myths about needing Experts and Only Experts to perform specific work. There is some work that only experts can do. The real question is: how much? I don't expect developers to become testers or vice versa. Nor do I expect UI designers to become security experts. But as a project manager, I expect everyone on a project to learn enough about the project to be conversant about the entire project. And, most importantly, I expect experts to work with others to share their knowledge.

Tip #2: Never let experts work alone.

I ask experts to pair with non-experts when they work on their areas of expertise. If they have refused to do so, I have transferred them to another project where they do not have expertise. I bet some of you just decided I was crazy. But here's why. If the expert is inside your organization and on another project, you still have access to the expert. If the expert has won the lottery and is in Fiji enjoying an umbrella drinks, you do not have access to the expert. When do you want to practice building your expertise? I want to practice with the expert still available.

I bet some of you managers are concerned about the project's pace. Well, when you remove the experts from the team, a funny thing occurs. The team pulls together and works as a team, not as a disjointed group of individuals. You want a team to work fast? Remove the experts. The team will work together and fast to discover what they don't know. They will share what they do know.

Myth #3: “This is a one-person project.”

You think you have a really small project. It really does look like it's just one person for a couple of months.

Don't fall for it! There is no such thing as a one-person project. That one developer still needs to talk to the customer or the requirements person. Or the developer needs help deploying. Maybe there's some database or testing work this one person cannot do alone.

The problem is this: Software development is a social problem. Even introverted people need to either talk things through, or, more likely, work problems through with another person.

Tip #3: Always staff a project with (at least!) two people.

If you always staff a project with two people, they can pair. Here are some possibilities for two people:

• They can code separately and then test each other's code.
• Before coding, or if they encounter problems, they can bounce ideas off each other.
• As a pair, they can learn to deploy, or more likely, debug the deployment.
• Offer each other moral support when they can't understand why things don't work.

Don't ever fall for the myth of a one-person project. There is no such thing.

Managers: you are not crazy. However recognizing your myths and following these tips can help uncraze you.

---

New to the Pragmatic Manager? See back issues here.

I keep my blogs current with my writings: Managing Product Development and Hiring Technical People.

and my newest blog (with it's own new mailing list) Create an Adaptable Life.

Johanna

Vol 8, #8, ISSN: 2164-1196

© 2011 Johanna Rothman