Do you think team dynamics make a difference in business results?

Agile methods depend on effective cross-functional teams. We’ve heard many Agile success stories…at the team level. But what happens when a product can’t be delivered by one team?  What do you do when the “team” that’s needed to work on a particular product is 20 people?  Or 20 teams?

There are no simple answers. But there are design principles for defining workable arrangements when the product is bigger than a handful of agile teams.

Some principles and practices to guide scaling Agile teams.

Most companies have policies that govern the selection and hiring process for new employees. Not a bad thing.  But I’ve noticed that in many of the companies I visit–especially the big ones–the guidelines put far less rigor around hiring people for dev teams than for management roles. (Occasionally, I see the opposite. Might write about that at some point in the future.)

I agree with the need for due deliberation in hiring managers at any level.  Managers can have a big impact, and it makes sense to hire carefully.  Many companies take a broad stripe approach to hiring managers. They look at management skills–but also assess psychological make up, interpersonal skills, and ability to work with others. At senior levels, the candidate often interviews with the other people he or she will work with. They gauge the candidates style, fit, and personality–and gain commitment from the work group, not only the hiring manager.

But when hiring technical people, many of these companies take a narrow stripe approach. They look only at technical skills and domain knowledge.  Both are important, of course.

But there’s an assumption there that personal qualities and interpersonal skills don’t matter as much, and team buy-in is irrelevant. There’s also an assumption that people developing software work independently as individual contributors, and they are relatively easy to replace if they don’t work out.

But, if you want to develop strong, creative, capable teams, you need to up the hiring game at the dev team level.

Here are four reasons why:

1)  A person working on an agile team is not  an “individual contributor. ”  He or she is expected to work interdependently.  In agile teams, people collaborate, negotiate, make trade-offs, handle conflicts.  These interactions require a high level of interpersonal skill and emotional intelligence.

2) Even junior members (in terms of experience, age, or skill level) are expected to exhibit a high degree of self-management.  They make commitments to other team members, follow through on commitment, manage their own work level and task completion. They need to know how to ask for help, and be comfortable admitting when they don’t know something.

3) People on agile teams need to have excellent problem-solving skills–beyond those needed by an “individual contributor.” An individual contributor needs to solve problems that are bounded by his task assignments. Problems of coordination and dependencies are often someone else’s job.  People on agile teams work together to solve technical problems, handle issues, and interface with other teams.  The manager isn’t doing the bulk of the integrating work between tasks and solving problems–team members are.

4) People on agile teams need an exceptional ability to learn and apply that learning–both in growing “generalizing specialist” skills and in improving team processes.

You can learn a lot about these factors in an interview if you use behavioral interview questions.  But not enough.  But it is very difficult to assess how someone will fit into the team, unless the entire team has a chance to meet him and interact. It’s hard to assess how people code, test, problem-solve, unless you see them in action. That’s why auditions are so useful.

Further, the broader the interview team, the more people will be invested in the new hires success.  They won’t have the cop-out of saying “your problem, I didn’t choose him.”

For some ideas on a hiring process for agile teams, see my article Hiring for a Collaborative Team.  And buy yourself a copy of Hiring the Best by Johanna Rothman.

(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).

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.

As I said in an earlier column, it’s not enough to slap the tile of Scrum Master or Agile Coach on a project manager, manager, or whatever other warm body happens by.  It’s also not enough to look for the keywords “CSM” or “coach” on a resume.

If you are serious about helping teams learn and thrive as self-organizing Agile teams, get serious about ScrumMasters and Agile Coaches. Start thinking about the work, the role, and the job–not just the job title.

Here’s my initial take on a job analysis of the role (using the job analysis template from Johanna Rothman‘s very useful book, Hiring the Best.)

First, I considered the qualities, preferences, and skills. Second, I thought about the sort of knowledge and understanding that’s essential for the role.  Then, I thought about elimination factors, patterns of thought and behavior that would eliminate a candidate from consideration.  Of course, you can’t just ask yes/no questions for any of the characteristics on this table. You have to do behavioral interview questions and auditions (see Hiring the Best if you need a refresher on interviewing and auditioning candidates).

After I had a handle on the skills, qualities, and characteristics, I considered the interactions, activities, and deliverables for the job. I summarized it all here:

Of course, what you look for in an agile coach or Scrum Master will be somewhat different. Each team has different needs for coaching. A given team may need more (or less) help with specific engineering practices. Another team may need more help with retrospectives or planning. The key is to think of this like any other job. ScrumMaster or Agile coach are not a plug-and-play roles. You need to look for fit–with your culture and with the needs of the team.

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 participant in one of my workshops of my workshops declared that in every team there is pecking order….and every one knows what the order is from one to n.  Since this is the case, he reasoned, it follows that ranking people in organizations is a reasonable management practice.

This is not the first time I have heard this assertion.

It often comes up when I talk about performance reviews, annual evaluations, and the harm done by stack ranking.

This assertion rests on tired analogies from sports or the animal kingdom.

I’m not buying it.

Software development teams are not “just like” sports teams. Software development teams aren’t packs, pods, herds, clowders, flocks or clutches.  Groups of people developing software are people in goal oriented social units–often in teams.

Sometimes, on some teams, it appears that there is one person who is obviously the star. Maybe.

In some companies, smart talk substitutes for action. So is the smartest talker the best on a team?

Some times there is a self-proclaimed genius who writes code that is so brilliantly complex that other people struggle to understand it. How does that make him the star? He is making it harder for everyone else to do work.

Then there are the people whose manager declare are top performers (though the basis of their assessment isn’t clear)–even though colleagues and peers  view them no more than average,  brown-nosers or a hindrance.

I observed a team where one person was viewed as the star by many managers.  To those managers, Joan (not her real name) looked like the one who generated ideas and figured out problems. From inside the team, Joan, suppressed contributions from other people through aggressive interruption, belittling others’ ideas, and arguing  until people caved in because it wasn’t worth the fight.

Rarely, there are people who are real standouts.  But not on every team.

What about the people at the bottom? What is the basis of the assessment?  Does the assessment include all of the dimensions of performance? In most cases it does not– it might include one dimension, perhaps coding. But in collaborative work, that is not the only thing that matters. Some times a person with relatively weaker coding skills contributes in other important ways. He or she may excel at  synthesizing information, seeing the software from a customer’s perspective, creating an environment where every one on the team can be more effective.

And the people in the middle? People who ascribe to the pecking order view believe that all of the members of a team could be lined up in rank order. But what is the earthly good of that? What is the basis of the comparison? Does it included the breadth of contribution or just one aspect of performance?

What if people are measurably different on some dimension?  Software is a collaborative endeavor. What matters is how well the team is doing.  Spending time teasing out relative contribution or trying to discern the pecking order does not aid in team performance, and can cause real harm.

As a manager, don’t waste your time trying to figure out the pecking order.  Do everything you can to help the team, as a goal oriented social unit, perform to its full capability.  Treat the true stand outs as exceptions. Promote them, or find other ways to reward them (don’t limit your thinking about rewards to money).  Treat the people whose performance is obviously below par as exceptions, too.  Either get them them help so they can contribute, or get them to a place where they can contribute (which may not be your company).  It is extremely difficult to assess relative contribution to collaborative work. The effort is not worth the benefit, and the downsides are significant. So skip it. And get on with helping the team.

I recently met with a group of managers who work in organizations adopting agile methods. Several of them asked whether functional managers should become ScrumMasters or coaches.

That’s a risky road.

One manager was adamant. In his view, making managers ScrumMasters was the best course of action. According to this fellow, managers already know people’s strengths and weaknesses. They know the domain, and the organization. So, he reasoned, the managers are already equipped to tell people what to do.

Errr. Not so much.  Coaches and Scrum Masters rarely tell people what to do. Usually, they work by different means–modeling, coaching, teaching.

But it begs the question, can a manager be an agile coach or ScrumMaster?

Here’s what I look for in an agile coach/ ScrumMaster.

Experience. If your company has used serial life cycles or ad hoc methods changing to agile methods is not a trivial matter. Nor is it simply a matter of adopting a few engineering practices or using time boxes.  Succeeding with agile does require engineering practices and time boxes. But the real change happens between peoples ears. It’s a shift in thinking–and not just by the development team. Some people change the way they work by changing their thinking. But many more change their thinking by changing the way they work.  Book learning and training is good, and it’s no substitute for experience in the agile way of working.

A deep understanding of agile practices and methods. Coaches need to know the why and when, as well as the how. They need to understand how practices fit together, the intent behind practices. People do need to adapt methods to local conditions.  Without understanding, adaptation is risky. I’ve seen teams and companies “adapt” themselves right back into the situation they were trying to fix because they didn’t fully understand the “why” behind some agile practices. An agile coach needs to be able to think through what adjustments maintain the essence of a practice, and which adaptations sustain the current pattern.

Coaching skills.  Seems obvious. An agile coach should know something about coaching. That means helping people learn skills through practice and feedback. It means helping people think through issues and see new alternatives.  It may mean providing answers, facilitating, or acting as a mirror. If often means helping people think about the way they are thinking, and helping teams get unstuck.  (It does not necessarily include “life coaching.”)

Coaching is tricky when a person also has the responsibility to rate and rank individuals. Coaching requires openness and trust. When people fear that revealing lack of knowledge or skill will show up on their annual review, they are less likely to ask for help. I know of several companies where managers are now “coaches” (and managers). Its confusing for the team members.  They don’t know who they are talking to–the person who helps, or the the one who will hand out a rating at year end.

Understanding of teams and team dynamics. Another skill that would seem obvious, but is often overlooked. When the job is coaching a team, the coach needs to understand something about how people behave in goal-oriented social units. He needs to know the foundations and enabling conditions that allow teams to form and thrive. He needs to recognize when problems are related to the design of the team, when they are system patterns, and when there are individual problems.

Interpersonal and collaboration skills. Coaching is about enabling other people to be more effective. The zeroth step is to make contact with people. If a coach cannot do that, he won’t be able to build relationships and trust. I do sometimes meet coaches who are all about “me.” Doesn’t work. Coaches need to be able to work with others, share credit, and let others shine.

Influence and organizational smarts.  It is silly (or worse) to expect a ScrumMaster to remove significant organizational impediments and drive organizational change–even though that’s often the hype. Coaches need to be savvy about the organization and to have influencing skills, so they can help managers understand the costs of impediments.

If you want empowered teams, you need to change the dynamic between managers and teams.  Slapping a new tittle on a manager (or project manager) will not change the dynamic unless the manager’s mindset and actions also change.

Of course, some managers do have all the qualities and skills to make the transition.  And some teams have the gumption to call out their former managers when they slip back into command and control thinking or acting.  Even when the mangers is willing and capable of changing the way he interacts with a team, it will take time for the new pattern of interaction to take hold.

But for many companies, calling managers “coaches” or “ScrumMasters” is really hierarchical control in coaches clothing.

Organizations still need managers.  Call them managers, and have them do management work–improving the organizational system and translating strategy into action. And get a coach to be the coach.

“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.

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?