The Three Conversations Every Engineering Leader Needs to Have (and Isn't)

There are three conversations that would change most engineering organisations if they happened. They don't happen - or they happen in a way that doesn't land - for reasons I've come to understand well. They involve uncomfortable truths. They require a level of safety that many organisations haven't built. They challenge assumptions that senior leaders have held for years.

But they are the conversations that separate organisations that genuinely improve from organisations that run transformation programmes and stay roughly the same.

---

Conversation One: The Honest Deployment Conversation

The question is simple: How long does it actually take to deploy to production?

Not the aspirational answer. Not the answer that excludes the unusual cases. The realistic, P95 answer: if you decided right now to ship the change you're working on, how long would it take before a real user experienced it?

I have asked this question in dozens of organisations. The answers are almost always more honest the lower in the hierarchy you ask, and almost always more uncomfortable the more specific the follow-up questions become.

Why does it take that long? What has to be approved, by whom, in what sequence? How often does that process go wrong, and what happens when it does? What's the longest it's ever taken, and what caused that?

This conversation is important not because deployment speed is the ultimate metric - it isn't - but because it is a proxy for everything. The deployment process reflects your architecture, your governance, your risk culture, your team structure, your technical health. When it is slow and painful, almost everything that caused it is also causing other problems. When it is fast and boring, almost everything that enables it is also enabling good outcomes elsewhere.

Most engineering leaders know their deployment process is slow. They have normalised it. The conversation that hasn't happened is the one where they name the real cost - to delivery performance, to team morale, to competitive position - and commit to changing it.

---

Conversation Two: The Flow Conversation

The question: What is actually blocked right now, and why?

Not "are there any blockers I should know about?" - that question gets sanitised answers about things the team has already accepted as normal. The real question is: if you looked at every piece of work currently in flight across the organisation, how much of it is waiting for something?

In my experience, when organisations actually map this - really map it, looking at the time each item has spent in each state - the proportion of work that is blocked or waiting at any given moment is shocking. 40%, 60%, sometimes more. Work that exists, is counted in WIP, is on roadmaps and in plans, but is not moving.

The reasons cluster predictably: shared environments with long queues, approval processes with infrequent windows, team dependencies that weren't designed for and aren't managed, architectural coupling that turns every change into a coordination exercise.

The conversation that needs to happen is not the "do we have blockers?" check-in. It is the "why does our system create so much waiting, and what would have to change to reduce it?" reckoning. This question points at processes, at architecture, at governance - at things that only leadership can change. It requires leaders to own the system's problems rather than asking teams to work around them.

---

Conversation Three: The Strategy Conversation

The question: What would we stop doing if we wanted to be elite?

This is the most uncomfortable of the three, and the one that is almost never asked directly.

Elite engineering organisations - those in the top quartile of DORA metrics - share a characteristic that is easy to overlook: they have made choices about what they don't do. They don't maintain multiple parallel release branches. They don't run manual regression testing suites. They don't have change approval boards for routine deployments. They don't operate sprawling monolithic architectures that require team-wide coordination for every change.

They stopped doing those things. Often, stopping was harder than any of the positive investments they made. The regression suite was comforting even though it was slow and unreliable. The change board felt like risk management even though it was a bottleneck. The monolith was familiar even though it was a constraint.

The strategy conversation is: what is the equivalent in your organisation? What practices, processes, structures, or architectural decisions are you maintaining because you've always had them, even though they are now the primary constraint on your performance?

This conversation requires safety to have honestly - because it almost always implicates decisions made by the people in the room. And it requires leadership genuine enough to hear the answer and act on it, rather than commissioning a working group to study the question for six months.

---

Why These Conversations Don't Happen

The pattern is consistent across organisations. These conversations are avoided because:

• Safety isn't sufficient. People know the honest answer and don't feel safe giving it, because past experience suggests the response will be defensive or punitive. The absence of the conversation is a safety signal.
• The answer is uncomfortable. These conversations tend to implicate leadership decisions - the architecture chose in 2018, the governance process introduced after the incident in 2021, the team structure that reflects the org chart rather than the flow of value. Hearing that your decisions are the constraint is difficult.
• The path from conversation to action is unclear. Even when the conversation happens, organisations often don't have a mechanism for turning "the approval process is the bottleneck" into a funded initiative with an owner and a timeline. The conversation happens, everyone nods, nothing changes, and people learn not to have the conversation again.

---

How to Have Them

The pre-condition for all three conversations is psychological safety - genuine safety, not stated values. Teams need to have seen evidence that honesty is welcomed, that problems are met with curiosity rather than blame, that naming a constraint doesn't damage your standing.

Beyond safety: the conversations need to be structured. Open-ended "any issues?" is not the same as "let's map our deployment process honestly, step by step." The specificity is the point. Vague questions get vague answers. Specific, honest questions - asked by leaders who genuinely want to know - get the truth.

And then: the truth has to lead somewhere. The fastest way to kill the next honest conversation is to have an honest conversation and do nothing with it.

Have the three conversations. Then act on what you hear. The organisations that do this - consistently, over time - are the ones that actually improve.