Four Team Types
itrevolution.com
itrevolution.com
Humans are more important than hardware
Quality is better than quantity
Special Operations Forces cannot be mass produced
Competent Special Operations Forces cannot be created after emergencies occur
Most special operations require non-SOF support
I was a part of an organization that implemented this book's recommendations, and it did not go well.
We had high performing teams that worked well together and all shared roughly equal responsibility for tech, features, oncall, and tech debt. The organization wasn't perfect -- we had scaled down the org for covid, only to be surprisingly successful (a great problem to have) which was brutal on us engineers and we incurred a ton of tech debt. And we had the standard issues with some collaboration and some politics.
Then someone was brought in who applied the concepts in this book, and it went very poorly. Suddenly we were shuffled into teams that weren't much larger but had huge areas of responsibility. In addition to the tech debt we already had, the breadth of our responsibility was expanded drastically. For example, instead of having one team responsible for kakfa, now 3 teams all owned slices of it, but in a way that we each had to become experts in order to satisfy our oncall obligations (I'm oversimplifying, but hopefully you get the point). Multiply that by 3-5 serious backend systems for each team, and you can hopefully appreciate the high cognitive load we were under.
To make matters worse, most of the teams doing the heavy lifting were now "product teams" which had UI ("fullstack") people thrown onto them, but those teams now owned 92% distributed backend tech, and 8% user interface. Almost all of the fullstack people had a great attitude about it and learned as fast as they could but it did not go well. I was effectively oncall 24/7 from that point.
Also the oncall burden and areas of responsibility were unbalanced between teams. Two teams bascially ended up with the most fragile, unstable systems with the highest oncall burden while others had almost exclusively brand new things that did not yet have serious flaws.
And then, to twist the knife, while we are drowning in our own tech debt and heterogenous team structure, there began a pattern of reducing our autonomy. Important decisions, or strategies, like how we test our software, or how we deploy, we suddenly being dictated by other teams full of recently hired junior engineers who knew less about these things than the staff engineers did, especially since they lacked the tribal knowledge we had built up (and still had not managed to offload onto our own teams!).
I gave some careful feedback about the most obvious problems to the director who seemed responsible for implementing all this, and she brushed off my concerns. That was weird, but made sense when I later learned she was implementing the concepts in Team Topologies. The teams had ridiculously large areas of responsibility because we were the feature teams ("stream-aligned" in Team Topologies b.s.) and we were supposed to crank out features without talking to other teams. That is also why some teams had practically no on call burden and others' on call rotations were full of sev 1s: when your ownership is based on features, some teams will own the one of the newer features that doesn't have tech debt, race conditions, or scaling issues yet, and other teams will end up with the older features, which we could barely keep online.
And the teams full of idiots bossing us around? Well those were the "enabling teams." This was especially bad on the infrastructure side, because these engineers would only talk about the way a perfect system should work, and refused to acknowledge any reality of the existing system. For example, we had a rather homegrown EC2-based autoscaling infrastructure with what I would call a "bespoke" service discovery implementation. The k8s-enabler assigned to one project insisted that k8s+consul was the answer, and the only answer. When I asked how that would work with the existing system in prod, he explained why k8s is better than EC2 and I'd better get with the program. When I brought up the source code of what we had deployed in prod and pointed at the exact line I expected to fail, he insisted it was working. He lied. We lost three weeks.
When I eventually heard about the book and read it, it make me angry to see what people in management (or that style of management) actually thought about us (there's some stuff about using teams as units to make us all fungible cogs but I'll skip that because this comment is already very long). Especially because most of the companies cited in the book were awful, boring places to work at. I sorry I can't remember any examples (other than maybe an online casino); all I remember is the case studies were all done for companies that I would never want to work at, and most of them were outside the tech sector entirely.
Another thing they did was disband the regular meetings of all of the senior engineers, and even told us to stop collaborating with each other a few times. I'm not 100% sure I can pin this one on Team Topologies, although it the book does promote the idea of trying to control communication between teams.
I watched the org decline for about 1.75 years before I left. That stupid ass book was not the only problem we had, and not even the biggest. But it certainly made things chaotic and unpleasant for a while.
I realize that there is an obvious counter point to everything I've written -- maybe my org was just "doing it wrong." Maybe this post will get a bunch of replies saying a long the lines of "well actually, chapter X doesn't say you supposed to do Y". And I would just like to point out that if it is so easy to misinterpret this book, if our Director and VP's best efforts simply fell short of understanding the text, and the claimed success is only possible with your enlightened interpretation, well that's a problem too.
If you are a staff engineer, I actually recommend reading it (hopefully in some manner that does not involve a purchase, like borrowing from someone). It can give you a useful perspective and insight into what some managers are thinking.
If you are some kind of manager or director or VP, I don't know what to tell you. Managing an org is hard. I certainly don't know how to do it. But if you are learning how to do it from this book, I hope I never have to work for you.
Someone at your company got a mandate to change the culture, and with such a mandate power gets shuffled around. The power was taken away from engineering teams that needed it.
I wouldn't say they were doing it wrong, just two things were happening simultaneously and the politics of power weren't paid attention to.
I read team topologies and found it to lack any novel insight but given its popularity I just took it as a presentation of the current jargon. It presents a sort of model for thinking about the organizational structures that you may already see popping up. Depending on your organization, you may end up with a unit of DBAs, the original enabling team. If they are doing their job well then they ignore the teams that have services with ordinary database usage and spend a lot of time helping teams with heavy db reliance optimize their usage. If they are pathological, they claim ownership of the entirety of database usage over an organization and everybody suffers. If a stream aligned team has to ask permission to do anything with a db, with a message broker, with a queue, with firewalls, with deployment, with testing, then congratulations, you built multiple walls of confusion. Enabling doesn't mean dictation. And as pointed out by others here, the lines between the enabling team, the complicated subsystem and the platform teams are not bright, they are blurry lines.
Team topologies are somewhat orthogonal to power topologies. Every organizational structure can be subverted to take power away from those that need it.
My experience of DBA teams (at a bank) was that they were desperately slow at approving anything (and all changes had to be approved by DBAs).
We had a DB query in the software for the Fraud Department that was very slow - it was taking several minutes to run, leading the fraud team to take frequent coffee breaks. I added an index to the schema, which led to a 1000x improvement in performance. It took 4 months for the DBAs to approve putting it into production.
Sure: adding an index could have hit performance in some other system; and the index was on the main Customer table. The change did need wider testing than I could do myself. But 4 months? That's not an "enabling" team, that's an "obstructing" team.
A DBA performing execution of an index migration is usually not a good use of their expertise.
But they were so SLOOW. My suspicion is that they didn't like it that someone who wasn't in the DBA club had found an improvement to their schema. They definitely had a walled and moated fortress.
This is a great summary.
Oh boy, this sounds all too familiar. And yet, from the OP:
> Enabling teams must avoid becoming an “ivory tower” of knowledge.
In my experience, these types of teams are sucked in to ivory tower thinking precisely because they are so far removed from the existing system. And yet, the article glances over this problem.
I definitely need to read this book
Anyone changing an org / team structure without doing an in-depth study consulting the teams involved is asking for trouble. The aim of the preliminary steps is to find the "no way will that work" opinions and take them seriously.
I am fed up of people getting paid to blindly apply these methodologies with next to no appreciation for the complexity, hidden or visible, that exists in most orgs.
Evolution is better than revolution for 99% of things in my experience. Add lightness is usually the way forward.
SCRUM, Agile (capital A), PRINCE2, TDD, BDD, [list any methodology at any slice of the org] all suffer from misapplication by hacks selling snake oil.
Sadly "it's complicated, there's no one-size fits all, and no easy answers" doesn't seem to sell books or get people hired; even when it is true.
I don't understand how you'd get this from Team Topologies, though. Not even slightly. I don't think this is an easy misinterpretation; there's literally a team type describing the way you used to do it.
Have not read the book, but the Four Teams list obviously describe real roles. But that doesn't mean organization must or should go out and immeiately partition their teams according this scheme. The value is to recognize that these roles exist and are probably performed somewhere by someone in some way or another in the organization. (But perhaps your org is too small to have much of Platform component, say, so it's just Alice who update CI every N week on as-needed basis.) And to use that knowledge to understand the overall process and where there may be problems or future problems.
This is different to platform teams which are meant to mostly build internal services which other teams use with self service, meaning they don't directly interact with members of the platform team (allowing both teams to operate independently). That said, platform teams may occasionally collaborate with steam aligned teams when building out new features or to better understand the problems the stream aligned teams are having.
The "platform" is there to allow teams to ship software. It is there to deliver value to other teams.
I think this second one is what is meant by "enabling" i.e. it's not "delivering value to the users", rather, enabling other teams to do better at that.
from the article: "A platform team enables a stream-aligned team to deliver work"
Complicated subsystem teams mostly work with value stream teams on a subset of a value "stream" that is complicated enough / specialised enough to need its own team of specialists, especially when it can be encapsulated in a library or service. e.g. owning an ML component within some software.
Platform Teams build an internal product and act like a value stream team where other internal teams are customers. Often useful for things that you wish you could buy off the shelf from a cloud vendor but can't. Building services and tooling that make the stream aligned and complicated subsystem teams more effective. Sometimes platform teams may need to act like enabling teams at times / with part of their effort to help other teams adopt their product.
Overall this post just seems like a great way to see who can win the "most pedantic" award in a management meeting.
That seems overly generic. There are clear, useful differences between teams that need to hit marketing goals or interview/support customers in production, than teams that run your internal GitLab instance.
Just look at my sibling responses.
A team of backend specialists will really struggle if they are suddenly given complex frontend work, and vice-versa. Plus, if you typically have teams of -4 engineers, that means that even one person being out can be catastrophic to your team’s balance. Or if you pick up a project that suddenly increases a specialist burden, you have to find the right enablement team or move people around the org. Expect that to happen often (perhaps even quarterly?) depending on your stream and product team.
You can also hire fullstack, but beware that they need to be truly fullstack in a way that is really rare. It will probably require a bigger salary commitment across your teams.
Edit: It's also a misquote from the article, they refer to it as an Enabling Team.
A person being both in a Stream-Aligned Team and an Enabling Team at once would kinda turn the latter into a ”guild” in the Spotify [1] lingo.
The premise is true, but the conclusion is a recipe for disaster.
As organizations grow, they tend to have more managers, teams, departments, and procedures. However, adding more layers to this complexity is not going to solve any issue. In fact, it will only make things mentioned above worse.
It's like adding fire to the fire to put it off.