How to UNBURDEN software teams

5 min readJan 17, 2023

Unleash the shackles of your software development teams!

Read how to unburden modern cloud-native software development teams. We should aim for a more holistic perspective when we make IT decisions. In many places we flood our teams by adding more and more to their load, bringing productivity and joy to a grinding halt.

Cloud-native has been one of my favorite ‘trends’ in software development. I love the productivity of modern independent strong teams that can build-run-own-scale their stack. Best-in-class technologies, processes, and skills enable them. They are standing on the shoulders of giants. But honestly, not every team or every company has reached this productivity Nirvana. Some might have even slowed down!

The best IT enablers can also be the huge disablers!

In this article, I will reflect on what factors contribute to enabling great team performance in a modern software development setting.

Complexity engineering for modern development teams

The complexity introduced by moving towards service-oriented, and later microservices in the past ten-to-fifteen years has put a lot of pressure on the capacity to deliver for software development teams. We even redefined what it means to ‘deliver’ in the context of a software development team. In 2005–2010, a team’s output could be measured in the ability to produce a software package or library (an improvement compared to lines of code a decade before). Fast-forward a decade, and top DevOps teams are now expected to rely on positive influence on business metrics when they — of course regularly — release.

With each change to our delivery machine, we have improved our technologies, process, and skills to match our new situation. While we unlocked huge potential with these ‘improvements’ we often find ourselves hesitant about the actually achieved benefits.

We need a delivery ecosystem instead of a machine

The software delivery machine appears to be in need of great attention and precision. It often appears to be delicate like a Swiss watch! However, it’s way more complex than something mechanical like a watch! If we are to draw an analogy, only something as complicated as the human body or the earth’s environmental ecosystem seems fitting. Only the right analogy will get you in the right mindset. Instead of a delivery machine, we need to think about our delivery ecosystem.

The BURDEN of a software development team

Teams have ‘attracted’ dozens of additional responsibilities. Think about recent trends like:

Cloud adoption to extend our scaling capabilities.
Event-driven architecture to facilitate this increased scale.
The emergence of full-stack job profiles so single individuals can deliver functionally.
The rapid change in technology stacks, ranging from programming languages to database technologies.
Serverless or X-as-a-service emergence of highly specialized 3rd party offerings.
Attention to — highly specialized — security measures.
The complexity of distributed systems architectures.

These are only some of the trends that modern teams have to deal with. It's not surprising that people started to complain about the impossibility of everybody hiring these rockstar-unicorn developers.

To cope with this added technical complexity we have created new processes and organizational structures to help them to cope with this.

Some of these are:

Adoption of a short cyclic way of working with agile processes.
Team independence thanks to DevOps processes.
Increased attention to team flow and support using Team Topologies.
Increase in software product strategic thinking.
Improve organizational alignment by restructuring using Domain Driven Design (DDD) and Conway’s law.

The bottom line in all these socio-technical trends is to unburden the cognitive load on a team and to maximize the time available to work on their bottom line: their feature stream (aka their backlog).

Holistic decision-making for thriving modern software teams

Let’s consider what steps we can take to thrive in the ecosystem of cloud-native. Again I want to stress that the first step is acknowledging that modern software teams operate in an increasingly complex environment.

Consider rebalancing the burden on any new decisions

For either technical or socio-technical improvements on your wishlist, gather a holistic understanding of what dimensions (technology, process, skills) in the organization or stack need to be mended to make it work. And now the most important part. Consider how new decisions might put stress on teams and what you can do to alleviate the stress as well. Think about it as a balanced scale. If you want to put something in, you need to take something out. Just like we have a boyscout rule when we touch a part of the codebase. We should also boyscout yourselves away from the debt of a burden that kills our productivity.

Built a toolkit for social-technical improvement patterns

Built up a toolkit of socio-technical improvement patterns and align them with the technological enablers. It will require experience, books, conferences, blogs, and collecting war stories from peers. An example could be Microservice adoption. This is a technical architecture decision. In order to make it a success it requires a socio-technical improvement aimed at your context. An example could be the adoption of a DevOps way of working to give the necessary autonomy to teams. Or it might require improved service boundaries thanks to DDD-enabled design.

Built up a council

Built up a council to strengthen your decision-making process. Add enough diversity to it. In high-tech organizations, it is a trap to converge to rather homogeneous groups. Decision-making teams like guilds, chapters, and special interest groups tend to consist of rather like-minded individuals. While participating in such a meeting, it might have felt that every individual was a uniquely stubborn individual, but in reality, you might all be in too deep. Partnerships with outside counsel can help to get the needed diversity into your organization. Including some cross-disciplinary counsel can spark new discussions.

Consider architectural decision records

Retrospect on past decisions and catalog what you have done to make them successful. Some organizations maintain architectural decision records (ADR). It's a great source of change logs and interventions to evaluate from a more holistic perspective.

A path to holistic thinking on our software ecosystem

Thanks for reading. You really made my day if I was able to expand your thoughts a bit toward holistic reasoning on our software ecosystem. It can be daunting to look outside of the boundaries of your role, and change might seem to be outside of your circle of influence. However, the biggest change you can make today is to involve: more people, more perspective, and more dimensions in your decision-making!