MY VIEW ON AUTONOMOUS TEAMS: 

Hello everyone, I’m Toon Wijnands, Lead Architect at Essent. My work largely involves managing and supporting our DevOps teams and architects as we transform our application landscape into a cloud-centric, event-driven environment— all while continuing to deliver business value. A part of that involves transitioning towards teams that can work more and more autonomously. In these 2 blogs I’m sharing my view on that, so here we go:  

At Essent IT, our ambition is to become The Energy Tech Company. To achieve this vision, we need to establish several key components, which we are currently working on: DevOps teams consisting of skilled engineers utilizing modern technology, a cloud-based architecture, and platforms designed with built-in quality to empower autonomous teams to deliver reliable value to our customers.  

While this description might sound like something from Dilbert’s Mission Statement Generator, it doesn’t provide practical guidance for implementing organizational changes. Therefore, we have detailed our approach to make it more tangible and actionable. We have defined our architecture, identified the technologies we will use, clarified our platforms, and set our quality standards. However, we still need to address the concept of "autonomous teams."

At Essent everyone is engaged and agrees that we need autonomous teams, but we are still figuring out what this means for us and what specific steps we need to take to move in the right direction. I want to share our goals, insights we've gained so far, and the road that still lies ahead. 

I’m confident this will be an ongoing journey of learning and growth. 

LET'S START WITH THE WHY.

Why do we believe this approach is beneficial?

The answer is straightforward. Research consistently shows that autonomous teams are more effective, and team members report higher job satisfaction. Beyond the data, it’s simply common sense: the people who are actually doing the work generally know best how to accomplish it.

That’s the easy part. However, understanding the "what" proved to be more challenging. What must we change about our current and past situations to improve this aspect? As I spoke with our engineers, some interesting discussions emerged. Several individuals—independently of one another—desire more autonomy in decision-making. When I asked each of them, "So, you want to set your own salary?" They all responded with a firm "no." They understood that there are logical limits to their decision-making power.

Discussing this further it all boiled down to constraints put on the freedom that engineers felt to reach their goals. Should we completely disregard all constraints? That would be too simplistic. Research indicates that total freedom is also inefficient. Ultimately, it's about finding the right balance for each existing constraint and those that may be introduced in the future. This is a significant undertaking, so we must be prepared for a long journey of gradual improvements, with each step making the situation a little better. We can organize these issues into categories and establish general guidelines for how to address them—essentially, how to achieve the right balance.

TEAM GOAL SETTING

We should not tell teams what to do. But we need to tell them what to achieve. Instead of making this feature on the website (output), tell them that the conversion rate of customers' needs to improve to X% (outcome). They will figure out the necessary features themselves. We already made that shift in the last years, but it doesn’t feel like that for many teams, because they are in the midst of technology transformation which involves decommissioning a lot of legacy systems. The goal with decommissioning often is to rebuilt the existing features of the old system in the new system. That feels more output oriented than goal oriented.

A second thing that can be improved is getting the right information to the team. Teams need feedback loops to learn and improve. Continuing on the above example: if you need to optimize a sales funnel to get information for the team to prevent information overload.

FEWER DEPENDENCIES

This might be the most heard ‘complaint’ and often translated into: “As a team, we will do this ourselves because then we are faster”. And sometimes that might even be the right thing to do. But silver bullets are rare, a closer inspection is necessary here.

Putting software to work often has hundreds of dependencies, so the first step is to see which of these dependencies are potentially harmful. For example, almost all applications depend on a functioning network and DNS server. I’ve never heard teams say: “Let us manage the network or the DNS service ourselves because then things will go faster”.

The reason no one is proposing changes to these services is the slow rate of technology change. From a developer's perspective, these services rarely evolve. For instance, the DNS protocol was created in 1983 and has remained unchanged since then. As a result, once you connect to it, you can largely ignore it from a development point of view. However, there is one important dependency to consider: as a development team, you need the ability to create DNS entries. We will address this in the section about self-service below.

So, the interesting discussion is about the things that change often. Over time a lot of stuff has been written on good software design, good software architecture etcetera. In the end, it all boils down to that one challenge: structure your software in such a way that you keep things together that are bound to change together. And the literature is trying to give guidance on how to determine which things we need to keep together because that is the hard part.

The main guidance within Essent on the team level is to cluster around functionality (instead of technology), everything around a budget bill amount (calculating it, communicating that to the customer) or managing the customer’s consent, etc. The reason for that is that the majority of change is always functional, basically because the organization responds to customer demands, changes in legislation, optimizations on current processes, etc.

The key question remains: how to cluster all the functionality we have? We use Domain Driven Design (DDD) - and more specifically Event storming - to get the boundaries1 between two clusters of functionalities (called ‘bounded contexts’ in Domain Driven Design terminology) right.

Boundaries are usually hard to change. Because boundaries define the interactions between software components, their shape strongly influences how bounded contexts communicate with each other. As a result, changing a boundary might require a lot of other bounded contexts to change, which is counterproductive to our goal of team autonomy.

Designing the right boundaries is one thing, the real trick is respecting the boundaries in the implementation, unnecessary information easily gets leaked across a boundary. The only way to prevent that is by getting a better understanding of the functionality needed (DDD’s ubiquitous language will help with that), the bigger picture (architecture will help with that), and the plain old technical craftsmanship of the engineers themselves.

UP NEXT: MORE INSIGHTS ON AUTONOMOUS TEAMS

As we’ve explored so far, transitioning to autonomous teams involves balancing team goal setting, managing dependencies, and finding the right boundaries for collaboration. These are foundational steps, but there’s more to cover.

In the second part of this blog, we’ll dive deeper into practical solutions for enabling autonomous teams, including approaches to testing, fostering self-service, improving access to information, and implementing effective guardrails.

Stay tuned for Part 2, where we’ll continue this exploration focusing on actionable steps and ongoing challenges!