“What if I told you we were putting a team together?”Tony Stark aka Iron Man
“I’m putting together a team, people with special abilities…”Bruce Wayne aka Batman
When we’re recruiting a new team, or augmenting an existing team, this is what we want candidates to think. We want them to believe they’re joining an elite team of professionals where their unique specialist skills will be brought to bear to change a market, an industry and perhaps the world.
Brilliant, I’m in.
It’s often not quite as we imagined.
So what is it? Why don’t teams turn out to be what we thought they would be? We wanted a high performance team, but somewhere along the line, with some exceptions, we end up with the lowest common denominator rather than the highest common factor?
Is it possible that we don’t know how to put teams together?
What Makes a Team?
Building teams is the subject of any number of books, each offering some piece of the puzzle.
Simon Sinek, for example, in Start With Why suggests that it’s about aligning people with a vision of why their company exists. That is an excellent place to start, and there are many other recommendations in the book that make it a great read.
Kim Scott’s Radical Candor on the face of it discusses communications skills, but has plenty to offer on coaching while Daniel Coyle’s The Culture Code drills into establishing groups and building a culture for success.
Then of course there’s the many books on the specifics of organisational structure, from Henry Mintzberg’s academic treatment of the subject, through DeMarco’s famous Peopleware to my last read on the subject Matthew Skelton and Manuel Pais’ Team Topologies which has to be one of the most comprehensive books on this topic.
And the list goes on and on, with each book, article and paper offering more insights into the psychology of teams, the structure of teams and the operation of teams. I have to admit that I habitually read the material; we can always learn something from another perspective.
Ego (and a little bit of experience) allows me to offer my distilled guide to building a high performance team – think of it as Dave’s Team Building Cheat Sheet…
Clarity of Purpose
Whether you agree with Simon Sinek or not, he has a point on starting with why. If you don’t know why your company exists, you can never know why you’re putting a team together. If you don’t know why a team exists, it can never succeed, because it’s going to be aimless.
A strong team has an identity, and part of that identity is grounded in the teams purpose. It’s logical, therefore, that you can’t build a team identity if the team doesn’t know why it exists. A team without identity isn’t a team at all.
Forests weep at the amount of paper that has been spent documenting collective ownership, shared ownership and every other type of ownership and responsibility.
Accountability, in my mind, is ownership’s more severe big brother. Accountability is ownership of the outcome, the benefits, and where necessary the consequences. Strong teams don’t just know that the buck stops with them, they feel it and they believe it.
Teams have to be permitted to be accountable, which is often where things start to fall down. If this is one of your teams, then you’re accountable for their outcomes; you will need to allow them to be accountable, even when you are ultimately accountable for how they perform – not easy.
If the team knows what it is supposed to do, and it’s clear that they have complete accountability for the outcome, then they must have authority to achieve that outcome. This means that they must be allowed to make decisions that in their opinion benefit the outcome.
It’s important to delegate that authority to the team, and allow them to figure out how to use it, but it’s equally important to constrain that authority. No team is an island, and they can’t be allowed to operate as such, authority to make decisions can’t be to the detriment of a dependent team.
Seems obvious right? Respect your people and they’ll respect you. But respect is a difficult road, people are hired to do a job, they’re interviewed them to make sure they’re the right people with the right skills and then this raw material is taken and moulded into a team. Finally that team is pointed in a direction and imbued with authority to succeed.
That’s enough right? What more could be needed? Surely giving them direction and authority is a measure of respect?
As I said, respect is a difficult road, it’s fine when all is going well, but a team needs to be respected enough to be praised when things are going well, and told when they aren’t. Respect demands the great conversations and the tough messages. This allows a team to always know where it stands; a team that knows where it stands is psychologically safe and safety is needed for a team to work effectively.
If you think respect is a hard road, trust is the rock many teams perish on. Closely aligned to authority and respect, trust is required at the level of the individual and at the level of the team.
If you’re putting a team together, you’re in a position of some authority. I guarantee that by virtue of being in a position of authority that you are a control freak at some level.
You realise that you need to provide the team with feedback, both the rough and the smooth.
But do you trust the team to make mistakes and recover from them on their own? Or do you need to interject when the team isn’t performing their task in the same way you would? Trust requires balancing feedback and control. Fact based feedback based on outcomes is respectful, uninvited opinion based feedback before an outcome is reached is a lack of trust.
People, and teams, learn more from their mistakes than their successes, but only if you trust them enough to allow them to make a mistake, and then support them when they’re trying to recover. If you can’t trust, you’ll quickly unwind respect and authority at which point a team can’t, and won’t retain any sense of accountability.
Teams need support. Support from a mentor what can offer opinions and insights when asked, support when they’re doing well, and support when they hit rough patches.
Support also requires that the team gets the resources they require: equipment, training, additional members. You wouldn’t put a football team on the pitch with no boots, and you wouldn’t ask them to win a trophy without coaching. You might think that passion and skill is enough – it isn’t.
The team also needs support in the form of air cover. There will be questions, questions on performance, accountability, output, which are all normal. But if you’re really going to trust the team, they will need significant cover when things go wrong, and they will, before the team starts to correct. You will need to keep faith with the team and protect them and their approach.
Achieve this and the team will really start to believe, and when they start to believe they will start to hold themselves accountable – and as they say This is the Way.
This is the test of your leadership: visibly standing out in front of the team, being the champion they need when they need it.
The High Performance Team
Not all strong teams are high performing teams. They may look like it, and relative to other teams in your organisation they may even appear to be it, but more can be done to send the team’s performance into the stratosphere.
High performance teams have a very stable structure. Each member knows their role within the team, understands the roles of the other members and have the skills to meet the demands of the role. There may be fluidity in the tasks that people take on, but there is no ambiguity on role which leads to clarity on expertise.
Again taking a leaf from high performance sports teams. There may be attackers and defenders, or there may be the strong and heavy and the light and fast, but it’s always clear who is supposed to do what. Similarly you might find your strong and heavy sprinting with the ball, but it’s rare and generally opportunistic rather than planned.
Structure also crystallises where the decision makers are within the team and the scope of the decision making authority. If a team needs to operate quickly there must be clear decision making structures in place and rules in place to ensure that those decisions are adhered to.
High performance teams have familiarity with each other. They’ve established their identity, their culture and their internal behaviours. This isn’t free, and it isn’t quick.
This means that your team needs to be stable over time; you can’t just pull people out of a team or parachute new people in without disruption. Disruption is the nemesis of performance.
Simplicity is the critical factor that every high performance team has in common. Whether you review sports teams, military squads or tech startups one thing is consistent: they eschew complex solutions and complex patterns.
This is particularly apparent in sports teams, where the results are often televised for everyone to see, but it is everywhere.
Here’s the logic.
What makes a high performance team? Choose your adjective, but at the bottom line it’s excellence. High performance teams are simply excellent. So how do you build excellence?
Repetition, repetition until the behaviour becomes internalised and then application. It turns out that practice needs to lead to performance to maximise the skills being learned – this is why athletes who compete surpass those who don’t.
Repetition requires consistency, you have to repeat the same thing over and over so there is no room for variety. Variety kills repetition.
Certainly there is room for complexity in repetition. Anyone who has played a video game knows that hours of gameplay allows for complex patterns to be identified and learned. But that’s an individual pursuit. You can have a team of people all learn the same pattern, so you might argue that simplicity isn’t the factor. This is incorrect.
Teams have interdependencies, they need to work together in a supportive way to achieve the outcome. This is not the same as them all executing the same pattern at the same time, it is every team member participating in the pattern each taking their own specific role. The more complex the pattern, the greater the interdependency. The greater the interdependency, the greater the chance for mistakes. Again, mistakes are not a friend of high performance teams.
High Performance Tech Teams
These rules work for every type of team. Tech teams are more challenging in many respects because the environment changes so quickly. New technologies, new platforms new processes and let’s face it, new toys are all distractions that can derail a high performing team.
Identity can be built at the department level and the team level. If you are building a system that comprises the output from each of the teams, then it’s important that you establish identity at the system level, but allow teams to coalesce into smaller groups that express their own identity. The military have done this for millennia at this stage, and there’s a reason why it persists as an approach.
If, on the other hand you have completely independent teams, then you can build identity at the team level, but identity purely at the team level needs to be established carefully or you are in danger of developing silos.
Build identity at the highest level of interdependence.
Stability needs to operate at the level of identity. Long running stable teams can be subdivided into squads as necessary if the members are all drawn from the same identity pool. Friction is introduced where two or more identity groups clash.
Stability must not be confused with exclusivity. We must aspire to maintain the stability of a team, and that stability is a strong factor for high performance teams, but it is also a slave to necessity. We may choose to destabilise a team, and take the hit on one teams performance to achieve a wider goal, and teams must know this.
This has always been the most controversial area with tech teams in my experience. Simplicity is the elimination of choice, it is standardisation and consistency of processes, tools, platforms and systems.
Service Oriented Architectures, of which Microservices is a subcategory suggests that standardisation is perhaps only necessary at the boundary / interface of the services. This may be true if you have deep pockets allowing you to hire enough people to support each service, but it will make your overall system architecture more complex, your operations more demanding, your training budgets extensive and your overheads will spiral.
You will fight to standardise, and you will have ongoing debates on those standards. Your tech team will rail against these constraints, but all of that can be managed with processes to define and manage the standards.
But if you want a high performing tech team, you will need to standardise.
At the end of the day, you’re dealing with humans. People with real lives, real concerns, dreams, desires and ambitions.
You are not in control of all the factors. All you can do is create the best environment you can for them to succeed, and hope they in turn take the opportunity you’ve crafted.
Respect the people, appreciate their individuality, and shape everything from a position of integrity and your team(s) will give you their best.
I抎 should verify with you here. Which is not one thing I normally do! I get pleasure from reading a post that will make people think. Also, thanks for permitting me to comment!