Effective autonomous teams all share these five things
By Lorén Rose, COO, Global Kinetic
Lorén Rose is a co-founder and COO of Global Kinetic. Drawn to software engineering by its utility in solving complex problems, as well as its satisfying testability, she spent a decade and a half designing and developing enterprise software, primarily in financial services. Working with her future colleagues at Global Kinetic much of that time, she gradually shifted her attention to another kind of problem-solving: operational strategy. Today, Lorén’s focus is on building top-quality, highly motivated, and happy software delivery teams in support of a steadily growing business.
Why autonomous teams in the first place?
Why does Global Kinetic use autonomous teams? Is it because we don’t want to spend money on layers of expensive management? (We don’t.) Would Global Kinetic have a hard time finding middle managers that our super-bright, highly skilled people trust enough to direct their work? (Probably.) Or is it because we genuinely believe that autonomous teams deliver better results? (We do!)
Full ownership and accountability at team level are essential to building highly motivated, efficient, and happy software delivery teams. Global Kinetic relies on our engineers to solve the problems they encounter for themselves, to make their own decisions about the length of time projects will take and the paths they might follow to get the job done. In our experience, that freedom has a measurably beneficial impact on speed and code quality.
So, next question: Why have early enthusiasts like Spotify and Medium reverted to more traditional organizational models? For me, it comes down to this: many organizations have hoped to use autonomous teams to scale, but they scaled too fast. They put ever more people on the ground but without the necessary support. Their early teams may have been exceptional, but most people aren’t ready for self-organization. It’s a skill like any other, and you need time to hone it.
In today’s blog post, I list five important elements I believe you need in order to benefit from autonomous teams. Each element impacts the others directly. If you’re burning on one side of the pentagon, you’re going to feel it on every side before long.
First requirement for autonomous team success: Context
If you want people to do something – and particularly clever people – you have to explain why.
In our industry, you see a lot of these feature factory teams, where they have product owners commanding engineers to “Build this feature! Build that one! Make them look exactly like this.” That’s not helpful. That’s 100 percent antithetical to any kind of autonomous team, well-functioning or not.
If you see the value in self-sufficiency, if you want to empower developers to make their own decisions, you have to ensure that they know, not only what they are building, but why they are building it. What are the problems the client hopes to solve? What are the benefits they hope to accrue? And since we are always indirectly building experiences for end users, we need to know who they are too and what they are wanting to do. Banks and other service providers can only benefit from having our engineers standing in their customers’ shoes.
Global Kinetic is strongly focused on quality, but our customer may also be looking for something else – prioritizing a rapid time to market, for instance. Let’s say that they have a limited budget: they need to launch fast, so that they can bring in new revenue and reinvest it in the software. That’s also important for a delivery team to understand. If they know that, they can determine today’s minimum viable product, taking into account the technical debt and planning how they will address any compromises tomorrow, when the money comes in.
I want our teams to make those decisions, which is why we are continually working to give them as much information as possible.
Second requirement for autonomous team success: Guidance
You have to know what worked before and master that, then come back and alter it if necessary.
While context ensures that teams build the right thing (effectiveness), guidance ensures that that they build it the right way (efficiency). I am highly conscious of the fact that everything I do – everything our teams do – has to be maximally efficient and cost effective. For me to have a hundred people solving the same problems from scratch, learning the same lessons every time, that’s money down the drain.
We have 20 years of collective experience on how to deliver top-notch enterprise software in reasonable time frames. We have codified, I suppose you could say, the lessons we have learnt and the processes that have reliably worked to date. I really value that body of knowledge; whenever things go wrong, our engineers can rely it to guide them back to predictability.
We didn’t approach it as a set of rules. We don’t want to hem our engineers in with anything so doctrinaire or inflexible that it requires them to check with HQ every time they are forced to deviate from the script. We see them as recommendations providing support to the teams in the field. And, by giving teams context on why the guidelines exist and the problems they help solve, we empower them to make better decisions over when and how to apply them.
We don’t hire based on prior experience of autonomous teams. Our approach is unique; it’s a product of many years of incremental changes made against the backdrop of our history and core values. We hope all new people master it over time and contribute something of their own to its evolution and our continued alignment. It’s a living thing.
Third requirement for autonomous team success: Continuity
Building winning teams starts with your pacesetters, but there’s no room for heroes.
You can put in the best sets of guidelines, all kinds of policies and procedures, but, if you don’t take the time to build out your delivery teams properly, your ambitious revenue targets will likely not be met. And it does take time. Identifying and developing your teams’ pacesetters can’t happen overnight, yet it’s vital that you have the right number of them embedded in your teams to provide direction and transfer tacit knowledge – the accumulated, mostly undocumented experience of seasoned staff.
I am highly reliant on skilled engineers who have mastered our processes and have the experience, confidence, and emotional intelligence to adapt them in the right way when necessary. Their availability to seed new teams, up-skill incoming staff, and provide day-to-day guidance constrains how fast I can scale.
In my last blog post, I wrote about how important work–life balance is in addressing employee churn. People do leave, however. When they do, as reliant as I may be on some of them, I want the impact contained.
“Key-person risk” describes the potential exposure of an organization to the sudden departure or incapacity of an important employee. Their loss could affect productivity, morale, client confidence, or brand perception. So, we work to mitigate this by always foregrounding team continuity in our considerations, ensuring that the team as a whole is the hero and their success is never tied to a single individual. As the African proverb says: “If you want to go fast, go alone. If you want to far, go together.”
How’s that translate into reality? Standardised ways of working, documentation and training, the organized transfer of project-specific know-how, mentorship, and the all-important informal sharing of tacit knowledge.
Fourth requirement for autonomous team success: Support
Finding a balance between the needs of the company, its delivery teams, and individual employees takes structure and a caring culture
In any company, you have people working on the business (the strategic layer), people working in it (the operational layer), and a framework to keep the two layers in alignment. So, too, does it work with technical leadership.
Firstly, you need leadership working across delivery teams to drive collaboration and normalisation of standards and processes. Secondly, you need leadership working within teams to drive delivery and apply those standards judiciously, based on business and project context. That’s the only way you are going to be able to scale.
At Global Kinetic, while some people are focused on initiatives aimed at driving the business as a whole forward, others leverage those initiatives within the teams to ensure they develop in turn. Working at another level, the cross-team leadership inspires craftsmanship and mastery in the individual, while the in-team leadership provides guidance to individuals on how to apply their craft optimally.
This sort of matrix structure is difficult to get right, and, done badly, can be distinctly counter-productive. On the other hand, it can happen quite seamlessly, if you have a strong culture of caring and support. What’s best for the business may not always be what’s best for the team or the individual team member. With champions representing each layer, we are better able to devise a solution that meets the needs of all three. It’s a collaborative process that goes a long way to achieving business success, team continuity, and individual growth and fulfillment.
Fifth requirement for autonomous team success: Alignment
Knowledge sharing factors valuable new insights into our formal processes and counters the development of silos.
In his excellent critique of the Spotify model, Jeremiah Lee wrote, “Autonomy requires alignment”. As an aphorism out of context, it’s opaque, I grant you, but Lee was on the money writing that, while cross-team dependencies multiplied as Spotify scaled, the high degree of team autonomy there hindered broader communication and collaboration. Without a structure and a language for sharing their insights and experiences, teams drifted apart and the business suffered the consequences. The biblical Tower of Babel springs to mind.
Early implementations of autonomous teams, including at Spotify, frequently neglected business-level operational considerations, particularly in areas where hierarchy might offer a more workable solution than holacracy: negotiation, conflict resolution, and escalation; individual support and development; and collaboration on developing and improving shared resources.
Unshared knowledge is a waste. “Learnings” have limited impact if they aren’t transformed into “teachings”. I don’t want teams working in parallel to answer the same questions, unaware of or unable to consume the others’ answers. Yes, their directive is to deliver on a project, but I want them to do so in a way that moves the whole organisation forward.
Alignment creates the context for achieving business goals: “What does success for the organisation look like and how do we align our team’s success to that goal?” Autonomy enables us to do that in an innovative, effective and efficient way.
Contact Global Kinetic to discover how we work together.