Team autonomy only works when leadership shows trust

3 positive examples and one rug pull

The magic ingredient of team autonomy is trust. With trust, teams will likely feel a higher sense of ownership. Without trust, teams will be less likely to take initiative and responsibility for their work.

I saw how leadership fostered the growth of trust, how they navigated through difficult situations and what the impact was on the overall organizational growth. I also know how trust can vanish quickly.

“Trust arrives afoot but leaves ahorse” - Dutch proverb

When our new CTO arrived, our company was in trouble. We did a lot of work but couldn’t deliver valuable products to our customers. Our archaic processes and rigid organizational formation were crippling any collaboration and progress. His conclusion was simple: we needed to change and he initiated an Agile transformation.

We went all in and didn’t make the mistake of only focusing on the software development teams. Everyone was in it, including leadership. They received training, coaching and mentoring just as the rest of us did. On top of that, their job descriptions changed as well. They had to make the transition from being managers to being leaders.

Many of them had no trouble with this and embraced their roles well. Others though had more trouble doing so. Here are three examples and how the organization dealt with it.

1. Manager vs Product Owner

We had a manager who couldn’t leave his old ways of steering the team behind. He was used to prioritizing the work for the teams, creating the plans and chasing them to complete the work accordingly.

He continued to do this, even when the team turned into a Scrum Team with a Product Owner. He even refused to take the Product Owner along when he spoke with the stakeholders, promising them things without the team’s consent. He created a plan while ignoring the Product Owner’s backlog. All the while, the stakeholders were unhappy with the false promises.

The team chose to stick to the Product Backlog. The Scrum Master coached the manager on how to engage with the team and how he stepped out of line when he engaged with the stakeholders and made these promises. The manager chose to escalate to the CTO, only to be informed that the Scrum Master was right and that he needed to ensure he would allow the Product Owner to do his job.

In the months that followed, the manager had a couple of other moments where he wanted to enforce his ideas, but due to the trust the team had in the CTO, he failed every time.

Once the shackles were removed, this team started to flourish, building a great relationship with their stakeholders while building great new product features and stabilizing their product at the same time. They showed how they could excel with the right level of trust.

2. Manager vs Scrum Master

Another manager was fully on board with the transformation, but she felt the teams she led could step up the gas and transform faster. There’s nothing wrong with challenging the teams, but she did more than that. She created a development path for the teams and demanded they stick to it. She bypassed the Scrum Masters.

The Scrum Master reached out to the Scrum Master community to request assistance and the community lead engaged with her to discuss if she required coaching. Sadly though, the coaching efforts didn’t result in the desired impact and she kept on pushing her teams. At a certain point, after being patient for months, the CTO had to take drastic measures. In the end, the manager parted ways with the company as she couldn’t fulfil the expectations of the role.

3. Architect vs Developers

Then there was an architect who believed he was the one to tell the teams what testing tool to use. After all, he conducted a year-long study of the alternatives and this tool came out as the best for the company. However, all the teams were objecting to this. The issue wasn’t the tool, but the fact that the architect believed he could force the teams to use this company standard tool.

Initially, the CTO was on board with this as he hoped that the Agile way of working with also lead to simpliciation and fewer tools. But when he understood that the developers had other ideas, he decided it would be up to the teams to decide.

The architect now had to convince the teams that his choice of tool would be great for them. In the end, about one-third of the teams were [persuaded while the others decided to continue working with their tool of choice.

Continuous trust

Meaningful change should not rely on one person. It should be engrained into the organization. The moment the CTO left the organization was an important litmus test: would we continue to embrace agility and autonomy? This proved to be the case. The CTO left an organization where Agile leaders trusted their teams to find the best ways to achieve their goals.

These leaders would constantly repeat the message of the importance of autonomy and lead by example. Autonomy became an integral part of the company’s culture.

Rug pull warning

I want to end with a warning. Fostering trust and autonomy should not be neglected. I have seen how a new leader discontinued the practices of their predecessors, talking about autonomy in throwaway lines and showing behaviour that indicated they valued the opposite, like not trusting their people to be professionals in their field and introducing a level of micro-management control. Trust disappeared rapidly, being replaced by fear, anxiety and apathy.

Fostering trust is hard work. And people quickly understand if you mean it … or not.

Generated with DALL-E-3