Managing Product Development

I was talking with a new manager recently, and she was explaining what she had to tell a new employee (a co-op, but an employee). “I told him he had to be here by 9am every day he works. He can eat lunch from 12 to 1, and then he should be back at his desk. I then told him if he ran out of work, he should talk to me, and that he could leave between 5:30 and 6:00.”

We were chuckling, and I told her the story of one of the first co-ops I hired. I had to tell him to brush his teeth, take a shower every day, wear different clothes every day, and make sure to use deodorant. After he got into the rhythm of work, about a month later, he thanked me. I was curious, and asked why he’d been so unaware all these years before this job. He said, “Well, I was smart enough to coast by on my brains. But all the work I did, I did from my room. I never had to see anyone or work with anyone before. This is a huge difference for me. And, my social life is improving!”

I’ve had a number of funny-strange conversations, and many of them are about feedback. If you have to give someone feedback about body odor or halitosis, remember how:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using “I” language.
• Make a request for changed behavior.

Take a look at With Feedback, It’s Kind to be Firm for an example. As long as we have geeky people in high tech, managers will have to have these conversations. Make them helpful conversations, and you’ll have an employee that’s loyal to you forever.

Both David Maister, in Compensation Systems, and George Dinwiddie, in Agile Compensation, have useful comments about compensation systems. There’s something implicit in both pieces, that the criteria to move from position to position (as well as from one salary to another) have to be explicit. For years, I called this expertise criteria.

You develop expertise criteria by defining what’s critical about a position. If you’ve done a hiring strategy and a job analysis for each level of the jobs that report to you, you can develop expertise criteria. Take your 5-7 essential skills (most of these are non-technical), and rank them across the top of a table. Do NOT include number of years of experience or the educational level. Those two things are for HR, not for promoting or compensating people.

Down the side, list the levels. If you have developers and testers, and they similar essential skills (likely in an Agile team), list the levels of developers and testers together. That is developer level 1 and tester level1 are on the same line. Now fill in the matrix. (I know, this is hard work.)

When I did this for my engineering group many years ago, these were the essential skills across the top: Technical knowledge and methods, Initiative, Independence, Responsibility/Judgment, Scope, Complexity. Down the side, I listed positions from associate engineer, engineer, senior engineer, principal engineer/manager, consulting engineer/group manager, senior consulting engineer, director, vp.

I found it relatively easy to fill in the matrix for the first 4 levels. It was much harder for the last 3 levels. But without expertise criteria, I don’t see how you can have an entire conversation about compensation. You get stuck in “did you do this practice” as in George’s post, rather than “did you better the project or the organization?” (George argues against the “did you do this practice” thinking.)

For me, the expertise criteria gives a level of transparency that I think David Maister is trying to get to, but doesn’t actually say. (He does say the system needs to be fair.)

Many of my clients do not have expertise criteria charts. If you’re a manager, consider making one just for your group, and see if your performance evaluations and compensation discussions are easier. I bet they will be.

Links you might want to read:

Hiring Strategy #1: More People for Similar Work. (There are 7 hiring strategy posts. I will categorize all of them at some point.) Avoid Shot-in-the-Dark Job Analysis. There are more job analysis posts. I gotta get to this categorization

Bob Sutton has an intriguing post, A Surprising Study of Infant Mortality Rates: Evidence-Based Management Meets Evidence Medicine. One of the surprising conclusions:

One kind of collaboration was linked to higher mortality rates. When front-line employees became more involved in unit governance — doing things like being involved in decisions about who was hired and fired, the creation of new positions, scheduling, and budget allocation decisions – mortality rates WENT UP.
[...]
I would also speculate that the staff who were involved in those decisions might have been distracted from their jobs – taking care of sick little babies – and that in some cases (although they were given lots of information) they may have been given a greater voice in decisions that they lacked expertise about.

It’s critical to consider where and how people collaborate. I bet some of those folks were not interested in budget allocation, especially if budgeting in hospitals is the sham it is in many of the organizations I work with. (The senior managers have already determined the budget. Why do they make managers do more work??)

I don’t know the answer to how much collaboration is the right amount. If the collaboration is about how we as a group work together, what work we do, how do we know when we’re done–that’s all ripe for collaboration. Even for hiring, the team needs to be involved in the interviewing and in the hire/don’t hire decision, but not necessarily about the hiring strategy or the planning, offer, or first day parts. If it’s about paperwork, get someone else to do it. It really depends on who makes the decision.

If the decision is already made, don’t involve the team. If the team can’t influence the decision, don’t involve the team.  But if the team can influence or make the decisions, and the decisions affect how they do their work, then that decision is likely ripe for collaboration.

It’s certainly worth thinking about.

Read Eric Sink’s Exception Handling in Running a Business. He says:

In entrepreneurship, there is no substitute for good judgment.

I would modify that to “In management, there is no substitute for good judgment.”

If you haven’t yet read Esther’s Promises Involve Self, Other, and Context, do so. Here’s a single quote I like:

There’s another part of integrity that involves cleaning up your own messes.

Cleaning up the messes you create is difficult and necessary.

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.

In Integrity is the Most Important Requirement in a Manager, I talked about integrity as a requirement for a manager. With the current Patriots scandal, I’m wondering what Belichick was thinking.

I don’t claim to know everything about football. I enjoy watching the games. I enjoy seeing a team come together, which is what the Patriots have done over the last few years. I am surprised that videotaping the other coaches is against NFL policy. (Oh, come on, when cameras can be hidden in glasses–which will happen in a few years–how is the NFL going to catch people taping the other team?) But it is against NFL policy, at least for now.

I asked Mark, who Knows All Things Football, at least in our house, about the taping. He said, “Everyone’s doing it.” The idealistic part of me says, “Maybe.” The cynical part of me says, “Figures.”

But even if everyone else is doing it, it’s not right. Not according to the current rules.

I’m trying to remember a time when I thought that going against the rules in a cheating way was appropriate. Then I remembered something I do all the time. I encourage my clients and colleagues to do work in an iterative/incremental way even on a supposed serial lifecycle. I tell people they don’t have to explain everything about their work to their management–that all they have to do is deliver results. (Which they can’t do in a serial lifecycle, but can in an iterative/incremental lifecycle.)

I’d like to think I’m doing something different from Belichick. I’m not telling people to spy on another group without their knowledge, and use the new-found information against them. I am telling people to “lie” by omission. (I’d never thought that was lying until now.)

Up until today, I thought that the ends–a successful project–justified the means. Now I’m not so sure. Part of me says that the project team are the experts and they should be in charge of their work process. That same part is sure the management team who insists on a serial lifecycle either doesn’t understand what they want, or doesn’t realize that artifacts are no guarantee of a working product. But the other part of me is wondering if I shouldn’t insist that project teams–who work in a way their managers don’t understand and deliberately keep that information from management–should tell their management what they’re doing.

I’m curious what you think. Are there times when the project ends justify the means? Where do you draw the line?

Labels: integrity, lifecycle, management

George Dinwiddie pointed me to this great column, Fired With Enthusiasm.

I have a talk that I’ve given at a bunch of Software Development conferences, called “Successful Software Management: X Lessons Learned,” where X started at 8, and is now up to 16. Lesson # 11 is “Fire People Who Can’t Do the Work.” I talk about hiring the right people to begin with, to provide feedback (and possibly coaching), and then when you can’t make the situation work, to fire them. But I always say, “One of the best ways to fire them is to help them find a job at your competitor.”

I did this once, thinking the person was more culturally suited to succeeding at the other company. A few months later, my counterpart called me and asked, “Did you send me this guy on purpose?” I said that I had, but that I was trying to find a better fit and thought the other manager was more suited to managing him. He laughed and said, “Don’t do me any favors anymore.”

Helping people find jobs at your competitors is a sly action. But it might work. And it will certainly get people who can’t do the work (and are bringing everyone else down) out of your hair.

Labels: management

A colleague asked how to deal with this situation. “It’s clear Brad is being a jerk. I’m working with him on how to be less of a jerk. But Susie asked me today when I’m going to do something about the problem–nothing she says seems to make a dent in his behavior. What can I tell Susie?”

Nothing. Not anything at all. You can say, “I’m working on the problem.” That’s it. And if you have to fire Brad, you say something like, “Brad has decided to pursue career opportunities elsewhere.” If anyone asks about Brad’s jerkiness problems, you say, “Brad has decided to pursue career opportunities elsewhere.” (That’s the management equivalent of a “no comment” answer.

You can’t say anything because even if you comment, how will they know what you say about them? You create a lack of trust by commenting about other people.

So, never ever talk about other people’s performance.

This is #11 and #12 in Memo for Bosses: 101 Ways to Prevent your Office from Hating You.

I facilitated a management problem-solving session at the STARWest conference yesterday. When I was debriefing the activities, one participant said he’s met a bunch of testers and test managers who had a “siege” mentality. He was surprised by that.

I’m still surprised when I meet people like that. I sometimes see developers who feel that they are at the mercy of marketing or management or the BAs. But much more often I see testers or test managers who feel as if they have no control over their schedules or the content of the release, or anything in their working lives.

For a long time, part of me (the nasty cynical part) wondered why they continue to work in a field in which they have no perceived control. But I realized over the years that these are good people who don’t know enough to change their responses to the system.

Too many people who feel as if they are the ones who need to make accommodation for others share these characteristics:

• They don’t know how to understand the insides of the system. Frequently, this means reading code, but not always.
• They don’t know how to work with evolving requirements. I met some people this week who told me with completely straight faces that they don’t test anything they can’t get fully defined requirements for. They were not testing regulated systems, where because of traceability requirements on the process, I might have understood their starting point.
• They don’t know how to use any risk analysis techniques to determine where to start testing and when to stop. All parts of the system are equal in their eyes for test time.
• They are focused on the goodness of the system, instead of reporting state. So a defect is a personal affront to them, not information about the system.
• They don’t realize that development is testing and that testing is development.

When I say that testing is development and development is testing, I mean that faster, high quality development does not occur without testing. Developers have to test. And faster, high quality testing does not occur without development. Testers have to develop. (How did it ever become the norm that testers don’t have to be developers? How else can they know how to create good test systems?)

Using iterative and risk-based approaches to planning and executing testing makes sense to me. Waiting for requirements to be perfect seems like a waste of time. But if these are well-meaning people, what would have to be true to make them act that way?

Part of the answer (and I don’t think I have the whole answer) is that these people have a limited knowledge of how to develop systems (especially not understanding that customers need to see the system to provide feedback about what they want it to do), limited testing technique expertise (so they can’t take advantage of early work products), and limited project management knowledge (so they don’t know about how to iterate or use risk analysis). I met some people who rejected all possible options except for how they knew to develop and test systems. (And in the spirit of fairness, I’ve met some development managers who fit this list, too.) To be honest, I was surprised people like this were at a conference.

But, in my experience, I’m seeing fewer of these people at conferences. I’m seeing many more people who have a deep understanding of the development process, who are conversant in a variety of development and testing techniques, who like to work in iterations of some variety, and are much more flexible in how and when to start testing pieces of the system.

I don’t know how to make the siege mentality go away. Expanding a person’s knowledge can help. Limited knowledge is fixable with reading, discussion, practice–learning in some way. But a closed mind is not fixable.