Many of the companies I work with want the benefit of the team effect in software development. The managers in these companies recognize the enormous benefits teams provide to the company–creativity, engagement, learning.

However, in many of these companies, the HR systems focus only on individual accomplishment. Individual goals, individual bonuses and merit-pay processes cause real damage when the desired behavior is collaboration and team work. I’ve talked to managers who spend the year building up teams, only to see their work undone by the review and ranking process.

In a small company, managers have the ability to directly change the goal, bonus, and pay systems. In large companies, or in companies where the software group is only one division, changing those policy may seem impossible.

Until you persuade HR to change to more team-focused strategy, take these steps to minimize competitive focus and amplify the emphasis on shared goals.

Amplify the Importance of Team

Make the expectation for teamwork behaviors explicit. Make team performance a significant portion of each team members performance expectation.  By significant, I mean 60% or more. Anything less communicates that teamwork is “nice to have,” but not essential. When people must rely on others to achieve a useful goal, tie the success together in performance expectations.

Dampen the Race for Rankings

Minimize the competitive focus by reducing stratification. Rather than have five or more ratings, use only three categories.

The top category is for people who are truly exceptional. They may out-perform the system, make an extraordinary contribution on a project, or stand out in some other way.  In most organizations, there aren’t many of these people, and most people know who they are and agree on who they are.

The bottom category is likewise small and for people who are exceptional. This is for people who clearly are unable to perform, due to lack of skills, poor fit for the job or some other reason. Note: Before you put someone in this category, check the manager’s contribution to the problem. Most performance problems are not the sole fault of the employee. When an employee is in the wrong job, or clearly lacks the skills, that points to problem with the hiring process, not the person. Of course, it doesn’t make sense to keep someone in a job they cannot do. But let’s not blame the individual when a management process has failed.

The middle category is the big one–for the people who are doing their jobs well and performing within the bounds of the system. Many companies waste an enormous amount of managers’ time arriving at fine-grained but spurious distinctions between employees contribution. Such distinctions are meaningless in collaborative and interdependent work. Managers’ time would be better spent working to improve the system so everyone does better.

A three-tier strategy based on normal variation and exceptions reduces the unhealthy effects of ranking individuals against each other. As a bonus, it frees up a great deal of time that managers would otherwise spend on suspect differentiations.

Don’t Treat People as Fungible

Don’t waste time comparing people as part of the evaluation. Comparing people within a team or group fosters division and competition. Comparing people across teams or functions is irrelevant–except when considering promotions.

Emphasize Interdependent and Collaborative Work

Eliminate individual performance bonuses. Some companies give team bonuses to recognize a team that has solved a particularly difficult problem, saved the company a huge amount of money, or launched a successful product. Since the bonus goes to the team, in most cases, the team members divide it equally.

Even without formal team bonuses, you can use the pot of money HR allocates for individual bonuses in this way.

Aim for Policies that Focus Improving the Organization

In the long run, consider some form of profit sharing or gain sharing based on the over-all performance of the department. Couple this with a clear emphasis on improving team and system performance and meeting business goals. This reduces the likelihood that people will skew their effort towards meeting individual goals at the expense of unit wide business goals.

Take a Stand

Many managers tell me that HR forces them to act out harmful policies related to annual evaluations, ratings, and rankings. HR is there to support performance, not disrupt it. Talk to them about the detrimental effects you are seeing. Share the research. Decline to participate in the ranking mess. If HR insists, distance yourself from the mess and have an HR manager communicate the ratings/rankings.

I have talked to many managers who have opted out of the rating and ranking madness and none of them have been fired. And several of them–through their action–started the conversation and change towards policies that support rather than hinder team work.

“A talented employee may join a company because of its charismatic leaders, its generous benefits, and its world class training programs, but how long that employee stays and how productive he is while there is determined by his relationship with his immediate supervisor.”  Buckingham & Coffman

Good managers know how to build strong relationships in a traditional manager-led environment. But when a company relies on self-organizing teams to accomplish work, the relationship between an employee and his direct manager may not be his primary affiliation When organizations form real teams, the strongest bonds may be to the team, not the manager.Managers still need to maintain rapport with individuals, but now they also need to maintain a relationship with the team as a whole.

What does that look like? Strong manager-team bonds come from co-creating, clarity, and coherence.

 Co-creating Relationships

As a manager, you need certain things from the teams you support. It’s reasonable to expect teams to make their status, progress, and road blocks visible. It makes sense to track certain metrics from teams to alert you to problems. You need trend information to reason about how the team is functioning, and how the system is functioning. (I’ll write more about which metrics might be useful and the importance of focusing on trends rather than targets in a future newsletter.)

And the team needs things from you, too. But what the team needs might be different from what a collection of individuals needed. Gather the team and find out. Start with two sheets of flip chart paper one of the team, one for you. Draw a line down the middle creating two columns. Label one Need, and the other Offer. Ask the team to work together to fill out their sheet while you fill out yours. Then compare what you wrote and what the team wrote.

Start with the areas where it looks like there is agreement between what the Team wants and what you offer. Discuss what that would look like. For example, if the team needs you to be available, drill down to see what that means. “Be available” could mean:

• The team wants you within 40 feet of the team room at all times (probably not something you can agree to), or
• They  want to you respond to their emails within 24 hours, or
• They want you to designate another manager they can go to if they need management support. or
• A weekly check-in, or
• Something else completely different.

Then, work through the areas where you and the team seem to be close on what you need from them.

This is a negotiation so be prepared to look for the needs behind requests and offer options. Once you’ve worked through areas of agreement, look at the requests that seem far apart. Some of them may be answered by the discussions you’ve had so far. For those that still need discussion, prioritize, and then ask “If you had that, what would it do for you?” You may learn something interesting about the team’s work environment and how they view your role.

As with any relationship, you don’t have to say Yes to every request. Nor does the team have to do everything your way. Before you go into the session, be clear in your own mind about the critical things you need from the team to do your job. But be flexible on how to achieve them.

Clarity around Decision-Making

The previous discussion may have already covered some decisions. You may want to document those in this step. Then identify all the decisions that affect the team over the course of a typical quarter. Group stickies that seem similar, so you can see classes of decisions. Some examples of categories shared by many groups are hiring, training, tools, and technical decisions.

Looking at the classes of decisions, answer these questions:

• Who defines the problem or issue?
• Who sets the focus and boundaries (e.g., money, timing, unacceptable options, criteria, etc.)
• Who identifies candidate options?
• Who evaluates chooses among options?
• Who implements the chosen option?
• Who evaluates the decision, once the chose option is in place?

If you don’t find a pattern in one of the decision classes, the category may be too broad.  Try breaking the category down.

At the end of the activity, you’ll have a matrix that looks something like this:

Don’t try to identify every single decision that team will make. Work to identify areas where the team has autonomy and authority. Delineate where you and the team will work together on a decision, and where the decision rests solely within your role as a manager. Clarity enables the team to act–without fear of crossing an invisible tripwire. It also reduces the likelihood of being blindsided by a decision, for you and team members.

Coherence in Values and Actions

In some organizations, it feels like there’s one set of rules for managers and another for non-managers. This condition fractures relationships and erodes trust. Simple Rules (1) are a tool to bring bring coherence, and reduce the feeling that there’s one set of rule for “us” and one from “them.” Unlike working agreements, which usually address protocols for  how to work together in a specific context, Simple Rules guide behavior in many situations across departments and levels in an organization.

Simple Rules reflect values and aspirations about behavior. Start with a warm up, identifying common current patterns of behavior in the organization. Based on observed behavior, test what unspoken Simple Rules might drive that behavior. Ask the groups what patterns are effective, and which they might want to modify or add. Generate rules that would help that pattern emerge.

Here are some Simple Rules from other organizations. Even if these seem like good rules, don’t copy–create your own!

Teach and learn in every interaction. (From a non-profit educational institute.)

Use every failure as an opportunity to learn. (From an organization that wanted to foster more intelligent risk taking.)

Raise the red flag early. (From a group that wanted early warning of problems and potential problems.)

As you develop Simple Rules, consider the patterns of behavior that you want to foster. Simple Rules should be “minimum specifications,” rather than detailed prescriptions for behavior. Keep the list short–five to seven rules. More that that is too many to remember, and acts against the ability to apply judgment, take responsibility, and self-organize.

Conclusion

In spite of the cries of a few pundits (and a few self-organizing teams), teams still need managers. But if you want the advantages of the self-organizing team effect, you have to make space for great things to happen. Sketch out the relationships boundaries, and Simple Rules to set the stage for  creative approaches, solutions, and responsibility.

(1) Simple Rules come from the work of Glenda Eoyang, hsdinsitute.org.

A while back, a colleague, Susan, called to ask me for some advice.

“I’ve been planning a vacation with my family for months,” she said. “And now my new client wants me on-site next week. I’d be happy to come the week after next, but they keep pushing. I told them I couldn’t come because I had family plans.”

“Have you been able to schedule the visit for a time that works for both of you?” I asked.

“No, not yet. The next day, my client called me back and said they really needed me, and to make it easy for me, they’ll put me and my family up at a five star hotel for the week and through the weekend. They’ll provide a nanny, a car and driver, and obtain VIP passes at the local theme park and children’s theatre.”

“Are you going to do it?” I asked..

“It’s tempting,” she said. “They say they really need me, and my kids would probably love it. But something doesn’t feel right.”

I had to agree.

Susan is at a turning point with her client: the way this initial exchange about scheduling her site visit unfolds will color the rest of their working relationship.

All of us establish working relationships, whether we are employees or external consultants like Susan. We make agreements with others about what’s expected and how we’ll work together. Sometimes our agreements are explicit, as in creating a project charter, setting a sprint goal, or establishing the boundaries of a new assignment. Other times the agreements are less explicit—the agreement comes about without conscious attention.

Pay attention to what happens in the early stages, when you’re working out how you’ll work together. The early stages often foreshadow the entire working relationship.

Susan’s client was establishing that he expects people to switch priorities at short notice and sacrifice personal balance to support his sense of urgency. If Susan acquiesced to this request, her client would have her asking “How high?” each time he said “Jump.”

After we analyzed the situation, Susan decided to stand firm. She called her client and thanked them for their generous offer, and said it didn’t fit for her to upend her family vacation. She reaffirmed that she’d be happy to be on-site with them the week after her vacation.

Susan’s client was surprised that anyone would act this way, but accepted her schedule.

After her week at the client site, Susan called me back. “You know how my client wanted me to drop everything, change my plans, and react to their sense of urgency? It wasn’t really urgent. And they treat almost everyone that way.”

“Yep,” I said. “Everyone but you.”

There’s a buzz about systems thinking in the software world these days. Systems thinking isn’t new. Jerry Weinberg’s An Introduction to General Systems Thinking was first published in 1975. Senge’s Fifth Discipline came out in the 90s.

Still, we haven’t turned the corner on this thinking revolution.  That may be because the pragmatic benefits of the systems thinking approach aren’t always clear, and some people find system diagrams inaccessible. Further, it’s not always easy to see what’s a system problem and what’s not.

You probably have a system problem if:

• You have tried repeatedly to solve a problem and it keeps coming back
• You replace people and the overall behavior doesn’t change
• Multiple factors interact to produce the result.

When you suspect a system problem, gather data that will help you understand the how the system performs, and how various factors interact. The following steps outline one way to “see” your system.

1) Expand the time horizon. Look back to the point where the problem may have started.  If you have historical data, look back at least two years. Notice any events that might have precipitated the problem (but don’t jump to conclusions).

2) Brainstorm factors that might be related to the problem. Choose factors that are potentially measurable. Name those variables using neutral or positive language to avoid confusing double negatives.

3) Sketch a graph of the variables to see how they move in relationship to each other.  Notice whether they move in parallel, in opposite directions, or seem unrelated.

4) Formulate a hypothesis based on the graph.  See if you can test it in a small way.

Here’s how one group of managers used this process to understand and improve their system.

During the year-end financial review the executives at FinCo were displeased that most of the IT projects were at least 100 per cent over budget. Wanting to  educe budget over-runs, the executives established a bonus target tied to meeting +/- 5 per cent of the original project budget.  They reasoned that project managers weren’t trying hard enough to meet budget targets, since there was no real consequence (to the project managers ) for not meeting targets. The incentive, they reasoned would provide the will project managers needed, and focus their attention that important number.

At the first quarterly review, most of the projects appeared to be on track to meet the target. But as the year went on, it was clear that many projects were still blasting through budgets at an alarming rate.  Since the incentive was clear, it must mean that the current crop of project managers didn’t have the skill to deliver to budget, they reasoned. This time the executives replaced the project managers.

But there was no cheer at year end. Once again, every single project was over budget. Faced with another year of disappointing results, the executives decided to try another approach. The fact that the results didn’t change after they changed the people made them think that perhaps their project managers weren’t entirely at fault.

First, they expanded their time horizon and looked as far back as they had project data.  They were shocked to see that out of dozens of projects, only one had spent less than 100% of it’s original budget–and it wasn’t a project managed by one of their replacement project managers, the ones they had hoped would work miracles.

Many projects spent 200-500 per cent more than their original budget. Could it really be that, over six years only one project manager had the will and skill to meet the budget?  Based their previous interventions, they could see that changing incentives and changing  people didn’t change the result. (Though changing the incentive did bring a change in behavior: project managers managed to game the numbers, at least early in the project.)

The executives brainstormed a list of potentially measurable factors of that might be related to the problem: size of project, lack of involvement of business stakeholder, number of scope changes, team size, length of project, number of new technologies, staff turnover, full-time vs. part-time team assignment.

To make it easier to see relationships among variables, they used neutral or positive words to avoid confusing double negatives. For example, stakeholder involvement, rather than lack stakeholder involvement.

They decided to look at three factors: stakeholder involvement, measured by the number of meetings between the stakeholder and the project team; original project size measured in effort months; and number of new or unfamiliar technologies used on the project. They didn’t worry about having precise measurements–they were going for a rough picture that would help them form a testable hypothesis.

Here’s what they saw:

Based on this initial sketch, they did more research and more graphing, looking for useful information about how their projects worked, and which levers were likely to reduce budget over-runs.

When the next project prioritization came up, the executives formulated an experiment. They chose two of the biggest projects. They set a guideline that these projects use rolling budget and deliver some piece of useful working software within three months. They directed the project sponsors and project managers of those projects to work together to identify smaller chunks of work that the projects could teams could build in short time-boxes, leading up to the three-month delivery. They also gained commitment from project sponsors to participate in project meetings.

At the end of three months, both projects had delivered useful software. Neither hit their budget numbers exactly– as one would expect. However, both stakeholders agreed that the new arrangement helped build confidence and trust. All agreed they had a better basis to predict costs for the next timebox than had been possible at the outset of the project.

Based on these results, (and despite some grumbling about re-work and wasted work in progress) the executives revised their project portfolio. They structured projects to complete useful working software within three months–at which point they could re-evaluate based on data and the current environment. Rather than plan and budget a year ahead, they committed to adaptive planning and incremental funding.

Initially, the executives in this story believed in their budget numbers more than they believed in their project managers.  It is common for people to put faith in predictive numbers such as budgets and estimates.  That faith led the executives down the wrong path–they tried to fix the problem by fixing their project managers. It wasn’t until they looked beyond the budget numbers that they began to see their project system and understand how to improve it.

Of course budget reports can be useful; while they can alert you to a problem, they  don’t give you the information you need to really improve the situation. To do that, look beyond budget reports. If you want to steer your system, you have to see it first. Using the steps described in this article can help you understand problems in your organization–whether the problem relates to projects, technical debt, or staff turnover–and see the dynamics of your system. Armed with that understanding, you’ll better equipped to find a fix that fits.

You can sign up to receive my newsletter via email using the box on the right of the screen.

Most of the time, when I hear about “agile change,” someone in management has decided that Scrum (and maybe XP engineering practices) will improve quality and time to market for the company’s software products.

I’ve heard some success stories. And I’ve heard about many failures.

Why do these efforts fail?

Some people blame the failures on mis-understanding Scrum, or not applying it with sufficient rigor. Both of these may be true. But I see a different thread running through these failures. Often the failed change initiatives nibble at the edges, without changing the way work flows through the organization. And that’s a management problem.

What if the change–not just the directive to change–started at (or near) the top?

Here’s are six management practices that will improve the way work flows through the organization.

1. Get Middle Managers Working Together

Many organizations make it difficult for middle managers to work together by structuring goals that foster local optimization and competition. For example, a development manager might be rewarded for meeting a date, while test managers are rewarded for releasing a product with few bugs. It’s easy for the development manager to meet his goal if he doesn’t care about the test manager’s goal.

Other companies are organized so that managers for different products must vie for scarce development resources to meet their goals. The winner isn’t always the organization or its customers.

If you current organizational goals foster conflict or competition, fix them. They take the focus off the real goal, delivering valuable products to your customers. Optimize for the organization’s success, rather than focusing managers on goals that detract from the end result.

2. Decide What to Do and What Not to Do (At Least Not Now)

Ray Cummings said, “Time is what keeps everything from happening at once.” The laws of physics say it can’t happen all at once. So why do we keep trying to do everything at once in our companies? I’ve spoken with several development managers who have a personal policy of never saying no to a request from the business. That keeps the conversation happy for a while—until it becomes clear that it’s not possible for the development team to do everything.

One of the biggest problems in companies is trying to do too much at once. That drives multi-tasking, context switching, and wasted mental cycles. It slows down delivering value to customers and realizing revenue.

But if you want to focus, you need to …

3. Manage Your Product Portfolio

You probably know which products are valuable to your customers and the company. But do you know why? Go and find out. (For some ideas on learning how your customers view your products, see Know Thy Customer.)

Make a retirement plan for products that are waning in value to the customer or the company. Those products will suck up both intellectual and monetary resources.

For the products you will produce, determine which features need to be delivered and in what order. A Kano analysis can shed light on which features have to be there to make the sale, which enhance attractiveness, and which are clear differentiators.

4. Realize the Benefit of the Team Effect

Establish stable cross-functional teams to work on software products. Groups of people who are assigned to one project but report to different functional managers are less likely to jell as a team. When those same people are assigned to more than one project they are extremely unlikely to become a high performing team. Groups of people who have a clear membership and a clear charter jell into teams.

It takes time to build the communication, trust, and commitment that foster high performance. Many organizations rearrange teams every few months to meet the needs of current projects. That obviates the benefit of the team effect. Rather than bring the team to the project, bring the project to the team. A given team may need to add a new member for a particular skill–which is more effective than breaking down, re-staffing, and restarting whole teams.

5. Embrace Adaptive Planning

Don’t use deterministic planning for projects that aren’t deterministic. For most software projects, detailed plans only give the illusion of predictability. Further, they encourage managers to shift the blame for missed dates to the team.

Instead, use adaptive planning. Chart a course, knowing that the competitive landscape and internal factors (e.g., the capability of the team, viability of technologies) may drive the need to adapt and re-plan.

Find a way to measure progress that’s meaningful and reliable enough to let you extrapolate into the future. You won’t find perfect measures of progress or capacity–and if you could they’d probably be too expensive to implement. You need something good enough to make decisions about planning and promises. Gaging team capacity using story points, along with establishing a common definition of done are reasonable starting points.

Adaptive planning works better in the real world of software projects. But it does put responsibility for tough decisions squarely with management.

6. Continue to Improve

Once you have stable teams focused and working on the most valuable products, congratulate yourselves—you are ahead of many companies. But don’t stop. Create a culture of problem-solving leadership though out the company.

Examine policies, procedures, and structures that may have worked at one time, but don’t support the emerging pattern. Some of the first places to look are training policies, hiring practices, differential pay and rating practices, formal approvals, budgeting, and audit policies. Make sure your policies and procedures are working for you and not against you.

***

Some people say Agile could never work–it’s just the latest silver bullet. Agile may be reduced to silver bullet status, if managers expect to solve significant organizational problems by working only at the engineering team level.

But if mangers address the way work flows through the organization, it will make a real difference when development teams start to use Agile Methods. No software development method can solve problems of throughput, quality, or product fit unless management also changes.

Sooner or later every manager faces the same dilemma: What do I do when I inherit or hire an employee who turns out to be a poor fit for the job?

Tom was the development manager for a supply chain product. He had an important project to deliver and was staffing up to meet the workload. The company had recently discontinued another product, InventoryPro, and HR was trying to find jobs for all the people who had been displaced within the company. When it was time to recruit candidates, Tom looked internally first .

Sara, one of the InventoryPro team, had the qualifications, at least on paper. But Sara also had a reputation for having bounced around the company for more than a decade. She’d been on “get well plans” and on the edge of being fired three times, but had always pulled it together long enough to climb out of probationary status.

Tom rationalized an explanation in his mind:

She just needs a fresh start. She’s bright and she’s got 12 years of experience. With the InventoryPro situation, I’d have to go through all sorts of hassle for an external hire when there’s someone from the InventoryPro team who could do the job.

So Sara started on the project. Tom—and the rest of the team—soon experienced first hand the behaviors that had landed Sara on employment probation three times.

Within three weeks, Jessica, the team lead, was in Tom’s office. “Tom, I’m worried about Sara’s impact on the project. Every meeting turns into a debate. It’s starting to wear on me and the team. Plus the work she does isn’t…well, it isn’t very good. I’ve had to ask her to redo 3 out of 5 deliverables so far. I’m worried that with Sara’s rework, we’re falling behind schedule.”

“You’ve got to give her a chance, Jessica,” Tom said. “Maybe she didn’t understand what she was supposed to do. She’s new to the team, after all.”

“I don’t know, Tom,” Jessica said. “I reviewed the completion criteria for each deliverable with her, and gave her examples from the last project. I wouldn’t expect to coach even a junior employee this much.”

“I’ll have a talk with her and sign her up for a communications skills class.” Tom said. “And I’ll talk to her about the quality of her work. But you need to cut her some slack and give her some time to fit in with the team.”

The next week, Jessica was back in Tom’s office. “It just isn’t working out with Sara,” Jessica said. “She sits through our work sessions glaring, and after the meeting tells the other team members how stupid my approach is. It’s really taking a toll on the team—they’re wasting energy bitching about Sara instead of working on the software! We’re definitely falling behind schedule!”

“I’ll bring Sara up to acceptable performance. I’ve never fired anyone,” Tom protested. “I’ll turn her around: I’ll meet with her every day to coach her.  It’s going to take time, Jessica. You need to be patient. ”

“How much time? How long before Tom decides he’s done enough to try to help Sara?” Jessica wondered.

Where to Begin

Tom made a poor tradeoff when he decided to avoid a hassle with HR and hire a person with a history of poor job performance. While Tom’s situation is extreme, sooner or later every manager is faced with a decision about how long to coach an employee who is struggling.

When you are faced with an employee who isn’t working out, ask yourself these questions:

How much rework am I willing to accept?

How much time am I willing to add to the schedule to accommodate poor-quality work?

What effect is this person having on the rest of the team? Am I willing to accept that effect?

What sort of message do I want to send to the rest of the team?

How much time am I personally willing and able to invest in coaching this employee?

Am I investing my coaching time where it will best serve the individual, the team, and the company?

If you’ve decided to coach an employee who is struggling, make a plan with a time limit.

Have a frank conversation about the gaps you see between the results you want and the results he’s achieving.

If you are both willing to work to close the gaps, develop a training and skills-building plan and agree when and how you’ll reassess progress.

If you don’t have other appropriate work and can’t accommodate the time investment to build skills, coach the employee out of your group. Your HR department may offer support to help him find another job internally or externally. Although it may be tempting to help the person yourself, don’t do it! You are not a job placement service, and getting involved in the job search will make it harder for you to fire the person if he doesn’t find other work outside your group in a reasonable amount of time.

When the employee doesn’t recognize the skills gap or there are behavioral problems, establish a “get well plan.” Determine the changes and actions that you’ll need to see and set a time frame. My preference is 30 – 60 days, with weekly checkpoints along the way. Your company may have specific guidelines, so check with your HR person or the company lawyer. Be ready to terminate employment if the employee isn’t willing or able to meet the goals of the plan.

What happened with Sara? Three months later, Jessica had moved Sara off the supply chain project. The team couldn’t recover the time and productivity they’d lost while Sara was on the team, but they were starting to settle in and re-gel.

Tom devised a one-person project for Sara to work on. It wasn’t really important work, but it kept Sara busy while Tom continued to follow up on her work and coach her twice a week. I doubt Tom will ever fire Sara, since doing so would admit he’d failed to bring her performance up to a suitable level.

Many managers, like Tom, have a hard time making the decision to stop coaching and move an employee on to another job inside or outside of the company. Some will spend months or even years accepting marginal performance and lowered productivity for the entire team rather than make a difficult decision.

Take a look at the bigger picture of the work to be done, the productivity and the morale of the team. Then ask yourself: Where should I invest my time?

When managers want to improve financial results, they turn first to trimming costs.  This is the logical first place to look if balance sheets are your primary view into how the organization functions.

Many cost cutting measures do have an immediate effect on the balance sheet.  A layoff reduces labor costs immediately.  Cutting travel, training, and conferences is less dramatic, but also shows immediate effects. There are more targets deep in the budget detail lines:  unplugging the break room coffee machine, rationing pencils, paper, markers.

But the cost of cutting costs rarely shows up on the financial reports.

A small engineering firm axed the company lunch room and eliminated over $200,000 per year in costs. That gave an immediate boost to the bottom line.

One side-effect was visible immediately. Without the lunch room, some people at ate their desks, and some left the building for lunch. That was probably a wash, with the longer lunches canceled out by quick lunches gobbled while catching up on email.

A more insidious side-effect was invisible (at least on the balance sheet) for several months. The lunch room had been a hub of informal, cross-department communication.  People who didn’t meet in the normal course of business ran into each other over lunch.  Someone from environmental remediation might learn about a new potential project from someone working on a run-off project in the mining division.  Someone working on a mine project might learn that one of the landscape architects was looking for more work, and bring him in on a site remediation project.

Middle managers lost the big picture of what was going on in the company—which made it more likely they make decisions that were good for their group, but bad for the company. Specialists lost opportunities to gain the perspective of other disciplines on their projects though informal means.  Formal consultation required a billing number, so they didn’t happen.

That led to poor decisions, and disappointed customers.  It took half a year before the communication gaps started showing up in project cost over-runs. Finally, the company lost a customer.

That captured management attention. The immediate response was to make more cuts—including a layoff.  Fortunately for the company, one of the partners insisted on a systemic analysis to explain what had changed before taking drastic measures.

Focusing on costs almost always increases costs, even if the balance sheet looks better (at least in the short run).

If you want to improve financial results, don’t just look at the balance sheet.  Look at how your company creates value for the customer.

For a start, follow a product from the idea stage all the way to software on a customer’s computer and money in the bank. There are almost always ways to make value creation faster and more effective.

You can start with a simple flow sketch.  As you make the sketch, notice:

How much coordination overhead is self-inflicted?  One organization I know had trouble developing by feature.  The company was organized by component groups. Each group had it’s own set of requests and it’s own schedule—which by some mechanism resembling a miracle—was planned to come together in a working release every six months.  Managers spent weeks negotiating, cajoling, and demanding time from various component groups to get a feature out the door.  Once they gained agreement, it was  full time job to facilitate meetings, track  tasks across multiple groups, and manage dependencies. When decided to try a cross-component team as an experiment, most of the coordination overhead disappeared.

How much rework might be avoided?  Another was developing by feature, but waited until all the functions with in the feature were coded to start testing, usually a period of three to four months.  Then they began the process of discovering misunderstood requirements, infrastructure that didn’t work as anticipated, and errors that started in one part of the feature and were then perpetuated through-out the feature. Most companies can’t afford (and don’t need) a process that eliminates all rework.  But there are methods that can reduce rework and find and fix errors early, before the rest of the software is build on a shoddy foundation.

Where are the delays in the process?  Delays in knowledge work often center on decision making and approvals—involving the wrong people, excessive sign-offs up the chain, processes where the rigor doesn’t match the risk.  (A friend told me about an approval process in this company that cost over $50,000 in management time to okay purchasing a $300 piece of software for one desktop.)

These are just three of the areas for opportunities to enhance value creation. And when you do that, costs will go down. Focusing on how you get products out the door and making that process effective will improve financial results in the long-run more than any one-time cost-cutting measure will.

***

If you are ready to explore value creation in your company, I am here to help. Curious about how we might work together?  Start here.
© 2010 Esther Derby

Authors Note:  The relationship between an employee and his/her manager determines how long a person stays with a company and to some extent how productive he’ll be while he is there.  That relationship also plays a part in stress level,and physical health. Choose carefully.

A couple of times in my career I’ve ended up with jobs that sounded good on paper but left me wondering “What was I thinking!?”  The management responsibilities and technical challenges of the job were where I wanted to be; my manager’s style was all wrong, at least for me.

Good hiring managers don’t just look for skills. They look for a good fit  between the candidate’s work-style preferences and the culture of the group, and so should you.  Before you go looking for your next job, do what the hiring manager is doing:  Don’t just think about the “on paper” aspects of the job; consider how you prefer to be managed.  Analyze what you want in an employee in this position – manager of you.

Think about past managers you’ve worked really well with.  What made that relationship work?  How about bosses you didn’t click with?  What were some of the factors that made the relationship difficult? Identify what factors will knock a potential boss out of the running for you.

Look at your own personal preference and style:

Is it important to you to be able to talk to your boss about risks and issues as well as what’s going well?

Is it important to you to know what is expected so that you can work within those boundaries?

Do you prefer to work with broad discretion to carry out your responsibilities in your own way?

Use behavioral interviewing and open-ended questions:

What sort of information is important for you to have in status reports or one-on-ones?

How have you approached a situation where a direct report comes to you with a serious project issue?

How do you prefer to learn about problems or obstacles?

How have you handled defining the boundaries of this position in the past?

Tell me about the results you look for in this position.  What is most important in the way the work is done?

Be prepared for the candidate boss to be a little unsettled by this sort of questioning.  After all, you are turning the tables on the hiring manager and some he may feel “on the spot.”  Watch how the candidate boss responds:  Does he pause and then answer your questions?  That’s a clue that your manager candidate is open to exploring your working relationship. Does he become angry and snap, “I’m asking the questions here!”?  Cross this one off your list.

Finding a new job isn’t just about the title, job description and technical skills.  It’s about relationship and fit.  Identify what you want in a manager.  Ask questions.  Look for clues.  It’s all information that will help you choose an employment situation that will work for you and your new employer.

Authors note: A recent blog post on Bob Sutton’s Work Matters reminded me of this little piece I wrote a while ago.

A simple thank you can make a difference; appreciation builds good will, and reminds people that they are valued as human beings, not just as CPUs (Code Producing Units) or FTEs (Full Time Equivalents).

In a recent workshop, I described an exercise for expressing appreciation. “That won’t go over here,” stated Patty, one of the managers participating in the workshop. “These are engineers; they don’t want that mushy stuff. Besides, they know that we value them.” Patty didn’t notice that several of the engineers were shaking their heads in disagreement.

The engineers in Patty’s company aren’t the only ones starved for notice and appreciation. A recent Gallup Poll report quoted this statistic: “…the number-one reason people leave organizations is that they don’t feel appreciated, notes the U.S. Department of Labor.”

Given the high cost of replacing knowledge workers, reducing the number-one reason for turnover seems like a good investment. And when you consider that this investment doesn’t cost a dime, why not eliminate the appreciation gap?

An Appreciation Primer

When you offer appreciation, appreciate the person, not just the work. Most people like to hear “you did a good job.” But a comment on the quality of work is an evaluation. I like to use this form, which I learned from the work of Virginia Satir:

[Name of person] I appreciate you for [contribution, action, quality].

I might say, “Tom, I appreciate you for moderating technical reviews. It’s really making a difference in our code quality.”

I’ll admit that this felt awkward the first time I tried it. But I also noticed that these words had a very different effect than “You did a good job” or “Thank you.”

Appreciation Guidelines

Be authentic.

Authenticity means that you really do believe what you are saying. Pavlov proved that it’s possible to shape canine behavior by providing rewards for a desired response. People, however are not canines, and they are quick to recognize manipulation. Going through the motions isn’t enough.

Appreciate privately.

Most people don’t need or want their manager to gush over every accomplishment in public. In fact, public recognition is uncomfortable for many people. A word in private will let people know that you do notice and appreciate.

Appreciate weekly.

“Atta boy” once a year during a performance evaluation isn’t enough. Notice and comment on a contribution every week–and keep it authentic. Rote appreciation doesn’t work. If you can’t find a single thing to appreciate, that’s a sign there is something wrong with the relationship.

Traps to Avoid

Don’t dilute the value of appreciation.

Some well-intentioned person devised the “praise sandwich” as a recipe for delivering feedback. A praise sandwich surrounds criticism between two bits of praise. I suspect this person wanted to ensure that the feedback recipient was in a receptive mood by making them feel good. In reality, the praise sandwich conditions people to expect a slap after a positive stroke. If you have feedback to offer, do it! Don’t dilute the value of appreciation by only giving it along with bad news.

Token rewards anger as often as they delight.

One colleague received a movie ticket from his boss after he’d worked well into the evening to fix a critical defect. His response to the reward was one of anger. “After I already spent one evening away from home, he wants me to spend another one… without my wife!” he stated in disbelief.

Don’t wait.

When Sara handed in her resignation, her boss told her she was the best project manager he’d ever worked with. “Why’d he wait until I quit to tell me?” Sara fumed later. “Maybe if he’d let me know that he noticed what I did for the company I’d still be there.” A few simple words a week could have kept Sara on the job.

You may feel awkward when you first try giving appreciations—I know I did. Practice in a low-risk situation, maybe by telling a store clerk you appreciate her for helping you find just the right item. Watch what happens and practice until it feels natural. Then try out this simple practice at work.

© 2010 Esther Derby

Understanding the market and your customers (and potential customers) is the first step in building products that will sell and keep the business in business. You need to know enough about both so that you can plan your product investments and know which features to deliver when.

If you aren’t sure what your customers think about your current products, it’s time to find out. This doesn’t mean you have to launch a huge market research or competitive intelligence effort. You can begin by reviewing customer support data, interviews, and watching your customers use your products.  These simple acts of analysis, listening, and observation will reveal how your customers currently use your product, which features need improvement, and identify unmet needs.

Read about Your Customers’ Experience

If you have any sort of technical support line, you already have information about how your customers experience your software.

If your support calls are in a data base that doesn’t allow you to sort, slice, and dice the data, move it to one that can.  But don’t make it such a big project that it gets in the way of learning about your customer’s experience.  You can always take a sample, start with one product, or look one months worth of calls as a starting point.

The first step is a rough sort by feature or module.  Is there an area of the software the generates more calls than other areas?  Start there to understand the pattern and content of the calls. Look at your sample as a time series.  Is there any pattern in when the calls occur or spikes in the number of calls? Investigate.

Put yourself in the customers shoes, and try to see the issue from a customers point of view.  The data from support calls may have information on how problems affected the customer, but that information is filtered by the questions the support person asks and the from used to capture data. You need that information pure, straight from the customer. Follow up with customers who have called support recently to learn about the disruption or irritation they suffered.

Talk to Your Customer

Interview a sampling of customers, a dozen or so. You may choose a representative sample, or focus on people who have reported problems or called technical support.  Design a short interview—no more than 45 minutes.  After all the interviews, analyze the data. Look for themes related to difficult to use features or missing features.  Both will give you clues on where to focus future efforts.

I think it’s important for all people involved in building software to get to know their customers.  However, some managers worry that developers lack the social skills and polish to speak with customers.  It does take skill to interview customers, so give everyone a crash course on the three iron rules of customer interviews:

1) Never argue with the customer.  Even if you disagree with your customers assessment, do not argue the point.  If you win you lose because the customer will feel discounted. If you lose you lose because you’ve shown you don’t understand your own software.  In both cases, you’ve damaged the relationship with the customer and destroyed a chance to learn.

2) Don’t turn the meeting into a training session. If the customer is using the software incorrectly, take that as information about the product, training materials, or support.  At the end of the interview, offer to arrange a follow up call for training.  If you start instructing during the interview, you’ll miss out on learning from the customer.

3) The interviewee should talk more than the interviewer.  My rule of thumb is that the interviewer should talk no more than 30% of the time and spend at least 70% of his time listening to what the customer has to say. This is impossible if the interviewer relies on closed questions, which can be answered with yes or no.  Open-ended questions and probing questions invite the customer to provide deeper answers and reveal more about his experience with the software. (For more on how to interview your customers, see Building a Requirements Foundation with Customer Interviews, insights Vol. 2 No. 1.)

Observe Your Customer

Visit your customers and observe them in their context.  Watch them using the most common use features, those that the find easiest to use and those that they find difficult.  Take notes, and take pictures. User Experience expert Jared Spool advises that people should invest time every few weeks observing customers use the software. You say you can’t visit?  What about skype or video conference? Webcams are cheap and getting better every day. There’s really no excuse.

As you go about learning how your customers experience you product, notice how easy or how difficult it is to talk to your customer.  One client of mine had to go through multiple levels of approval in order to make a follow up call to a customer. Unless you work in an industry with high security or secrecy, it’s a big red flag if you can’t gain access to your customers. It signals that the customer’s point of view is distant, diluted, or discounted by the people who manage software development. How can you satisfy your customers when the people who build the software are prevented from getting to know them?

When everyone involved in writing software knows the customer, benefits abound.  People understand the customer’s context and concerns. They may find out that the feature they thought was wonderful is unwieldy. They’ll see the pain of duplicate data entry, foot-long drop down lists, and navigation that feels like searching for a needle in a hay-stack.  Feedback is critical for improved performance.

Are you getting the feedback you need to build great products?

***

If you would like to learn more about how your customers experience your software, my Customer Interviews workshop will give you the skills to prepare for and conduct effective interviews.