BA 41/52: The Trouble With Autonomy
This piece is part of an ongoing stream of thought on Systems of Work. Together, these individual pieces form a playbook on how TPMs can leverage their skills to help teams do the work of doing work effectively.
In the modern agile world, every organization is striving towards a structure composed of autonomous teams constantly delivering value to the customer. Why? Because what we are told is that truly effective engineering teams are autonomous. Google does it, Spotify does it, GitHub, Atlassian. Why can’t you.
Here is my verse to the larger discussion - autonomy is not what you want; there is something better, something I saw and experienced at Apple — self awareness.
Why does this matter to Technical Program Managers — Leadership turns to us, TPMs, when it comes to dealing with inefficiencies within engineering organization. The most concerning of inefficiencies for any leader is not delivering value at the right pace and at the right time. Unfortunately, leadership’s first diagnosis is always “the engineering teams are not performing well, we need to make changes.”
It is our job to help steer leadership to arrive at the right diagnosis and eventually the a potential solution.
Let’s suppose the engineering teams are the issue. What would you change? Pick up any literature that has the word agile and the buzzword will be autonomy.
“Teams need to be given autonomy, so they can be closer to the customer issues and drive the change they see fit.”
Alas, as many things, sometimes, the answers are simple and sometimes, they are not.
I have been part of numerous effective (and non-effective) teams and I can tell you, autonomy isn’t on the list of reasons why they are high-performing teams.
What truly made those teams high-performing was a heightened sense of self-awareness.
Self-awareness of what the individual team members of the team can deliver.
Self-awareness of what the whole team as a unit can deliver.
Self-awareness of that teams role within the company (organizational structure wise).
Self-awareness of what aspects of the product or platform they could impact and control. (cross-functional)
Self-awareness of the limitations they had on strategic and tactical decision making.
How to create more self-aware teams? The Apple Way
Self-awareness comes from clarity, authority, and people.
The secret to the highly performant teams at Apple was not autonomy but the trifecta of the above 3 elements creating the environment for highly self aware engineering teams laser focused on what needed to be done.
So, can this formula be replicated? Not a 1:1 copy, but I can share a framework that will help you develop your own program to create self aware teams.
Lets start with clarity.
Clarity — at every step, leaders and management needs to ensure engineering teams have high-level of clarity about the world in which they are operating.
Where is the business heading?
What is important to the stakeholders?
What is the grand strategy the company is staking everything on?
Where are we in the release cycle?
What matters most right now?
It does not matter how much autonomy an engineering team has, how amazing they are at agile, or scrum, without purpose and grand vision, the team is no different than a ship without direction.
At Apple, everyone knew exactly what the company focus was, what was the priority, and what was not. This gave the teams the boundary to operate and make decisions and understand how their decisions could impact the world around them.
Authority — I have often said that what made Apple Apple is the little thing called the DRI (Directly Responsible Individual). Every project or effort had one single, expert, in charge, who isn’t necessarily a people manager or VP but the person most fit to drive the effort end to end.
Just naming a DRI is not enough, it has to be followed up trust from leadership.
If senior leadership is still asking questions or updates through the organizational hierarchy instead of going to the DRI, the system has failed.
In that same breath, leadership trusts the DRI to make tactical decisions on day to day basis for the cross-functional team while setting the expectation that they will bring to leadership the more consequential strategic decisions who impact could have impact outside the effort in question.
Above all - the authority of the DRI is clear and universal understood across the organization. There must be no doubt.
Until you make it clear for the person in charge the expectation placed upon their shoulders, you do not equip them with the right lens to view the day to day proceedings of an engineering project. They are not aware of the weight of the decisions the DRI makes in a cross-functional project until there is… clarity.
Lastly, people.
People — you hire the people that are not just good at their job but can bring the best out of others with their presence in the cross-functional team. You can say “the ones with high emotional intelligence”. You can have the greatest of frameworks and methodologies but if the people you put in positions are not equipped with the skills to handle the role, process will not help you.
Modern technology is one of highly complex cross-functional smaller systems (think: microservices) operating at varying pace, speed, and statefulness to achieve an even greater output/outcome.
Much like these systems, there are differing and varying opinions of what makes teams high performing. My experience from Apple and Google has taught me that above autonomy, self awareness is a more powerful mindset to develop within you engineering organization to have truly effective teams.
Perhaps, autonomy is what we should strive for and the only way to get there is through first developing a heightened sense of self-awareness in the teams.
Good luck, TPMs. I hope this opinion of mine gives you another data point to leverage the next time leadership comes to you with: “we need to do something to make the engineering teams be better.”
Until next time 👋!
-Aadil
How was this week’s newsletter?
I was asked by my CTO to figure out a way to make our product suites more robust and reliable by reducing the number and duration of the incidents. I will put my proposal together with the data points shared in this newsletter. Timely and insightful!