Balancing autonomy and process in your tech teams

Recently, I was invited to speak at a livestream alongside John Sherwood, the CTO from Gleam.io, and Andrew Murphy, Founder of the Tech Leaders Launchpad. The topic is near and dear to my heart and something all tech leaders grapple with at some point in their careers.

How do you balance giving your engineering team full autonomy with providing the structure and alignment for them to do their best work?

The panel inspired me to write this blog post. Don’t forget to watch the video recording the event for all the juicy insights and discussions. In the meantime, I’ve penned some highlights and key takeaways to share with the Kaleida community.

Defining autonomy and process

First, let’s talk definitions. To me, autonomy means that the team and the individuals within it can make their own decisions, whether about technology choices, ways of working, or approaches to solving a problem.

Formal processes are scenarios where there may be particular constraints within which a team should operate. I don’t like to think of processes as something that is ‘imposed’ top-down on team members. Instead, they are more like a set of sensible defaults. Sometimes, those are formal steps and actions, but other times, they’re a set of guardrails that can shift depending on the problem you’re trying to solve, the team you’re working with, and the experience level of the individuals involved.

Is the balance between autonomy and process fixed?

Autonomy and processes aren’t as much of a dichotomy as people would like to think. Processes aren’t inherently bad in and of themselves. There is a difference between rigid processes and defaults that are sensible and help you get work done effectively.

If someone focuses on completing a task, they don’t necessarily want to be thinking about all the stuff behind it, such as business-specific nuances, reporting tasks or regulatory and compliance requirements. In those cases, adhering to processes can be a shortcut to focus on getting the job done. In a different situation, that same person could want to be curious, challenge current ways of thinking, and effect change. I know people groan when they hear this – but it really does depend on the context.

At one point in my career, I moved from a process-heavy organisation and leapt into my next company resolving to give everyone lots and lots of autonomy! But the team was young and inexperienced. I was effectively giving them a blank canvas and asking them to paint a masterpiece, which was completely unfair to them! I learnt the importance of putting in guardrails for them, providing them with guidance and opinions that they could work safely within and then begin to break out of after gaining more experience.  

What factors need to be in place to support team autonomy?

The right frameworks and data for decision-making

One of my favourite discussion points from the panel was from Andrew, who said that it’s not enough to give people complete autonomy. It needs to be supported with solid decision-making frameworks and data to help the teams make the right choices within those frameworks. 

He used the example of companies who expect their software teams to exercise autonomy by deciding what features to build – as long as they are profitable and well-adopted by users. But if company leaders keep criteria and data for defining profitability and adoption locked away, they can’t expect their teams to make good decisions. It’s forcing the team to make decisions in a vacuum or just to throw something at the wall, hoping it sticks! 

Accountability and a sense of ownership

With autonomy comes responsibility. As my fellow panellists pointed out, software engineers can sometimes be shielded from the consequences of poor decisions. But there are so many valuable lessons when things don’t work out. 

To go back to the example of software teams deciding on what features to build, I subscribe to the idea that if teams want to own something, they should fully own it. And that means taking the credit and rewards when it goes well but also being accountable when it doesn’t pan out.

I love it when my teams go away and do the research, measure the data, and then come back to me to say, “Hey, we did a thing, but it didn’t work!” It’s crucial to build psychological safety so team members don’t fear failure, but at the same time understand the business implications of that decision. If they realise it doesn’t make sense to maintain a legacy system with no value to customers, I see that as a good outcome. It may be something to cull so the team can move on to the next better thing.

Leaders need to understand that autonomy only comes with empowered people, with the right data, the right access, and the passion to achieve. 

Good processes (not rigid processes)

As I mentioned, autonomy and process don’t operate on a binary. Teams can exercise their autonomy with good feature delivery processes that go from ideation, building, testing, releasing and maintenance to the end of the feature’s life.   

However, be wary of rigid and heavy processes that don’t flex to meet the needs of the team and organisations. In those cases, it’s more likely that the teams and organisations will flex to meet the process needs, and what can end up happening is that you lose talented, passionate and creative people who cannot work well under such a constrictive environment.

How do you know if your team has too much or too little autonomy?

Are team members being weighed down with unnecessary processes (too little autonomy), or are they off working on their side projects that may not contribute any business value (too much autonomy)?

I always start with my DORA metrics to give myself an understanding of my team’s performance. What’s the time for delivery, and how quickly are they deploying? What’s their throughput? These simple measures are a starting point to give me a good idea of value delivery. 

When there’s too much autonomy

Teams or even “lone wolf” individuals with too much autonomy might disappear for a month because they’ve suddenly decided to build a thing that no one knew about.

During the panel, John joked that he became a “helpful lone wolf” when he worked in a highly structured environment. I think there are two types of lone wolves: the ones like John who see an opportunity to make everyone’s lives better and build Skunkworks projects that help solve a lot of pain points. But they’ll bring everyone along on the journey of maintaining it. 

Then there’s the other type of lone wolf, who think they’re right and then change the systems or code architecture unilaterally without considering the broader impact. They don’t think about the budget implications or maintainability of the feature. Those are the detrimental lone wolves that you’ll want to pull back into group decision-making and set some guardrails in place for them. I used to have a rule that if something was going to take up more than half a day, it needed to be carded up and prioritised. Every individual is accountable to their team, managers and the business. These conversations need to happen early enough so you don’t end up having to throw out good work.

When there’s too little autonomy

You can get a good indication if your team needs more autonomy from regularly observing and conversing with them. You’re more likely to hear dissatisfaction and grumbling from a team that feels they have too little autonomy. Or, sometimes, they might just go silent and give off a sense of resignation. Or it can manifest as team members being afraid to take risks and playing in their safe space. If my team isn’t coming to me with ideas, suggestions and enthusiasm, they probably feel they’re getting spoonfed and have too little freedom to explore.

Another telling sign is when the team starts shifting the locus of control for their decisions to external parties. If you’ve heard teams complain: “Sales want this,”; “Sales won’t let me fix the tech debt”, or “The business won’t let me fix the tech debt”, then you know what I’m talking about. This externalising is often down to a lack of context to understand what tradeoffs must be made, or from a lack of experience to effectively consider, prioritise and negotiate stakeholder requests. 

How do you introduce needed processes to a highly autonomous team?

If you’ve been working with a team that prizes autonomy but could benefit from additional guardrails, how do you start making the change?

Lead with openness and curiosity

If you’re new to an organisation and team, go into your one-to-ones and team meetings with curiosity. There is a whole history behind why things are the way they are, and you’ll only be able to discern it if you talk to the people who are the holders of the oral history of the organisation. Chat with them on how they got to where they’re at, because you plan on continuing that journey with them. 

Approach it from a problem-solving perspective

When I first introduce a new process, I first talk through the problem and then suggest an approach that could help solve the issue. I don’t impose the solution on them. If they have a better way to solve the problem, I’m open to giving it a go. Developers love experimenting, so bringing people along with you on the problem-solving journey can help break down barriers. 

Be open to changing and evolving processes over time

Team members are more open to process changes if they understand the rationale. So, set a time limit and some way of measuring the impact of the change. Measuring this impact doesn’t have to be onerous or overly formal. But people will be more likely to get on board if they see it working. If it’s not, they’re more likely to buy in if they can have some say in the next evolution of the process. Team members want to have a voice in making change happen. 

Balancing autonomy and process with Kaleida

Striking the right balance between autonomy and process isn’t easy. The ability to judge when to lean in one direction versus the other takes time and experience, and it can be a daunting challenge for leaders.

But with the right tools, the journey can be a lot easier. Kaleida’s career growth platform is the ultimate tech leaders’ toolkit, which offers frameworks that provide clarity on benchmarking and growth. 

If you’re looking to empower your team with the right blend of autonomy and structure, Kaleida can help. It’s the platform I wish I had when I first became a tech leader, and it’s a big reason why I decided to build it with my co-founders. Let us be your partner in creating an environment where your tech teams can thrive.