This is the first part in the article series The Performing Organization. The series will explore and explain the organizational characteristics that Agile practices try to unlock. There will be Agile principles and practices mentioned, but they will not be the focus. Focus will be on overarching organizational capabilities that are common traits for well performing, efficient organizations. We will explore these capabilities by asking ourselves a number of fairly simple questions.
The first question we need to ask ourselves is: How do we get things done?
Do we get things done through:
- Individual Achievements
- “Project Teams”
- Stable But Immature Teams
- Mature Teams
The reason we need to ask ourselves this question is to determine whether our modus operandi will scale or not – and by scale, I am referring both to speed and size. Will we be able to scale up our production without hitting severe bottlenecks? Will we be able to take on larger, more complex work, without relying on key individual achievements?
High performing organizations tends to have a culture of openness and collaboration. One of the best ways to establish and nurture that culture is through team work. So we need to ask ourselves: how do we get things done?
Individual Achievements
Let’s get one thing out of the way right from the start: We need individual achievements!
High performing individuals are not a bad thing. In fact, we often need these driven individuals to excel and break new ground. The problem occurs when we rely solely on individual achievements to get things done. There needs to be a way for us to duplicate that competence to some extent, or simplify things so that more employees can contribute. Otherwise we have created ourselves some formidable bottlenecks – or even worse: a hero culture!
A hero culture is when an organization relies on single individuals to get important things done. These people are considered indispensable, extraordinary, and irreplaceable.
This is a double-edged practice. Firstly, because it doesn’t force the organization to improve its overall capabilities. Things get solved by personal sacrifice from the heroes – often in the form of overtime, stress, or constant context switching. We as an organization risks finding ourselves in a key competence trap, becoming too reliant on single individuals to operate. This is not a robust status to be in.
Secondly, this situation might feel very rewarding for the hero. Being in demand, the center of attention, and the Go To Guy is very ego boosting. However, it’s usually a hard balancing act to manage, as pressure is likely to mount on that individual. Sooner or later this person will be dancing too close to the edge, and once on that slippery slope, burnout is never far away. In that scenario, both the organization and the individual are in a really bad situation.
To speak Sports: Individual achievements might win you a game or two, but it won’t win you the season. So, while we might need individuals to excel in specific situations, we definitely need teams to stabilize or accelerate our output.
“Project Teams”
I use “Project Teams” in quotations, because these teams are usually not teams at all. They are at best a work group, at worst a bunch of random people. These “teams” are usually put together by requesting resources for a specific project. Meaning the “team” will only work part of their time together, for a short period. People might even drift in and out during the project, meaning the team is never stable. This makes it very hard to build interpersonal relationships, as well as establishing a well functioning team way of working. Psychological safety and collaboration, among other things, will suffer.
I played football (soccer) in my youth, so my idea of a team is very much colored by the world of sports.
No professional football player, no matter how good they are, play for more than one team at a time. Kylian Mbappé’s line manager does not have a spreadsheet where he tries to find the optimal way for maximum utilization of Mbappé in several teams. That would be absurd!
And still, this is how we often plan our “star players” time in project team situations. Calling this type of part time, temporary assignment a “team” is – in my opinion – to misrepresent the concept of the word to such an extent that it loses meaning.
My definitions of a team is:
- A group of people with a common goal
- They need each other’s competence and to collaborate to reach the goal
- They continuously strive to perform better as a unit
So in football, we have different individual specialties – goalkeepers, defenders, midfielders, attackers – but they also practice how to play together. How to operate as one unit, not as eleven individuals. The team members need to know each other and have an established and refined way of working together, otherwise there is no team.
Stable But Immature Teams
By “immature team” I’m not talking about a band of people exhibiting juvenile behavior as a group. In fact, some of the best performing teams I have worked with have had an extraordinary capacity for juvenile shenanigans.
In this context, immature teams are those who have stagnated or reversed in their maturity in regards to Tuckman’s Stages of Group Development.
These immature teams have usually forgotten (or given up on) the last bullet in my definition list – they don’t strive to perform better as a unit. This leads to a bouncing back and forth between Forming and Storming, because they don’t have the experience, tools, or time to solve their internal issues. They either avoid addressing them, or let the most opinionated decide the direction. Either way, they don’t commit as one unit.
This bouncing back and forth could also be the result of high personnel turnover. Team maturity takes both time and effort. Susan Wheelan’s research on team maturity suggests that the average is six months for a team to reach the Performing stage, and that is assuming that the team and its context stays reasonably stable during that time period.
Essentially these teams end up working as individuals, with limited collaboration. Never really getting used to or finding a way to work effectively as a unit. Don’t get me wrong, it can be perfectly pleasant to work in such a team. It’s not necessarily a dysfunctional group. But the performance simply isn’t there, because we choose to avoid hard or uncomfortable discussions and decisions.
While this is still better for an organization’s performance than temporarily assembled “project teams”, this situation doesn’t facilitate self-organizing, high performing teams. These teams still require a lot of help and management involvement, because the group is not mature enough (or lacks the competence) to take full responsibility.
For that to become possible, we need mature teams.
Mature Teams
The best way for an organization to accelerate through collaboration is stable, mature teams.
Stable in the sense that there is low personnel turnover and the context the team operates in is stable. This is because efficient collaboration is both down to knowing how you are expected to act, but also that you know your closest collaborators well enough to trust them.
Google’s Project Aristotle showed that the most important trait in their high performing teams was psychological safety. Since Wheelan’s research found that six months is the average time to reach a high performing state, one can speculate that proper psychological safety takes roughly that time to build, as well as establishing a well functioning internal way of working.
This does of course not happen on its own. It requires that you deliberately and continuously work on improving the team’s way of working and their relationships.
To send a team on a single Scrum course and then expect them to become a self-organizing, high performing unit overnight is simply sloppy team building. Retrospectives is a good start, but is often not enough, because effective retrospectives require a high degree of trust and psychological safety. Otherwise those pressing issues will never surface or get properly addressed.
Teams require, for example, an experienced Scrum Master, manager, or team coach to keep things rolling in the right direction. Preferably also helping the rest of the organization to establish how to interact with the team. Set expected behaviors and input channels. Like refinements, backlog handling, and how to write proper requirements, in whichever flavor or form they may come.
It could be Scrum. It could be Kanban. It could be something completely different, but a practice needs to be put in place and followed.
Summary: How do we get things done?
To excel we most likely need individual high performers, but in order to accelerate we definitely need to facilitate collaboration. A high degree of collaboration is essential for the overall performance of an organization. The best way of doing this is through self-organizing, cross-functional teams.
If we are not serious about it, we should stop using the word “team” altogether, otherwise we will probably place unreasonable expectations on our work groups. That said, even temporary work groups perform more efficiently with a bit of team development exercises. However the synergy effects of mature teams will likely never appear.
Not all teams will become high performing, but the least we can do is help them past the Storming phase, so that they can reach Norming. It’s the bare minimum if we are serious about using teams as the fundamental blocks on which our organization is built.
Now that we have our basic building blocks, how well does our collaboration culture hold up over organizational boundaries? No matter how cross-functional our teams are or how value stream aligned our organization is, there will come times when we need to collaborate between teams and departments. So the question is:
How easily do we collaborate across team and department boundaries?