When leading a tech organisation, how do you determine what makes the difference between success and failure in a market that is rapidly changing? Determining where to focus in shaping an organisation and creating the right culture is clearly one of the key challenges of being a leader. In this post, I will look at how some of the leading tech companies set up their development organisations to deliver innovation and keep on top of a fast-moving world. Never has the adage that you need to run to stand still, or not to lose ground, been so true. So what are the cultural and organisational factors that the successful tech companies rely on to deliver innovation?
Google – Taking risks – the importance of psychological safety
For an insight into what makes Google tick, there is probably no better place to look at “How Google Works” by Eric Schmidt and Jonathan Rosenberg. However, a more useful perspective into the dynamics of teams at Google is found in the outcome of a large data-driven project Project Aristotle. This was a multi-year investigation by Google’s People Operations team to find out what differentiates the highest performing teams in a year. The key finding was that success depended not so much on who was on a team but on how the team interacted.
Of all these dynamics, the driving one was that of Psychological Safety, which describes if the team can take on risks without feeling insecure or embarrassed. The project found that the safer team members feel about taking risks and making mistakes, the more cohesive the group is and the more likely they are to take on new ideas. Fundamentally, they become more effective as a team. The irony is that a multi-year data-crunching project resulted in conclusions are hardly novel – in good teams, members listen to each other and show sensitivity to each other, something that a good manager would know anyway.
Spotify – Aligned Autonomy
One of the most widely shared case studies of how important culture is in making a successful dev team is Spotify. The Spotify approach was popularised by a couple of inspiring videos by Henrik Kniberg. They went as viral as any video on engineering culture can aspire to(close to 800k views and counting!).
The key principles espoused by Kniberg are as follows. The core unit of work at Spotify is the “squad”, a self-organising cross-functional team that has a single key mission. For example, build a given feature. Crucially, the squad has end-to-end capability and accountability from design to release. In turn, squads are organised into tribes, which are designed to feel like self-contained start-ups. Squad members are also members of Chapters oriented around particular areas of expertise. This makes it similar to a matrix structure, though the principal orientation is around delivery.
The key challenge is is that building upon independent, self-contained self-organising teams can be a recipe for chaos. This is where alignment comes in. This is the key role of the Spotify leadership – providing a clear, unambiguous direction for the teams to focus on. In their words, “autonomy with alignment increases motivation, quality and also faster releases.” In this way, Spotify has managed to maintain an agile mindset without sacrificing accountability, nor by exerting excessive control or micro-management.
Amazon – The Machine that makes the Machine
In the early days of Amazon, Jeff Bezos established a rule – no team should be set up that cannot be fed by two pizzas. This effectively limited all teams to no more than 7 people. Taken at face value, this seems to be a pretty prosaic rule, but as we shall see, this was a fundamental building block of Amazon’s uncanny ability to grow.
In small teams, and the entire team can communicate effectively, but as it grows, the number of links between team members increases dramatically. In turn, this increases the administrative burden within the team. Moreover, putting an upper limit on team size also protects against the team scaling fallacy. Adding more people to a team does not necessarily make it more productive, indeed the opposite is often true. This rule therefore acts as a counterbalance to the natural urge to grow teams.
“A machine that makes a machine”
However more important than the efficiency consideration is the benefit that it provides when scaling. In Amazon, these atomised teams can be easily multiplied and set to take on new product lines. They are often given responsibility for their own P&L, are encouraged to take ownership and have the resources to move fast and decisively. When viewed in this way, Amazon is not so much simply a company growing by adding new products. Instead, in the words of Benedict Evans, it is a machine that makes a machine. In other words, Amazon is designed to produce more of Amazon.
This is the secret behind its ability to grow at such staggering rates. When Jeff Bezos, in another of his edicts, way back in 2002 required that all teams will provide services through standard APIs. These APIs will be available to all internal teams and must be designed with the assumption that they can be made public. The mandate ended with “Anyone who doesn’t do this will be fired. Thank you; have a nice day!”
The insight that led to this instruction was that Amazon could only scale if each area of functionality and each feature was decoupled from each other and could interact with each other programmatically. If features required bespoke interactions, manual configurations or some other form of non-standard communications, then Amazon would soon reach an upper limit on its ability to grow, and its growth would grind to a halt. It was as though in one fell swoop, Jeff Bezos eliminated gravity. With clear deliberation, he changed the laws of governing scalability, creating an organisation, that in a very organic way, could grow with as few constraints as possible.
Conclusion
Of course, in the real world, not all organisations or companies can become a Google, Spotify or Amazon. This is a mistake that Eric Schmidt makes a few times in the advice he dispenses in his book. Not all that works for Google can be applied to other companies. Nevertheless, the key themes here are not only applicable, but are in my opinion, essential for any company trying to grow in today’s rapidly changing and unpredictable markets. Google’s research into what makes a team excel will apply to all high-performing teams, while Spotify provides a model as to how to empower those teams and provide guidance without sacrificing autonomy. When it comes to growing and scaling, there are few case studies as compelling and effective as Amazon’s focus on removing the blockers to growth.
More Reading:
- https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
- https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html
- https://hbr.org/2017/02/how-spotify-balances-employee-autonomy-and-accountability
- https://hbr.org/2014/01/how-netflix-reinvented-hr
- https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/
- https://www.ben-evans.com/benedictevans/2017/12/12/the-amazon-machine