Meet the enabling team (3/4)
Have you ever experienced an IT project delay because someone was on leave? The enabling team is designed to fight such dependencies.
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
Enabling teams teach self-sufficiency and shouldn’t take ownership of delivery,
Their work ends when the delivery team owns the capability,
They’re best for teaching DevOps, testing, AI, architecture, or cloud engineering,
Our first enabling team “vaccinate” 90% of technical employees with CI/CD skills
Contents
Hey there,
Adam here again.
Effective Delivery has 41 readers now, including those who misclicked.
I’d like to sincerely thank you for subscribing 🙏
I know your time is counted in dollars.
We’ll make it worth it as much as we can!
The enabling team.
You’ve at least heard of the concept.
It’s the A-team that comes in and teaches the use of something like test automation, containerization, or AI-assisted coding until another team can do it alone.
Here’s the catch.
People often forget about the 2 golden rules for the enabling team:
there always should be a start and end date to its work,
it shouldn’t ever develop for other teams but rather teach them to act solo.
When do you need an enabling team
I’ve preached before that a stream-aligned team should be like a grown adult.
Independent.
But the team members might not be aware of their skill gaps.
Here’s how you’ll learn an enabling team is needed:
Development halts because someone’s OOO
The DevOps leaves, and the team can’t deploy or fix a pipeline.
A serverless architect gets sick, and no one can debug lambda timeouts.
It’s the “waiting for” scenario often revealed at dailies.
A new, unexpected requirement comes in
Copilot use or vibe coding aren’t a brag.
Can your feature team build an AI chatbot that’s not stupid?
They probably could — just not under a hard deadline from the PO.
Your Team lead or Engineering Manager spots an expertise gap
We’ve introduced EMs for this specific reason.
Now, there’s 15 of them.
And they’re on the lookout for any upskilling opportunities.
Engineers are pretty open about what they need — if someone listens.
AI/ML, cloud and data engineering, DevOps, and cybersecurity skills might be missing inside your IT.
Funnily enough, not using the enabling team enables the situation 😀
The team’s lifecycle
When we taught our teams containerization, we paired our DevOps and docker expert with specific engineers.
The developer was asked by his lead to start building a Docker file,
Our DevOps was called for the review,
His only job was to advise what he’d change in the code and why,
The developer’s job was to code the solution himself.
DevOps stopped his consulting gig once the developer mastered the task.
This is your basic process for the enabling team.
Your developer rides the bicycle kept stable by someone holding the stick.
The enabler must let go off the stick eventually, even if it means seeing someone crash 😀
Teaching DDD or other principles influencing architecture adds a couple of steps.
But even if you start with group workshops or demos, 1:1 work is always necessary.
The being taught using microservices might be unable to read the code on the first try.
But with each explanation from the enabling team, they'll understand the consequences of the technical choices.
Some of the 1:1 teaching methods that we use include:
Mob programming
The entire team works on the same task together, with one person coding while others guide and review in real-time.
Pair programming
Two developers work at one workstation, with one writing code while the other reviews and provides immediate feedback.
Internal learning sessions
Dedicated team workshops where experts share knowledge through presentations, demos, or hands-on practice sessions.
The Software House was once hired just to demo micro-frontends.
Robert, our Senior Frontend, acted as a one-man enabler.
He built a dynamic form and explained the code to the client’s team.
We didn’t implement it — it was a teaching experience.
Here’s a rundown of his code.
A refinement meeting is also a perfect stage for coaching.
Sometimes, we ask each feature team member to prepare a task for refinement,
Then the expert / architect analyzes each deliverable, fills in the gaps, and explains what they did differently and why.
Who should be on the team
You’d like to enroll people with an R&D or architectural background.
Don’t look for top talent.
Rather, choose developers who are keen to learn 1 or 2 new technologies per year.
I call them the “Jokers”. Like the card, right?
It doesn’t matter if they’re asked to master C++ or Cobol.
They have a “will do” attitude, jump into the subject, and are proud to demo their first tries.
What might surprise you is that such talent can’t really write perfect code.
That’s unnecessary.
The enabler is there to show the POC or just an opportunity.
Your stream-aligned team should be the one to bring a solution to excellence and worry about its scalability.
Jobs for your enabling team
Managers might be tempted to place their best engineer in feature teams as enablers.
But the team becomes too dependent on that support.
So, set clear exit conditions, or you'll create a "team within a team" paradox.
Having that in mind, here’s what an enabling team should do:
1. DevOps upskilling
The inability to self-deploy remains a challenge for many inexperienced feature teams.
Teaching GitHub, Docker, Kubernetes or AWS deployments might be a good first step.
2. Self-testing
Again, I’ll keep insisting that an engineer should test their own code.
In this case, a QA is your enabler.
And they stop supporting the feature team once it can handle testing.
3. AI enablement
At TSH, our biggest AI nerd was asked to do R&D.
In 1 month, they had a POC for an AI application that extracts and processes data from documents.
They then spent around 2 weeks transferring the know-how to the feature team.
4. Architectural work
Most of our own enabling teams are made of hardcore architects.
We have a veteran bunch that coded in Ruby, PHP, .Net, C#, Rust, JS, TS, React, Symfony, Vue, Python, and who are now exploring AI.
These are the “joker” types who always get hyped about new technologies.
They usually coach engineers on choosing architectural frameworks, CQRS, DDD, system integration and performance patterns, or observability and monitoring.
5. Cloud engineering
We had a project that needed to be built with Lambda functions.
Contrary to what it seems, serverless architecture is quite specific.
Only the top 10% know how to use it well.
This creates a dependency where you absolutely must have someone on the team who knows Lambda by heart
You want more team members to understand it properly.
So you deploy someone who hovers over the feature team as a mentor.
A fintech client asked our developer if he could do a side-quest related to Amplify.
This sounded like a regular engineering assignment for a feature team.
We suggested using Cognito instead, which was preferable.
We also offered to teach the client’s team how the solution is built and how to maintain it.
The job took 1 month.
How we “enabled” our DevOps culture
In the past, containerization, log reviewing, monitoring, CI/CD and such, were only done by our DevOps engineers.
Of course, they ended up pretty overworked.
We launched a massive propaganda initiative.
It was before we knew what an “enabling team” is 😄
We taught people how to do CI/CD using Bitbucket, GitLab, and similar services.
Now, there’s a critical mass of “vaccinated” with CI/CD skills.
90% out of 220 technologists at TSH have them.
The inability to pipeline delivery is a “disease” that will soon go extinct at our organization.
Next time
So, any ideas how your organization could use an enabling team?
If you've got war stories of good or bad interactions with such, do comment!
In 2 weeks, we'll examine the complicated subsystem team.
You'll discover which computational nightmares they can help you fight off.
Thanks for reading Effective Delivery!
👋🏼 Hey, you legend!
We’re looking for new readers 👀
Could you please recommend our Substack to 1 person?
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|