How to scale your engineering team the modern agile way / Part 3
Insights from a servant leading VP of Engineering — a multi-part series
Welcome back, dear reader. In parts 1 and 2 we looked at how empowering your people and both providing but also encouraging leadership on all levels form a solid foundation for scaling your organization in a modern and sustainable way.
In this part we will begin to zoom out a bit by shedding light upon the topics of team independence and scalability, answering questions along the way like what we actually mean by that, how the two concepts line up with each other in the first place and what are ways to achieve bring them together to achieve our ultimate goals.
3. Independence and scalability
Often times when I (over)hear people talk about the need for independent teams in order to finally find that land of milk and honey, I’m noticing that this desired state or pious hope is basically lacking either or all of the following three qualities:
- a sound concept of reasonable and feasible levels of independence and its connection to scalability
- why we actually should go into that direction
- how this could and should look like in the everyday practice of an engineering team
And it just so happens that these qualities quite nicely line up with our questions from earlier, so let’s get to approximate them one by one.
What is team independence?
So first off it is important to dispel a myth which stems from a common misconception of the term independence itself when seen in the context of product development teams. Because, except for a few very isolated edge cases or when it comes to just straightforward start-up-like contexts, there cannot and should not be total independence between all teams. The reasons being manifold and will be detailed later on but in essence, since modern software products are internally built or structured as collections of distributed functionalities (such as services or micro-services for that matter), it is both reasonable and obvious to come up with collaborating teams which more or less follow similar structures when viewed from an organizational angle.
What we instead want to achieve is to reason about varying levels of mutually independent teams that make sense in the respective contexts at hand. Hence the basic insight albeit trivial in nature is that we deliberately enforce team independence only where reasonable and applicable. We acknowledge the fact that the more independently any given team is working within a still larger business context, the more communicative overhead both technically but moreover organizationally is needed.
Why do we want team independence in the first place and how does scalability come into play?
Our ultimate goal, our mission is to have engineering teams in place that are both sustainable and scalable in nature. But what does ‘scalability’ mean in this case?
Recap on scalability
When we think of this term in the broader context of IT and infrastructures/servers what comes to mind is of course vertical vs. horizontal scalability. The first, which is also known as scale up basically is to stay within your, often also physically, limited means and try to scale your existing system by adding more power, storage, memory inside of it. The latter, which also goes by a so-called scale out approach is to mainly take whatever is needed to be scaled, copy and paste it using the original entirety as a template and add it next to your existing system. Ideally what you want to achieve by that is that at least in theory you can replicate this process as many times as you like or can afford it. The classic trade-off is the aforementioned overhead with respect to communication and alignment.
So can we apply these concepts on scaling organizations? Yes indeed. And it should come to no real surprise that what we are aiming for obviously are team structures that scale nicely along horizontal efforts. What this effectively means is that we need to make sure we develop our teams into self-contained small powerhouses with as much capabilities and independence as possible. And not forgetting about that communicative overhead needed in order to keep all of our efforts aligned with our overall vision and strategy, the exercise is to understand healthy communication on all levels as an integral part of team independence. Ultimately this forms as a key success factor for scaling your organization in a healthy and modern agile way, which we will see in a moment.
Putting it all into practice
So far we have reasoned about what team independence and scalability are and how they are interconnected to one another. Now we will conclude this article by shedding some lights on actual approaches you can follow to set up and prepare your organization for scaling out.
But first things first — maybe you are asking yourself now: “That’s all good and well but how do I know when it’s the right time to start thinking about scaling out my teams?“, and rightfully so. Because finding the happy medium is key here. Don’t kick this off too late but not too early as well. It’s out of place to overcomplicate things right from the start, i.e. when you’re in a classic start-up-y context, think everything from 5–15 or so engineers usually is better off by applying just a good portion, over-the-desk communication and just good ol’ common sense.
By the time you’re slowly but gradually entering the realm of having more than two full-fledged cross-functional teams essentially working on one product or roughly off one code base, you should start doing some homework.
Spotify-model?
How to go about it? Well, what helped me greatly was getting in contact with a few tech leads who had done it already, basically had already progressed to the next stage and listen to their input and insights. “Back in the days” what had been the new black was trying and adopting the so-called Spotify-model. In fact I for one did an article on my experiences implementing it in our tech organization in a review fashion.
However, the original model, apart from never really having been intended for direct adaptation, is suffering from a number of flaws, so that Spotify itself essentially never fully applied the way it was brought to life. Still it stuck with many companies keeping us tech leads pondering about the simple fact that organizations are living, breathing organisms that need constant caring and attention in order to stay healthy and productive.
And it brought us to reason about sensible and sustainable growth by achieving levels of scalability that are actually applicable.
There might be a better way
So what came out of it and could easily be called the latest industry practice if not standard are Team Topologies. And as always it of course weren’t authors Matthew Skelton and Manuel Pais alone to invent the whole thing entirely on their own — but rather coming up with terminologies and methods, wrapped up nicely that it just makes sense and is a mere breeze to get people engaged in discussing and eventually applying it. They essentially extended their own pattern-based team assessment practice DevOps Topologies, which in turn was a concretization of Patrick Debois’ DevOps “movement”.
Going through all the details of the model is beyond the scope of this article and truth be told, the accompanying site, books and a zillion articles will do you great service when it comes to learning all about it.
In a nutshell, Team Topologies views teams as complex structures that are spatially collocated (hence the term topologies), highly dynamic and have varying levels of interconnection and collaboration depending on their mission, expertise and mutual needs. It takes widely accepted concepts such as services and platforms and applies them to literal teams. And it’s doing away with stereotypical cross-functional one-size-fits-all team-approaches that may read nicely on paper but are almost never really applicable in real life scenarios. Team Topologies on the other hand are merely a collection of just very common sense team patterns and ways of communication that are readily available for you to apply and adapt as you see fit in your organization.
In essence my key takeaways for you would be along these lines:
- Paying close attention to Conway’s law always has been, is and continues to be key
- Acknowledging and taking into account the fact that your people are as different and varied in their strengths and weaknesses will guide you on your way
- There is no such thing as all-purpose solutions to scaling your organization — they are complex and breathing organisms. You will always inspect and adapt, it’s at the core of truly being agile
This article is part 3 of a multi-part series. I will edit this article and include the according links to upcoming texts as they flow in.
Thanks for reading.
