Managing Product Development

When we think about manufacturing work, we measure labor productivity as the ratio of the output of goods and services to the labor hours devoted to the production of that output, output per hour. (See U.S. Dept of Labor)

Remember the discussion of Project Constraints and Requirements? That’s where I said the project requirements were a tradeoff of how much (feature set), when (time to market) and how good (defect levels). That’s the reason we can’t use output per hour as a software (or any knowledge worker) productivity measurement. Here’s why: If you don’t care how good a deliverable is, I can have it for you almost immediately. It won’t work, but my “productivity” if all you consider is when I say the deliverable is complete, is very high. (Not much time spent, so the ratio is high.)

If we want to start measuring developer or tester productivity, we have to define output per hour (or whatever time period you desire).

For developers, we can measure designs considered, lines of code generated, the number of defects generate along with the code, unit tests generated, unit tests run, how good that output is,and the time it took the developers to generate all that output.

For testers, we can measure test designs considered, number of tests generated, attempted, and run, test logs, defects detected, defects reported, number of measurements provided back to the developers as information,how good that output is, and all the time it took the testers to generate all that output.

Not so simple, eh? If we just knew how to measure how good our work was, we’d have a chance to measure individual producitivity. The more I think about productivity, the more I know it’s a project-by-project thing, not a person-by-person thing. Yes, some people have more effective output than others. And I’m not sure that matters.

If I can figure out how to share some data tomorrow, I will. Most of my data is under non-disclosure, so I have to be careful with what and how I talk about data.

In the past few weeks, too many managers have written to me, asking for help on knowing how “good” their people are. When I ask more questions, such as “What does good mean to you?”, they say they want to know who’s most productive. Then I walk through this analysis with them:

Productivity is not about the number of lines of code, the number of tests, the number of defects reported, or the number of requirements defined. Productivity is how long it takes the entire team to create a usable product, and for whom that product is usable.

It usually takes us a few emails to get past that statement. That’s because these managers now realize a single-dimension measurement is inadequate for measuring a person’s productivity, and that on a project, it’s the productivity of the project, not the productivity of a given person that matters.

For you lifecycle/process aficionados, that’s why agile projects, staged-delivery, evolutionary delivery lifecycles, and critical chain project management works. Each of those lifecycles or techniques focus on getting work out of the project, not waiting until the entire project is complete.

Tomorrow, I’ll deal with the kind of things you can measure.

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.

Steve Smith commented on yesterday’s post, “I think managers have a tough job, especially middle managers. I think that middle managers who are respectful to their employees but choose to execute to abide with their management team’s decision are acting in a dignified manner.”

Steve is right, and it’s not always easy to balance the needs of the company, the manager’s employees, and the manager’s needs. When this has happened to me, I go back to these questions:

1. What do they pay me to do? (This helps me derive the company and employee needs)
2. What decisions do I need to make or actions I need to take that I can live with? (This derives my needs)
3. Can I reconcile those decisions or actions with what they pay me to do and how I can live with myself?

If I can’t successfully reconcile the decisions or actions with my needs, I stop working at this company. If I can, I continue to work at the company. Maybe a couple of stories will help.

Story 1: I was a Director of Quality at a company. The software stunk. They’d brought me in to fix the process. As with many change and process initiatives, we moved at glacier-like speed. The management team asked me to sign a legal document attesting to the quality of the software. I asked them these questions:

1. Am I signing in my capacity as Director of Quality?
2. Am I describing reality or wishful thinking?
3. What is my liability if I sign this?

In the past, my job was to take the heat at customer meetings, to push for change, and to lead the corporate quality initiative. This was a new responsibility, and I needed clarity. My management wanted me to take the heat. But they also wanted me to describe a process we couldn’t even agree on, never mind implement. And, I had substantial liability if the customer became angry and sued us.

This was a no-brainer. I didn’t sign anything. In fact, no one signed anything, because we couldn’t do what the customer wanted. I helped my management see what was happening, something else they paid me to do.

Story 2: I was a Director of Development and had inherited a “problem” employee. My boss came by my office one day, and said, “Fire Sam.” I asked why. Boss said, “I’m tired of his expletive deleted questions. I don’t care how good he is, fire him.”

I told my boss that if he had problems with my employee, he should come to me. I would work with the employee manage his behavior. If that didn’t work, I would fire him myself. But, they didn’t pay me to fire someone whose interpersonal skills were inadequate. At least, not without providing feedback, and coaching if necessary. I chose to provide feedback. The employee chose coaching. We were successful.

I’ve participated in layoffs before. If the senior managers make the decisions, they get to have the joy of the announcement. If they let me make my own decisions, they are also balancing the needs of the business, the employees, and their needs. Once they take over my decision-making, they’re not thinking about one of the pieces. That’s when layoffs go bad and seem irrational. And, that’s when the middle managers can’t be respectful to their employees, nor act in a dignified manner.

Steve Smith challenged me in a comment to the cowardly layoff/no feedback posting: “What would you have done if you were the manager who layed off these people?”

I’ve written about layoffs in a previous Software Development column, but let me address the specific problem Steve described:

1. The manager needs the paycheck.
2. The manager (or more likely, the manager’s management team) chooses to use some form of numbered ranking system to choose which people to lay off.

What does the manager do?

Couched in these terms, it doesn’t look as if the manager has too many options. Effective problem solving involves deriving more possible solutions (at least three solutions). Here’s what I’ve done when faced with this dilemma:

1. Elicited the real need (requirements): “Ok, we have to lay people off. Which projects are we not going to complete? Which work will we focus on? Are we changing strategy? …” You can’t know who to lay off until you know what work you will be performing and what work you won’t be performing. Using rankings without understanding the value of the work behind the rankings guarantees you’ll make poor decisions.
2. Learn what the layoff package is. If you’ve managed through three or four or five (gack!) layoffs, it’s time to consider laying off yourself. The more technical staff you remove, the less necessary the managers are. Here’s why: as you lay people off, the best performers have removed themselves, as well as you removing the “worst” performers. (The best people have found their escape hatches.) If you’re still at the company, and you have fewer people (but competent people) to manage, does the company need you in your position? If you volunteer to lay yourself off, you’re more likely to improve (negotiate) your layoff package than if you blindly wait for the standard package.
3. Describe the worst thing that could happen to you. “If I lay myself off, these are the worst things that could happen:” Then take that list, and talk about it with your partner, a trusted friend, your accountant, or whomever you need to talk to, to see if you can live with the worst thing that could happen. How long could you live with the worst thing that could happen? If you became unemployed now, how long could you live in your house or apartment? Do you have bills you can’t manage in three - six months without a job(such as college tuition or nursing home bills)? What about your self-esteem?

The first time I was laid off, my self-esteem crashed and burned. I defined myself by my job. The money wasn’t nearly as big a problem, although I didn’t have three months of mortgage saved up. Because my self-esteem crashed, I found it difficult to work on my resume and interview. So the worst thing for me was not knowing how to define myself, so I could obtain a new job.

Once you know what the worst things that could happen to you are, can you manage around them?

If you can, then maybe it’s time to take the layoff. Otherwise, what do you need to do, to be able to manage your life through a layoff?

Too often, management doesn’t define a strategy, other than “lose headcount so we stop hemorrhaging money.” You’re more likely to retain your staff (and your job) if you help articulate a strategy, define projects that support that strategy, and then closely manage those project.

And if after all of this, you still have to lay people off, be honest. Don’t apologize, don’t make it a performance issue (unless it is). Be clear, be human, and treat people with respect. Who knows who’ll lay you off the next time?

I was at STAR East this week, facilitating some sessions with Esther Derby. The session was fun for us and the attendees seemed to learn a lot.

For me, one of the best parts of conferences is meeting new people, making new friends, and learning about new things. Some of us bloggers got together for a little BOF-thing at the cocktail party (hey, is it a geek cocktail party without a few computers?):Brian Marick (who still hasn’t linked to me, who may never link to me, but whose writing I still read and whose friendship and review I cherish, and now I get to tease him about this linking business :-), Esther Derby, Cem Kaner, Andy Tinkham (who’s working on a new tool so he can syndicate sites without RSS feeds! Whoo-eee Andy!), Bret Pettichord, and some folks without blogs: James Whittaker, Scott Myers, Lee Copeland, Rick Craig.

Some of you familiar with these names may be thinking, “Oh, JR’s just name-dropping. Hmm. That’s strange. Why would she do that?” I’m not *just* name-dropping. I know these people. I respect them. I don’t always agree with them, but that’s ok. We are peers, and we use each other to read and review our writings, refine our ideas, and challenge our ideas to make them better.

I don’t know how much influence I’ve had on each of these people. I suspect it ranges from none to some. It doesn’t matter to me how much influence I’ve had on them; it matters more to me that they’ve influenced me. Cem, Brian, and Bret have explained to me in multiple ways that the kinds of testings I take for granted are not normal for much of the testing community, and if I want to reach that community, I need to explain what the heck I’m doing. James and I both enjoy speaking, and I’ve learned from James that if I chose to dance around on the stage, people might not walk out. (I’m still not sure I’ll actually dance, but it’s an option.) When Scott spoke about “Just Plain Stupid” design, I felt as if I was back at Symbolics, and was thrilled that he encouraged the testers to call developers on wacko designs. I’m not sure I would have considered facilitating an open-space type of session at a conference without Esther.

I’ve learned from my friends and colleagues. I know they’ve influenced me. I suspect I’ve influenced them too.

If you’re not attending conferences now, consider it. You don’t have to make friends with the speakers, but I recommend it. If you have no money to attend conferences, attend local professional group meetings. Read articles and books. Correspond with the authors. You’ll make friends, people you can ask for informal help if necessary. The speakers and authors speak and write to influence you. And the more you correspond with them, the more you’ll influence them.

In the last two weeks, four different colleagues have found themselves suddenly unemployed, all for the same reason, “You didn’t do what we expected you to. Since your performance is inadequate, we’re firing you.”

My colleagues and I were surprised. Three of the four people received raises and good-to-great performance evaluations in the last six months. The fourth kept hearing “atta-boys” from his boss. So what’s happening?

1. Maybe the manager is giving these people feedback, but in a way they can’t hear it.
2. Maybe these colleagues are suddenly not performing (after 20-25 years at work).
3. Maybe the layoff/firings are not about my colleagues.

Here in Massachusetts, if a company wants to lay off at least 10% of their workforce, they need to file paperwork with the state and let the employees know 30 days in advance. I’m sure there’s more to the law than that, but I’m finding these onesies and twosies layoffs of middle management surprising. If the company makes a series of small layoffs for “performance” reasons, the company doesn’t have to inform the state, doesn’t have to pay severance, and doesn’t have to treat these over-40’s as a protected class. From what I can see, the layoffs/firings are not about my colleagues at all, but about the management performance of their bosses.

Only cowardly managers use performance as an excuse to avoid the perception of layoffs. These unethical managers don’t care if they batter someone’s self-esteem, or make finding a new job difficult. They only care about saving their tushes.

I’m tired of cowardly managers. If you really do want to fire someone because they’re not performing, follow the second rule of feedback:

Give the feedback to the person:

1. State your observations. Make sure the other person agrees with your data.
2. Describe the impact of the person’s lack of performance, explaining the effects on the product, the team, the project…
3. Describe the change you want to see. Be specific. “I’d like to see you complete the whosis task before you take on the whatsis task.”

Real managers, professional managers, competent managers give feedback way before firing is required.

If your company is losing money and you think it’s your employees’ fault, think again. Maybe the real performance problem isn’t your employees. And if the performance problem isn’t your employees, all the onesies and twosies firings for “performance” won’t make a damn bit of difference.

(I’m angry and when I’m angry, I don’t always write well. Please do provide feedback!)

I’ve been thinking a lot about some of my clients’ problems managing their projects. Two of my clients are stuck on the notion that there is a silver bullet, one right way to solve their problem. Then I read Steve Norrie’s blog entry this morning, and saw this quote: “Nothing is more dangerous than an idea when it’s the only one you have. — EMILE CHARTIER” .

When you have only one idea, you end up with institutionalized best practices. Some practices are good sometimes. None are best all the time. When you have multiple ideas, you can choose among useful practices.

One client is looking for the one-and-only project plan template. Argh. I asked, “Are all your projects the same size and duration, requiring the same number of the same kinds of people?” The people around the table looked at me as if I’d grown three heads, and said, “No, of course not.” I asked, “Why do you want only one template then? Don’t you want guidance about what you need to write in a project plan so that the bigger projects have more in the project plans and the smaller projects have less? That the more risky projects deal with more of the risks and the less risky projects don’t?

I’m all for project plan templates. Having a place to start can be very helpful for many of us (including me). But we need to guide people to thinking instead of blindly filling out forms, planning a project the One And Only One Way.

The value we bring to our companies is our brains. Let’s use them. Let’s think of at least three alternatives to each problem, not stopping at the first One Right Way.

I’m not big on information hiding. I’ve always wanted to know what was going on in other parts of the company, so I could better understand how to do my job. I recently read Laurent’s post on Information Hiding, and realized that I when I recently spoke about open book management, some people didn’t understand what I meant. So, here’s what I mean by open book management: share all information about strategies, sales, revenue, and costs so that everyone can help manage the business better. Instead of making locally optimum decisions, everyone can make macro-level optimum decisions.OBM is difficult. How many of us want to post our salaries (including bonuses) for everyone to see? How do you deal with OBM when dealing with individual productivity? I don’t have all the answers. Here’s what I’ve done in the past:

1. Focus on defining the strategy, the tactics that flow from the strategy, and how we’ll measure the success of those tactics.
2. Measure the cost of the tactics by team. Since I can’t measure productivity individually anyway, I measure it by team. I can also measure salary plus bonus by team. This requires that I not move people around from team to team too often, or the arithmetic gets too hard to be correct.
3. Make sure everyone knows what the tactics are, and why.

OBM requires that everyone want to serve the best interests of the company; that the employees are responsible and will make good choices, if they understand the context behind those choices. It’s not easy to do, and if your company is in financial straits, necessary. Just imagine if the airlines had treated their employees are reasonable adults instead of tantrum-holding children. They may not have expanded innapropriately, and they certainly wouldn’t have tried to keep the top management’s excess monies while negotiating for pay decreases with the unions. (I firmly believe unions arise when management witholds relevant information.)Don’t treat your employees as if they were children. Laurent doesn’t treat his children as unthinking beings I hope I didn’t when my kids were smaller. Now, I wouldn’t even consider it. Help your employees understand the context and discuss how to make the best decisions everyone can make, so that the company succeeds.

I was extremely fortunate in my choice of companies and work early in my career. I developed in assembly language and microcode and Fortran for a few years. Then, I moved to object oriented languages, primarily at Symbolics, using LISP.

At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some forms of pair programming. Why? Because the language, LISP, encourages this. It’s easy to make small changes. It’s easy to take what you have and try something. It’s easy to walk someone through small functions and then have that person explain what else you could do. It’s easy to grab someone and show them what you have already working, even if other parts don’t work yet.

I’m not a LISP expert, certainly not the way I was an assembly language or microcode or Fortran or MAGIC/L expert. I became sufficiently fluent in LISP to write pretty good tests. It took me a long time to get past linear thinking in LISP.

But once I figured out the basics of writing software in LISP, I became a much better project manager. I understood how easy it was to break things into small pieces and write products from the bottom up, rather than the top down. I understood how the engineers needed time to experiment. I could help them timebox their prototype activities. Even though I wasn’t a LISP expert, I could use my knowledge of the environment to help the engineers create a product development process that worked.

If you’re not happy with your projects, look at the language and environment you use. Maybe LISP isn’t the answer for you. But you can create an environment that creates a helpful process — one that allows the technical staff to create small pieces, test them, and build on them. We know that successful software development occurs when we build small pieces from the bottom up and check those pieces with the customers. Make your project environment help your technical staff create successful products.