An engineering manager's calendar looks full and evenly spread: one-on-ones, standups, planning, a review here and there. What that calendar hides is where the manager's actual attention goes inside those blocks, and it is not distributed anything like evenly, and not for reasons that map cleanly onto which parts of the team need it most.
Attention as a scarce, contested resource
A manager has a fixed amount of attention in a given week, and every part of the team is implicitly competing for a share of it. Under that kind of contention, attention behaves the way any scarce resource behaves when nobody has explicitly rationed it: it goes to whoever is loudest, most recently, not to whoever's problem is largest in expectation. A team member escalating a blocked task gets addressed today. A quietly accumulating architectural risk that nobody has escalated because it hasn't caused a visible problem yet gets addressed never, until it does. Anyone pairing engineering management with an actual go-to-market motion will get more out of XenGrowth's operator guides.
This isn't a character flaw in any individual manager. It's the predictable behavior of attention under contention, and it maps directly onto something Richard Cook described about complex systems generally: organizations build strong, ready defenses against visible, urgent failures, and they systematically under-defend against the slow accumulation of risk in things that haven't broken yet, because nothing is currently generating the alarm that would redirect attention there.
Type of problem | How loudly it demands attention | How much attention it typically gets |
|---|---|---|
A production incident right now | Very loud — pages, escalations, visible impact | Immediate, often disproportionate to its actual long-term cost |
A team member visibly struggling and saying so | Loud, if they're comfortable escalating | High, once raised — assuming psychological safety allows raising it |
Slowly accumulating technical debt in a stable system | Silent — nothing currently alarms about it | Low, until it produces a visible failure of its own |
A quiet team member's underused skill or unaddressed frustration | Silent, especially without strong psychological safety | Low, and easy to miss for months |
Why this connects directly to team effectiveness research
Google's Project Aristotle research is relevant here in a way that goes beyond the usual reading of it. The study ranked psychological safety as the strongest predictor of team effectiveness, with dependability and structural clarity close behind — and a manager's day-to-day attention allocation is one of the primary mechanisms by which a team actually gets any of these three, or doesn't. Psychological safety isn't built by a values statement; it's built, incrementally, by how a manager responds the specific times someone admits a mistake or raises an uncomfortable point, which requires the manager's attention to actually be present for those moments rather than consumed by whoever escalated loudest that week.
A manager who is only ever available for the loudest problem is teaching the team, by pattern rather than by statement, that quiet problems don't get heard — which is the exact mechanism by which psychological safety erodes without anyone deciding to erode it.
The specific asymmetry worth naming
The failure mode this produces has a specific shape: a manager becomes excellent at handling escalations and slowly worse at preventing the conditions that require them, because preventing them requires attention spent on things that aren't currently asking for it. This is the organizational-scale version of Cook's point about complex systems resisting single, visible failures while quietly accumulating the conditions for a multi-cause one — a manager's attention, allocated purely reactively, defends well against the failure that's already loud and defends poorly against the one that's still three months from becoming visible. The XenGrowth resource library covers the the operations side of this side of this.
Reserve a fixed, protected portion of weekly attention for the quietest members of the team on a schedule, independent of whether they've escalated anything — the whole point is checking on risk before it becomes loud enough to demand attention on its own
Treat a long stretch of silence from any one part of the team as a signal worth checking, not as evidence that nothing needs attention there — silence is exactly what low psychological safety and quietly accumulating risk both look like from the outside
When responding to an escalation, separately note whether the underlying condition that produced it was visible beforehand, and if so, why it wasn't addressed before it escalated — this converts each incident into information about the attention-allocation pattern itself, not just about the specific issue
Distinguish urgency from importance explicitly when deciding where attention goes this week, because the two are only weakly correlated and the whole failure mode described here is substituting the first for the second by default
What this means for an engineer trying to be heard by a stretched manager
If you're on the quiet end of this allocation, the fix isn't necessarily escalating louder — that just moves you into the reactive category the manager is already over-indexed on, at the cost of whatever credibility comes from being someone who doesn't normally do that. The more durable fix is making the quiet risk itself briefly loud enough to register once, in a form specific and time-bound enough that it earns a scheduled slot rather than demanding constant escalation to stay visible: a short, dated note describing the risk and its likely timeline, rather than a recurring complaint that blends into the background noise the manager has already learned to deprioritize.
A worked example: two team members, one quarter
Consider a manager overseeing two senior engineers on the same team over one quarter. The first hits a blocking dependency roughly every two weeks, escalates promptly and clearly each time, and gets a fast, engaged response each time — the manager genuinely enjoys unblocking well-articulated problems, and this engineer is good at articulating them. The second rarely escalates anything, works through ambiguity quietly, and mentions in a one-on-one, almost in passing, that a service they own has been getting harder to change safely for a few months. The comment doesn't land as an escalation, because it isn't framed as one, and the manager's attention, already allocated to the first engineer's more frequent and more legible asks, moves on to the next agenda item.
Three months later, the second engineer's service has an outage traceable directly to the accumulated difficulty they mentioned in passing. The postmortem, following the pattern Cook describes, focuses on the specific code change that triggered the incident — a single, nameable cause — rather than on the quarter of quietly growing risk that made the system fragile enough for that change to matter. The manager, reviewing the postmortem, is surprised. They shouldn't be: the information was raised, once, in the correct room, and simply lost the competition for attention against a louder, more frequent, better-articulated signal from someone else on the same team. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
Escalating engineer | Quiet engineer | |
|---|---|---|
Frequency of raised issues | Every ~2 weeks, clearly framed | Rarely, and informally framed |
Manager's typical response | Fast, engaged, same-day | Noted, not followed up |
Outcome after one quarter | No major incident — issues addressed as they arose | Outage traceable to the risk mentioned once and not revisited |
What the postmortem attributes it to | N/A | The immediate trigger code change, not the underlying accumulation |
This is not a case for treating every quiet engineer's comment as an emergency
The corrective here has an obvious failure mode of its own, worth naming so it doesn't get overcorrected into: a manager who starts treating every offhand comment as a potential hidden crisis will spend their scarce attention on false positives constantly, which just relocates the scarcity problem rather than solving it. The actual practice being recommended is narrower than that — a scheduled, protected check-in specifically with the parts of the team that aren't currently escalating, on a predictable cadence, rather than an escalation-detection reflex applied to every sentence. The distinction matters: one is a fixed, bounded allocation of attention that doesn't compete with the reactive share on a given day. The other is an unbounded expansion of what counts as urgent, which just produces a different, equally unsustainable version of the same imbalance.
The honest limit here
This isn't a claim that every manager who seems reactive is failing, or that a perfectly proactive allocation of attention is achievable at scale. Some weeks are genuinely dominated by real emergencies that deserve the attention they get, and a manager overseeing a large enough team faces a harder version of the same contention that no amount of discipline fully solves — there is only so much attention, and some of it is always going to be spent on whatever is loudest, because sometimes the loudest thing really is the most important thing. What's worth tracking, on both sides of this relationship, isn't whether attention is ever reactive — it always partly will be — but whether the reactive share is trending toward the whole, which is the specific pattern that predicts the next incident nobody saw coming.
The practical version of the scheduled check-in is deliberately unglamorous: a recurring calendar block, once every few weeks, for each team member who hasn't raised anything recently, with a single open question — anything that's been getting harder that you haven't mentioned yet? Most of the time the answer is genuinely nothing. The value isn't in catching a problem every time. It's in the rare times the answer isn't nothing, which is exactly the information that would otherwise have stayed silent until it stopped being quiet on its own. There is a longer treatment of AI search, GEO and discovery in XenGrowth on AI search, GEO and discovery.
The uncomfortable summary for anyone managing a team is that the loudest week doesn't need this argument — the loudest problem was always going to get attention. The argument matters for the ordinary week, the one with no visible emergency, when it's easiest to believe attention is being spent fairly simply because nothing is currently on fire.
That's also why this pattern is so hard to notice from inside it. A manager reviewing their own week rarely sees an allocation problem — they see a series of individually reasonable decisions, each one the obviously correct call given what was in front of them at the time. The pattern only becomes visible in aggregate, over a quarter, which is exactly the timescale most managers never step back far enough to actually look at.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
Working on engineering management inside a commercial team? XenGrowth's growth operations team publishes operator guides on the revenue side of this work.
Five questions on the mechanism behind how a manager's limited attention gets allocated under normal pressure.
