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 caught three significant technical risks in the first quarter, all of them 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 governance structure that captures the upside without the risk
⚠️ Why AI improves some people and degrades others
The mechanism is not complicated once you see it. AI tools for project management do one thing extremely well: they apply consistent structure to unstructured thinking. They take whatever the PM brings to them and organise it, format it, and surface it in a professional form.
For a PM who struggles with structure, who has good instincts and relevant experience but produces inconsistent outputs, this is transformative. The AI provides the scaffolding that was always missing. The PM's underlying capability now has a reliable vehicle. The output improves dramatically.
For an exceptional PM whose value is not structural competence but the specific, nuanced judgement that comes from deep contextual understanding, the same scaffolding becomes a liability. The AI produces a structured, professional output that reflects the template more than it reflects the situation. Under time pressure, the PM accepts the output rather than interrogating it. The work becomes less specific, less contextual, less right.
AI amplifies existing patterns. It makes organised thinkers more organised and scattered thinkers more organised. But it also makes nuanced thinkers less nuanced because it replaces contextual judgement with structural consistency.
What the delivery leader notices | What is actually happening |
Stand-up running 5 minutes shorter than usual | Three concerns were not raised. Self-filtered before the stand-up even started. |
"No blockers" from the most experienced team member | Active blocker known and being worked around rather than escalated. |
Smooth, consistent delivery velocity | Work is proceeding, but accumulating technical debt that will surface later. |
Senior engineers are less visible in the team. Slack | Information sharing has moved to a private channel with trusted peers. |
🤔 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
3 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.
BEFORE Senior engineer is silent for 11 days. No private conversation held. Structural decision identified as problematic in week 26, not surfaced until catastrophic failure at week 30. | AFTER Private conversation on day 6 of silence. Engineer surfaced a performance concern about a third-party dependency. Resolved in 4 days before it reached load testing. No incident. |
✅ 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.
BEFORE No structural audit of concern-raising cost. Collective self-filtering had been operating for 6 weeks before it was noticed. By the time it was noticed, six significant concerns were outstanding. | AFTER Concern-cost audit run in week 2. Seven items surfaced. Two were raised as formal risks within 48 hours. Three were resolved through a change in communication norms. Two were already being addressed but the team did not know it. |
✅ Fix 3: Week 3 — The structural fix — build 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 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.
BEFORE No structural mechanism for low-cost concern-raising. All technical concerns required direct verbal escalation in a group setting. Three senior engineers operating in near-total silence by week 4. | AFTER All three structural changes introduced. End-of-day risk log received 23 entries in the first month. Four became formal RAID items. Team verbal engagement in stand-ups increased within two weeks without any direct instruction to engage more. |
Task for you
🎯 What to do this week
This week, track one metric you have probably never tracked before:
For the 3 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. |
👉 Wrap Up
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. |
That’s it for this week.
Keep showing up, keep cheering each other on and as always, run happy! 🏃♂️
P.S: Details in this issue have been changed to protect client confidentiality. The situation and the lesson is real
New here?
If this issue is named something you have been watching but could not describe, forward it to one person who needs to read it.