Engineering Velocity Diagnostic for Teams That Stopped Shipping
A senior engineering leader spends two weeks inside your delivery process and hands you a written verdict. It names the constraint, and it tells you whether you’re looking at a process fix or an open seat.
An engineering velocity diagnostic is a two-week outside read of why a team ships slowly, ending in a written verdict that names the constraint and says whether the fix is a process change or a hire.
A mortgage servicer came to us last spring with two senior backend reqs and a release cadence that had slipped from every two weeks to roughly once a month. Their VP was confident about the diagnosis. Short two people. We opened both searches, because he might have been right and the market for that stack is not fast. We also asked for two weeks inside the delivery process before anybody signed an offer, and what turned up was that a director three levels into the approval path had quietly become the last gate on every production change without ever being told that was his job, so the queue behind him had grown to eleven days and nobody upstream could see it. Eleven days. Nobody charted it.
He wasn’t the problem either. Nobody had decided he was the gate. It just happened.
That’s the work this page covers. We place a senior engineering leader inside your organization for two weeks, they read the delivery process the way an outside reviewer reads it rather than the way the people running it describe it, and you get a written finding at the end. Sometimes the finding is a hire and we go fill it through our engineering staffing practice. Often it isn’t, and we say so in writing. That happens a lot.
The framework underneath belongs to Kris Drouet, who spent 25 years building and leading engineering teams in fintech and mortgage tech. He wrote the reader’s version of it in The Clarity Stack. If you’d rather run the tests yourself before you call anyone, the free three-test engineering velocity assessment is the same thinking with none of us in the room. Same framework. No invoice.
You Can Run the Tests Yourself. The Trouble Is Who Answers Them.
Every question worth asking in this diagnostic has an honest answer and a political one, and internal leaders get handed the political one for free. Ask your own engineers who slows down a release and watch the room re-price the question in real time. Every time. They’re not lying to you. They’re doing arithmetic about next quarter’s review cycle, and that arithmetic is rational. It’s also invisible to you.
An outside reader gets a different set of answers because they can’t help or hurt anybody’s career. That’s most of the value, and it’s not a flattering thing to say about how organizations work. But it’s true.
The second reason is arithmetic of a different kind. A wrong senior engineering hire in a growth-stage shop runs well past $200,000 once you count the search, the ramp, the six months before anybody admits it isn’t working, and the backfill. Two weeks of somebody reading your delivery process is a rounding error against that. Most of our clients who run this end up hiring anyway. They just hire a different role than the one they had queued up. Different title. Different level.
Three Measures, and What Each One Resolves To
These come out of your artifacts and your calendar, not out of a survey. Each one produces a number somebody can argue with, which is the point, because a number you can argue with beats a feeling nobody can. Count first.
Hours a pull request sits before a human being touches it, measured from the repo rather than from anybody’s recollection. Long waits almost never mean the reviewers are slow. They mean review is nobody’s actual job, so it happens in the gaps. Queues don’t self-clear.
Share of what a sprint committed to on Monday that actually shipped by the end of it. Under sixty percent for three sprints running and the team has learned that the plan is a suggestion, which is a much harder thing to unwind than a staffing gap. Habits outlive headcount.
How many people have to say yes before a change reaches production. Four or more usually means the path is missing an owner senior enough to end a conversation, and that gap gets filled with a seat rather than a policy. That one’s a hire.
The thresholds are ours, drawn from what we’ve watched break rather than from a benchmark anybody publishes. For the industry-wide version of the flow numbers, DORA’s research program has spent more than a decade tying delivery performance to four measures, and it’s the honest place to calibrate against. Our own 2026 engineering velocity benchmark report covers what moved industry-wide over the last year.
Week One Is Watching. Week Two Is Counting.
The first week changes nothing on purpose. Nothing gets fixed yet. Our advisor sits in your planning, your standups and your incident reviews without commenting, reads a quarter of merged pull requests, and interviews eight to twelve people one at a time. Never as a group. Group interviews produce the answer the most senior person in the room would like to hear, every time, and there’s no version of that worth paying for. So we don’t.
“The most common issue I encounter when joining a struggling engineering organization is not a technology problem. It is a clarity problem.”
Week two is where the counting happens and where the argument starts. Numbers get pulled, the three measures get scored, and the draft finding goes to whoever commissioned it before it goes to anyone else. That last part matters more than it sounds. It’s a small thing. A verdict a VP first reads in a room full of their own directors is a verdict they’ll spend the meeting defending themselves against instead of acting on.
You get the finding in writing. Paper, not a deck. Two to four pages, the counts, what we think they mean, and a disposition. If the disposition is a hire, the req is already scoped by the time we hand it over, whether that lands as contract staffing for a fixed stretch of work or a direct hire who owns the gap for good.
What KORE1 Brings if the Verdict Is a Hire
Time-to-submittal and retention are KORE1’s own placement figures, trailing twelve months. Kris Drouet’s tenure and case data are his own, and he is a real person with a bio on this site. The wider hiring picture sits with the Bureau of Labor Statistics, which still projects software developer employment growing much faster than the average occupation through 2034.
Three Things the Verdict Can Say
Roughly half of these end in the first one, which is an awkward thing for a staffing firm to publish and also the reason clients call us back. Nobody expects that.
Fix the Process, Keep Your Money
The constraint is a review policy, a planning habit, or a gate nobody assigned. We write it up, you fix it internally, and we close the reqs.
The free self-run version →A Specific Person Is Missing
Usually an owner with enough seniority to end an argument. We scope the req off the finding and run the search.
VP of Engineering Staffing →The Structure Produced This
All three measures flagged and the org chart is the cause. That’s a redesign, not a req, and it’s a different desk.
Org Design Advisory →
Four Times We’ll Send You Somewhere Else
Scoping calls go faster when the wrong fits get named early, so here are the ones we redirect most. Four of them.
If your team has been running at surge pace for two quarters, you’re looking at a capacity problem rather than a clarity problem, and these three measures will point you the wrong way. Read actually slow versus just tired first. If you already know exactly where it hurts and want the structure rebuilt rather than measured, that’s engineering org design advisory, and running the diagnostic ahead of it just adds two weeks to something you’ve already diagnosed.
When one specific person is struggling, almost always a strong engineer six months into their first management job, that’s engineering leadership transition coaching. A finding sheet won’t help. If the promotion has not happened yet, new engineering manager coaching designs the handover before anybody needs saving. And if the answer is simply that you need better engineering hiring, skip all of this and start with our engineering recruiters a fractional VP of engineering who can hold the seat while you decide, or director of engineering staffing if you already know the gap sits a level under the VP.
Kris Drouet on Why the Number Has to Come First
Kris is VP of Engineering at a mortgage technology company and a contributor here. Twenty-five years building and leading teams, nearly all of it in regulated shops where a process that only exists in somebody’s head eventually gets read back to you by an auditor who is not in a hurry. That world is its own hiring market, which is why mortgage tech and fintech engineering staffing and fractional VP of engineering for regulated industries run as separate desks here.
His position on velocity arguments is that they’re unwinnable without evidence. His rule is simple. Show me the data, then we’ll talk about headcount. He’s watched leadership teams spend an entire quarter debating whether engineering was slow, with both sides right, because one was talking about cycle time and the other was talking about roadmap slip and nobody had written down which one they meant.
One case he brings up when the finding turns out to be architectural. Critical systems tied together point to point, brittle enough that touching one broke another, what he calls load-bearing spaghetti. Decoupling it onto a Kafka pub/sub platform cut downstream processing latency by 45 percent. He mentions the latency number second. Deliberately. The part he leads with is that the team could finally estimate again, because for the first time in two years a change meant one change.
Common Questions
What is an engineering velocity diagnostic?
An engineering velocity diagnostic is a short outside engagement that measures why a team ships slowly, then delivers a written verdict naming the constraint and whether the fix is a process change or a hire.
Two weeks. Three measures. Two to four pages at the end. The written part is what separates it from a conversation. A verdict somebody can hand to a board is a different object than a consultant’s opinion delivered on a call and remembered differently by everyone who was on it.
How long does it take and what do we get?
Two weeks. Week one is observation and interviews, week two is measurement, and you receive a two-to-four-page written finding with the counts, the interpretation, and a disposition.
Interviews run eight to twelve people, always one at a time. Never in a group. If the disposition is a hire, the requisition comes scoped, which typically saves another week or two of back and forth before a search opens.
How is this different from the free engineering velocity assessment?
The free assessment is three tests you run yourself in about twenty minutes each. This one is staffed. We run it, we pull numbers from your repo and calendar rather than from recollection, and you get a written verdict instead of a self-scored result.
Plenty of leaders do the free version first and never call us, and that’s fine. It’s genuinely the intended outcome for a lot of teams. The staffed version earns its keep when the internal answer keeps changing depending on who you ask, or when a board wants a read that didn’t come from the person being evaluated. Start with the free three-test version if you’re not sure.
What does an engineering velocity diagnostic cost?
A standalone two-week diagnostic lands in the mid four figures to low five figures, priced as a scoped engagement rather than an hourly retainer, and it’s credited against the fee if it converts into a search we run.
Size drives the number. One forty-engineer group with a single product line prices very differently from three teams across two business units where the platform team reports somewhere else entirely and nobody thought to mention it on the first call. We quote after that call, never before it.
Won’t our engineers see this as a performance review?
Some will on day one. The thing that changes it is telling them plainly that no individual is named in the finding, and then keeping that promise.
Our advisor says it in the first interview and it’s true. Every measure on the sheet is about the system, not about a person. Wait time is a queue, not a slow reviewer. Scope survival is a planning habit. It’s a system read. The one time this goes badly is when leadership commissions the work and then quietly asks for names anyway, and we don’t take that engagement.
We already track DORA metrics. Do we need this?
Often not, and if your four DORA numbers are clean and trending the right way you should skip this entirely.
DORA tells you that you’re slow and roughly where. Not why. It won’t tell you whether the cause is a missing person either. Teams with good dashboards and a stalled roadmap are the ones this helps most, because the instrumentation has already ruled out the easy explanations and what’s left is organizational.
Can you run it while our searches are already open?
Yes, and that’s the most common version. We keep sourcing on the reqs you’ve already opened while the diagnostic runs, so you lose nothing if the verdict confirms the hire.
What you gain is the option to change the role before an offer goes out. About a third of the time the req that opens after the finding is a different title than the one that was open before it, most often a level up, occasionally a completely different function. Nobody has ever complained about finding that out in week two instead of month seven. Not once.
Get the Verdict Before You Get the Offer Letter Wrong
One call is usually enough to tell whether you need two weeks of measurement, a search you can open tomorrow, or nothing from us at all.
Talk to an Engineering Recruiter →