Delivery intelligence for technology leaders · Issue #40 · Every Wednesday
Not 3 months. Not 3 weeks of runway. 3 weeks until something breaks.
Disclaimer: Details in this issue have been changed to protect client confidentiality. The situation and the lesson are real
She had been the most engaged person in every stand-up for 7 months.
The lead engineer on our most complex workstream. Sharp, direct, the kind of person who would call out a bad architectural decision in front of the client without hesitation. She had identified three significant technical risks in the first quarter, all of which were caught before they reached the backlog. The team trusted her completely.
In week 29, I noticed she had not challenged anything in stand-up for 6 days. She was answering her 3 questions. She was present. She was doing her work. She had just stopped.
"Yesterday I finished the integration layer. Today I'm continuing the same. No blockers."
Eleven days later, the integration layer failed under load. It was not a simple bug. It was a structural decision that had been made in week 26 - one she had known was wrong, had decided not to raise, and had spent the following three weeks building around.
When I asked her why she had not flagged it, her answer was more honest than I had expected: "I raised two things in month 5 and both times I felt like I was being managed rather than heard. I decided it wasn't worth the energy."
Today's menu:
🚨 The problem: The specific silence pattern that precedes every major technical failure I have seen in 14 years and why it is always the most capable person who goes quiet first
💸 What it costs: Why the silence of senior engineers is the most accurate leading indicator of delivery risk available and why it never appears on a RAID log
✅ The fix: The 3-week intervention that catches the pattern before it becomes a crisis⚠️ The silence pattern — what it is and why the best person goes first
Senior engineers go quiet in stand-ups for a specific, identifiable reason that is almost never the one delivery leaders assume. It is not burnout — burnout produces agitation before silence. It is not disengagement — disengagement produces lower quality work, not lower verbal frequency. And it is almost never satisfaction.
The most common cause of senior-engineer silence in a well-functioning team is a specific, rational cost-benefit calculation: the engineer has assessed that the cost of raising a concern — the social friction, the pushback, the feeling of being managed — is greater than the benefit of having the concern heard. And they have made this calculation based on evidence from the programme.
Senior engineers do not go quiet because they have nothing to say. They go quiet because they have learned that saying it is not worth it.
The reason the best engineer goes first is exactly their seniority. A junior developer raises concerns because they are still learning the social norms of the team. A senior engineer has already made the social calculation with much more precision — and has enough other things to focus on that withdrawing from verbal risk-raising is a rational conservation of energy.
🤔 Quiz
You lead a 12-person engineering team. Your most senior developer historically engaged, opinionated, and reliable has given a variation of "all good, no blockers" in stand-up for 8 consecutive days. Delivery metrics are normal. What is the right first action?
A) Nothing — consistent delivery metrics are the signal that matters, not verbal frequency
B) Ask them directly in the stand-up: "Are you sure there are no blockers? You've been very quiet this week."
C) Have a private 15-minute conversation outside the stand-up: "I've noticed you have been less vocal recently, is there anything you're sitting on that you haven't raised?"
D) Send a team-wide message encouraging everyone to raise concerns more actively
👉 Answer at the end of this issue💡 The fix
Three interventions timed specifically to the 3-week window before the silence becomes a structural problem.
✅ Fix 1: Week 1 — The private, direct conversation
Within 5 days of noticing the silence, a 15-minute private conversation. Not a performance conversation. Not a welfare check. A specific, respectful inquiry:
"I've noticed you've been less vocal in stand-ups recently. I want to make sure I'm not missing something important. Is there anything you are sitting on technically or otherwise that you haven't raised?"
The silence after this question is important. Do not fill it. The engineer is doing a rapid cost-benefit recalculation. Is this person going to hear what I say or manage it? Your job in the first 90 seconds after they speak is to demonstrate, specifically and behaviourally, that you are doing the former.
If they say "nothing, all fine": thank them and leave the door open. Watch for a second week of silence. If that occurs, the calculation has been made and you need the next intervention.
✅ Fix 2: Week 2 — The concern-cost audit
If the private conversation has not produced the information, the issue is structural: the cost of raising concerns in this team is too high. A 45-minute session with the senior engineers only, no junior team members, with one question:
"Think of the last time you identified a concern on this programme and decided not to raise it. What made you decide not to raise it?"
Write every answer on a whiteboard. Do not defend against any of them. Do not explain or contextualise. Just write them down and read them back. The act of making the concern-cost visible, in a room, without defensiveness, is often enough to change the dynamic because it signals that this is now a problem you are taking seriously rather than managing.
✅ Fix 3: Week 3 — The structural fix builds concern-raising into the process, not the person
If the silence persists into week 3, the issue is not about the individual engineer. It is about the environment. Three structural changes that reduce the cost of raising concerns at the team level:
- The end-of-day risk log. A standing Slack channel or equivalent where the only acceptable input is "I noticed X today and I am not sure whether it is a risk." No resolution required. No follow-up demanded. Just observation. The programme lead acknowledges every entry within 24 hours.
- The pre-commitment check. Before any architectural or technical decision is finalised, one question is asked of the most senior person who disagreed with it: "What would need to happen for you to be proven right?" This gives dissent a legitimate structural role instead of requiring it to be raised as a confrontation.
- The monthly technical retrospective. Separate from the delivery retrospective. Focused entirely on technical decisions: what are we building that we are not comfortable with? This is where the concerns that are too technical to raise in a delivery forum find a legitimate place.
🎯 What to do this week
This week, track one metric you have probably never tracked before:
- For the three most senior engineers on your team: how many substantive observations (concerns, challenges, technical flags) have they made in stand-ups and ceremonies in the last 10 working days?
- Not "did they attend." Not "are they performing." How many times did they say something that was not a status update?
If the answer is fewer than two per person per week: you may have a silence pattern forming. You now have 3 weeks before it becomes a structural problem.
Want the concern-cost audit questions — the exact 45-minute format?
Reply "silence" to this email and I'll send it directly to you.🌐 Around the web this week
⚡ 1 tool: TeamRetro — asynchronous retrospective tool with anonymous input. The specific use case: a standing "what am I not saying" prompt that team members can contribute to before the synchronous session. The anonymity removes the social cost before the concern reaches the room.
📊 1 number: Google's Project Aristotle research found that psychological safety, the belief that one will not be punished for raising concerns, is the single strongest predictor of team effectiveness across the 180 teams studied. It ranked above all technical, organisational, and individual competence factors. The silence pattern is what happens when psychological safety has already failed.
💬 1 quote: "What got you here won't get you there." - Marshall Goldsmith. For delivery leaders, what got you here: confidence, decisiveness, pattern-matching from experience, is precisely what creates the silence in your best people. Success and the conditions for future success are not the same thing.
👉 Quiz answer
C — private, direct, and non-accusatory.
Option A is the most common response and the most dangerous, it treats delivery metrics as the only signal that matters, which is the assumption that allows this pattern to reach crisis. Option B creates a public moment that compounds the social cost already causing the silence. Option D is too diffuse to address the specific pattern and may actually increase the cost of raising concerns by making it feel scrutinised.
Option C works because it is private, it is observational rather than accusatory ("I've noticed" not "why aren't you"), and it specifically names the concern about unraised issues. It gives the engineer a low-cost way to surface what they are sitting on without requiring them to do it in front of the team. The phrase "is there anything you're sitting on" is important — it names the specific pattern you are looking for.
The lead engineer I described in the opening story is, as far as I know, thriving. She left the programme at the end of that engagement — not because of the incident, but because the engagement ended.
What she taught me by going quiet, by deciding three weeks before the failure that raising concerns was not worth the energy, is something I now treat as the most important signal in any programme I lead. Not the RAG status. Not the velocity chart. The voice of the most capable person in the room.
When that voice goes quiet, everything else is noise. The 3-week clock is already running.
Think of the most technically capable person on your current team. When did they last challenge something, a decision, an assumption, a plan in a group setting? If you cannot remember, the clock may already be running.
Hit reply. I read everything.
Until next Wednesday,
Aman
If this issue is named something you have been watching but could not describe, forward it to one person who needs to read it.
No comments:
Post a Comment