Category Archives: management

Building Effective Teams: Miss the Start, Miss the End

(This article originally appeared on Gantthead.com)

“The beginning is the most important part of the work.” Plato, Greek philosopher and writer, 429–347 B.C.E.

I’ve written several articles about a manager’s relationship with a team that has already formed. A manager’s relationship with a team as they work is essential for cultivating a self-organizing team and maintaining a link with the organization. But a managers role in growing effectives teams starts long before the work actually begins.

The 60-30-10 Principle

J. Richard Hackman, has been studying teams for decades. One of his most significant findings is that 60% of the variation in team effectiveness is attributable to the design of the team, 30% to the way the team is launched, and 10% to leader coaching once the team is underway. By “design of the team,” he doesn’t just mean picking the best people. You also have to think about the nature of the work, articulate a goal, and plan for enabling supports.

Aim for Flexible, Long-lived Teams

You can call a group of people a team the first day they come together. But that doesn’t mean they’ll achieve teamwork right away. People need time to understand each others strengths, weaknesses and work styles. They need to agree on, try, and adjust the way they work together to find their groove.

In many organizations, managers from cross-functional teams to meet the needs of a specific project. In some cases, that means the team will be together for a long time. More often, it means teams will be disbanded after a few weeks or months. That’s barely enough time for a team to gel and gain the benefit of the team effect.

Analyze the work that’s in the pipeline. Aim to organize the work so that teams have “whole” work–creating a product or service that has meaning from a business perspective. Look at the trade-offs and tensions inherent in the product. Make sure people who represent those aspects are part of the team. Look for dependencies and to the extent possible, keep them within a team boundary. Form teams that have the breadth of skills to handle a broad range of work.

Then, bring work to the teams, rather than reforming teams for each new project. You won’t find a team that’s perfect for all the work in the pipeline. When teams lack a specific expertise, keep the core team in tact and add expertise.

Articulate a Compelling Goal

An effective goal statement does two jobs. First, it focuses the attention and effort of the team. When the team has a shared understanding of what their task is, they pull in the same direction.  When teams have don’t agree on the goal–or the goal is so vague it’s open to many interpretations–team members waste time and brain cycles arguing, working at cross purposes, or doing the wrong work.

Second, a well-formed goal engages the team in a meaningful challenge. An effective goal provides a sense of purpose to the teams work. The goal might be solving an important problem, enabling business, launching a new product, or meeting a  customer need. State the goal in a way that taps into purpose.

Take the goal handed down to the FinCore team: “Maintain the FinCore Product.” That goal isn’t enough to get someone out of bed in the morning. It talks about a process (maintenance), but leaves out the purpose. It misses the opportunity to tap into pride-in-work.  A more compelling goal might be:

Sustain the FinCore product by adding necessary functionality and ensuring the technical integrity of the code, so we can provide uninterrupted service to 40,000 customers.

Not all work is exciting and sexy, but all work should have a purpose. Making that clear will help people focus and engage.

Pillars of support

The right people and a compelling goal are a good start. But if you neglect the pillars of support, the team may still wallow. The pillars of support are:

Information related to the situation, domain, problem and technology. These reinforce the goal, and provide the context for the team to make good decisions.

Material support, such as machines, tools, facilities, adequate budget, and supplies. Adequate material support communicates that the work of the team is important. Starving a team for resources undercuts the goal and creates cynicism. Paradoxically, providing too much isn’t good either. A certain level of constraint can drive creativity (and over constraint kills it).
A strong foundation for team performance.

Expertise to supplement the knowledge and skills of the team when needed. Even when the team has all the skills required by the task, they may need an expert eye for consulting or reviewing. Some times there is some aspect of the work that requires scarce knowledge. It may not make sense to develop that knowledge on the team, or it may only be needed for a short time.

Feedback loops that connect the team to the organization. Regular demos of working software allow the sponsor or product owner to see how the team is doing–and allows for course correction. The heartbeat of progress builds trust.

If any one of these pillars is missing, you’ve put the team at a disadvantage.

This Sounds Like More Work for the Manager. Why bother?

Team design is a pay me now, pay me later proposition. It’s a myth that you can throw a group of people together and they’ll gel as a team. Strong effective teams don’t just happen by some magic chemistry. Well designed teams are more resilient. They make better use of the knowledge, talents, and skills of team members. They function and stay on track with relatively little management intervention. You may not always be able to bring together the perfect team. But you can set a team up for success….or failure. It is up to you.

Rethinking Manager’s Relationship with Agile Teams

This article originally appeared on gantthead.com 

In the early days of agile, some pundits (and developers) cried, “We don’t need no stinking managers.”

By now, most people realize that organizations still need management (and people in management roles) after they adopt agile methods. However, if those organizations want all the benefits of agile, managers must also change the way they work.

Managers can play an even more valuable role in organizations as teams become self-organizing and take on more responsibility. But if managers want teams to take more self-responsibility, they need to shift their focus from monitoring the day-to-day work of individuals and let teams grow up.  Here are three common areas of confusing as managers and teams negotiate their new relationships.

Messing with Team Membership

No group is a team the first day they are together.  Becoming a team takes time–time to learn how each person fits in and contributes, time to lean how to work together, time to develop group identity and trust.

If you want the benefit of the team effect, provide the enabling conditions:

  • A clear and compelling goal
  • Appropriate constraints
  • Stable membership
  • Time for the team to gel.

Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.

That doesn’t mean that team membership never changes. People leave (or are asked to leave) and people join. Hiring new people for a team should always be a joint decision, involving team members. And when people are asked to leave it shouldn’t be mysterious to the team why that happened. (For more on hiring as a collaborative process, see this article.)

Delegating then De-delegating Decisions

As a general rule, delegating decision making to the people who are closest to the work is an excellent principle. Doing so can remove bottlenecks, lead to faster decision-making, and improve customer responsiveness.

Except when it doesn’t, as happens when a manager and a team haven’t clarified who makes which decisions. Or when a manager delegates a decision, but doesn’t clarify boundaries or constraints around that decision.

When managers see that a team is about to make a poor decision, they may be tempted to countermand that decision. Countermanding a decision prevents the problems that would have been caused by a faulty decision. But it leads do a different kind of problem–loss of trust between the team and the manager.  Team members may feel the manager wasn’t serious about delegating decisions in the first place. They may believe that he only delegates decisions on the condition that the team decides exactly what the manager would choose.  Such situations will damage a mangers relationship with the team.

If the team makes a decision that will result in real harm to the company, a manager must intervene. How he intervenes makes a difference. To prevent real harm to the relationship, refrain from blame. Acknowledging that key constraints weren’t clear or communicated will help. Use the opportunity to learn from the mistake, and to set appropriate boundaries for team decisions.

Strategic decisions belong to management. But tactical decisions, course corrections, and decisions that affect day-to-day work belong with the development team. Some decisions fall in between, and require both management and front-line input.

Work with the team to identify which decisions are squarely with the team, which ones you share, and which ones are management decisions. Then set boundaries, about cost, impact, and scope.

For example, when it comes to hiring a new team member, the decision about what skills and qualities to look for in a new team member is probably a joint decision.  The choice among candidates is best done as a recommendation from the team (which you may over-ride at your own peril). But the offer and salary are neither a team decision or a joint decision. Employment terms and salary (in most organizations) are management decisions.

Clouding Team Commitments

One of the secrets ingredients for team success is that team members make commitments to each other to complete their goal. Peer pressure can be a wonderful thing. But commitments can lead to conflict, it’s not clear who makes commitments to whom about what.

Fred, a member of an agile team, participated in a planning meeting where he and his teammates committed to deliver six stories during the next iteration.  Then Fred when to the team manager, Megan, to get approval for a two week vacation, starting the second week of the next sprint–as he had done every spring for the last four years.

But this time, the result was a mess. The other team members were mad at Fred, for committing his effort to the team, when he knew he wouldn’t be in the office for half the next sprint.  The team members were mad at Megan, too, for giving Fred permission when they thought he should have talked to them first. Fred and Megan felt attacked–for doing what they’d always done.

Managers are still point-person for matters of company policy. But work commitment a happen between the team as a whole and their product owner or customer. Megan and Fred landed in the middle of that. In the end, Fred took his vacation. The team needed to renegotiate their commitment to the product owner. Megan attended the meeting to explain what had happened to the product owner.

When Fred (gratefully) returned from two weeks at the cabin with his three kids and the in-laws, they all had a sit down. They talked about which commitments the team could make, what the team could negotiate among themselves and where Megan needed to be involved for legal reasons.

I hear managers say they want teams to take more responsibility. The best way to make that happen is for managers to stop acting in ways that take responsibility away from teams. Start with these three areas.  Then, spend some time examining your relationship with the team. What else could the team do that would enhance their autonomy and responsibility? What else are you doing that might confuse the team about how much responsibility they really have?

Yes. No. Negotiate.

Many people are conditioned to say Yes to every request that comes their way.

I met a CIO like that. He told me his policy was to never say No to the business. So he always said Yes, and the business was always angry because things he agreed to didn’t get done, or got done poorly or far later than they wished. His Yes meant nothing.

Sometimes, a clear No is the best response. When there’s no real possibility of meeting a request, No allows the person making the request to adjust accordingly. That may mean changing plans or finding another way to get some work done.

But other times, No is the starting point for a negotiation. Here’s a story about how one new manager learned to stop saying Yes, and getting talked out of No.

Recently, I met with Monroe, a new manager, over lunch. He was feeling overwhelmed, and recited a long list of projects he was working on. Monroe complained that his boss didn’t seem to realize how much work he was doing.

“Do you ever say no?” I asked.

“Of course I do!” Monroe said. “I try to say no, but then he gives me all the reasons it’s important for the company to do this extra project. He does have good reasons for what he’s asking for, so I cave in. But I can’t see how I’m going to get all this work done!”

Monroe isn’t alone in having difficulty in turning down his boss’s requests. Some people have a hard time saying no because they fear offending. Others have rules that say “Don’t disappoint,” or “Always be helpful.”

Rules may keep us from saying no even when we want to—when we realize saying yes doesn’t serve us. Some people don’t consider their own needs when they say yes, assuming (albeit unconsciously) that whatever the requester wants is more important than their own priorities, health, well-being, or ability to juggle one more task.

As Monroe and I talked over lunch, I began to understand that Monroe had a slightly different problem. He could say no, but he just couldn’t hold it. If Monroe stood firm in his refusal, his boss might think he wasn’t up to his new management role. But Monroe was paying a price for backing down.

Since he said yes to all the requests eventually, Monroe was actually training his boss to keep pressuring him until he wore him down. In doing this, Monroe was also bringing about the result he feared most: showing his boss he wasn’t up to his management job by failing to prioritize and follow through on agreements.

Underneath his inability to say no and have it stick Monroe suffered from having a two-speed switch: On (Yes) or Off (No). What he needed was a way to start a negotiation toward an agreement that recognized organizational goals and took into existing work commitments into account .

Monroe and I started thinking of ways he could start a negotiation. Rather than simply blurting out “No!” Monroe decided to start by affirming his boss’s intention by saying, “I can see why that’s important to the organization.” Having something to say would give him a bit of time to think.

Then, depending on the situation, he’d use one of these phrases to start a negotiation:

I can’t fit that project in right now. I can do it ___________.

I can’t do that, but I can do this ___________.

I’d be willing to offer________________. Would that help?

This is what I can do. I can do that instead of _______________.  Which is more important?

I can start on that project after ____________.

I can do that AND here is how that will affect ___________ (other work, commitments, etc.).

If Monroe didn’t have an immediate grasp of the impact, he’d one of these answers to gain time analyze the situation:

I need to check with ________ before I commit to that.

I can’t give you an answer I can stand behind until I review my other commitments.

Monroe and I met a week later to check in, and he reported on his boss’s latest request. “It was sort of funny!” Monroe started. “My boss asked me to take on another task, and I used one of the responses we rehearsed. Then I went over to the white board and did a chalk talk of our current work. When I finished the picture, I turned to my boss and asked him what work I should put on hold in order to fit in the new work.” Monroe grinned. “And you know what my boss said? He said, ‘Now you’re thinking like a manager.’”

The Agile Blindside

(this article originally appeared on gantthead.com)

Agile project management depends on transparency and feedback. Visibility into the product and process is built in with iteration reviews and retrospectives. Task walls and Kanban boards make progress (or lack of it) and bottlenecks obvious. Stand-up meetings seek to raise impediments to management attention. But are managers ready to hear about these problems?

If organizations want to realize the benefits of agile methods, managers need to act on the problems that bubble up from teams, deal with unexpected events on projects and proactively find and fix problems that derail projects. Unfortunately, many managers behave in ways that communicate they aren’t interested in solving problems–and ensure they won’t learn of problems until it’s too late.

“Don’t bring me problems, bring me solutions.”

I suspect that managers who repeat this sentence believe it will encourage people and teams to solve problems on their own. But people don’t approach their managers with problems they know how to fix and can solve (or believe they can solve). The problems they raise are ones they don’t know how to solve, don’t have the organizational influence to solve or need some help to solve.What really happens when managers talk this way? Team members struggle in isolation or ignore problems, hoping they will go away. Managers who tell people not to bring them problems ensure that they won’t hear about small problems that are part of a larger pattern.

“Failure is not an option!”

Managers who rely on this exhortation ensure they won’t hear about risks and issues. The phrase sends the message that success is a matter of character and will rather than the result of planning, observation, re-planning and course correction when something unexpected occurs.

Will and character are assets in any endeavor; however, they are not sufficient for success. Success requires removing impediments and proactively finding and ameliorating problem situations. Failure may not be an option that managers like, but it is always a possibility; ignoring that fact forces problems underground and makes failure more likely.

“The thought that disaster is impossible often leads to an unthinkable disaster.”- Gerald M. Weinberg

“Get with the program or get off the bus!”

When managers give the impression that their minds are already made up, subordinates are less likely to bring up weaknesses, problems or alternatives. People fear that their concerns won’t be heard. Worse, they fear (often with reason) being labeled as naysayers or whiners. Discourage people from shining the light on problems and they’ll stop.

But managers don’t need to be obvious in their discouragement; more subtle actions can also plug the pipe.

Interrupting

Interrupting a person who brings unwelcome news makes it harder for that person, who is already facing a difficult conversation. People interrupt for many reasons–excitement, the desire for more details, etc. But to the person being interrupted, a stream of interruptions can feel like an interrogation. Interrupting implies impatience–and that anything the interrupter has to say is more important than what the other person was about to say.

Ignoring Intuition

A couple of years ago, a friend felt uneasy about an action his manager was taking. He couldn’t quite put his finger on why he felt concerned, but his feeling strong enough that he went to his manager–who dismissed his intuition, telling him, “Come back when you have some facts and we can have a logical argument.” But the situation outpaced data gathering and blew up.

Asking for excessive proof and demanding data ensures that a whole class of complex and systemic problems won’t come to attention early.

Non-verbal cues

I coached a manager who furrowed her brow and tapped her pencil when people told her about problems. She was thinking hard. They thought she was irritated with them for brining bad news.When there’s a problem on a project, the earlier you know about it, the more options you have to mitigate the impact, make a course correction or re-set expectations. But you won’t hear about problems if you plug the information pipeline.

“The problem isn’t the problem. Coping with the problem is the problem.” – Virginia Satir

As much as we might wish there were no problems on projects, that’s not the way the world works. Problems are a normal part of life. Managers need to know about problems so they can see patterns, find options and steer projects.
Here are three things you can do to make sure your information pipeline flows:

Tell people you want to hear about problems. Sounds simple–and it is. Assure people that you understand that nothing goes exactly as planned and you don’t expect perfection. You may not want every problem dropped at your doorstep to solve–but if you act as if having problems is a problem, you won’t learn about impediments and issues when they are small.

Learn how to listen. At a recent talk, a participant asserted that people from [fill a non-western country here] don’t know how to say “no.’” This is not true. What is true is that many Americans don’t hear it when people from different cultures say “no.” The same is true for hearing about problems. If you want to build an early warning information system, you need to learn how to listen. That means refraining from interruptions. It also means listening for less obvious cues and what isn’t being said. When there’s a long hesitation preceding a positive statement, there’s more to learn. If you don’t hear any mention of risks or issues, delve deeper.

Teach people how to speak up. I don’t want to clog the information pipeline by implying that I only want to hear about problems that have ready solutions:

The most important and dangerous problems don’t have an obvious fix.Here’s a framework that has worked for me. It provides useful information and an agreed-upon format that reduces the psychological barriers to raising issues:

“Here’s my hunch…” This makes it explicit that I don’t require excessive proof.
“Here’s why you need to know about it…” This signals that I recognize that I don’t know everything.
“Here’s my data…” If there is data, it’s good to know. And I’ve heard about intuition being born out enough that “I have a bad feeling about this” is good enough for me.
“Here’s what I’ve considered or tried…” I do want people to think about the issue and I want to hear about their thinking. Problem solving is improved by multiple points of view.

Standard agile practices such as visible charts, frequent demonstration of working product, and retrospectives are all ways to make both progress and problems visible. But if people don’t feel safe to bring up issues, you won’t hear about them until it’s too late. If you take the actions outlined here, it will be easier for people to bring up problems to you. Problems are part of life–and projects. Pretending otherwise creates a culture for them to hide and fester.

Fixing the Quick Fix

Here in the United States, our business culture tends to be action-oriented. We value the ability to think fast and act decisively. These qualities can be strengths. However, like most strengths, they can also be a weakness. Taking action when you don’t know the facts can lead to irreparable harm. Deciding too quickly before you’ve examined your options can lead you down the wrong path. Fixing fast may assuage symptoms but leave the underlying problem to fester.

Treating symptoms may work with the common cold, but with many technical and organizational problems it’s a prescription for disaster. Before you chase a solution, slow down and make sure you are looking at the underlying problem, not just soothing symptoms. (Sometimes, as with the common cold, you do need relief from symptoms in order to make any progress.) Of course, we can’t always tell right away whether we are fixing a symptom or an underlying issue. But, if the problem keeps coming back, you can be sure that you’ve been dancing around manifestations of the problem, not tackling the problem itself.

Start by Questioning Your Questions

Every question contains assumptions. While a question opens one avenue of inquiry, it closes others. The questions you ask constrain your thinking about the problem and your eventual solution. For example, in one company, the executives weren’t satisfied with the speed with which the IT department delivered projects. They sacked the VP of the IT department and brought in a new one with a reputation for decisive management action. The new VP immediately started asking questions, which seems like a good sign, until you know her questions:

Where is the dead wood?

How can we get the testers and developers to work harder and move faster?

These questions assume the source of the problem: lazy and incompetent people. But, what if the reason projects are late has something to do with the fact that people are assigned to several projects at the same time or that priorities change so quickly that teams never reach “done” before they are pulled to work on the latest urgent issue? The VP has already narrowed her inquiry and will only arrive at “solutions” that involve firing the “dead wood” and whipping those deemed “live wood.”

Examining our questions is critical, because not only do our perceptions influence the language we use, but also the language we use influences what we perceive.

Starting with a more general set of questions will help reduce perceptual bias and uncover the facts of a problem situation:

What are the visible symptoms?

What other effects can we observe?

Who cares about this issue?

What is the impact on that person/group?

What is the impact on our organization?

What other factors might contribute to the problem situation?

What other events might influence the context?

These questions may lead you closer to the real problem, or at least help you see whether the area you are looking at is the most fruitful for alleviating pain. Based on this, choose where to delve deeper, and get more specific as you explore the details of the situation:

When does the problem occur?

How frequently does it occur?

Is the occurrence regular or irregular?

Does it always happen, or is it an exception?

Under what circumstances does the problem occur?

What are the circumstances under which it doesn’t occur?

What else is happening around the same time? Are those factors connected?

At this point, you may start to feel you have a pretty good idea of what the problem is, so …

Back Up Your Hunches with Data

These questions will give you some clues as to the problem, but data will confirm your hunch (or point you in a different direction). I’m not talking about a measurement program here, but simple, “good enough” data gathered from observation or existing sources. Once you have data, look at it from several vantage points, or you may miss something important.

For example, at a large financial services company, operations analysts collected data on the number of minutes during which each application was unavailable during core business hours. They presented the data at a monthly management meeting using a pie chart. The chart clearly showed which application had the largest portion “outage minutes” for the month. Presenting the data in a pie chart facilitated putting the manager of the offending application on the hot seat at the management meeting. But, it didn’t help much with understanding the problem, or knowing where to look for solutions.

By the time I arrived to help them solve their problems, they had many months of data, and looking at it differently provided useful information.

I used the questions above to guide how I viewed the data. I looked at the total number of outage minutes each month. I look at the trends for each application. I looked at outages in time series. But, the data didn’t answer the question, what is the impact on our organization? I set out to answer that question, and found that not all outages were equal. A day-long outage in a specialized application only affected ten people. A five-minute outage in another system meant everyone in the department—several hundred people—couldn’t access any applications, but it had only happened once. A short outage in an application used by one-third of the department that happened every day accounted for most of the outage minutes over time. Knowing this didn’t solve the problem, but it told them where to focus their fixing.

Quick-fixers may bemoan the amount of time I spent cleaning the data, looking at it this way and that way, asking more questions and gathering more data. It took about a week. Of course it did take a bit more time to repeat this process at the application level. Still, taken in total, the time spent asking questions and gathering data was far less than the time that had passed while management tried to understand the situation with data presented in way that hid useful information—and less then the outage minutes for all affected employees for one month.

Generate At Least Three Candidate Solutions

Now, it’s time to look for possible solutions. Quick-fix thinking conditions us to choose the first idea that’s even remotely plausible. Don’t dismiss your first idea, but don’t stop there either. Develop at least three candidate solutions. You may go back to your first idea, but by developing additional options, you’ll understand the problem better. If you have difficulty thinking of more than one candidate solution, turn your thought process upside down and ask, “How could we make the situation worse?” That paradoxical question almost always jiggles more ideas loose.

As part of developing a solution, identify at least ten things that could go wrong with each candidate solution. Looking at the downsides might send you back to generating more options. Sometimes the best solution isn’t the most elegant; it’s the one with the fewest or least objectionable downsides.

Once you have several options to choose from, choose one and put it motion. Chances are it won’t work out quite as planned—and that’s an opportunity for learning. Observe and gather data, re-adjust, and try again.

Every solution carries the seed to the next problem. That’s a given. When you apply systematic thinking to the problem, it’s less likely that next problem will compound the problem you were trying to fix in the first place.

This article originally appeared on stickyminds.com.

Still No Silver Bullets

Not so very long ago, I made my living writing code. My colleagues and I did our best to understand what our customers needed, and to write code that was easy for other programmers to understand, solid, defect free.  When our managers asked us how long it would take to create a new feature or modify and existing program, we studied the problem, considered how much code we’d need to write or change, how we’d integrate the new functions with existing functions, and what sort of testing would allow us to feel confident our work was complete and correct.

Our managers were often not satisfied with our estimates.  They wished we could deliver working software more quickly.  They suggested we were exaggerating how complicated the work was.  They hinted we were padding our estimates, and spoke sternly of work expanding to fill the available time.  Then they revised the estimates to fit their desires and handed down a due date.

Strangely enough, the work usually took longer than the managers wished it would.  Our managers contemplated the gap between wished-for and actual delivery and pronounced us not sufficiently productive.

And so the quest to improve our productivity began.  First it was CASE tools.  They were supposed to improve productivity by an order of magnitude (they did not).  Then came Rapid Application Development (apparently the managers stopped reading after “Rapid”).  The next improvement, Object Oriented programming, was supposed to save the day (it did change the way we think about programming).  When I left that company, the productivity pill was a development methodology that took up an entire 4-foot bookshelf.

And the quest to improve productivity in software organizations marches on.  More and more often, the quest includes some flavor of Agile Methods, and a promise of hyper-productivity, quick delivery, and change for free.

Agile methods can help achieve business results, get software out the door faster, adjust to new priorities, and dramatically reduce the number of errors that reach the customer.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes.  Armed with such information, managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce working software can allow a company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices add up to a marketable set, managers can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

But when agile methods—extreme programming, scrum, kanban or some combination there of—are imposed as a way to “fix” perceived programmer productivity problems, the effort almost always fails.  Sheep-dip training programs, “going agile” by decree and cherry-picking the agile practices that don’t seem difficult won’t achieve great results.

No method, or set of methods can improve results unless managers also change the way they do their work.

Managers need to get organizational systems working.  Managers must do the hard work of understanding the market, their customers, and make difficult choices about what work to do and what work not to do.  Managers need to study how teams and organizations really function and then create systems and environments that don’t hinder people from doing work.

Writing software is hard.  Agile methods can help.  But they are not a silver bullet.  And no method can improve productivity unless management also changes.

Real leaders make space for others to shine

I’ve seen a renewed cry for leaders in organizations lately. Too often in these discussions, the definition of “leadership” boils down to a role where one individual creates a vision for others to follow. That’s not enough. We need more leadership, not just more anointed or appointed leaders.

“Leadership” is most potent when it’s a verb, not a noun. Leadership is taking actions that will help a group create a product, achieve their charter, grow in capability, solve problems, or improve results.

Looked at this way, we can create organizations that are full of leadership, not just individuals in leadership roles. And, sometimes, the most potent leadership action is the quiet act of choosing to follow. I call that being an active follower. Here are three ways to be an active follower on your group or team.

Step Back and Let Someone Else Step Forward

When one person on the team is the most skilled, it’s easy for the rest of the group to over rely on that person. Overreliance on one person poses a risk. On the operational level, there’s the truck factor: If the most-skilled or sole skilled individual leaves the job for whatever reason (and we hope it’s not because he is hit by the proverbial truck), the team won’t be able to function. No one will be ready to step in. In cases of extreme overreliance, the rest of the group won’t be aware of all the work that person was doing. It might take weeks before someone else can identify and pick up the pieces.

There’s also a long-term risk to team health. When person takes the lead, others don’t have the opportunity to learn and develop their own capabilities. If there’s no place to grow, people will check out and leave—or, worse, check out and stay.

Break Gridlock by Deferring to Someone Else’s Idea

When too many people want to be “the leader,” the result often isn’t action but a complete lack of forward movement. If no one is willing to step back and declare “I don’t have to have my way; let’s try your way this time,” the result is gridlock. An active follower seeing gridlock will choose to follow someone else’s lead for the good of the team.

Take a Supporting Role

There’s a reason that the Oscars have an award for best supporting actor. Without the supporting actor, the work of the lead falls flat. Many jobs demand the work of two people, but it’s not equal in every case. An active follower is willing to take that supporting role and let someone else take the lead. You may not get the credit this time, but chances are that if you’re willing to support someone else today, she’ll be willing to take the supporting role another day.

Back up a team mate when he chooses a difficult-to-implement story–or one that’s at the edge of his technical skills. Pair program with him, but let him drive. Offer informal peer review, offer feedback, or coach.

Let a less-senior member of the team make an important presentation. Play a supporting role by offering feedback on a draft, listening to a practice run, and sharing tips and experience that will help the other person succeed.

When only one person leads, the rest of the team members are turned into passive followers. Unlike active followers, who make a choice to allow someone else to lead in a particular instance, passive followers always hang back. Passive followers fall into the habit of depending on others, whether it’s keeping track of time, coming up with ideas, or galvanizing the group into action. Passive followers wait for someone else to step up, not out of an intention to achieve results, but out of habit or a sense of disempowerment.

Over time, the de facto leader may resent being the only one who attends to time or urges action. When only one person comes up with ideas, the team is missing out on a rich mix of ideas to choose from and may be missing good options. Other team members don’t exercise their own creativity, and the team as a whole misses out on their talents. Some people prefer to let others take the lead and the credit (and also the blame). But, most people want at least a slice of the glory. When they’re always in the background, they don’t get that and eventually disengage. They may even undercut the star who won’t move off center stage so they can get their own moments of fame.

Productive teams count on leadership throughout the team and know that each can lead at different times. Likewise, they expect that, at some point, each will follow another’s lead all in the interests of the team and team results.

When you consider your team or group, which sort of followership do you observe? How is that serving your team? What are other ways to be an active follower? Post your comments.

(An earlier version of this article appeared on Stickyminds.com.)

Should a manager know a language? Yes. One that enables communication with people.

When I talk to people about making the transition from technical work into a management role, one of the recurring questions is whether managers need to know a language. There are strong opinions on both side of the argument:

On one side, people say: “You must know a language if you are to understand the work of your staff and have the respect of developers!”

On the other side, people respond: “Knowing a language isn’t necessary. Managers need to understand the work and not pretend to have more technical depth than they really have.”

Of course, the participants in this discussion are talking about a computer language. But what about being an expert in spoken language?

We communicate every day—to our families and friends, co-workers, managers, and teams. Language allows us to go where we want to go, have what we need, and communicate our ideas and feelings to others. Like many daily activities, our use of language is below the radar of conscious examination.

And that can trip us up. Here are some language traps for managers to avoid:

Absolutes

Have you ever heard this conversation?

Fred: You always forget to take out your testing stubs when you turn code over to CM.

Megan: Sure— I forgot a couple of times and you’ll never let me live it down!

Jennifer: You never include enough information in your bug reports.

Tom: Yes I do. Just ask Chase—he was able to recreate that data purge problem right away.

Always and never should never be used; they will always land you in trouble.

Well, I wouldn’t go that far. These words have their place. But be careful of how you use them, especially when you are hoping to influence future behavior. Always and never tend to focus the mind on finding a counter example. Absolutes set up the dynamic we saw with Fred and Megan and Jennifer and Tom.

Missing Details

Have you ever seen something like this happen?

Krista: You need to do better with your defect reports.

Dave: Okay.

Dave goes off and designs a new automated form that captures the memory state at the time of the error. Two weeks later he proudly shows Krista his work.

Krista: That’s not what I meant! I wanted you to describe the clicks that lead up to the error so the developers could recreate it!

Krista might have gotten what she’d wanted if she had filled in the details of the request. (If you are on Dave’s side of such a vague request, don’t guess, ask for clarification!)

Missing Comparisons

Product manager: We need to get this product out the door faster!

Compared to what? Without a comparison, we tend to fill in the blank with our own definition (which is most likely different from the next guy’s definition). Does faster mean one week faster? A day faster? Faster than our competitor? Faster than the speed of light?

We will do much better at meeting improvement goals when we are explicit and specific:

“The goal for 2.0 release of WidgetWonder is to improve mean-time-to-failure by 10%.”

“The Rec_retrieve function needs to complete in 1 second or less.”

“Our goal is to improve our turn-around time on customer identified critical errors by 25% on average.”

Black and White and Gray

Managers need to recognize when they are talking about a continuum (as with the concept fast) or a mutually exclusive category. We have a natural tendency to categorize. And our professional experience may condition us to look for binary conditions: A test passes or fails. A task is done or not. The release criteria has been met or it has not been met. Being clear about discrete conditions can be useful.

But not everything belongs in a mutually exclusive category, especially characteristics and qualities that pertain to people.

Consider this exchange:

Eric: I’m thinking about moving Cyndi into a management position.

Chris: I don’t know about that…I don’t think she could handle management. Cyndi isn’t assertive.

Assertiveness is not a category, it’s a continuum. One end may be doormat and the other end domineering. People can be at any point on that range, and their placement on the range isn’t fixed. In some situations, when Cyndi knows the subject matter and is feeling good about herself, she can be appropriately assertive. On another day, when everything has gone wrong at home, she’s out of her comfort zone, and is dealing with a situation she’s never faced, she may be less assertive.

Before you put someone in a box, check to see if the variable you are describing is continuous or discrete. Look at how the quality plays in different situations and over time.

It may help to know something about Java or C++…But it’s essential to be competent in the use of daily language (whatever your native language) when you are making the transition to management. Communicating clearly and unambiguously with your team will improve relationships, morale, and results.

An earlier version of this column appeared in STQE magazine, May/June 2002

Are you part of the team if you are on the team part-time?

“Part-timers just don’t seem to fit in with the team,” a manager complained recently. “I do everything I can to impress on them the importance of teamwork and team spirit, but they just don’t gel with the team. What can I do to motivate these people to fit in?”

“These people just aren’t accountable,” another manager declared, referring to individuals who were assigned to four or five projects at a time. “I need people who will be accountable.”

Here’s the news nobody wants to hear:

The problem is not with the part-time people; it’s with the part-time assignment.

When people are assigned part-time to teams they face several hurdles that hinder their ability to contribute. The hurdles are structural, not personal.

Priority

When a person is assigned to more than one team, she’ll gage priority by the proportion of her time that’s allocated to each project. One tester I know was assigned 90% to developing manual test cases and 10% of her time to creating a “critically important” automated test harness. No matter what words her manager said about the importance the test harness, the fact that she was directed to spend only 10% of her time on it communicated a different message.

Furthermore, when she attended meetings or working session with the automation team, she spent most of the time catching up on what had transpired since her last sliver of time with the team. The arrangement wasn’t satisfying for her, and frustrated the automation team. Soon, she stopped working on test automation at all.

Ambiguity

Many people will opt to spend their time on work that has clear-cut outcomes over work that’s ambiguous. The more clarity around the part-timer’s contribution, the more productive the situation will be for everyone. When the assignment isn’t clear–or the relationships between the part-timer and the team isn’t clear, it’s harder for the part-timer to contribute effectively.

Team Cohesiveness

If the full-time team is cohesive, the part-timer may not be able to fit in. Gelled teams develop their own subcultures. They may have unspoken rules of engagement, communication patterns, and established relationships that make it difficult for someone who isn’t full time to fit. Over time a part-timer may acculturate, though the process will be slower than it would be for a full-time team member.

Missing Context

When someone works on a team part time, he is by definition missing part of the context of the team. While the part-timer is off doing something else, the full-time team makes decisions, solves problems, and exchanges information. While the full-time team may document and transmit major events, there are numerous small decisions and communication events that may not seem important enough to pass along but still affect the way the work is done. The adage “You never step in the same river twice” fits this situation. Each time the part-timer re-enters the team, the team has inevitably moved on from the last time the part-timer participated.

Design Before You Assign

So, what can managers and team members do to improve the situation? First look at the work and how the part-timer needs to contribute. Design based on the needs of the work before you assign the worker to the team part-time. As a contributor, if you find yourself assigned, negotiate the dynamic of the relationship so that you–and the team–can be successful.

Here are some of the questions to ask about the work:

Is the contribution time-limited, meaning that part-timers skills are needed for several days, but not for the duration of the project?

Maybe the person only needs to contribute at some critical point. Perhaps he is only needed for one or two iterations, when the team is working on a particular feature. Consider contracting for the person to focus full attention for those periods of time.

Can the contribution be batched so the part-timer interacts with the team for a day or two a week?

Blocking out a day or two a week to work with the team is more effective than having the part-timer spend an hour here and an hour there with the team. This may require more clarity and coordination from the full-time team, but it will make better use of everyone’s time in the long run.

Is the part-timer needed for hands-on work, or can he act as a reviewer, consultant, or coach to members of the full-time team?

Sometimes the full-time team needs to use a certain skill a little bit each day or week, but needs the skill over all long period of time. In this situation, it probably makes sense to develop the skill on the team and have the part-timer act as an expert coach or reviewer until the full-time team members are self-sufficient.

A person can act as a resource to a full-time team without being a member of the team. The team can contract for deliverables, consulting, review, or time. After you understand the nature of the work and the contribution needed, work with the full-time team and the person whose skills are needed to develop explicit agreements. Don’t rely on happenstance and assumptions. Reach agreement on how the full-time team and part-timer will work together, how the part-timer will contribute, and how the full-time team will keep the part-timer in the loop. Don’t expect he’ll gel completely as a member of the team–because he won’t.

Sometimes I see groups in which almost everyone is part time. Sometimes a group working together part time will gel, usually when they have a long, shared history. Don’t expect groups made up entirely (or mostly) of part-timers to gel as a team without time and attention to creating a cohesive whole. And as long as the group is accomplishing its goal and managing the interdependencies between tasks, that’s OK.

It may look simple on paper to say a team needs a specialized skill X amount of the time, but by analyzing the nature of the work and being explicit about part-time arrangements, you will help the team and the part-timer work together more productively.

Bully Boss

A recent phone call reminded me of this article that I wrote in 2004. The story is real, the names are not. It’s a story that is all too common.

***

Not too long ago, I had lunch with my friend Sarah. I hadn’t seen her in a while, so I was surprised when she mentioned that she was leaving the company she has been with for almost ten years. The developers, testers, and other managers at this company respect her, and she loves what she does. Her workplace sounds ideal. So, why is Sarah leaving?

Sarah isn’t leaving for a more prestigious position or a higher salary; her boss is driving her out the door. Sarah’s manager blows up when things don’t go the way he wants them to, and she has had enough. “I’m tired of being screamed at,” Sarah said. “Life is too short.”

Sarah’s not the only one who has had to deal with a hostile boss. According to an article in American Way, “42% of US workers reported incidents of yelling and verbal abuse in their workplace.” While some people may feel they have to accept abusive behavior from bosses in order to keep their job, I agree with Sarah: Life is too short.

The Costs of Yelling and Verbal Abuse

Some people I talk to dismiss my concerns about workplace abuse. They tell me I’m too sensitive. “It’s just Frank,” they say. “He blows up, and then it blows over. Nobody takes it seriously.” But there are costs.

People who work for abusive managers often have stress-related problems and illnesses. They miss work due to symptoms, and they are less productive when they are at work. Their energy isn’t going into building software; it’s going into dealing with the emotional fallout of their manager’s behavior.

Yellers also drive attrition – turnover is higher, and it’s harder to entice internal candidates to work for a manager who has a reputation for outbursts and abuse. Many people would rather walk out the door than work for an abusive boss. The people who do stay may feel trapped by the job market or their own beaten-down self-esteem. People who feel trapped or beaten-down are not productive workers.

In my experience, abusive managers fall into three categories. How you handle the situation depends on which kind of screamer you’re up against.

Unaware

Strange as it may seem, I’ve actually met managers who were not even aware they were yelling. Some people come from families where yelling is part of their “normal” communication. They see yelling as expressive, not aggressive. They may not be aware of the effect their yelling has on other people.

Crack-the-Whip

Some managers believe that people are basically lazy and will not work without coercion and threats of punishment. This view is called “Theory X” management. It doesn’t work. I don’t hear many developers or testers say, “I work better when I’m a little afraid. If my boss didn’t threaten me, I’d never get a thing done!” But some managers believe that this is the case. People who hold this view see yelling and threats as appropriate management action.

Sometimes yelling works in the short-term, as people will do what the yeller wants to get him to stop yelling, or keep him for yelling again.  This reinforces the yeller’s mental model of management.  He seldom looks at the other effects of his management methods: stress, illness, information hiding, lack of engagement.

Out-of-Control

Some people are not able to manage their emotions and responses. These are the bosses that react disproportionately, blow up, vent, swear (we’re not talking the occasional “Oh, %#@!”),and generally fly off the handle.

What You Can Do

If your manager is the Out-of-Control variety, you can try solve the problem by working with HR.

When your manager becomes abusive, stand up, state that you will not tolerate verbal abuse, and leave the room. Go to HR and file a formal complaint. Keep in mind that HR’s job is to protect the company’s interests, not yours. In my experience, the higher in the management chain the abuser is, the less likely HR will take action. The company has probably tacitly accepted his behavior for years, but when there are multiple complaints on file, HR may decide that it is in the company’s best interest to deal with the abuser. If there are witnesses to the abuse, talk to them about corroborating your account. And be prepared for an tense and uncomfortable patch while the process works out.

You may be able to manage this situation by making your own power move. Bring a recorder to your next meeting. Don’t hide it. (That could lead to some other problems.) Be quite open, put the recorder on the desk and say “I’m going to record our conversation, so I don’t have to rely on my memory to recall all the important things you have to say.” Start the recorder. This reduces the chance that your manager will yell. And if she does, it’s on tape.

Rarely, I hear from someone who has found a way to survive an abusive boss.  They manage to cope and let it roll off their backs.  The fact that you can’t let it roll off yours doesn’t mean you are too sensitive, thin-skinned, or weak.

Threats of physical harm, retribution, and personal attacks are well over the line. Verbal abuse is never acceptable.

People who cannot manage themselves should not manage others.

No ifs, ands, or buts. No excuses. End of discussion.

Sometimes the HR department isn’t willing to take any action. Consider what you are willing to live with, and start examining your options for another position, in or out of the company, and make an exit. If you do leave, state your reasons for leaving in the exit interview.

There’s more hope for managers who aren’t out of control. Start with the most generous interpretation and the smallest intervention.

Assume your manager isn’t aware that he’s yelling. Comment on the yelling and the effect it’s having on you. In a calm voice say, “What you have to say is important to me, but I can’t hear you when you’re yelling.” This may be enough to jolt the yeller into awareness.

A manager who continues to yell may be a Theory X Manager. You probably won’t change his mind, but you might change his behavior. State again that it’s important that you hear what he has to say, but right now you can’t because of his yelling. State that you will reschedule the meeting for later in the day, and then leave the room. When you meet again, tell him the effect that his yelling has on you. Request that meetings and conversations take place in a normal tone of voice. If that fails, consider bringing a recorder to meetings, and contact HR.

Employees have a right to be treated with respect and dignity in the workplace. Many mega-decibel managers cease and desist when faced with resistance. When you encounter an abusive manager, hold on to your self-esteem, take action, and decide whether the paycheck is worth the price.

***

Reader Jerry Conklin sent this response when the article was originally published (posted with permission):

The manager who uses his position to bully employees is pathetic and worse than useless. The negative effect of such people is powerful. This kind of bullying behavior has produces human misery and project failure. Such people need to be weeded out of management.

Like all bullies, the bullying manager hates himself. Since he cannot face that fact, he uses whatever power he has to dump that hate on anyone perceived as weak and vulnerable. At bottom, he is a cringing coward and can generally be seen to grovel before his superiors. He is drven by fear.

The main responsibility of any manager is to remove obstacles to productivity not to create them. The fulfillment of such a responsibility requires character, integrity and courage. The bullying manager is often tolerated because she has high technical qualifications. When someone has shown herself to have the cited leadership traits, then we can talk about technical capability. The bully is a weakling who is, by definition, devoid of the character traits necessary to lead people.

Well said, Jerry.

Also check out Bob Sutton’s The No Asshole Rule.

An earlier version of this article appeared on stickyminds.com.