Engineering Velocity Assessment: The Free Three-Layer Diagnostic
Three tests you can run this week to find out why your team ships slowly, and which layer to fix before you hire anybody.
The Clarity Stack
Work top to bottom. The highest broken layer is the one you fix first.
An engineering velocity assessment is a structured diagnosis of why a team ships slowly, run across three layers of clarity rather than capacity. This free version takes about 20 minutes per test and names the single layer to fix first.
Most stalled engineering orgs go looking for a hiring problem. They find one, because there is always a req open somewhere. The req is real. The bottleneck is not. The real bottleneck usually sits a layer above the work, inside an operating system the leadership team believes it is running but has never written down, which is why the org keeps trying to solve a definition problem with headcount it does not need yet.
This assessment finds that layer in a week. No consultant. No dashboard. No new tool. Then it tells you whether what you are looking at is a process fix or an open seat, which is the question our engineering staffing team gets asked more than any other.
The framework is the Clarity Stack, built by Kris Drouet across 25 years of engineering leadership, most of it in regulated industries where one bad quarter eventually lands on somebody’s compliance report. The pattern repeated. He wrote it down because he kept getting hired to fix codebases that were not the problem.
That is not just a recruiter’s opinion. Stanford GSB’s research on management practice and productivity found that structured management practice accounts for a large share of the output spread between firms running comparable technology in the same market. The operating system is the variable.
Velocity Is Shipped Work, Not Closed Tickets
Velocity is how often a working change reaches a customer who pays you. It is not story points. A team can burn down 80 points a sprint and ship nothing anybody can use, and plenty of them do it quarter after quarter while the burndown chart climbs and the roadmap slips another six weeks.
The four numbers worth tracking come out of the DORA research program at Google. Cycle time, deployment frequency, change failure rate, mean time to restore. Four numbers. If a leader cannot say roughly where the team sits on all four, that gap is already a finding, because a team whose delivery you cannot describe numerically is a team you are managing on vibes.
Those four tell you that you are slow. Not why. That is what the three tests below are for. Each one produces a number you can count instead of a feeling you can argue about, and the counting is the whole trick. For the wider picture on what changed industry-wide, our 2026 engineering velocity benchmark report pulls nine primary datasets into one place.
Run These Three Tests
Work top to bottom. Layer 1, then Layer 2, then Layer 3. Order matters. Fixing Layer 3 while Layer 1 is still broken buys you beautifully documented decisions about the wrong things.
One check before you begin. If the team has been running at surge pace for months, you are diagnosing a capacity problem rather than a clarity problem, and these three tests will point you the wrong way. Sort that out first using the slow versus tired diagnostic.
Nobody agrees on what done looks like
- Ask
- Pull six engineers aside one at a time, never as a group. Ask each one what success on this quarter’s biggest initiative looks like. Write the answers down word for word.
- Count
- Distinct finish lines.
- Broken at
- 4 or more
What your count means
One or two answers and Layer 1 is healthy. Move down.
Four or more and you do not have a hiring problem, you have a definition problem, and the tell is that every leader involved is certain the target was already communicated. It was. Once. On a Zoom call in February. Repeatability is the bar, not utterance, and if the team cannot say the goal back without looking it up then the goal is not set.
Priorities live in hallway conversations
- Ask
- Inventory every artifact somebody on the team would point to as the source of priorities. Repo markdown files, Notion pages, recurring meetings, Slack channels, your own head.
- Count
- Sources of truth.
- Broken at
- 2 or more
What your count means
Two is already broken. If three artifacts disagree, none of them is a source. They are all opinions.
Kris walked into a fintech running six prioritization systems side by side, one of which was a Slack channel called #prios where the newest message won. Engineers read that situation faster than leadership ever does. They always do. They learn to build whatever the loudest stakeholder asked for last, because they have watched what happens to the teammate who shipped the documented work and got questioned for missing an unwritten request nobody copied them on. That is the moment the documented system becomes theater. The hallway-decision problem is the long version of this failure.
Decisions get made, then evaporate
- Ask
- Pick one architecture choice from the last year that surprised somebody. Ask three engineers to explain how it got decided and which alternatives lost.
- Count
- Engineers who can answer both halves.
- Broken at
- Fewer than 2
What your count means
Zero or one and Layer 3 is broken.
Nobody remembers why the order pipeline runs on Kafka instead of SQS. The person who made the call left in January. So the team quietly rebuilds as though the decision never happened, which is how a six-month replatform becomes an eighteen-month one. Kris calls the end state load-bearing spaghetti. Nobody planned it that way. It just grew until everything was holding everything else up and now nobody wants to touch it.
Most orgs fail two of the three. That is expected. Fix the shallowest broken layer first, then re-run the deeper tests six weeks later. A surprising share of what reads as a Layer 3 documentation failure turns out to have been Layer 1 confusion wearing a technical costume, which is the single most expensive misdiagnosis on this page.
How Long Each Fix Actually Takes
The work is rhetorical. Trajectory changes inside a sprint or two.
A habit change for leadership. Old systems do not die quietly.
You will feel this one working months before you can measure it.
Trailing 12-month average, with 92% retention at the one-year mark.
Remediation windows are Kris Drouet’s, drawn from a decade of Clarity Stack diagnoses. Time-to-hire and retention are KORE1’s own placement numbers.
One Move Per Layer
Every article like this one drifts into culture and ownership and psychological safety. All real, none of it gives a working VP something to do differently on Monday. So here are three things you can do on Monday. Start there.
Say the quarter out loud
Write the quarter’s goal in one sentence and read it aloud at every leadership meeting for six weeks.
Kill four of five systems
Keep one tool, then end every priority meeting with a one-line update written into it in front of the room.
No merge without a record
Block any architecture change from merging without a short decision record naming the options you rejected and why.
Two Broken Layers Is the Normal Result
Almost nobody fails one test. Most orgs have a primary broken layer and a secondary one, and the reason sequencing matters is that the fixes interact. Order is the whole game.
A team without a shared definition of done will generate priority churn, because there is no agreed finish line to protect the sprint from the loudest request of the week. Fix Layer 1 and some of the Layer 2 noise disappears on its own. Run it the other way around and you will spend a quarter building a beautiful single source of truth, then discover it is pointed at a finish line half the team never agreed to in the first place.
Re-run the deeper tests six weeks after the shallower fix lands. Same questions. Count again. The counts move before the mood does, which is exactly why counting beats asking people whether things feel better.
When the Answer Is a Hire, Not a Process
One hiring mistake compounds all three layers at once. Promoting your strongest IC into management with no transition plan. That is it.
She misses the work. She resents the calendar. Around month nine she gives notice, and a senior engineer follows her out the door because the team trusted her judgment more than it trusted the leadership team’s, which leaves you down two of your best people in a market that was hard to hire in last quarter and is harder this one.
Both real paths work. Build means training a senior engineer into leadership over 18 months with a coach and an honest way back into IC work if the role does not fit. Buy means hiring somebody who has held the seat before and pairing them with enough internal context, a named sponsor and a real 90-day plan that they do not spend their first quarter guessing at how decisions get made here. The lazy default, promote and hope, is the only version that reliably fails.
KORE1 places engineering leaders down both paths through direct hire searches and fractional and interim VP of engineering engagements, and we fill engineering manager seats when the gap sits one layer below that. If your org runs under audit pressure, the tradeoffs shift again, which engineering leadership in regulated industries covers in detail.
Common Questions
What does an engineering velocity assessment actually measure?
It measures clarity, not capacity, across three layers, definition of done, where priorities live, and whether architecture decisions get written down. Output metrics like cycle time and deployment frequency tell you that a team is slow. These three tests tell you why, which is the part you can act on.
How long does the assessment take to run?
About 20 minutes per test, or one working week if you run all three properly and give people room to answer honestly. Layer 1 is six short one-on-one conversations. Layer 2 is an inventory you can build in an afternoon. Layer 3 is three conversations about a single past decision. Nobody needs to block a quarter for this.
Do I need a dashboard or a vendor tool to do this?
No. Every test here is a conversation and a count, run with a notepad. A developer productivity dashboard earns its keep later, once you know which layer is broken and want to watch it move, but buying one first is how organizations spend six months instrumenting a problem they have not named yet.
What if two layers look broken at the same time?
That is the normal result, not an edge case. Most stuck orgs carry a primary broken layer and a secondary one. Fix the shallower layer first, then re-run the deeper tests six weeks later. A good share of what looks like a Layer 3 documentation failure turns out to have been Layer 1 confusion the whole time.
How do I tell a clarity problem from real technical debt?
Ask three engineers to name the single biggest blocker on the team. Two pointing at the same file means technical debt. Three pointing at three different things means clarity. Real debt is local and reproducible, so engineers can demo it, show you the workaround, and tell you roughly what it costs them every sprint. Clarity problems are diffuse. Everything is hard and nobody agrees on which thing is hardest.
When does a broken layer mean we need to hire?
When the layer stays broken after the process fix has been given a fair run, the gap is usually a person rather than a policy. Layer 1 that will not hold after two quarters of trying often means nobody in the room owns scope decisions with real authority. Layer 3 that keeps regressing usually means no staff-plus engineer has the standing to block a merge. Those are hiring problems wearing process clothes, and they are the ones we get called about. McKinsey’s developer velocity research describes the same pattern in different language.
Ran the Tests? Bring Us the Verdict.
If the assessment pointed at a seat you have not filled, that part is ours. Tell us which layer came back broken and we will tell you whether it reads as a search or a coaching problem, in writing, before you commit to anything.
