Meet the complicated subsystem team (4/4)
When one developer's sick leave can halt production for a week, you might need a complicated subsystem team. Here’s how it can prevent delivery delays.
This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
A complicated subsystem team owns the most fragile parts of a platform or system,
Its members must have deep domain knowledge and technical expertise,
Payment systems, authorization modules, API integrations, or any other can’t-fail components should be handled by that team,
One of our teams of this type eliminated coordination chaos across 20+ services by centralizing shared components
Contents
What defines a complicated subsystem team
Recognize when you need this team
Platform team vs complicated subsystem team
Use cases
Who belongs on this team
Measuring success
Hey there,
Andrzej here again 👋
Let me tell you about the most expensive mistake I've witnessed.
A client had ONE developer who understood their iOS payment integration.
The entire payment system was written in Objective-C.
In 2025, only a bunch of folks know it anymore.
That developer had a sudden accident and landed in the hospital.
IT couldn't push anything to production in that time and was left paralyzed.
Their CTO, a sharp man, was the second Objective-C expert on the inside.
And he totally missed this dependency.
If your product has a value flow that requires a niche skillset, you have a strong case for forming a complicated subsystem team to own it.
Let’s break this down.
What defines a complicated subsystem team
They own the critical or complex parts of a system that other teams depend on.
Imagine the people in the complicated subsystem team as surgeons.
They focus on cases where:
every mistake has serious consequences for multiple teams
deep domain knowledge and technical expertise must work together
the solution is too complex for feature teams to build and maintain themselves.
The team must be able to create complete, production-ready solutions.
If they’re asked for an authorization module, they’ll return with something that can be installed immediately.
In our projects, the complicated subsystem team owned components related to:
regulatory compliance,
performance optimization,
security updates,
edge cases that would slow down any feature team.
So, how would your IT benefit from their grind?
Ideally, deep architecture work wouldn’t block all the feature teams.
In turn, delivery time should stabilize or improve.
Recognize when you need this team
I’ve been involved in dozens of projects where multiple feature teams had to do the same darn implementation separately.
An example?
Having 3 pet marketplaces in 3 countries serviced by 1 business unit.
Your organization might not be on that level.
But you might recognize these telltale signs that a complicated subsystem team should enter the field.
Your release roadmap keeps slipping
When people in the stream-aligned team get stuck on the same technical component, you have a systemic problem.
You could invest in upskilling…
But should your developers understand data parsing and processing, or is this an edge case that a support team could own?
We had 7 commercial projects in which we used 1 authorization solution.
In 5 of these projects, our teams kept having issues with it.
We formed a complicated subsystem team inside TSH to centralize and standardize the authorization process.
That eliminated the delays in our client work.
The "bus factor" is 1
You’ve heard the phrase, right?
One person gets hit by a bus, and the work halts.
You could tell the complicated subsystem team to own integrations, document them, and ensure they never depend on a single person again.
A simple code change requires massive coordination
I feel dizzy just remembering that one example I’ve witnessed.
A corporate client needed to swap the logo in the footer of 20-something websites they owned.
So, 20+ feature teams needed to be called in!
The same thing happened with phone numbers or menu updates.
Nobody centralized such shared components for years until we did.
Similar bug reports keep reappearing
An IT manager could see that bugs around areas like data processing or integrations keep reappearing for one or many teams.
Don’t let people solve the same problem independently.
It’s a clear case for a complicated subsystem team.
Platform team vs complicated subsystem team
These two team types often get mixed up.
Let's get this cleared out.
What platform teams do
They focus on technology R&D and building generic, standardized solutions everyone can use.
Examples
A command-line tool for setting up new services,
A platform for automating testing and QA,
Modular templates for deploying server or cloud applications,
Automated testing and QA platforms.
Have you seen our explanation of platform teams?
What complicated subsystem teams do
They build complete business solutions requiring industry-specific expertise that’s hard to get.
Examples
Order processing and tracking subsystem,
Customer account management and authentication,
Infrastructure automation pipeline for multi-cloud deployments,
Auto-scalable media streaming subsystem.
One of our seniors acted as a one-person complicated subsystem team.
A client had a shift scheduling system used by dozens of hospitals.
It was something like Excel in a browser.
Since hundreds of employees used it, the app lagged hard.
Our developer worked several sprints optimizing it.
He made the performance so reliable that all the feature teams didn’t have to worry about it.
Use cases
1. E-commerce payment systems
When multiple stream-aligned teams implement different payment functionalities in different places.
Some teams might use “pay now”, payment card processing, and a separate cart payment function at once.
In that case, one subsystem team can own all payment-related functionalities.
Payment issues would get centralized, saving everyone time on debugging and maintenance.
2. Banking system integrations
Imagine 3 teams building their own SEPA integrations, each debugging the same issues independently.
The complicated subsystem team could build microservices to handle external communications.
Then, feature teams would just send and receive data through APIs.
You’d also limit the scope of training on banking protocols.
3. Portals with shared components
Think of Adobe for a moment.
20 websites for 20 products, but each one is packed with text, media, and functions.
That’s a perfect case for having a team responsible for shared UI elements and business modules.
I can’t think of any other efficient way to cut an ecosystem update from days to hours.
One government subsidiary had 20+ portals with different Vue.js versions.
Suddenly, the end-of-life announcement dropped.
Think of the potential loss of vendors or compliance violations.
We formed an emergency complicated subsystem team.
They built shared components for all services in React that included:
component libraries,
project starters,
table components with smart filters.
After the change, a new service with proper architecture could be created with 1 click.
Developers were also happy they didn’t have to wrestle with integrations anymore.
Who belongs on this team
You need your “jokers”.
The developers who are willing to master 2-3 new technologies yearly just for fun.
We often mix senior architects who decode system-wide impacts with domain experts who know the business inside out.
Building a banking system?
Well, your joker-engineer better be able to “breathe” banking.
Add performance specialists to the team when speed matters.
You’ll also need UX designers if they’re shared frontend components to build.
Also, I’ve seen managers try to form this team with juniors.
That’s a no-go, of course.
It’s for veterans only.
Measuring success
How do you know if your subsystem team is working?
Cycle time should improve as teams stop getting blocked,
There should be fewer bugs reported for shared modules when one team owns them,
Roadmap delays should decrease when technical blockers are centralized,
The manager should stop hearing about the same development issues repeatedly
Not seeing these improvements?
Your subsystem team might be solving the wrong problems.
Next time
We've covered all four team types from Team Topologies!
But it’s not vacation time yet.
You’ll need to figure out how all these team types can interact.
And there are 4 interaction modes designed in Team Topologies.
You’ll discover them in the next issue.
Thanks for reading! ✌️
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|