Subscribe
Share
Share
Embed
Where business meets innovation and technology drives transformation.
Engineering Evolved is the podcast for leaders navigating the forgotten ground between startup chaos and enterprise bureaucracy. If you're building and scaling teams at organizations in the middle — where startup rules no longer apply and enterprise playbooks are far too large — this show is for you.
Hosted by Tom Barber, each episode explores the real challenges facing today's engineering leaders: scaling systems without breaking them, building high-performing teams, aligning engineering strategy with business goals, and making technical decisions that drive measurable impact.
Whether you're a Director of Engineering, VP of Technology, CTO, or an IC engineer stepping into leadership, you'll find practical insights drawn from real-world experience — not theoretical frameworks that only work on whiteboards.
Topics include:
Scaling engineering teams and systems for growth
Building effective engineering culture
Bridging the gap between technical and business strategy
Leadership tactics that actually work in the messy middle
Making architectural decisions with limited resources
Navigating organizational complexity
Engineering Evolved — guiding today's leaders through the evolution of engineering.
New episodes drop weekly. Subscribe now and join the conversation about what it really takes to lead engineering in the modern era.
Here's a question that keeps engineering leaders up at night.
Why does it feel like your business and IT teams are playing perpetual game of hot potato
with blame?
The business says IT can't deliver, IT says business can't prioritize.
And meanwhile, customers are wondering why that feature they asked for six months ago is
still in the backlog.
I've sat in rooms where the tension between these groups was so thick you could cut it
with a knife, where every status meeting felt like a trial.
with each side presenting evidence for why the Evo is responsible for the latest delay.
Today, I'm going to introduce you to a collaboration pattern that doesn't require hiring
more people, adding more meetings, or buying another tool.
It's called the Trio model, and it might be the structural change your organization
actually needs.
But fair warning, this only works if leadership is willing to change their behavior, not
their staff's behavior, their own.
Let's get into it.
Welcome to Engineering Evolved, the podcast for engineering leaders navigating the messy
middle.
Companies too big for startup chaos, too small for enterprise bureaucracy.
I'm your host, Tom Barber, and this is episode number 14.
If you're leading engineering at a company somewhere between 200 and 1000 employees, you
know exactly what I'm talking about.
You've outgrown the everyone talks to everyone phase.
but you haven't yet built the infrastructure of a Fortune 500 company.
You're stuck in what I call technical purgatory.
You can't just walk over to someone's desk and hash things out anymore.
There are too many people, too many priorities, too many competing demands.
But you also don't have a dedicated program managers, robust governance frameworks, or the
budgets to throw bodies at coordination problems.
And nowhere is that purgatory more painful than the relationship between business teams
and IT.
Today, we're diving deep into the trio model, what it is, what it isn't, and most
importantly, how to actually make it stick in your organization.
I'll share the specific questions you need to answer before implementing it, the
leadership behaviors that will make or break it, and a realistic starting point you can
try this quarter.
So I want to start with a confession.
I've been part of organizations where this dysfunction was so deeply embedded that it felt
like the natural order of things, like gravity.
You didn't question it.
You just worked around it.
Picture this.
Requests sitting in backlogs for months because no one has the bandwidth to prioritize
them, not because work isn't important, but because there are 17 other things that are
also important.
And the people who could make the call are too busy fighting fires to step back and
actually make decisions.
Then you've got the urgent escalations.
And somehow every escalation is urgent.
Every request is critical.
Every stakeholder is the most important stakeholder.
I remember one organization where I counted in a single week, 11 different requests that
came through as top priority.
11 top priorities.
That phrase stops meaning anything.
when you use it that way.
Business teams frustrated by what they perceive as IT's inability to deliver, start
building their own shadow solutions.
Spreadsheets become databases.
Personal Dropbox accounts become document management systems.
Someone's nephew builds a little access database.
It suddenly becomes business critical.
And then IT isn't just playing catch up.
They don't even know what they're supposed to be catching up to.
They're discovering systems they didn't know existed when some systems break.
Meanwhile, the engineers feel like they're reduced to order taking function.
No autonomy, no input on what should be built or why, just a queue of tickets and a
deadline that they had no part in setting.
I've talked to so many engineers who described this as demoralizing.
They've got into the field because they wanted to solve problems.
And instead, they're just executing instructions that sometimes don't even make sense to
them.
Here's what's interesting.
Not every organization operates this way.
I've also been part of teams where business and IT work together beautifully, where there
was genuine partnership, mutual respect, and shared accountability.
So the question isn't whether the dysfunction is inevitable.
It isn't.
The question is, how do you recover from it when it's already set in and how do you
prevent it from creeping back?
That's what led me to study the trio model because the usual fixes, they don't work.
Let me tell you why.
First, a quick word from our sponsor.
Okay, back to the show.
Let me walk you through the standard playbook that most organizations try when business IT
alignment breaks down.
I've seen all of these attempted and I've seen all of them fail.
First fix, hire more managers or engineers.
The thinking goes, we have a communication problem, so we need more people to communicate.
Sounds logical, right?
But here's the issue.
You're adding people who lack context.
They don't know the history of why certain decisions were made.
They don't know the relationships, the informal power structures, the unwritten rules.
They don't know that Sarah in finance and James in engineering haven't spoken since that
incident two years ago.
And now they're supposed to bridge a gap they don't fully understand.
What you've done is increased your salary costs without addressing the underlying
dysfunction.
You've added another layer of abstraction between the people with the problems and the
people who can solve them.
Second, like I mentioned, you could hire more engineers.
We can't deliver fast enough, so let's add capacity.
This one feels intuitive.
If you're behind, add more people.
But there's a famous observation in software engineering that adding people to a late
project makes it later.
And more broadly, more engineers without alignment just means more code that may or may
not solve the right problems you're optimizing for output when the real issue is
direction.
I've seen teams, I've seen teams double their engineering head count and actually slow
down because you've now got twice as many people who need to coordinate twice as many
people who need context twice as many people asking questions about requirements that were
never clearly defined in the first place.
The third, the fix attempted fix is implement better ticketing and prioritization systems.
Now I'll grant you this can help with visibility.
Having a quick, clear queue and defined priorities is better than chaos.
If you're currently operating in the whoever shouts the loudest gets attention model,
ticketing system is an improvement.
But a ticketing system doesn't fix misalignment.
It just makes the misalignment more visible.
You can have a perfectly prioritized backlog of the wrong things.
A beautiful Kanban board of all the features that don't actually matter.
The tickets flow smoothly from left to right.
And at the end, you've shipped something nobody wanted.
The system becomes a crutch.
Well, it's in the backlog becomes an excuse rather than a commitment.
And because there's now a formal process, people feel less empowered to have the human
conversations that might actually resolve things quickly.
fourth fix, and this is my personal favorite, add more alignment meetings, leadership
meetings, planning meetings, status updates.
retrospectives, pre-mortems, post-mortems, sync meetings, async catch-ups, stand-ups,
sit-downs.
Pretty soon your engineers are spending more time in meetings talking about the work than
actually doing the work.
And here's what happens in those meetings.
They become what I call status theater.
Everyone's performing for each other.
Stakeholders are trying to make their requests sound more important than everyone else's.
Engineers are trying to explain why things are taking so long without sounding like
they're making excuses.
Managers are trying to look like they've got everything under control and nothing actually
gets decided.
I've sat in two hour alignment meetings where we went around the room, everyone gave their
update, and at the end there were no more aligned than when we started.
We'd shared information.
We hadn't made decisions.
We hadn't resolved conflicts.
We just talked to each other for two hours and then gone back to doing exactly what we
were doing before.
the core issue with all of these fixes is they treat business and IT as separate entities
that hand work back and forth rather than partners who solve problems together.
You've got a wall between them.
Sometimes a literal one.
sometimes an organizational one.
And these fixes are all about making it easier to throw things over that wall.
Better ticketing.
That's a nicer catapult for throwing requests over.
More meetings.
That's a regularly scheduled time to throw things back and forth.
More managers.
That's more people standing at the wall, catching things and throwing them to the other
side.
What if you just, how do I put this?
removed the wall, and that's the paradigm shift the trio model demands.
So what is the trio model?
At its core, it's a collaboration pattern built around three roles working together on a
defined problem, not separate functions, coordinating through tickets and meetings, but
genuine collaboration.
Same room, same goals, same accountability.
In a typical engineering focused organization, a trio might look like this.
First, you have a business owner.
This is the person who owns the problem and the customer relationship.
They understand what the customer needs and why it matters to the business.
They can answer the question, why are we doing this?
And what does success look like for people we're serving?
Second, you have the technical lead.
This person owns feasibility and implementation.
They know what's possible, what's practical, and how long things will actually take.
They can answer questions like, how do we build this?
And what are the technical trade-offs?
Third, you have a designer, analyst, or ops lead, something along those lines, depending
on the problem type.
If you're building a customer-facing product, maybe it's a designer who optimizes for user
experience.
If you're improving a business process, maybe it's a business analyst.
If you're tackling an operational challenge, maybe it's an ops lead.
This person optimizes for their domain's excellence.
Now here's what's crucial to understand.
The trio enables co-ownership of outcomes, not just handoff of tasks.
This isn't about the business over writing requirements, throwing them to the tech lead
and waiting for delivery.
This is about all three people being in a room together, literally or figuratively,
working through the problem jointly, understanding the constraints together, making
trade-offs together, earning the outcome together.
Let me be very clear about what the trio is not.
It is not a committee.
It does not vote on things.
It doesn't require consensus for every decision.
It's not an approval layer.
It's not there to sign off on work that other people do.
It's there to work on the alignment and the decision making itself.
It's not there to oversee.
It's there to bring the right people together before decisions are made, not after.
If you're using the trio to review and approve decisions that have already been made
elsewhere, you're doing it wrong.
It's also not consensus driven.
Three people doesn't mean three votes.
And this is where a lot of organizations get it wrong.
They hear Trio and think everyone has to agree.
But that is a recipe for gridlock.
Instead, decision rights are explicitly assigned.
The business owner has a final say over customer priorities.
What problems we're solving and for whom.
If there's a question about which customer segment to prioritize or which pain point
matters most, the business owner makes that call.
The technical lead makes the call on the feasibility and the implementation, whether
something can be built, how it should be built, and what the realistic timeline is.
If there's a question about architecture, technology choice, or delivery estimate, the
tech lead makes that
The third member decides how to optimize their domain, whether that's user experience,
business process design, or operational efficiency.
And here's the key.
The tech lead cannot be vetoed by the business owner on the technical feasibility.
If a tech lead says this will take six months, the business owner doesn't get to say, make
it three.
That's not how physics works.
That's not how software development works.
Pressuring engineers to commit to timelines they know are unrealistic is how you get
burned out teams and fail projects.
Similarly, the business owner can't be overruled on customer needs.
If they say, this is what customers are asking for, the tech lead doesn't get to say,
well, customers are wrong.
The tech lead can certainly raise concerns, suggest alternatives, or explain trade-offs,
but the business owner is the one with the customer relationship.
This clear assignment of decision rights prevents gridlock and ensures each key area is
covered.
One more thing.
The trio is not the entire delivery team.
They make directional and trade-off decisions.
They don't execute all the work themselves.
The trio sets the direction the broader team delivers on it.
In a 10 to 15 person IT organization, not everyone can be in a trio.
If they were,
Core work would stall because everyone would be in decision meetings instead of doing
actual work.
Trio is also not permanent.
They form around defined problems and disband when those problems are resolved.
Assigning people to trios without clear problems just recreates the committees you were
trying to avoid.
We've got a trio for general stuff is a red flag.
What's the specific problem and what does resolution look like?
And the warning I want to plant in your mind right now.
The trio owns it can quickly become no one owns it.
Shared outcomes don't mean shared responsibility for everything.
Each role still has distinct accountability.
The business owner is accountable for understanding customer needs correctly.
The tech lead is accountable for accurate feasibility assessment.
The third member is accountable for their domain.
Shared ownership of the outcome doesn't mean you can point at someone else when your part
goes wrong.
Ahem.
All right, so you understand this concept.
Now let's talk about how you actually implement this.
First question is, which problems warrant a trio?
Not everything needs this structure.
If every problem required a trio, you'd have more coordination overhead than actual work
getting done.
So you need to be selective.
Good candidates for a trio.
are problems with high ambiguity, where the solution isn't obvious and requires
cross-functional input.
If you already know exactly what to build and how to build it, you don't need a trio.
You just go and build it.
There are problems with significant cross-functional dependencies, where no single team
can solve it alone.
If engineering can handle something entirely within their domain, they should just do it.
TRIOs are for problems that genuinely require business context, technical capability and
design or operational expertise coming together.
And they're problems of strategic importance where getting it wrong has meaningful
consequences for the business.
Minor features, routine maintenance, incremental improvements, these don't need the
heavyweight coordination of a TRIO.
So what doesn't need a trio?
Well, defined requests where the path forward is clear.
For example, business as usual work that's following established patterns, pure technical
debt that can be handled within a single engineering stream, bug fixes, standard
operational tasks.
The tricky part is preventing scope creep.
Every business stakeholder wants their engineer in a trio.
If you let that happen though,
You will end up with too many trios and not enough people to do the actual work.
Leaders need to be disciplined about this.
So I recommend a lightweight quarterly review of trio assignments and resources.
Look at how many trios you have active.
Look at how they're distributed across your technical staff.
Too many trios spread technical people thin.
Too few create confusion and inertia.
People don't know where decisions get made.
Balance isn't a one-time fix.
It's an ongoing practice that requires attention.
Now, let's talk about meeting cadence.
Actually, scratch that.
Let's talk about what really matters, which is authority.
So here's something I learned.
C-suite execs don't actually care about the meeting frequency.
They may say they do, but they really don't.
They care about outcomes.
Specifically, they care about...
Will this create more meetings that waste time or fewer escalations that waste my time?
If you frame authority as trust divided, you can show executives that granting decision
autonomy leads to fewer escalations and faster learning loops.
Every time the trio can make a decision without bumping it upstairs, that's time saved for
everyone.
It's a strategic investment, not a risk.
The real cadence question though is what can the trio decide without asking permission?
And how often do they need to meet to exercise that authority?
This could be daily for high priority, fast moving project where things are changing
quickly.
It could be weekly for something more measured.
A long running trio with a slower moving initiative might only need to meet once a month.
There's no universal answer.
It depends on the pace of the work and the scope of the decisions that the trio is
empowered to make.
Now here's the low bearing section of this whole episode, is decision rights.
Most organizational dysfunction stems from ambiguity about who can decide what.
The business thinks they can set priorities.
IT thinks they're drowning in competing priorities with no clear ranking because
everything comes in super urgent.
Both are frustrated because they have different understanding of who's supposed to be
doing what.
IT thinks they're empowered to push back on bad ideas.
The business thinks it's IT's job to execute whatever comes in and that IT is being a
restrictionist on purpose.
Again, different understandings of decision rights.
And nobody, literally nobody, knows who can say no to the CEO's pet project.
So the trio model only works if you can explicitly answer these questions.
Who can green light work entering the trio scope?
If anyone can dump work on the trio, you haven't actually solved anything.
Who can kill or de-scope work that's not feasible?
And this is often the hardest one because who has the authority to say, we are not doing
this.
What trade-offs can the trio make without escalation?
Can they adjust scope, shift timelines, change priorities among items in their domain?
And lastly, what must escalate?
budget thresholds beyond a certain amount, timeline changes beyond a certain point, scope
changes above a certain magnitude.
You need bright lines.
Here's a test that I like to use.
Can your trio members summarize their escalation rules in one tweet?
Something like, only the tech lead can veto feasibility, business owner has final say on
customer priorities, anything over 50k or three month delay goes to steering.
If they can't do that, if there's basic hesitation or disagreement, you've got lingering.
You've got lingering ambiguity that will fuel dysfunction.
If you don't answer these questions and make them prescriptive, you'll end up with the
same bottlenecks you have now, just with a new name.
You'll have replaced vague dysfunction with trio-shaped dysfunction.
So let's talk about how you measure success with a trio.
And this gets a fundamental problem with how most organizations think about
accountability.
The classic setup measures IT on delivery velocity and system uptime.
It measures business on revenue and customer outcomes.
Makes sense on paper.
Each group has metrics that reflect their contribution.
But these metrics can often point in the opposite direction.
The business wants feature shipped fast because there's a revenue opportunity.
IT wants to build it right because there's a stability risk.
If you measure business on feature delivered by Q2 and IT on system uptime above 99.9%,
you've created a structural conflict.
Shipping fast might compromise stability, building stable might miss the deadline.
Both sides are rationally pursuing their incentives and those incentives are fighting each
other.
If the metrics aren't shared, the trio becomes adversarial.
The business owner pushes for speed.
We need to do this feature yesterday.
The tech lead pushes for quality.
We need more time to do this right.
And the third person picks a side or checks out entirely because they don't want to be
caught in the crossfire.
And this is clearly suboptimal to put it mildly.
A trio needs at least one shared outcome metric that all members are accountable for.
Not IT delivered on time and the business adopted it, but rather this problem got solved
and here's how we're measuring it as a team.
The trio should rally around customer centric metrics.
Things like customer satisfaction scores, net promoter score, time to market for customer
facing value, defect rate from the customer's perspective, adoption rates, usage metrics.
These are tangible goals that all Trio members can collectively work to improve, and they
require all three functions to be successful.
If customer satisfaction drops, all three need to figure out why.
Was it the wrong feature?
That's the business owner territory.
Was it poorly implemented?
That's the tech leads territory.
Was it hard to use?
That's the designer's territory.
But the Trio collectively owns the outcome of customer satisfaction.
And this shared metric is what gets reported at the chain to the C-suite executives, not
IT did their part and business did their part, but we as a trio achieve this outcome
together.
This translates shared outcomes into concrete action and collective accountability.
When you succeed, you succeed together.
When you fail, you figure out why together, not point fingers at each other.
And now a word from our sponsor.
Ahem.
All right, welcome back.
This is where I need to tell you the uncomfortable truth.
All of that structural stuff I just described.
It will fail if leadership doesn't change.
This is the single biggest reason why process improvements don't stand the test of time.
We implement new structures, new frameworks, new ways of working.
We train people, we adjust incentives, and then six months later, we're back to the old
dysfunction just with a new vocabulary.
Why?
Because leadership is the one unwilling to change.
Not the ground level staff implementing these patterns.
The staff adapt.
Leadership defaults to old habits when under pressure.
So let me be direct about what needs to stop.
Stop sending urgent requests directly to IT that bypass the trios.
Every single time you do this, you undermine the model.
You're telling your organization the trio process is fine for normal work, but when
something really matters, we skip it.
which means everything that really matters will skip it.
Which means the trio process will only handle things that don't really matter.
Which means the trio process is pointless.
If every request is urgent, there's no way for IT to prioritize.
You've essentially told them that the trio's decisions don't matter when it's inconvenient
for you.
The business also needs to accept that sometimes deliveries will get pushed out.
Legitimately urgent requests will come in that need to be actioned immediately.
Security vulnerabilities, critical bugs, regulatory deadlines.
These have a knock on effect on everything else in the pipeline.
Trio makes the call on how to handle the trade-off.
It's not IT being slow.
That's prioritization in action.
That's the system working.
Stop letting business leaders commit to timelines without technical input.
And I cannot stress this enough.
If a sales team promises a feature by Q3 without talking to engineering, you've broken the
system before it even starts.
There's no guarantee that the people doing the implementation can adhere to those
timelines given their existing workload and delivery schedule.
You're setting everyone up to fail.
The sales team who made the promise, the customer who believed it, and the engineering
team who now has to either kill themselves to meet it or take the blame for missing it.
The trio is where the timeline discussion happens.
Not in the sales calls, not in the executive off-sites, in the trio where all the relevant
information exists.
So protect trio time.
cannot stress this enough.
If your 10 person IT team is running 15 trios, plus business as usual support, plus
handling incidents, you don't have a trio model.
You have a burnout.
Research has shown that a survey of over 3,000 developers found that organizational
culture, sense of belonging, and work satisfaction are directly associated with reduced
burnout.
When everyone is spread across too many trios, constantly context switching, trying to
plan, whilst also developing and supporting existing systems, you're creating the exact
conditions that drive talented people out of your organization.
If you care about retention, and you should because replacing engineers is expensive and
disruptive, you need to protect focus time.
That means limiting the number of trios.
That means giving people uninterrupted time for deep work.
That means not treating every hour of every day as available for meetings.
Finally, hold the business owners accountable for outcomes, not just the engineers.
If a project fails, the business sponsors should be in that post-mortem.
They're part of the chain.
It's not purely an engineering function that causes failure.
It can be a lack of specification, inaccurate scoping, changing requirements midstream, or
unrealistic expectations that were set before engineering was consulted.
If we always assume that the business is right and IT is wrong, you'll forever be in a
spiral of finger pointing with IT taking the blame and good engineers will leave because
they don't want to work somewhere that scapegoats them for failures they couldn't prevent.
This is where you earn trust as a leader, not by telling your teams what to build, but by
changing what you personally stop doing.
All right, let me give you something actionable to walk away with.
Don't try to roll out trios across your entire organization at once.
That's a recipe for chaos.
You'll overwhelm people, create confusion, and probably trigger antibodies for people
who've seen too many transformation initiatives.
Instead, pick one or two high value, high friction problem areas.
Look for places where business and IT currently are butting heads.
where there's visible frustration on both sides and where projects have stalled or failed
due to misalignment, where the same arguments keep happening over and over.
Form trios around these specific problems.
Here's the process.
Firstly, clearly define the problem that the trio is solving, not vaguely, but
specifically.
What outcome will indicate success?
What are you trying to achieve and how will you know when you've achieved it?
Second, assign clear roles to each trio member.
Make sure everyone understands their responsibilities and decision rights.
Write it down, make it explicit, use the one tweet test.
Third, establish specific metrics to measure success.
Customer satisfaction, time to market, whatever makes sense for the problem.
Make sure it's a shared metric that all three members are accountable for.
Fourth, schedule a review after one quarter to assess performance.
Identify what's working and what's not.
make adjustments.
Then run it for a quarter, see what breaks and iterate over it.
This isn't an overnight transformation.
It's not going to suddenly fix your organization, but it will enable more direct
communication and allow multiple groups to take shared responsibility for outcomes.
Requirements don't just get chucked over a wall anymore and everyone has a stake.
I want to acknowledge this is hard.
It takes longer than you'd like and it requires
buy-in across the organization.
And if you don't get that buy-in, particularly from senior leadership, you will not
succeed.
But the difference between a real fix and what I call shelf wear, where you try something
for a week, decide it doesn't work and chuck it on the shelf, is sustained commitment.
Real change isn't easy.
It takes courage to step out of the comfort zone, to change your own behavior, to hold
yourself accountable for enabling rather than undermining the new way of working.
Let this be a call to that courage.
Here's my question for you this week.
When in your organization is the business IT blame game most visible and what would it
look like to form a trio around that specific friction point?
I'm not asking you for you to overhaul your entire structure.
I'm asking you to try it once, pick one problem, form a trio and just see what happens.
And if you do try it, I genuinely want to hear how it goes.
Drop me a message on LinkedIn or send me an email.
Tell me what worked and what didn't and what surprised you.
These real world experiences helped me make this show more useful for everyone.
If you found this episode useful, please share it with another engineering leader who's
dealing with that business IT tug of war.
Word of mouth is how shows like this one grow.
And if you haven't already, subscribe wherever you get your podcasts so you don't miss
what's coming next.
Reviews always help more than you might think.
They help other leaders in the messy middle find out what's going on in the
real world.
If you've got two minutes to leave a review, I would really appreciate it.
Coming in the next episode, we're tackling the topic that's directly related to what we
discussed today, how to run post-mortems that actually lead to improvement instead of just
becoming another blame game in disguise.
Until then, I'm Tom Barber.
Thanks for listening to Engineering Evolved.