To create a remarkable engineering team—one that is driving the whole company forward—CTOs have to make a conscious effort to bridge the gap between business and engineering. Such an effort can only come to fruition if one accepts that providing a team with autonomy is a requirement for creating a solid connection between the team and the rest of the company. Vice versa, for autonomy to be directed well, it needs to be accompanied by product mastery.
I think this is an excellent opportunity for story time: I was advising the CTO of a fintech B2C SaaS, and we were focusing on cultivating an environment where his team can be the most impactful they can on the business. They wanted to move the needle on a daily basis.
He completely empowered those talented, bright people—though most weren’t senior—and ensured that they were deeply knowledgeable about their product and market. That resulted in an autonomous team that rapidly delivered results.
Working in several squads, each group tackled business issues at an incredible pace and propelled the company forward. That allowed him, as the CTO, to focus on leadership and strategy as the team was humming along. And it wasn’t rocket science.
Why fostering autonomy is necessary
I doubt you’ll object to the notion of wanting to enable your people to do remarkable work and operate at the top of their ability. We know that is not possible when they depend on their managers for every single decision and aren’t granted enough leeway to work on their own. When people are truly autonomous, they can focus on impact and waste less time on escalating issues and waiting to receive directions.
Having autonomy is also the only way to allow your people to genuinely achieve self-actualisation—the top of Maslow’s Hierarchy of Needs pyramid. Working with multiple companies has taught me to value those exceptional individuals, who then become engineering force multipliers.
And, of course, autonomous teams provide their leadership with more time to… lead. Rather than drowning in the day-to-day minutiae, you gain the time to focus, think, and invest in longer-term vision. Almost every single leader I help, especially first-timers, is continuously shuffling from one meeting room to the other (or from one Zoom call to the next if there’s a pandemic). The freedom an autonomous team enables is invaluable.
Not an on/off switch
A word of caution: when I coach executives about their team’s lack of autonomy, some try to make the change immediately. They give their teams goals and let go. Set it and forget it. Then, when it’s the end of the quarter, and no result was achieved, they claim autonomy doesn’t work for their company.
There’s a complimentary part that goes hand-in-hand with autonomy, and that’s having absolute clarity about the company’s purpose. Without it, you might find that your people are losing track of what’s important. I always say that engineers can be placed on the Tech-Product motivation continuum. Most engineers don’t really care just about the tech and not about the business. The chances are you are not giving them enough context and perspective to understand and care about the business. That, in turn, makes them focus on what they do understand—the tech.
Don’t abdicate your role and responsibility here. Provide them with autonomy, but make sure you put the right coaching and leadership in place to make it work.
Bootstrapping autonomy right
To kickstart your autonomous transition in the right manner, here are some steps you should take:
- Provide a wide perspective – Do not discuss the ‘what’ before you first cover the ‘why’. Quarterly kickoffs, for example, that solely focus on the roadmap and its timing, are wrong. You should start by laying out the reasoning and the strategy (and you, as a genuine CTO, should fully comprehend these and take part in shaping them).
- Invest in Product Mastery – The key to connecting your engineers to the business is by making it their business. Create regular friction points where they get to experience your customers and product first-hand. Whether it is by dogfooding the product, shadowing customer support, watching recorded client interviews etc. Product Mastery is needed to push them towards the Product side of the Tech-Product continuum.
- Empower them – Whenever possible, provide your people with goals and not tasks. Interdisciplinary teams that own a specific business objective and come up with their own plan to achieve it are often more creative and aligned.
- Don’t accept siloed thinking – There shouldn’t be any ‘us’ vs. ‘them‘ when talking about Product, as well as not accepting the mentality of slinging code over the wall to the next person saying, “I did my part, he was late.”
- Provide guidelines – Rather than supplying answers and decisions, when your team approaches you, you should default to laying out the underlying thinking so they can reach the conclusions on their own.
- Put your coach hat on – This isn’t a one-time thing, but a journey. Be prepared to make adjustments and help everyone hone their efforts until this becomes ingrained.
- Debate, don’t manipulate – Discussions should be genuinely used for finding the best path of action and not your platform to get ‘buy-in.’ If you start knowing what is the way you’d like to go and the intent of convincing everyone to do things your way, then you might get their short-term approval but also do long-term harm to their autonomy.
Autonomy assessment
To finish off, here are a few questions I ask clients to quickly assess where we.
- How deeply do your people know your ‘commander’s intent‘ and can explain why they’re working on what it is they are focusing on?
- When asked for guidance, how often do you provide reasoning and guidelines to make a decision rather than a ‘finished result’ decision?
- Can the team explain and use the product even when it comes to parts they didn’t actively work on?
- How often is the group exposed to the impact of its work on the customers?
- When there’s disagreement with Product, or when shaping up the work to be done, can your people express trade-offs in business terms or can only use the techie-stick (“It’s hard, and it will take X days”)?
After answering these, it should be clearer which of the above are the most critical steps to start with and get you well on the way to making your team remarkable.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more