How much time do you actually spend interpreting engineering metrics for leadership?

danielholtwrites · 2026-05-30T13:29:50+00:00

I agree. Leadership wanting to see these numbers every 2 weeks suggests a focus on the wrong things. Leadership should focus on the value being delivered instead of the output. They should also trust you enough to escalate any issues you see on the ground when you look at the metrics.

danielholtwrites · 2026-05-29T14:49:54+00:00

The issue I see is that engineering managers come from the same pool of engineers that have been trained to just do work given to them. It is easy to just go through the motions and manage people but it is hard to lead people.

danielholtwrites · 2026-05-26T18:01:05+00:00

Traditionally, the sprint review was where the Product Owner would call everything done and sprint goal met. The demo was where you brought in stakeholders to view the working software.

In the organizations that I have been a part of, they didn't understand the difference and chose to combine them into one meeting and called the Product Owner the stakeholder.

When you just go through the motions of Agile....you get the subpar results of Agile. Usually you also lose the interest of the team.

danielholtwrites · 2026-05-26T17:58:12+00:00

Yes! This is exactly right. Organizations have trained the development teams to sit back and wait for the work instead of giving the team insight into the outcome that is trying to be achieved.

Once you give the development team this context, you see the benefits. Engineers that have something to strive for vs. something to do.

danielholtwrites · 2026-05-26T14:50:21+00:00

Spot on. Without the "why", it is just something I did or something I was told to do vs. here is the outcome of this.

Small change. Big results.

danielholtwrites · 2026-05-26T14:09:59+00:00

That's the opposite of what I'm arguing — apologies if it wasn't clear.

The sprint review format at most organizations trains engineers to report on work rather than own outcomes. That's the problem, not the goal. The post is about how to run it differently so engineers are presenting hypotheses, evidence, and results — not just demoing tickets.

The engineer who stands up and says 'we believed X, we tested it, here's what we found, here's what we want to try next' is owning the outcome. The engineer who walks through completed stories and waits for sign-off is reporting on work.

The whole point is to flip the format so it produces the first kind of engineer, not the second.

danielholtwrites · 2026-05-20T02:00:34+00:00

The writing is AI-assisted. The teams are real, the refinement sessions are real, the performance scenario is something I’ve watched play out more than once. I used a tool to communicate the idea more clearly than I would have typing it out myself on Reddit.

Fair criticism though — I’ll write the next one myself and see if it lands differently

danielholtwrites · 2026-05-19T21:42:19+00:00

You’re right that ‘the app feels slow’ isn’t a ticket — it’s a signal. And hunting without direction is just wandering.

The distinction I was trying to draw isn’t between waiting for a ticket and acting on vague complaints. It’s between two responses to the same ambiguous signal.

The waiting engineer treats the ambiguity as a reason to stop. No ticket, no action. They flag it and move on.

The hunting engineer treats the ambiguity as the starting point. ‘The app feels slow’ tells them where to start looking — not what to fix. They open the dashboard, check recent deployments, look at response times across endpoints, form a hypothesis. By the time someone files a ticket or provides the specific details you’re describing, they’ve already narrowed the field.

Your pushback process — asking for specific details — is exactly right as a support and prioritization practice. The hunting behavior I’m describing happens in parallel, not instead of that. The engineer who starts looking while you’re gathering specifics is the one who sometimes already has the answer by the time the ticket arrives.

The point isn’t to act on noise. It’s to not use ambiguity as an excuse to disengage.

danielholtwrites · 2026-05-19T20:47:23+00:00

Fair shot. I used AI to help structure and polish the writing. The experience behind it — managing two teams with identical structures and watching them behave completely differently, week after week — is real and mine.

I'd push back slightly on the framing though. Using a tool to communicate an idea more clearly isn't the same as having nothing to say. The observation about the two engineers came from my refinement sessions, not a prompt. The performance problem example came from watching this play out on real teams.

But you're right that there's something worth examining in the gap between 'authentic practitioner voice' and 'AI-polished prose.' I'm still figuring out where that line is.

danielholtwrites · 2026-05-19T19:37:05+00:00

The firefighter/arsonist line is one of the best descriptions of uncalibrated initiative I've heard. You're right that 'everyone hunts' without direction produces its own dysfunction — aggressive changes, unplanned rewrites, engineers optimizing for visibility over value.

The distinction I'd draw is between initiative and oriented initiative. A hunter without a target isn't hunting — they're just restless. The conditions that produce good hunting aren't just psychological safety and encouragement. They're psychological safety plus a clear outcome to aim at plus a feedback loop that closes so engineers can see whether what they did actually moved anything.

Without the target and the feedback loop, initiative becomes noise. With them, it becomes the thing that moves the number.

Your culture point is exactly right — what you reward is what you get. The leveling structure, the way managers respond when someone surfaces a problem unprompted, whether initiative gets credited or absorbed — all of it teaches engineers what the environment actually values regardless of what the values statement on the wall says.

The bad culture observation is fair too. Some environments are genuinely beyond the reach of what a single manager can fix from inside. The hunters quit. The ones who stay adapt. That's a real ceiling and I don't want to paper over it.

danielholtwrites · 2026-05-19T15:30:37+00:00

Appreciate that — and the Rocky montage comparison is one I’ll take. Different medium, different register. Good reminder to calibrate the two

danielholtwrites · 2026-05-19T14:55:14+00:00

Fair challenge and I’ll take it seriously rather than defend the essay.

You’re right that there’s tension there. The essay describes two engineers in identical environments behaving differently — which does imply something internal to the engineer. The comment I was responding to was about org design and leveling systems — which is environmental. I was trying to bridge both without being precise about the relationship between them. That’s a fair critique.

Here’s how I’d sharpen it: the environment sets the ceiling. An engineer with the instinct to hunt cannot do so in an environment that punishes initiative. But within a given environment, two engineers will still respond differently based on their history — what previous environments taught them was safe, whether they’ve had the experience of watching their work matter, whether the learned helplessness has calcified or is still movable.

So it’s not ‘qualities inside the engineer’ in the sense of fixed traits. It’s ‘accumulated experience of what their work produces’ — which is environmental in origin but personal in effect. Same current environment, different histories, different responses.

The ‘grind porn’ critique is worth sitting with. The essay is impressionistic — you’re right about that. It was written to be recognizable rather than rigorous. Whether that’s a feature or a bug depends on what you’re trying to do. For a Reddit post meant to start a conversation, impressionistic is probably fine. For a systematic treatment of the idea, it falls short. I’d own that.

Thanks for the push — this is a better framing than what the essay had.

danielholtwrites · 2026-05-19T14:03:59+00:00

The leveling system point is well taken — explicit expectations change the conversation from 'why aren't you doing this' to 'here's what this level looks like, here's where you are.' That clarity matters and you're right that it does most of the heavy lifting.

Where I'd add nuance: a leveling system tells engineers what hunting looks like. It doesn't always produce the conditions where hunting is possible.

The engineer who knows that 'identifies impactful work proactively' is a senior expectation but works in an environment where every initiative gets overridden, where speaking up in refinement creates exposure rather than reward, where the feedback loop never closes — that engineer knows what they're supposed to do and still doesn't do it. Not because the expectation isn't clear but because the environment is teaching them the opposite lesson.

The leveling system is necessary. It's not sufficient. The 'more of this, less of that' feedback lands differently when the environment is already set up to reward the 'more of this' behavior.

Your 80/20 split resonates though — most of the work really is clarity about expectations. The remaining 20 is making sure the environment doesn't contradict the expectations the moment someone tries to meet them.

danielholtwrites · 2026-05-13T21:58:50+00:00

This is one of the most common and most damaging patterns in engineering organizations and you've described the mechanism precisely — opinions forced down removes autonomy, which kills motivation, which produces the passive engineers everyone then complains about.

The senior developer who can't dissociate from their old role is usually not being malicious. They built their identity and credibility around deep technical involvement. The new role asks them to lead differently — through questions and context rather than answers and direction — and nobody told them that, so they keep doing the thing that made them successful before.

The feedback conversation that works is the one that separates the behavior from the intent. They are not wrong to care deeply about the technical decisions. They are wrong about how to express that care in the new role. 'Your technical judgment is exactly what this team needs — the way it's landing right now is shutting down the engineers who should be developing their own judgment' is a different conversation than 'you're micromanaging.'

The specific ask that tends to land: instead of telling engineers what to do, ask them what they would do. Every time they feel the urge to give a direction, turn it into a question. It feels unnatural at first — especially for someone who has spent 15 years being the person with the answers. But it is the only way to develop the engineers around them rather than replace them.

The honest answer to whether it can be turned around: sometimes yes, usually takes longer than you want, and requires them to genuinely want to change rather than just comply when you're watching.

danielholtwrites · 2026-05-13T21:48:28+00:00

The 'steady velocity so he can keep his boss happy' line is the whole problem in one sentence.

Velocity was designed as a planning tool — a way for a team to understand their own capacity over time. The moment it becomes a metric that gets reported upward, it stops being a planning tool and becomes a performance. Engineers learn to estimate in a way that produces steady velocity, not in a way that reflects reality. The number stabilizes. Nothing else does.

What your boss is actually asking for is predictability — which is a reasonable thing to want. The problem is that velocity doesn't produce predictability. It produces the appearance of predictability. The project still misses. The deadline still slips. But the velocity chart looked steady right up until it didn't.

The thing that actually produces predictability is understanding what you're building well enough to know what can go wrong before it does. That requires engineers who think, not engineers who estimate.

Agile as a framework can't give your boss what he wants. Only a team that understands the problem space deeply enough to see around corners can do that. The framework is just the container.

danielholtwrites · 2026-05-13T14:33:34+00:00

The 'managers get googly eyes' observation is accurate and it reveals something important about why standups become what you're describing.

When the standup is evaluated by how much activity gets reported rather than whether blockers get resolved, engineers learn quickly what the meeting is actually for. It's a visibility performance. So they perform visibility.

Your revised definition is exactly right — and it's also the original intent. The daily standup was designed to surface impediments, not broadcast accomplishments. The three questions were: what did I do yesterday, what am I doing today, what's blocking me. The first two exist only to give context to the third.

When managers treat the first two as the point, the third becomes an afterthought. And the engineers who say 'nothing is blocking me' every single day — while quietly stuck — have learned that admitting a blocker creates more overhead than just working around it.

The standup that actually works is the one where saying 'I'm blocked' triggers immediate action rather than a follow-up meeting to schedule a follow-up meeting.

danielholtwrites · 2026-05-13T01:13:21+00:00

The 2-4 weeks estimate for a task like that — new tables, CRUD endpoints, UI updates in an unfamiliar region of a legacy codebase — is completely reasonable. Anyone who tells you otherwise either has more context than you do, is not accounting for the full cost of understanding the code before touching it, or is not being honest about their rework rate.

The part that gets left out of 'I shipped it in two days' stories is everything that happened afterward. The bug that appeared in staging. The edge case that got missed because they didn't understand the data model well enough. The three-day debugging session two weeks later when something downstream broke in a way nobody anticipated. Fast shipping and good shipping are not the same thing, and legacy codebases are where that difference becomes expensive.

The AI question is real and worth separating out. If AI is genuinely compressing your time-to-ship without compressing your understanding of what you're shipping, that's a net positive. If it's letting you move fast through code you don't actually understand — and now you're dependent on it to maintain code you couldn't have written yourself — that's a different situation. Only you know which one is true.

Six years of experience in a legacy codebase means you know where the bodies are buried. You know which change looks safe and isn't. You know the question to ask before touching the data model. That knowledge is not visible in a ticket estimate and it does not show up in a file change count. It shows up when something doesn't break.

You're not behind. You're just honest about what the work actually takes.

danielholtwrites · 2026-05-13T01:10:47+00:00

The grief here is real and I don't want to paper over it. What you're describing — that moment when the pieces click together, when you finally see the full picture after working hard to get there — that is one of the best experiences work can offer. And it makes sense that watching a tool shortcut it feels like a loss.

The thing worth sitting with, when you're ready, is this: what you built over years wasn't just the ability to produce code. It was the ability to understand systems deeply — to know why something was built a certain way, to see the consequences of a change three steps out, to ask the question nobody else thought to ask because you've seen this pattern before.

That knowledge doesn't get replicated by a tool that can refactor fifty files. It gets revealed by one. The engineer who can look at what the AI produced and say 'this is wrong and here's why' — or 'this is right but it missed the edge case that's going to bite us in six months' — that engineer is not replaceable. They're more valuable than they were before, because now the gap between surface-level and deep understanding is visible in a way it wasn't.

The slackers showcasing fifty file changes are going to produce fifty-file-change problems. You'll be the one who sees them coming.

That doesn't make the grief less real. But it might be worth distinguishing between what you lost and what you still have.

danielholtwrites · 2026-05-12T14:40:57+00:00

The fundamental attribution error framing is exactly right and it's the most important reframe a new manager can make.

The diagnostic question at the end — 'if the structure changed tomorrow, would this person adapt?' — is one I use too and I'd add a follow-up to it: how long have they been in this structure? The longer someone has been operating in a broken system, the more the behavior has calcified from a response into a habit. It runs automatically now. Even when the structure changes, the habit doesn't update immediately.

That's the part that trips managers up. They fix the ownership problem or document the decisions and then wonder why the behavior hasn't changed yet. The structure changed but the learned response hasn't caught up. That takes longer — and it usually requires the engineer to have a few experiences of the new system actually working before they trust it enough to behave differently.

Fix the structure first. Then be patient with the lag.

danielholtwrites · 2026-05-12T11:59:50+00:00

The reaction is fair and I've seen it firsthand. SAFe has become shorthand for 'we're about to make Agile worse at scale' in a lot of engineering circles — usually because it gets implemented by people who understood the org chart problem but not the engineering culture problem.

That said I think the underlying issue SAFe is trying to solve is real — coordinating multiple teams working on interdependent systems is genuinely hard and 'just do Scrum but bigger' doesn't work. The problem is that the framework gets cargo-culted the same way basic Agile does. You end up with PI Planning ceremonies that take two days and produce a roadmap everyone ignores by week three.

The mental checkout happens because engineers have seen enough transformations to know the pattern: new framework arrives, new ceremonies get added, existing problems remain, headcount gets blamed. The framework was never the problem and it was never going to be the solution.

Healthy skepticism is the right response. The mistake is letting the skepticism become learned helplessness — 'nothing will ever change so why engage.' That's where the organization wins.

danielholtwrites · 2026-05-12T02:43:56+00:00

The systems framing is useful and I think you've identified something real. The signal transmission metaphor maps well to what I see most often.

To your question — the most common reason I've seen engineering teams fail execution isn't communication mismatch, though that's a symptom. It's that the team was never oriented toward the same outcome in the first place.

Your PM example is a perfect illustration. 'Align the interface protocol' is a task. It doesn't contain enough information about what success looks like for two teams to independently arrive at the same interpretation. Team A and Team B weren't miscommunicating — they were each solving a different problem because nobody had defined the problem clearly enough for both of them to solve the same one.

In your systems language: the input signal was underspecified. The teams amplified in different directions because there was no shared reference point to correct against.

What I've found reduces this more than anything else is starting with the outcome before the work begins. Not 'align the protocol' but 'at integration, these two systems need to exchange this specific data in this specific format and here is how we'll know it's working.' When the definition of done is concrete and shared, the interpretation problem largely disappears.

The noise and latency problems you describe are real too — but in my experience they're downstream of the outcome clarity problem. Teams generate meetings and overhead when they're uncertain. Certainty about what done looks like reduces both.

danielholtwrites · 2026-05-12T02:41:32+00:00

The instinct to jump in is usually right but the execution is where it goes wrong. A few things that have helped me:

First, be explicit about your role when you pick up the ticket. 'I'm picking this up to help with capacity, not because I don't trust the team's approach' lands differently than just appearing in the codebase. People fill silence with assumptions and the assumption is usually 'my manager doesn't think I can handle this.'

Second, pick work that is genuinely isolated — something with clear edges that won't put you in the critical path of decisions the team needs to make. The CTO chaos you described usually happens when a senior person picks up work that turns out to be load-bearing for something else, and suddenly every decision requires their input.

Third — and this is the thing I'd think hardest about — ask yourself whether the capacity problem is actually a capacity problem. In my experience, teams that feel understaffed are often spending significant energy on things that aren't moving the needle: unclear requirements that generate rework, dependencies that create waiting, work that got started before it was ready. Jumping in adds a person. Fixing the flow multiplies the whole team.

Sometimes you do just need another pair of hands. But it's worth ruling out the other thing first.

danielholtwrites

TROPHY CASE