1 comment on “Forget about AGILE! Reduce Overbearance in Management first”

Forget about AGILE! Reduce Overbearance in Management first

This is part 5 of a series exploring what makes an effective team. Read this if you are interested in great teamwork and like to explore different types of teams.

COE4.png

Condition 4: Clear Boundaries

Effective teams are groups of people that act towards a particular direction. Although everyone is different, people inside a team align actions with one another. A crude but essential way of achieving alignment is setting clear boundaries.

By setting boundaries, two things are achieved: First, the freedom to act is clearly defined. The team can do everything that is within the limits of the team.  Second, everything that is set out of bounds is simplifying the mission: It is one less thing to take care of – which is very welcome as long as the boundary does not overly restrict the team’s ability to deliver. Cleary stated limits create certainty for the team. They are giving the team something to work with. They lessen the risk of the team running into major, unyielding, yet unstated boundaries later.

Boundary conditions are everything that is framing the team’s mission: Resources, scope, and deadlines are the three classical boundary conditions given to a team. However, it is although its decision-making power and the very definition who is on the team and who is not, and what is means to be on the team.

Who is on the team?

To merely assign team members is not enough. There are two things to consider. First, what does it mean to be on the team? Which rights and obligations come with team membership? A decision on team membership is a decision to include a person – but it is a decision to exclude a person, too. There should be no in between, and there should be no half-baked assignments, no “extended teams”- just universal clarity. Extended teams are a backdoor to increase team size and dilute responsibility, often for the sake of political convenience. There are always persons outside the team who need to contribute, but usually, that contribution can be limited to consulting with the team, delivering some tasks, contributing to workshops, reviewing and testing.

Second, in high-performance teams being on the team does mean to spend a lot of the time on it, the more, the merrier: Everything being equal, a full-time dedicated team will always outperform the part-time team in efficiency, speed, quality, and any other target dimension. This is not to say that the team needs to be together all the time. It may be necessary to split up the work or explore different paths, while all the time working on the team’s task.

These two demands, clearness who is on the team and who is not, and full-time dedication are so immensely essential and easy to understand yet appear so often utterly unrealistic in most companies. All the right people are already over-assigned.  Restricting the number of assignments is often hard to do, as there is always some constituency to please by demonstrating action. This is all too understandable. Well then, go ahead and over-commit your team to multiple endeavors simultaneously. Just do not expect high performance.

Again, this sounds a bit passive-aggressive. I do not mean to. The fact that people are overcommitted again illustrates the underlying theme in this series of posts: Organizations do not care about individual or team effectiveness too much. They are willing to sacrifice performance for other priorities, like stability and predictability.  Sometimes, they even choose to sacrifice performance to uphold the appearance of busyness. Where results are hard to link to individuals, hierarchies tend to reward people who appear to be busy. It takes much discipline for a company not to overload its co-workers with work. More on that in part III.

What is the authority level of the team?

What is the team allowed to decide on its own? What is the team’s freedom to act? Hackman describes four levels of authority:

  • Level 1: Authority to execute the task
  • Level 2: Authority to monitor and manage work processes and progress
  • Level 3: Authority to design the team and its organizational context
  • Level 3: Authority to set overall directions

Based on these authorization level 4 types of team’s can be identified.

ToT

Type I: The Workgroup that is executing the team task

At the first, fundamental level, the team needs to be authorized to execute the team task. That may sound very basic, but in more political companies even this authorization level is sometimes not given to a team.

One of my very first projects, as a young consultant, was of this kind. Our team was supposed to fix the multi-billion investment management process in the Volkswagen Group across all its brands, VW, Audi, Skoda, Seat. For this, we were supposed to be using a brand new shiny new software package from a south German company called SAP, which offered work-flow functionality to fully digitalize the very communication intensive review and approval process of investment projects. Albeit the very same corporate grandees that initiated this project didn’t want any change in the way work is done to not upset the powerful brands. To implement standard software without changing historically grown processes is a blatant contradiction. Still, our mission was: Implement but do not change anything. While informing a senior partner in our company on our straits, he just smiled thinly and said: “Oh well, they are playing their old game: Go wash me, but do not get me wet.”

Every boundary set on the way the team task is to be executed closes down an avenue to a solution – possibly up to the point that the job is no longer feasible – or becomes bereft of economic sense. An example for this is the demand often faced by teams to keep within just one silo of the organization: You can do everything here, but do not change process X or System Y, that is a given. It is the nature of really important changes to have an impact on multiple organizational silos. Most modifications done to just one part of an organization quite often result in a local optimum – and global dysfunction. They might make sense for a unit, but not for the company a whole.[1]Such boundaries can turn an otherwise pretty sensible team mission to one might make limited or no sense at all.

Type II: The Self-Managing Team that is Monitoring and managing its work process and progress

Once that first, existential hurdle is cleared, and the team is all set to execute the task the next question is: Who is to monitor and manage the work process and progress, i.e., to lead the team? Usually, a manager (or project manager) is assigned to do this, no questions asked. The alternative that a team can monitor and manage its own work is not even considered. Yet this amount of freedom to organize in a way it deems best is precisely what a high-performance team needs. Mr. Hackman and all the researchers specialized in the science of high-performance teams have delivered an abundance of evidence about that.

Managers are not irrelevant in ta Self-Managing team. They still set the overall direction, convene the team and provide the working environment, including setting the boundary conditions. However, they refrain from intervening in the way the team does the work. If managers intervene, for example by coming up with meticulously detailed work break down structures, teams just won’t perform on a high level. Such manager-led teams are workgroups: Collections of individuals to whom work is assigned by a manager. A workgroup might be good enough to do a job, but it is unlikely to achieve high-performance levels. If the work process is managed by a single person, the team cannot build its emergent properties, not integrate in a way to deliver results that are more than the sum of its parts. In such a one-sided power structure, the openness and integration needed for a genuine team effort are unlikely to occur.

Beware about the overbearing manager (especially in projects)

Wait a minute! I just said that the manager led teams are a killer to a team’s performance. I even said that those are workgroups and not teams at all!

This is true. Workgroups are the way most company units or departments are organized. A loosely bound collection of individuals coordinated by a manager. Their performance will never be as high as a team, but their results are predictable and controllable. Work-groups are the norm, and Self-managed teams are exotic. Performance aspirations of line units might not justify a team effort, but within more significant projects, performance aspirations are usually higher. A good case for a high-performing, self-managed team. So how often are project teams self-managed?

Conventional project teams are headed by a project manager. Although Agile Methods like SCRUM discourage the use of project managers, most companies hold on to the notion of project managers. A manager leads a business unit. A project manager leads a project. Someone needs to be in control. It just makes so much sense to them.

Here comes the snag: Effective teams are NEVER manager-led workgroups. They are at least Self-Managing teams, where every team member can engage more wholly. Science has proven that classical, manager-led teams that come with micromanaging, intrusive, administrative procedures, overbearing interventions into the team space do not lead to exceptional performance.

The trouble is that most project managers approach projects with the same mindset as line managers. To be in control is their core concern. The question of control is at the heart of the world’s leading project management methods like PRINCE2 or PMBOK. To reliably come up with projects that deliver on time, in quality and to budget. Control is what is expected by them by the line organization. Get out there, take charge of a project and deliver according to the plan.

The problem with big project management frameworks is not that they do not solicit good advice. The problem is rather that they give too many methods, tools, and advice. If you learn the whole curriculum, you are likely to end up with a zoo of intrusive management interventions that patronize team members and undermine their initiative. There is a commercial incentive to blow up what it takes to manage projects successfully. Project managers tend to think they need to apply all those methods. I am not saying that learning about project management is a bad idea. However, I am saying that a core condition of effective teams, the freedom to determine its path on its own, is often threatened by overbearing project managers. Those types are keen to show what they have learned and are eager to display to the rest of the organization that they are in control.

That sounds like a fundamental attack on the time-treasured ancient art of project management. Old style project management may lead to great charts, great reporting and the illusion of control, but seldom to a great performance.

What’s the alternative to run successful projects? The standard answer nowadays is Agile and Scrum. The trouble is, Agile and Scrum can just be as overbearingly intrusive to teams as classic project management methods can be. The underlying solution lies, according to a host of research on high-performance teams, in managers not intervening too much: Hands-off – Eyes on. The actual project method, waterfall style or SCRUM, is of secondary importance.

Great team performance needs managers who enable teams to do their best. For that, they need to devolve control to the team and give people the freedom to act. According to Hackman and other researchers, a manager should design the team and its organizational context, but not interfere and intrude into the group dynamics of a team. A useful manager is an environment builder and coach, not an overbearing patron or a dictator. Alas, the sheer size of world-leading project manager standards leads people to believe that the more interventions, the merrier. The contrary is true.

Type III: The Self-Designing Team that is designing itself and its environment

Time to go even further. A team can also be trusted with designing itself and its work environment. For example, and contrary to popular belief, it is not a law of nature that managers need to “staff” teams. People can assign themselves to teams and teams can decide on shedding team members themselves. They can produce their own boundary conditions, setting targeted costs, marshaling resources, and to determine the scope of the project without managerial oversight.

Teams can be “self-designing.” In such a context, a manager points a team at a direction and let the team figure out everything on their own.

Wait a minute! That sounds like a free for all. A chaotic commune. Anarchy. Sure, if you make a team Self-Designing, without doing anything about the other 11 conditions for effective teams, you are bound to get into trouble. Those things only work if one takes a holistic approach to work design. What’s more, this holistic approach needs to extend not only to the management of teams but to the management of the company as a whole. Precisely what this blog is about.

Type IV: The Self-Governing teams that set its own directions

The fourth level is to authorize the team to set its overall direction. Such a “Self-governing,” free-ranging team is subject to the same team dynamics described in this part of the post but needs an entirely different organizational context to operate in than a traditional hierarchical organization provides. Such a team is found in Self-managed organizations that replace hierarchies of authorities with hierarchies of purpose – a  phenomenon that is explored in this blog, e.g. Holacracy, Liberation and Management 3.0.

How common are these four types of teams?

What is the empirical frequency of the four different team authorization levels in today’s companies? I have found no studies about this, but here is my hunch:

  • The overwhelming majority of teams are managerial led, co-working groups, let’s say 85% in a line organization and 70% in a project context
  • Self-Managing teams are about 13% in a line organization and 25% in a project context. These are those teams, where a manager is shrewd enough to take on an enabling role to the team and keeps his interventions to a minimum. Such a team might call itself “Self-managed,” but it is.
  • Self-Designing Teams make up the larger share of the remaining 2% in line and 5 % in project contexts. Using such a high authorization level on teams would seriously undermine the appearance of being in control and decisive that a manager needs to uphold, so this is seldom done. It is most common in informal groups, like for example communities of interest.
  • Very few teams are Self-governing. Self-governing teams are only possible in a self-managing organization, and those are very few. They are in the vanguard of today’s organizational thinking.

Managers relinquishing control is a rare phenomenon. Yet it is what is required for great team performance. However, without a manager being in full control, how can a team stay on track? How can low performance be sanctioned? Please hold on to these questions until we make through all 12 conditions of effective teams, as all of those deliver important pieces to the answer.

That’s it for today. In the next post, in two weeks, I will show why diverse teams are sometimes a good idea, but not always.

___

Audible…no: I hope you enjoyed this post. Let me know what you think!

Key points

  • There is just one team. Not an extended Team, too.
  • Full time dedication of people to a team is king. Period
  • Authorize the team to organize on its own. There simply is no other way to high performing teams.
  • Good Managers refrain from intervening in the way the team does the work. People call that Self Management.
  • Effective teams are NEVER manager-led workgroups.
  • Agile and Scrum can just be as overbearingly intrusive to teams as classic project management methods can be

Previous posts in this series on effective teams:

  1. Performance in general and what makes individual performance: You call yourself a Great Manager? Let Me Hear Your Theory of Performance!
  2. Why Most Companies Should Not Seek to Work in Teams
  3. The twelve conditions for effective teams, including condition one, a compelling direction

Sources and Footnotes

[1]For more on local optima and how to find out the things that really need to be changed in businesses check out Goldratt, Eliyahu (1994) ‘The Theory of Constraints‘

0 comments on “One Hell of a Task Needs Two Pizzas”

One Hell of a Task Needs Two Pizzas

This is part 4 of a series exploring what makes an effective team. If you want to know how to shape the task given to a team and the optimal size of a team, this post is for you.

CoE23

Condition 2: A True Team Task

A true team task is one that cannot be reached by working individually. A task that needs the close cooperation of every person in a team if it is to be successfully mastered. Creating a new system for customer service, expanding to vastly different geographies, coming up with new products and services are all things that surpass the abilities of what workgroups can successfully deliver. It is not that work-groups can’t deliver those things, but results will likely be less than optimal. The typical rate of project failure in today’s businesses is often portrayed to be as high as 70%.

A true team task is often not defined by its nature, but by the performance aspiration.

Let’s take the practical example of implementing a big, enterprise-wide IT application. To implement such a complex system is entirely feasible by working in a workgroup fashion. An experienced project manager is dividing up the work into chunks assigned to team leads, as team leads divide up the work further. While there is some level of cooperation required between team members, this can be organized, for example through the approval of blueprints and in integration tests. Cooperation is limited. Work is parceled out to individuals by managers. Managers rely on project plans that break down all the things to do into detailed tasks and who should do them by when. This proven way of working that will produce results if competent professionals drive it.

So, is implementing a big, enterprise-wide IT application not “a true team task”? There are two answers to it.

  • No, it’s not. It does not really require close cooperation between its members. Instead, such a project is relying on a proven, scripted way of working that allows all individual efforts to be summed up into the final product, the IT system.
  • Yes, it is, if the performance aspiration is high enough. For example, if the ambition is to do that in say two years, a manager led workgroup can do that in the mode described above. However, if the team is supposed to do that within one year, a genuine team effort is what it takes. To cut a year in throughput times needs people to rise above their competent selves and come up with something together that is collectively greater than themselves.  Most of us tend to agree with this instinctively. We know that if we want to achieve something extraordinary, we need some team magic. Moreover, our intuitive understanding is supported by scientific evidence, like the one from Mr. Hackman: A true team can achieve magic.

But unfounded ambitions, won’t do any good, too

The problem is that companies often set extraordinary high-performance targets, because ambitions at the start are high, or they need to overcome the hurdles of budget approval and low bids are what is asked for.  However, usually, the way a project is executed reveals a lack of understanding of the art of building high-performance teams. I have seen this dynamic playing out multiple times in my career in business. While I know that a project could be done in a fraction of time and costs, I did not advise some customer to put in the low numbers. I knew that some clients we not ready for a high-performance approach. Sometimes, most often really, companies as a whole are not prepared to embrace a genuine team approach, as described in the twelve conditions of effective teams. Organizations which embraced my advice may have ended up with long, tedious, but ultimately successful projects. Organizations which rejected that advice and went for ambitious performance targets while relying on traditional workgroup ways of working ended up with significant time and quality problems, budget fiascos, vastly increased employee and management turn-over.

Companies got to lay the groundworks for their ambitions. I have described that point in general terms in a 2016 post Execute crisply with sharp tools.

c11

Besides the occasional major project, true team tasks are essential for day to day operations of teams too. If the performance aspiration of maintenance, customer service, or sales teams is extraordinarily high, the chances are that a high-performance approach is called for and one should have a look at the 12 conditions. If the sum of all individual contributions is not enough to reach the overall target, a true team approach is called for.

Teams are needed if it gets real complex

All this might be understood as a call for overly ambitious targets. Indeed, there is a blurred line here: It is tough to judge whether the combination of skills and minds in a team will make the goal possible or the target is just wishful thinking. Even for those well-meaning, competent managers who know and do everything in their power to provide the 12 conditions of effective teams, an over aspiring, unrealistic or outright silly target might doom the exercise right from the start. As a rule of thumb, it is useful to understand the level of collaboration between team members that is really needed. The less the need to discuss with one another, the less the need for a high-performance team, the less critical the twelve conditions are.

It takes much collaboration between individuals to deliver good results in complex environments or systems. Complex systems are those where cause and effect can neither be predicted with certainty nor is the relationship between a cause and an effect stable. A machine, for example, is not a complex system. It is just a complicated system, but not a complex one, as its parts are known and behave predictably. All social systems involve humans, and therefore are rather complex than complicated systems, as humans act inconsistently from time to time. Therefore, all teams are complex, and companies tend to be very complex.

Groups of individuals can reliably master less complex tasks without much need of collaboration between them. Take for example service teams in call centers. The core of the work is done by individual agents on the phone, during the conversation on the phone. Co-workers can be useful to reflect with before and after the customer call, but all work is centered on the individual without the need for much collaboration.

The thing is: The more complex the task, the more it becomes a “true team task,” the more collaboration is needed and, in turn, the more critical it is to consider the 12 conditions in the work design of a team.

Most companies have configured themselves to be less complex

Indeed, in most organizations, most performance contexts may not lend themselves well for a true team task. Only if the performance ambition is high enough and the nature of the task requires intense communication between team members, a team effort is called for. Many businesses use the term “team” in an inflationary member and think of all groups of people as teams. So, they invest in nice team building events sponsored by HR budgets and helped by a host of business trainers. This is as inefficient as it can get: To spend money or time on team building while the need for collaboration is really not that important at all is to create waste.  It usually suffices to give such a work-group a good understanding of expected behaviors, control the application of those behaviors and let them do their work.

The point is: On a case by case basis, the work group is a better choice to organize work inside traditional organizations. But on the whole, if the whole organizational design of the company would not have been set-up to contain complexity and promote predictability, the team would be better choice. Most companies have configured themselves to be less complex, to suppress the complexity of the market. Designs that allow the complexity of the market inside the company usually involve a bit more structures that promote self-management within a company. But I am getting ahead of myself here.

Condition 3: Team Size 5

Defining a true team task is tricky. It’s time for some refreshing simplicity: The optimal team size is five people. Do not build any teams much bigger or smaller than that. The standard variation around the optimal team size of five is two. So, any team size of 5 +/- 2 is the optimal team size.  Beyond that size, split teams. Beneath that size, is just the pair. For two people working together, the laws of teams are not as relevant as the laws of psychology and good communication.

Even the science on team size is rather simple. With every member added to the group the number of relations which each individual needs to build and maintain increases linearly. In a team of three, a team member needs to develop and maintain two links to the other team members, in a team of four three links, in a team of 5 four links.

However, in order to effectively operate within a social group, it is not sufficient to build and maintain links with all other team members, it is vital to theorize about the ties that others have with one another, too. If you know that Joe and Sue do not get along well in a particular aspect, it may be better to circumvent that problem before it arises. Effective social groups do not only care for the relationships that they have individually, and they care about the links that others have between them. They care for the collective. They care for the team.

The trouble is that the total number of links in a team does not increase linearly. It grows exponentially. The total number of links between team members = N * (N-1)/2, whereby N again stands for the number of people in a team.:

  • A team of three everyone has a total of three links.
  • A team of four has six links.
  • A team of five has ten links, and in a team of seven has 21 links.

This number rises exponentially. In a team of 20 persons, every team member would have to build and maintain 190 connections. Why the jump from seven to eight team members might not seem like a big deal, the total number of links in the collective increases from twenty-one to twenty-eight. While the number of links per person is just increasing by one (from 7 to 8)- that is 14% –  the number of total links in the system is increasing by seven (from 21 to 28), 33%. Increase the team size by three from seven to ten, and this ratio goes up from a 42% increase in the number of links per person to 214% for the total number of links in the group.

This a mathematical way of saying: Size matters. The negative performance impacts of increasing group size are hard-wired into teams. With rising team size people can relate to one another less and less. To invest more in coordinating the team helps a bit but can never offset the negative impact on performance fully. Jeff Bezos is known to have coined the phrase “two-pizza teams” as a rule of thumb for determining team size at Amazon: A team that cannot be fed by two large pizza’s needs to be split.

  • If intense collaboration is what is needed, low team size is the way to go.
  • If intense collaboration is not required, don’t go for the team approach at all and organize the group as a work team instead.

It might not always be easy to cut down on team size, as this or that skill or organization needs to be represented. In this case, consider two things: Either split the team in two and manage those separately or come up with a better definition of the team boundaries, especially who is on the team and who is not.

That’s it for today. In the next post, in two weeks, I will get to discuss a very exciting subject: Do teams need a manager?

___

Audible…no: I hope you enjoyed this post. Let me know what you think!

Key points

  • Most tasks can be made a great one for a team if you just level up the performance aspiration
  • HOWEVER, do not level up the ambition, without having laid some solid groundwork inside the organization for those conditions that make teams great
  • Most companies have configured themselves to be less complex, to suppress the complexity of the market. Therefore the workgroup is often a better choice
  • Team Size 5. Team Size 5. Team Size 5. GOT  IT?
  • Two Pizzas – one Team

Previous posts in this series on effective teams:

  1. Performance in general and what makes individual performance: You call yourself a Great Manager? Let Me Hear Your Theory of Performance!
  2. Why Most Companies Should Not Seek to Work in Teams
  3. The twelve conditions for effective teams, including condition one, a compelling direction