Here's a question that might sting a little.
How many hours did you spend in meetings last week?
I want you to actually think about it.
Monday through Friday, sprint planning, stand-ups, one-on-ones, roadmap reviews, backlog
grooming, stakeholder sinks, all hands.
The retrospective that somehow always runs over.
Now, how many of those meetings actually moved your team forward?
Not just exchanged information, but actually built something.
Trust.
Understanding.
Alignment on hard stuff.
I've been in organisations where calendars looked like a game of Tetris gone wrong.
Back to back, 8am to 6pm with 15 minute gaps that were somehow supposed to be enough time
for lunch, bathroom breaks and actually doing the work.
And after all of it, people still had no idea what anyone else was actually doing.
Project managers felt like they were throwing specs over the wall and hoping that they
were somewhere useful.
They landed somewhere useful.
Developers felt blindsided by requests that seemed to come out of nowhere.
Everyone was exhausted and nobody felt heard.
The thing is, this wasn't an organization that lacked rituals.
If anything, they had too many.
The problem was something else entirely.
And today, we're going to talk about...
why your rituals might be optimized for the wrong thing and what to do about it.
Welcome to Engineering Evolved.
I'm Tom Barber and this is episode number 13.
If you're an engineering leader in a mid-sized company, let's say somewhere between 200
and a thousand employees, you're living in a strange no man land.
I call it the missing middle and it's where most of the interesting problems live.
You're too big for startup chaos that somehow worked when you were 15 people in a room who
all knew each other's coffee orders.
Back then, coordination happened by osmosis.
Someone would overhear a conversation and jump in.
Problems got solved at the whiteboard before they came crisis.
You didn't need formal rituals because the team was the ritual.
But you're also too small for the enterprise playbooks.
You don't have a dedicated program management office.
You don't have formal escalation matrices with color coded severity levels.
You probably don't have relationship managers or alignment teams or any of the other roles
that large companies create specifically to handle the friction of working together.
You're in the middle and the middle is hard.
This show exists for you, the people navigating that space between the scrappy startup and
lumbering enterprise, trying to figure out what actually works at your scale.
And today's topic, it's something every single one of you is doing probably multiple times
a day, team rituals, standups, planning sessions, retrospectives, all hands, roadmap
reviews, the ceremonies that structure how your teams work together.
Now the question is whether those rituals are actually building the team you need or just
creating the illusion of coordination.
while the real problems fester in Slack channels and the one-on-one venting sessions.
So let me tell you about two very different experiences I've had with the same ritual, the
Daily Standup.
When I worked at NASA JPL, I was part of a team building science software to process data
downlink from NASA's Perseverance Rover.
This mission was critical.
This was mission critical work.
When data comes down from Mars, you need to process it correctly and you need to process
it quickly.
There's no, we'll fix it in the next sprint.
For years, two, three years at least, I joined nightly standups, not daily, nightly
standups, because I was based in the UK and we had to get Los Angeles, Melbourne, and
London on the same call.
Think about those time zones for a moment.
Los Angeles is eight hours behind London.
Melbourne is 11 hours ahead.
The only window that didn't completely destroy someone's day was late at night UK time.
So 11 p.m.
Every single night for 20 to 30 minutes, that was my stand up.
Now, I won't pretend that it was fun.
I wasn't at my sharpest at 11 p.m.
after a full day of work.
My family learned that dad disappeared into his office every night before bed and it was a
sacrifice and I felt it.
But here's the thing, those stand ups were effective, genuinely effective.
We could hand off work, we could hand work off cleanly.
The Melbourne team would finish their day, walk us through what they'd done and what was
blocking them and we'd pick it up.
We could discuss blockers without them festering for days.
And critically, we actually knew each other.
Over the months and years of those calls, we built relationships.
We'd shared frustrations and celebrated wins.
We knew who was going through a tough time at home and might need a lighter load.
We knew who was itching for a challenge and ready to take on something hard.
When someone said they were stuck, the rest of us believed them.
We didn't assume they were making excuses or padding estimates.
We jumped in to help because we trusted that if they said it was hard, it was hard.
And that trust wasn't built in a team building offsite or a personality assessment
workshop.
It was built in 11 PM calls, night after night, doing real work together and the
occasional onsite.
Then I went to work for a medical startup, completely different context, completely
different dynamics.
We had a team on the US East Coast and a team in India.
This is a common setup.
Lots of companies work that way.
And on paper, we had the right rituals in place.
Daily standups, sprint planning, retrospectives, scrum masters in India running the
ceremonies by the book, project managers in the US tracking progress and flagging risks.
Probably see where this one's going.
But the dynamics couldn't have been more different from NASA.
The standups were pure transaction, status update, status update, any blockers, no
blockers, next person.
It felt like going through customs at an airport.
Show your passport, answer the questions, move along.
No one asked follow-up questions.
No one said, that sounds hard.
Tell me more about what's making it difficult.
No real conversations happened.
The business owners were perpetually frustrated because things kept sliding and they
didn't understand why.
The developers were increasingly jaded because they felt like they were just executing
tickets without any sense of the bigger picture.
Requirements would come over the wall, beautifully documented, technically detailed, and
the team would build exactly what was specified.
Only to learn later, it wasn't actually what the business needed.
And I sat somewhere in the middle.
trying to bridge gaps that kept widening, trying to translate between groups who shared a
stand-up every day but somehow didn't understand each other at all.
Same ritual, same 15 minutes every morning, completely different outcomes.
So what was the difference?
It wasn't the format, it wasn't the frequency, it wasn't even the time zones, though those
certainly didn't help.
The difference was what the ritual was optimized for.
So here's what I've come to understand after years of working in both functional and
dysfunctional teams.
The problem isn't missing rituals.
If anything, most midsize companies have too many rituals.
They're trying to read agile books, implementing the scrum ceremonies, adding the safe
layers on top, and now they're drowning in process.
The problem is that those rituals are optimized for the wrong thing.
Think about the cross-functional meetings.
What are they actually designed to do?
Sprint planning moves requirements from one system to another.
Stand-ups broadcast status updates.
Roadmap reviews present decisions that have already been made.
Stakeholder sinks keep people informed so they don't complain about being left out.
There's a word for this kind of work, and that word is perfunctory.
carried out with a minimum effort or reflection.
These meetings answer the what and the when.
What are we building?
When will it be done?
What's blocking us?
And what can we expect in the next release?
But they completely miss the deeper questions.
Why does this matter to you?
What are you actually worried about?
What would make you feel confident about this is the right approach?
What are we not talking about that we should be?
And those questions are everything.
And I don't mean in a soft touchy feely way.
I mean in a hard practical, this will determine whether your project succeeds or fails
way.
Developers building without understanding the bigger picture will always be on the back
foot.
They'll build the wrong thing because they didn't understand the context or they'll build
the right thing in the wrong way because they didn't know about the constraints that
seemed obvious on the business side.
Or they'll build it perfectly, but fail to communicate why it matters.
So it sits unused while stakeholders wonder what engineering has been doing for the last
three months.
For mid-sized companies, this is especially acute.
You don't have the luxury of dedicated alignment teams.
You can't hire a chief of staff to manage up and down.
You probably don't have the product managers with the bandwidth to write 50 page specs and
anticipate every question.
Your engineering leads have to be technical.
strategic and interpersonally effective all at once.
They have to write code, understand the business and navigate relationships with
stakeholders who have competing priorities.
And that of course is a lot to ask.
And your rituals either support them in that work or they actively undermine it.
This brings me to a framework that's been around for over two decades, but remains
devastatingly relevant.
Patrick Lencioni's Five Dysfunctions of a Team.
Lencioni published his book in 2002 and it's since sold over three million copies.
It's become one of those business books everyone references, but not everyone has actually
read.
So let me walk you through it properly because understanding this framework changes how
you think about every ritual on your calendar.
The book presents team dysfunction as a pyramid where each layer builds on the one below
it.
You can't fix the upper layers if the foundation is broken.
And of course, most organizations are trying to do exactly that.
Let's go for each layer.
At the very bottom of the pyramid is the absence of trust.
And this isn't the trust in the, trust you not to steal from my petty cash sense.
This is the vulnerability based trust, the willingness to say, I don't understand.
or I made a mistake or I'm in over my head without fearing it will be used against you.
Think about your last team meeting.
Was there a moment where someone could have admitted confusion but didn't?
Where someone nodded along rather than asking the clarifying question that might make them
look uninformed?
That's absence of trust in action and it's poisoned for teams.
When this foundation is missing, people perform competence rather than building it.
They hide problems until they become crisis.
They spend energy managing perceptions instead of solving problems.
Everything above this layer is built on sand.
The second layer is fear of conflict.
When trust is low, people seek artificial harmony.
They're not along in meetings and then tear each other apart in Slack channels afterward.
Or they escalate to their managers instead of having a direct conversation.
Or they just quietly disengage and stop caring about outcomes.
Fear of conflict isn't about avoiding outcomes, it's about avoiding productive
disagreement.
It's teams where the roadmap review is a presentation, not discussion.
Where decisions are announced rather than debated, where disagree and commit becomes
pretend to agree and quietly undermine.
The third layer is the lack of commitment.
This is what happens when people don't feel heard.
When a decision was made before the meeting started and the meeting is just theater,
people feign buy-in, they say, sounds good, and then quietly pursue their own agenda.
They do minimum required to satisfy the tracking system while directing a real energy
elsewhere.
Of course, lack of commitment creates ambiguity that ripples through the entire
organization.
Is this actually the priority?
Does leadership really mean it?
Should I drop everything for this or will it change again next week when people don't
believe the commitments that they're making neither does anyone else.
The fourth layer is avoidance of accountability.
And this means people duck responsibility to call out counterproductive behavior.
Not just in peers, in superiors too.
When the VP makes a commitment misses it, does anyone say anything?
When a team lead consistently shows up unprepared, does anyone address it?
Avoidance of accountability sets low standards.
And here's the insidious part.
When leaders don't hold themselves to standards, expecting others to do so becomes absurd.
The team takes its cues from what leadership tolerates, not what they say they value.
And at the very top of the pyramid is inattention to results.
And this is where ego trumps team success.
where individual status becomes more important than collective outcomes, where people
optimize for their own visibility, their own promotion case, their own department metrics,
even when it hurts the broader mission.
Now here's what struck me when I first encountered this framework.
Most of the standard rituals, the sprint reviews, the planning sessions, the stakeholder
updates operate exclusively at those top two levels, accountability and results.
We track velocity, we measure outcomes, we create dashboards and store scorecards, can't
say that word, and OKR trackers.
But we're addressing the top of the pyramid whilst assuming the foundation exists.
We're measuring results without building trust and we're demanding accountability without
enabling healthy conflict.
We're expecting commitment without actually earning it.
And that is building on sand.
And the thing about sand is that it holds for a while.
You can even construct something impressive looking, but when the storm comes, it all
collapses.
And now, a word from our sponsor.
So of course, what do we do instead?
How do we design rituals that actually build trust, enable healthy conflict, and create
genuine commitment?
I want to give you three practical shifts, not new meetings to add to the calendar, you've
got enough of those, but ways to transform the meetings you already have, ways to move
your rituals from perfunctory information transfer to actual team building.
Shift one, rituals that surface vulnerability.
And so this first shift is designing rituals that surface vulnerability.
I don't mean forced icebreakers, I don't mean share your spirit animal or what's your
enneagram type.
These can actually backfire by making vulnerability feel performative.
I mean structured moments where admitting uncertainty becomes normalized, where the senior
people go in first showing that they don't have all the answers.
Picture this, an engineering lead opening a quarterly planning session with, here's what I
don't understand about this quarter's priorities.
Not as a gotcha or a complaint, as genuine invitation for dialogue, and then asking the
product manager to do the same.
What are you uncertain about?
What keeps you up at night?
That back and forth normalizes uncertainty between the groups.
The people deciding what should be built and the people doing the building can both
acknowledge that they don't have perfect information.
that they're working with assumptions that might be wrong, that they need each other's
perspective to get this right.
When I've seen this work well, it transforms the energy in the room.
People stop posturing, they stop defending positions and start exploring problems.
The PM admits that they're not sure if customers actually want this feature or if they're
just loud.
The engineering lead admits that they don't know if the architecture will scale and
they've been afraid to bring it up.
Suddenly you've got a real conversation instead of parallel presentations.
In a mid-sized company, this is transformational.
You don't have layers of middle management to absorb ambiguity.
You don't have business analysts to translate between technical and business language.
Your people need to work directly with incomplete information all the time.
And making that explicit rather than pretending everyone has it figured out changes
everything.
The key is that leadership has to go first.
If the most senior person in the room never admits uncertainty,
No one else will either.
Vulnerability flows downhill.
Shift two, rituals that practice disagreement.
And so this second shift is creating rituals that practice disagreement because here's a
pattern I've seen over and over.
Teams that only agree in meetings and then fight in Slack.
Teams where the roadmap review is peaceful and then the aftermath is chaos.
Teams where everyone nods along and then nothing gets implemented because no one's
actually bought in.
And that's a ritual problem.
Your ceremonies are optimized for artificial harmony instead of productive friction.
What does it look like to build productive friction into your cadence?
One approach I've seen work well, introduce a red team rotation into the roadmap reviews.
Before the meeting, assign someone the explicit job of asking the hard questions.
Give them permission.
No, give them an obligation.
Poke holes.
Not to be difficult, but to ensure that the
Friction happens in the room in a structured way rather than afterward in side channels.
The questions sound like this.
What are we not considering here?
What if our core assumption is wrong?
Who's going to hate this decision and why?
What's the failure mode and we're not talking about?
And if this doesn't work, how will we know and what will we do?
And here's what's powerful about making this a role.
When disagreement becomes a job rather than a personality trait, it stops being personal.
The person asking the hard questions this week might be defending the roadmap next week.
Everyone takes turns.
It normalizes challenge as part of process, not an attack on individuals.
For midsize companies, especially, this matters.
You probably don't have a chief of staff whose job is there to ask inconvenient questions.
You don't have a strategy team running scenario analysis.
That function needs to be distributed across your teams.
Make it part of how you operate, not something that depends on having a contrarian
personality in the room.
I'll add one more thing.
The red team has to have real power.
If their objections are consistently overruled without genuine consideration, people will
learn that the ritual is theater.
The questions have
to actually influence decisions sometimes or the practice becomes meaningless.
Shift 3, rituals that build shared context and not just shared information.
And so this shift is perhaps the most important.
Building these rituals that create shared context, not just the shared information, is of
course supremely important.
And there's a world of difference between here's the roadmap and here's the trade-off I
struggled with and why I landed here.
The first is information transfer.
It's a broadcast.
It's one directional.
You can do it with an email or a Notion page or recording that people watch at two times
speed, much like this podcast.
Of course, I'm joking.
The second is context building.
It's an invitation into someone's thinking process, it helps people understand not just
what was decided, but how to make similar decisions themselves when you're not in the
room.
Context is what enables distributed decision making.
When someone understands why you made a choice, they can extrapolate that to new
situations.
When they only know what you chose, they have to escalate every time something doesn't
quite fit the original decision.
One practical implementation, consider replacing your quarterly all hands presentations
with smaller cross-functional contact sessions.
Instead of the CEO presenting a polished deck to hundreds of people, most of whom are half
listening while doing email,
Have smaller groups dig into specific decisions.
In these sessions, leaders walk through their reasoning, what their alternatives were
considered.
What data did we look at and what data do we wish we had?
What are we still uncertain about and what makes us change course?
We actually saw this work on a medical project I mentioned earlier.
When we finally split the giant cross team standups into smaller, one might more focus
groups,
Communication improved dramatically.
People could actually have conversations rather than sitting through status theater.
They could ask questions and get real answers instead of, take that offline.
The managers still track the broader project goals at a higher level.
You don't lose visibility by going small, but the individual contributors finally
understood why their piece mattered.
They could make better local decisions because they understood the global context.
And now word from our sponsor.
Alright, back to the show.
There's a compounding effect to all of this that I want to name explicitly because it's
where the real return on investment shows up.
When rituals build, trust and normalize disagreement, conflict resolution becomes
dramatically cheaper.
Think about what happens in most organizations when there's a real problem.
A deadline is going to slip, a key dependency fell through, someone made a mistake that's
going to be expensive to fix.
In low trust environments, that energy goes into blame management.
Who knew what when?
Who should have flagged this earlier?
How do we present this to leadership in a way that protects our team?
People spend days crafting the narrative, building the case, lining up allies.
By the time the actual problem gets addressed, it's bigger than it needed to be.
In high trust environments, the problem just gets solved.
Someone says, hey, we have an issue and here's what I think we should do about it.
The team discusses, decides and moves.
No theater.
No blame games, no political maneuvering.
Teams that have practiced navigation tension in low stakes settings don't need elaborate
escalation paths.
When a real crisis hits, they already have the muscle memory to work through it.
They know how to disagree constructively.
They trust their colleagues are acting in good faith even when they see things
differently.
I've worked in both environments.
In London startups where small engineering teams face unrealistic deadlines, I watched
project managers get genuinely angry when delivery slipped and they couldn't comprehend
why it happened despite all the ceremonies being followed.
The escalation would go up the chain, consuming days of leadership attention, damaging
relations that took months to rebuild, all because the foundation of trust wasn't there to
have a direct early conversation about the risks.
But I've also worked in organizations where product managers, project managers, and
engineering leads have built enough trust that problems could be surfaced when they were
small, where saying, I'm worried about this timeline, didn't feel like admitting failure.
The difference in delivery capability was night and day, not because the engineering was
better, often it wasn't, but because the friction was lower, because the energy went into
solving problems instead of managing perceptions.
Now, I know some of you are thinking, this all sounds soft.
Relationship building rituals feel indulgent when there's a product to ship and investors
breathing down your neck.
And I get it.
I really do.
It's harder to justify building shared context in a planning document than it is to
justify a sprint review.
Your CFO isn't going to get excited about vulnerability rituals.
Leaders from larger companies or from non-engineering backgrounds might see these meetings
as naval gazing.
Nice to have when times are good, first thing to get cut when the times are not.
But here's what I'd say to that.
The return on investment is real.
It just compounds slowly.
You won't see results in the next sprint.
You probably won't see them in the next quarter, but when the crisis comes and the crisis
always comes, that's when your investment pays off.
When your team has to bail the company out because something wasn't in the plans,
When a competitor launches and you need to pivot in two weeks.
When your best engineer gets an offer from a fan company and you need to convince them to
stay.
When the priorities shift overnight and you need people to throw out three months of work
and start fresh without burning out or build burning bridges.
The teams with strong foundations deliver in those moments.
They rally, they problem solve.
They work insane hours, not because they're told to, but because they care about each
other and the mission.
The team's built on rituals of pure information transfer.
They fall apart or worse, they go through the motions while quietly updating their
resumes.
And there's another cost that's harder to measure, but equally real.
Staff happiness and retention.
People who feel like they're just cogs in a status update machine become disengaged.
They stop putting in discretionary effort.
They do exactly what's asked and nothing more.
They update their LinkedIn profiles.
They take recruiter calls.
Eventually they leave and you spend six months trying to replace them while the team
absorbs their workload.
Your rituals signal what you actually believe about how work gets done.
If every ceremony is about outputs and timelines, you're communicating that relationships
are someone else's problem.
Don't be surprised when people treat relationships as someone else's problem too.
So let me leave you with a diagnostic, not a checklist or a framework, just a question to
sit with.
Think about the last three team meetings you ran or attended.
Pick the ones that felt most typical, most representative of how your team operates.
How much time was spent on information transfer versus relationship building?
Was there any moment where the format made space for connection or was it all status
updates and action items?
Did anyone admit that they didn't understand something?
Not as a challenge or a gotcha, but as genuine acknowledgement of uncertainty.
Did anyone say, I don't know and have that be okay?
Did anyone disagree openly and productively?
Was there a moment of constructive friction where different perspectives collided and
something better emerged?
Or did everyone just nod along?
Did people leave with shared context about why decisions were made or what the decisions
were?
Could they explain the reasoning to someone who wasn't in the room?
If your honest answer is that those meetings were mostly status updates and requirement
handoffs, if vulnerability was absent, disagreement was suppressed and context was thin,
you're building on sand.
And the thing about building on sand is it works for a while.
You can construct something impressive looking.
You can hit your quarterly numbers.
You can check boxes on your OKRs.
But when the ground shifts, and in our industry, the ground always shifts, the whole thing
comes down.
The structure of your rituals reveals what you actually believe about how work gets done.
Make sure what you believe is actually serving you.
If this episode got you thinking, I'd love for you to subscribe to engineering evolved
wherever you get your podcasts.
And if you're finding value here, leave a review.
It generally genuinely one day I'll get that word right.
Helps other engineering leaders discover the show.
We're building something for the missing middle and every review helps more people find
this.
Head over to conceptocloud.com for more resources, including downloadable frameworks you
can actually use with your teams.
Next time on Engineering Evolved, episode 14, the product trio model, making actually work
in engineering heavy orgs.
You've probably heard of the product trio, product manager, designer, and tech lead
working as equals.
It sounds great in the blog posts, three perspectives, balanced input, collaborative
decision making.
But what happens when your organization is engineering heavy and design is an
afterthought?
When you have one designer for every 15 engineers, when the trio becomes a duo plus
someone who occasionally shows up for the important meetings.
We'll dig into how to make this model actually work in the real world with all of its
constraints and imperfections, when to follow the playbook and when to adapt it and when
to throw it out entirely.
Until then, keep evolving.