TeamTopologies
martinfowler.com
martinfowler.com
Almost everything he hawks causes misery for software developers, like his whole multi-year spin for Microservices, he's turned refactoring into a fetish (honestly there are people at my dayjob who have been "refactoring" the entire 3 years i've been here) and now hes blogged multiple times about platform teams - which - having been on one - don't work. I see him as a very damaging character.
Well intentioned, i'm sure, but I don't think he has good ideas.
That's kinda dumb, but the book is super good, I learned a whole lot from it, and apply the principles basically all the time.
He's been banging the drum on testing for longer, and that makes up for a lot of craziness (I'm with you on microservcies, except where you have 1k+ developers where they might make sense).
But its a bit like a health influencer telling people to stay hydrated and blame him for his fans damaging themselves by trying to drink 10 liters a day.
On the other hand I don't know that having people dedicated to refactoring is necessarily ridiculous. At least "in theory, given unlimited resources".
Have any openings?
Most of my nightmares with microservices comes from where there has been > 1 per team. That came from people who read his "microservices are great!" blog post and just thought that they should build as many as possible. I used to hate him because of that - because it was a logical response to his blog post and people would use it to justify their technical decisions - with argument-from-authority.
In another company I worked at each team maintained ONE microservice and it worked really well.
Because it was a corporate environment with all the usual power politics, control freakery and lack of effective inter-team communication, even though it was more work overall and definitely a technically inferior solution, it did a neat end run around those systemic corporate issues by giving teams relative freedom of development, freedom of deployment and a deliberately simple, loosely coupled, standardized JSON interface to microservices run by other teams whom they didn't talk to much.
So, I get it, but I lost a lot of respect for him over his inability to parameterize his suggestions and the fact that he didn't seem to initially really understand why microservices worked so well for him.
Micro services are an attempted solution for having highly bespoke infrastructure that required difficult, long, manual, fragile deployments that were high risk, and thus didn’t happen often and delayed business value. The problem was that they saw that issue and thought it was monolithic applications, not just having bad infrastructure. 99% of the benefits of devops with almost none of the drawbacks are done by having all of the standard dev ops stuff like Cicd, containers, software defined infra, etc and just doing it on the normal monolith.
Eventually you do need to break things up, but the micro services single functionality, single team per service type of micro services goes way to far and harms more than it helps.
To me, it's the Clean Code of web services.
There in lies the rub, the majority of engineers don't work at companies that need the kind of scale that Facebook has.
The majority of us work at smaller shops that can get by fine without all the overhead that microservices introduce. The problem that I see is that there are to many folks not weighing the pros and cons of the architectural decisions they are making, and are just joining the cargo cult.
The same people are now saying creating microservices is a sign of incompetence and the smart thing to do is create monoliths.
But not to sound ridiculous, they bring a spin to it: they now say they create modules within the monolith.
Software engineering is like fashion. It goes full circle every X years.
EDIT: I suck at writing coherent messages on my phone.
If that were true, then moving to a microservice architecture they'd need 5 million instances of the microservice that replaces the part of the monolith that required 5 million instances in the first place, plus a couple of millies for all the other services.
On a small-medium vertical team at a large company? Probably-maybe not.
Many, many engineers (and managers maybe even more so) immediately jump to micro-services (often resume-driven development) where most companies have poor tooling and poor security knowledge that turn them into a living productivity-crippling nightmare to work with.
a lot of people are giving Martin flack that the idea sucks when the reality is they're implementing it poorly or inappropriately.
I generally hate the term “micro services”. They are just “services” and nothing new.
I’d love to hear more about your experience with a platform team and why you say they don’t work.
Yes it creates friction and reduces velocity at ticket level but it prevents misalignment errors in UAT and production. This can be solved somewhat by having dedicated product owners in each module but it's often not feasible for smaller companies and brings in too much non-technical chatter.
For example, if your product acts as a metadata repository as well as a task execution engine it is important that the execution engine modules access the metadata only using streamlined (and maintained) internal APIs and not hit the database or maintain duplicate metadata for different engines. This way you actually improve velocity at milestone/release level because you're free to make changes to the metadata codebase without breaking features in various downstream execution engines.
In my experience, with a well-scoped platform team, the integration phase of a release gets significantly smoother with fewer defects. YMMV based on product type and company size.
- Business hates and underfunds these teams because they are often blamed as being a blocker because of the previous statement. They are a pure cost center too. Career suicide joining them.
- Unless you have a very motivated team lead you will end up doing the work of the most aggressive and loud team leads from other teams. Anyone good at playing politics will dictate your roadmap.
- Given the first statement, how do you hire someone for these teams? If they are responsible for platform evolution, upgrades, CI + CD, making frameworks, writing scripts, improving developer experience PLUS you are the backstop for the full backlog of every other team so need a lot of domain expertise. You would need to pay someone a lot to do this right? Well no - because of point 2.
The idea of a platform team is one of those weird things that sounds obvious and clearly needed - until you marry the idea to that of any org that has layers of management + politics and a misunderstanding of the long tail effects of platform work.
An interesting thing that happened at our company when we ended up having a platform team was that the "Can do" attitude of our previously homogenous group of mobile devs stopped over night - "That's a platform role" became a common refrain.
Only small companies can silo everything into verticals.
The platform teams I've seen at scale are more focused on providing APIs and services for a business domain. Such as, you can have a platform team for KYC/KYB that develops integrations to document verification providers, and then have stream aligned teams that sit on top of that platform and use it in a product to onboard users. Or in payments, a platform team can manage all of the underlying banking integrations, and then a product team can use these APIs to develop a product that lets users pay for things online. I once managed a platform team that managed the internal ledger for a virtual wallet/venmo type company. There weren't many product features there, but they had to deal with scaling our transaction processing capacity, ensuring idempotency of money transfers, and providing an easy to use API for product teams to integrate with. For more academic/research minded software engineers, it's an awesome team to be on.
> making frameworks, writing scripts, improving developer experience PLUS you are the backstop for the full backlog of every other team so need a lot of domain expertise
This has more or less been the case for my entire tenure at my current company. Sure, I want to do X, but we're crunched for time almost always. And there's another team that probably handles X. So it would be irresponsible/wrong of me to work on X when someone else can handle it faster and "owns" it. Except, who owns it? Whose team do I contact? That, I never know. It's a shifting, amorphous creature that lives around the app development team; I am required to communicate with it but I don't know how. Ultimately I end up with many micro-blockers where I don't know if a given task is something I should be learning myself or passing off to someone else.
See Project Managers becoming 'scrum masters' rather than neatly disappearing.
Platform teams are similar, they sound plausible, but as you say the reality is pretty miserable. 'Enabling' others to do work eventually looks a lot like doing the work.
What I've seen is platform being the "elite" place to work, or at least the one where you can do cool things. Otherwise you're working with "cookie cutters". Most specific content, in our case written for individual customers was not as important! There are many customers and projects, but theoretically only one platform. Projects come and go. However, platform being responsible for most of the code that determines basic functions, puts you at their mercy.
The infrastructure and base code was a huge deal. The other teams were fat... it does cut either way though.
I think the issue is a lot of people read his stuff and then blindly think it all applies to them and microservice themselves into a corner without actually thinking through if it actually applies to their situation. Same goes for various blogs from FAANG companies about scaling. Hardly anyone has scaling issues that they have, yet technologists like the bright and shiny new thing so they end up adopting over complicated solutions to their simple problems.
The team types he talks about in this post I see working well in some companies and situations but he's not saying "thou shall have a platform team and it solves all your woes". The first paragraph states the primary team is a "stream aligned team" which I take to mean a product team that is responsible for app(s) from top to bottom - UX, UI, backend, scaling, support, etc.
What your employees and customers observe and perceive is the reality, not what Google, Martin Fowler or Bill Gates prescribe.
Classic "my experience trumps yours".
Be careful around software evangelists
I'd would not call it "virtuous cycle" more of vicious cycle.
Well intentioned I doubt. Unless it means McKinsey style well intentioned: hammering about re-orgs and reforms while generating ton of consulting revenue with it.
Side point here…
I absolutely love refactoring sometimes. Like taking a messy chunk of code with deeply nested conditionals a d simplifying it, which makes it more readable and extendable. You also have very clear requirements as well (whatever the original code did). There are few things in software development that bring me more joy than that.
But its often not necessary. And furthermore, refactoring is often not of that type. Sometimes people rewrite things because they don’t understand how they work (and writing is easier than reading). Or because they completely misjudge the value of the refactor.
In my experience, it's worked out terribly when a company treats a platform team as a catch-all for any back-end service regardless the business domain. On the other hand, it's seemed to work reasonably well when the team has a narrow (and very clear definition) of which services they own and why.
That said, I've never worked directly within a platform team as an engineer, so maybe it just appears that way as an outsider.
I'm not sure I completely understand "platform" in this context. I've worked on teams that tried to write a common platform, then delegate to more specialized teams for specific implementations.
I have often hated working under these conditions. These problems are often true for software suppliers whether internal and external. There is a disconnect, and weirdly platform is not motivated to provide good quality code with whatever analysis / testing is needed. It can be even worse if the supplier is internal, and it's known that the company doesn't want to use someone external (where's your leverage!)... good chance platform has more political pull than you, too!
Often times they just ship it and say "your problem". Meanwhile, they also insist that we do not modify their code, or else take full responsibility. There's more motivation to finger point, or push responsibility on to your customer (including other internal teams).
Mind you that in my industry this all pushes the limits of ethics, and maybe our obligations dictated by regulations. Of course, we do everything we can to meet our obligations and do the right thing. However, you're left with the decision to leave in poor quality code (or missing work products), or modify / test code you probably will struggle to understand. It will also be difficult to understand the implications, eg. for other modules.
It's a very awkward situation.
What we have found is that platform teams are a huge point of frustration for product teams, since they cause unnecessary and unmanageable coupling between different business divisions, leading to impossible to balance priorities. What we've seen happen over and over is that product A needs Feature A, and product B needs Feature B, and they both need it tomorrow, and the platform team only has resources for one. And since Product A and Product B are in different business divisions, you end up needing to involve a senior VP or even an officer to make a prioritization decision for a simple software feature, and everyone gets frustrated by the process.
What we're striving towards instead is an "inner source" model, where a platform is collaboratively developped and maintained by multiple product teams. Each product team is then empowered to build new features as needed into the platform, and others can reuse them.
Of course, the platform needs some architects and overall review, and all teams will not equally participate. But the key point is to encourage this collaboration mode, where no one team is a bottleneck for multiple products.
The inspiration for this structure is obviously the open-source world, where multiple corporations and foundations collaborate on a single code base without needing to rely on a single platform vendor to provide features for them.
Based on my experiences, the idea that a genuine bottleneck in tech is being made visible to customer division management and senior management, is generally an authentic way to ensure realism creeps back into the prioritisation and funding processes.
Either you put too many in there, and they are basically idle the time in between. Or you put a limited team, and once even a single team requests something they will have to wait for the developments, let alone 2 requests at the same time.
The OP describes an excellent solution: the team that needs the feature, pays for it in man-hours. In fact, those developers that need it, are pretty familiar with using it, so most of the time capable of doing some developments on it. They can also schedule in the work in their project. The teams that will need it afterwards will get it for free.
It's actually an excellent solution.
But When would this hypothetical occur? If the platform is new-ish, there’s always going to be more work to be done than there are people to do it so there’s no variation in workload - there’s just lots to be done.
When the platform is established and operating in self-service mode, so think Amazon S3, were in a mode where we’re really not expecting features to be added, more about bugfixes and operational capacity at that point.
>> the team that needs the feature, pays for it in man-hours
there’s no free lunch. These developers don’t really care about the platform, they have bigger fish to fry. You need to ensure that infra doesn’t become a tragedy of the commons.
This is such a situation, and it happens all the time in internal products.
Either you over invest, you under invest, or the solution proposed here: jit developments where you can allocate resources as you need them.
> These developers don’t really care about the platform
They care as much as it helps them. The overall vision is steered by the architect responible for that internal product/platform, as said by OP.
Again there’s just no free lunch here, you’ve got a generalist writing a specialist component.
In your example, how confident are you that the full stack product team developer is acutely aware of, i don’t know , let’s say accessibility practices or maybe performance tradeoffs for constructing this component?
The specialist in the platform team member knows this intimately, it’s their specialism.
But hey, if you want some experts to sit idle until some real work comes in, that's all fine by me.
Additionally, this overall means that no one can plan in advance any features that depend on the platform, since global business priorities are constantly shifting.
Not to mention the political angle, where more adept business leaders can always push through their pet platform features to the detriment of what are more obvious business goals. Or at least, it will always seem this way to teams whose requirements keep falling through the cracks.
You don’t NEED to do anything, it’s all choices.
If product A is my breadwinner, i might not even need product B to estimate workload impacts for their feature request because my business strategy might be such that i’ll be allocating the resources based on business priority of product A.
Trying to second guess this by making tech a black hole with no levers to pull by the business is fundamentally unsound.
>> where more adept business leaders can always push through their … Or at least, it will always seem this way
I mean i think you’re calling out the solution with the problem. Just strive to be a better operator, level up to their ability. Exceedingly hard to do but overall win for everyone.
And of course the choice is sometimes simple, but it's often not. It's often the case that both Product A and Product B are breadwinners. One might need a feature that can bring $1M in revenue, and take between 3-4 months, and another might have a feature that should bring in $200k in revenue, but take 0.5-1 month. Which do you prioritize? What if both must be done by some date, but for one there is a chance to push a customer to accept a later date, but it's not sure yet? What happens when it later turns out that the estimation was overly optimistic and it will take twice as long?
> Just strive to be a better operator, level up to their ability. Exceedingly hard to do but overall win for everyone.
Politics in an org is a 0-sum game. If I win, someone else loses, and then their team is going to be the one that feels frustrated, and we're back to square one.
I have seen this fail (once myself and once through coworker experiences) as well, IMO the best approach is to have as little shared infrastructure between teams as possible even if it means more work in the end
That's the route to shipping features faster for sure, but it costs more, requires duplication of effort, and is really painful when you discover two teams built the same thing and you want to unify on one version rather than paying to run and maintain both. Plus, when the cost cutting comes in the bad times, you find whole teams are axed because you don't need two sets of people doing the same job. The remaining engineers then have to unify the features but without the resources to get the work done and without access to the institutional knowledge required to understand the version they didn't build themselves.
If you're an engineer in a FAANG it's not a bad solution to the shipping issue. If you're anywhere else it's a road to absolute chaos.
In my experience shared infrastructure is less prone to breakage on reorgs because "platform" teams usually get the axe first as they are not directly delivering value (from upper management perspective at least)
IMO each team should maintain their own infra and tools and be free to choose what works best for them within reason, a few exceptions need to be made of course like having unified authorization and the like, infosec is usually better to be a separate team consulting to individual product teams, etc
Is this any different from a product team where there's competing demands between Customer A and Customer B?
Not sure I'd like to use a platform with a code base that has the whole organisation contributing to it. Sounds like a design-by-committee dumpster fire. Teams need ownership of their product to perform effectively. You can claim that this is collective ownership of the platform, but in reality no one will feel any responsibility for the platform when things don't work or don't align entirely with the particular thing they are currently working on.
And have you ever looked at the source code for most open source software? It's an absolute mess that requires the collective effort of large numbers of people to keep it going. It works, but it's not exactly a good or effective model for internal software.
Related to collective dev/ownership, that is a risk, I absolutely agree. That is going to be the hardest part for sure, maintaining a uniform standard and a high bar for contributions to a common platform.
Finally, I believe the general opinion is that open-source software is higher quality and especially has higher code quality than internal company software. I can't say I studied any directly comparable open-source projects VS our internal tools, but code quality definitely varies significantly between our own internal projects, with some extremely clean and well written, while others are messes of hasty bug fixes and accumulated tech debt.
A platform team is there to consolidate tooling and provide services that enable product teams to move faster.
Think of it as an internal AWS. In small companies AWS is the platform team. If you’re talking about an upstream service that your product team depends on, it’s just an internal product team that’s understaffed. Or poor organization if your product team’s domain has been split up into two teams arbitrarily based on e.g. managerial politics or front end/backend division.
The products using the shared frameworks had slightly different histories and were mostly addressed to different market segments with different conventions, but still neede plenty of common scaffolding that a platform provided. A common platform team seemed to be a natural fit, and to a great extent in worked, but the problems I was discussing earlier were also pretty constant throughout its lifetime.
TLDR; platform teams without product team's freedom to deviate (optionality) is corrupt and can destroy a large chunk of engineering velocity.
Sorry in advanced if I state this a little bluntly, but this rhetoric of teams going off and building the same tools all over the place is in my experience not a fault of any team, it's that of the context/organisation they operate in. Framing it as such is IMO destructive for company culture. As if product teams, left to their own, will just degrade into building sub-par platform-esk tools that ruin the org. I don't buy it. Trying to make one thing do two things (the single source of tech complexity) is a trap often catching platform engineers who try to tailor to an audience that is not unified in their needs, still platform teams are incentivised to create just that.
That seems like an unnecessary coupling between different products.
I understand this concept of a platform team mainly within one (larger) product. But maybe it's the same thing, just on a different scale.
> What we're striving towards instead is an "inner source" model, where a platform is collaboratively developped and maintained by multiple product teams. Each product team is then empowered to build new features as needed into the platform, and others can reuse them.
I think it breaks down at a certain point of complexity. The platform itself is complex enough that it's very difficult for product teams to understand it holistically. I've seen this multiple times when the product teams were still able to make the changes as needed, but over the long term this approach created a hot mess of platform features which didn't align to each other and no single person understood.
Sometimes the platform team is staffed by people that have been there forever, as a sort of semi-promotion. But when they know everything, it's easy to have little interest in the difficulties of learning internal concepts: After all, the learning has already been done. This makes the tools be technically capable, and intractable. Other times, the team is easy to get along with, but what they deliver isn't very good at all, and the lack of quality is papered with social skills.
You need people capable of understanding the problem other teams have, and their architectural constraints, and deliver something that will save them time, and they'll prefer to use over some open sourced hodgepodge. They need to think of upgrade paths, or live in a low-repo environment where the platform team can upgrade things for everyone. The customer service attitude should be immaculate, as to make people be happy to ask for help, yet be so good at documentation, or at simple enough architecture, as to make that customer service load be light. Many places can't hire people that meet those kinds of profiles at all, as someone like that will basically excel in most roles in most companies. So yes, you end up with the technically capable, yet gruff guys that nobody wants to talk to: The equivalent of Seinfeld's Soup Nazi... and that's if at least they are very good.
Most team topologies will work if your company is full of empathetic heroes though, so platform teams might not even be needed if you really are that good at hiring.
> Platform teams, however, need to build their services as products themselves, with a deep understanding of their customer's needs.
If there is no malfunction like a monopoly or a scam, as a customer I just choose a different product if one is not meeting my needs. The same must be true of a platform, and if it happens a lot that its customers are choosing something else then its time for some hard reflection. This is not just an ideal, but a hard requirement, and something that a lot of orgs just don't have.
So, what do I need as a developer? I can make excellent use of open source libraries within even a couple of minutes, but somehow for my enterprise platform I need to fire up a request and wait for weeks or months to even get to play with it. When I need a tiny little change I can't do anything myself, I need to request it and it is filed in the backlog. The same change, would I have composed it out of open source libraries or had cloud access myself, I could make in minutes. Now it takes days, weeks and I even experienced many months of waiting for a simple task I can do in 5 minutes. Thus, making use of the platform meant fighting for higher cloud privileges so we could do it ourselves and ship at least within a couple of month instead of a year, and dancing around bizarre compliance regulations, mostly in order to either evade or pleasing a chain of risk owners to satisfy audits required for certification. At some point we became almost incapable of shipping.
Not every platform team is as kafkaesque as this though, and it doesn't need to be.
We tried inner sourcing as well and it was quite hard honestly, because each team was just focused on their own goals and contributing to the shared platform or libraries was often an extra investment that defacto penalized their achievements - which _did_ have repercussions on their individual performance reviews. Furthermore, it was done in such an ad-hoc way that it was quite hard to get something sane off the ground. I think you do need a kind of dedicated ownership.
Best experience was in a team where we did everything ourselves and had the required expertise. Second-best was in really close collaboration with a platform team where we also had members going from one team to the other. But even that team failed to build the features we really needed as a product team.
Open source is a good model, and there is one essential thing that platform teams need to provide their users that open source has: autonomy. I have actually never seen this in a platform team in the org I am talking about.
I can use a library, drop it, change it or exchange it for another one. The same _must_ be possible with a platform. It needs to be something that helps its users, not limits them in any way, and it can't ever be rammed down their throats. If your platform doesn't work for me, I should have the autonomy to just use a third party to get the job done. If your magic abstraction over AWS doesn't work, give me an AWS account with admin access and I do it myself. Bonus points if its not an all-or-nothing and I can just use what works and build the rest myself.
If you don't have time to build feature B because feature A is more important, everything I need to build feature B myself should be readily available. For example, I must be able to just fork the platform, build feature B, and when done 'upstream' it to the platform again.
If a platform has shared ownership, then decisions will get implemented by cohorts only thinking for themselves and thus damaging the long-term roadmap. All systems, especially complex ones, need sole owners or they will devolve into what is essentially a pyramid of doom at the product level.
Good communication across teams and good design (i.e. flexible, maintainable, extensible) tends to alleviate the tunnel vision associated with each team building what works for them.
I've had to wait weeks for one-line changes because somebody else had to do them.
What I've seen is that platform teams work well in either small scale (because focus is clear to all) and large scale (because of this internal competitive dynamic) but are extremely hard to execute between the two.
But its understandable, cause that shit is hard, its political, and its difficult with the current feudal entities that companies are
But I've also seen this book promoted heavily within an org, and the one core strength kept feeling like a core weakness that mades me incredibly sad, about how isolated it made work.
It doesn't insist it has to be so, but the org I saw that was so excited for TEam Topologies loved how it continually stressed independence of teams. And as a direct result, I've seen cooperation, coordination, & cross-team planning plummet. In ways that keep having suboptimal plans get put into action with bad outcomes. Stream aligned teams would turn into complicated subsystem teams, after they created something complicated and gnarly while being stream/product aligned, and unchecked.
I think the topologies here are quite useful framings, and as Fowler says the idea of trying to reduce cognitive complexity is an interesting one we haven't heard well represented before. And is probably due given how impractical making each team truly full stack devops has become, as the CI/CD/observability stack complexity has expanded. But I caution so much against the messages this book gives management, which is that stream/product aligned teams just need to be racehorses with blinders on & interference is bad. The book glories the stream aligned team, the value creator, and makes everyone else auxiliary, which is sort of true & great. But the book's glorification of execution speed doesn't leave much space for how and where cross-team wisdom happens, what kind of processes you have there. Broader cross-team architecture reviews, brainstorming, systems planning, systems coordination aren't well captured here: most teams need a strong collaboration mode to build good software that fits the architecture well. But the book only really regards a single collaboration need: those of platform teams to get feedback to ease their Developer's Experience.
The missing element was ubuntu. If you want to go fast, go alone. If you want to go far, go together. - African Proverb
I agree that teams must collaborate to go farther. One team can only do so much. Management should make sure all the teams stay aligned and hold them all accountable, but the teams themselves should still strive to be independent.
It sounds like what your organization needed was a project manager to co-ordinate or a forum for the teams to share information.
I think what made it kinda work is when they introduced “infra” dev teams that tried to see what the global problems were and solve them on a library/infra level.
Networking was one terraform module away, kafka integration was solved with in house abstractions, design systems, knowledge bases, etc. While not perfect there was a sense that “if its too gnarly a solution, ask around, somebody probably already solved it more elegantly”.
They would talk to all the teams and if someone developed an elegant package/lib/idea they would promote it to other teams.
Key was to have people working explicitly on tech sharing and global problem solving. Ended up quite a nice team environment by the time I was leaving the company, though it took years to get to that point.
Plus Manuel, one of the authors is a really friendly guy that pushed the Lisbon tech meetup scene forward around 10 years ago when nobody was having any regular local meetups and he was traveling between Spain and Portugal on the regular to make them happen (or so I remember). I presented my first proper talk in one of his meetups and I remember that going well and giving me a lot of confidence for other things later on. Definitely read it if you need to think about groups of teams!
When much of the industry adopts these ideas, and the resulting inefficiencies become the baseline, it is virtually impossible for anyone to effectively detect those inefficiencies. It becomes a "is everyone crazy, or am I crazy?" situation, until some sort of disruption (e.g. widespread project/startup failures) forces the industry to paradigm shift back to sanity.
The book describes 3 types of problems/areas: simple, complicated, and complex. The definitions of simple/complicated/complex has shifted for me a bit since I read it, but this is how I currently describe it:
Simple - the solution is clear and is fairly low risk
Complicated - the problem is well framed, but the solution isn't clear
Complex - the problem itself isn't really clear
This 3 tiered framing lends itself to so many useful structures and interactions. Junior/Senior/Staff scope of responsibility fits remarkably well. Sprint planning / Quarterly planning / Executive planning fits.
The biggest thing it has helped with is recognizing that a team needs space to explore complex problems. Those teams need to operate very differently from a standard product stream team and recognizing that need is such an important thing.
It feels like he's only catching up with what many have been doing for decades building high performance teams.
George Box neatly quipped: "all models are wrong, some are useful". Thus Team Topologies is wrong: complex organizations cannot be simply broken down into just four kinds of teams and three kinds of interactions. But constraints like this are what makes a model useful. Team Topologies is a tool that impels people to evolve their organization into a more effective way of operating, one that allows stream-aligned teams to maximize their flow by lightening their cognitive load.
On the other side: You can be perfectly right ;)
It is never clear what exactly is meant by a topology, whether the description is covering all important aspects and, importantly, how we could recognize and have some assurance about the "optimality" of a pattern and why there isn't a better one just nearby.
More formal descriptions are not necessarily the solution. They would need to be both concise and faithful to the system being modelled.
Topology has a definition. It doesn’t mean anything different in this context. https://en.m.wikipedia.org/wiki/Topology
It seems like you’re just not willing to put in the effort of understanding the basics. Which would be fine if you didn’t plan on giving a review of the complexities.
The comment was based on reading the review. I assume the review covers all essential contributions of the book and it is not merely a promotion piece.
I would be more inclined to take your "advice" if you had made any effort to address my concerns / observations. I suspect you simply can't.
> Topology has a definition. It doesn’t mean anything different in this context.
Thanks for the gratuitous and patronizing arrogance. It further reinforces my sense that these pompous sounding vacuities are a marketing tool and have no intrinsic applicability.
Or does it just mean 'some structure over a set'? That could really cover anything ...
While it is certainly useful to consider how you structure your teams, using the term 'topology' seems like marketing gloss. Also alliteration, of course.
When dozens of teams need a shared capability (e.g. for ad serving across many verticals at a FAANG), then you absolutely need one or more.
One team for a shared platform where it makes sense, sure, but everywhere, like it's some factory chain is the biggest waste of productivity.
I would also add that his suggestions around micro services did us absolutely no favors.
The one takeaway that I stick with from the stream-aligned teams is that we need teams that can build a capability from front to back independently. I think the industry has taken a step backward with huge single page web applications that end up with microservice teams building back end services, but then a monolith on the front end that isn't as modular as a web app where you can simply link to another application. I don't know if microfrontends is the right answer, but a collection of mini-monoliths with shared data services seems to work well enough.