Jessica McKellar co-founded Zulip with a group of MIT friends in 2012. Eighteen months later, Dropbox acquired it. It wasn’t her first exit either. She’d sold Ksplice to Oracle on a similar timeline. Asked what she credited the pattern to, her answer was engineering management done right: supporting the people on the team directly, coordinating execution across teams, and stepping back often enough to see how the broader process was actually working.

That combination, support plus visibility plus the discipline to step back, is what proactive engineering management looks like in practice. It isn’t a personality trait. It’s a habit built on data: the best way to be proactive is to use data well, and using data well requires enough proactivity to set up the tracking in the first place. The two reinforce each other.

What proactive engineering management actually looks like

A reactive engineering manager spends most of the week putting out fires: one broken build, one cross-team miscommunication, one escalation after another. A proactive one spots the pattern that causes the fire before it starts. That requires a curious mindset, a way to see what’s actually happening across the team, and enough lead time to act on what you see.

When developers can see that patterns get caught and addressed instead of ignored until they explode, they trust the process more.

Done well, proactive management doesn’t just clear up efficiency and delivery problems, it builds that trust, and trust is most of what a healthy engineering culture is built on.

Where DORA metrics fit in

Delivery performance is a genuine competitive edge, and proactive engineering management is largely the practice of pursuing it deliberately instead of by accident. DORA metrics are the standard starting point for measuring that:

• Lead time for changes (LTTC) — the time between the first commit and the moment code is released
• Deployment frequency (DF) — how often a team releases code
• Mean time to recovery (MTTR) — how fast a team recovers from a failed release
• Change failure rate (CFR) — the percentage of releases that lead to failures

Source: Google Cloud

Tracking DORA metrics early lets you drill into the specific, common issues that quietly extend lead time or interrupt deployment frequency, low reviewer availability, hard-to-follow code, a bloated pre-deploy test suite, before they compound. Pairing DORA with cycle time tracking gives you the detail behind the summary number: exactly which stage is where time is actually going.

Short-term gains: fixing what’s in front of you

Proactive management is easiest to see in its short-term wins, the everyday friction points that either get fixed early or quietly erode a team’s output for months.

Immediate workflow improvements

Through observing engineering teams over time, we’ve identified nine recurring workflow patterns worth watching for as coaching moments:

• 01Bit fiddling
• 02Pinpoint commits
• 03Code and clean
• 04Domain expertise
• 05Code hoarding
• 06Hero engineering
• 07High churn
• 08Overhelping
• 09Zoning in

The Engineering Leader’s Handbook covers each of these in detail, along with how to address them. Here’s a look at the first.

Bit fiddling happens when an engineer stays focused on one narrow area of the codebase far longer than the work justifies, making small, largely meaningless changes with little real progress. A quick look at the Developer Summary, now part of the broader Contributor Insights view, will often surface this as an unusually high churn rate: the same code being rewritten repeatedly without moving forward. Cross-referencing that against Review Collaboration data, part of Pull Request Insights today, shows whether the same commits are also stalling in review.

That connects directly to lead time. Code can stall in the pipeline for a few common reasons: too few available reviewers, code that’s hard to follow, or a long chain of required tests before deploy. One useful early metric here is PR flow ratio: PRs opened in a day divided by PRs closed. A ratio that keeps climbing tells you PRs are piling up faster than they’re resolving, which usually means declining reviewer responsiveness or motivation, and it’s a concrete signal to investigate before lead time balloons on its own.

Identifying coaching opportunities faster

Coaching only works when it’s grounded in both someone’s working patterns and the results those patterns produced. Seeing that a developer works fast, or spotting churn and risky commits late in a cycle (a pattern we call hero engineering), isn’t enough on its own. The useful step is connecting the pattern to the outcome.

Take hero engineering itself: one engineer consistently fixes everyone else’s work right before a release. It looks like a strength, and the engineer clearly is skilled, but the net effect on the team is often negative. Other strong engineers start to feel like their work isn’t trusted to stand on its own, which quietly erodes both morale and their own growth.

• Check who tops the “Help Others” metric in Team Insights (formerly Project Timeline).
• Cross-reference that against late check-ins in the individual Work-Log.
• Look for self-merged PRs late in the sprint in the Pull Request Insights workflow view, often a sign of low review engagement because there’s no time left to wait for one.
• Watch the risk metric for a spike in high-risk commits, and consider coaching the team toward smaller, more frequent commits instead.

The same instinct applies to catching good patterns, not just bad ones. Code and clean developers, who split their time between new features and paying down legacy debt, are a clear example. You can spot them through the Work-Log and confirm it against top performance in the Legacy Refactoring data point in Team Insights. Once you find them, the highest-leverage move is asking them to document how they work, so the rest of the team can adopt the same habit.

Long-term change: from daily wins to standards

Short-term wins build momentum, but they only compound into lasting change once you start using the data to set standards rather than just fix the day’s issue. Bit fiddling, PR pileups, and code-and-clean patterns aren’t isolated incidents. Each one is a small piece of evidence pointing toward how the team’s norms should evolve.

The instinct that separates reactive from proactive management is this: small patterns are where big problems start. Left unaddressed, they don’t stay small. When you use commit, push, and review-speed data to shift developer behavior or refine the review process, you’re acting on that instinct instead of waiting for it to become a bigger issue you have to react to. And once a change works for one team, the same data lets you scale it into a standard practice across the org.

Optimizing software delivery performance

None of this works from a single report in isolation. Proactive engineering managers corroborate multiple metrics, code quality, review health, and delivery velocity, into one picture, because any one of them read alone is easy to misread.

For cycle time specifically, that means watching four stages:

The same AI-era shift shows up in a few of the nine patterns above. Hero engineering increasingly looks like someone quietly cleaning up unreviewed AI output before a release, rather than someone else’s handwritten code. Bit fiddling can show up as a developer stuck in a prompt-and-regenerate loop instead of hand-editing the same function. Code hoarding might mean someone refusing to let an agent touch “their” part of the codebase at all. The underlying coaching move doesn’t change, connect the pattern to its outcome, but what the pattern looks like on the ground has shifted with the tooling.