The Clarity Stack: 3 Reasons Engineering Velocity Stalls (And None of Them Are Technical)

Last updated: June 9, 2026 | By Kris Drouet, in partnership with KORE1

Twenty-five years in this field, almost all of it inside regulated industries where one bad engineering quarter eventually shows up on someone’s compliance report, has taught me one thing the new VPs I coach never want to hear first. The codebase is rarely the problem. The problem almost always sits one layer above the work, in the operating system the leadership team thinks it is running but has never actually written down.

This piece is the one I wish someone had handed me the first time I was asked to “fix” an engineering org, and KORE1 helped me put it in front of you because they keep seeing the same pattern across their engineering staffing placements at growth-stage and mid-market companies. Companies are not running out of engineers. They are running out of clarity.

What Engineering Velocity Actually Measures

Engineering velocity is the rate at which a team ships outcomes that matter to the business, not the rate at which it closes Jira tickets. Those two get confused all the time. One is throughput of value. The other is throughput of motion.

If you run a team and your gut says velocity has stalled, you usually already know. Release cadence slipped. The same problems keep coming up in retros. The CEO is asking why the roadmap takes a quarter longer than promised, and the answer keeps mutating depending on who in the room is talking. I do not need a productivity dashboard to find a stalled team. I need a calendar.

The real signal lives in the four numbers the DORA team at Google has been publishing for over a decade now, and any honest engineering leader should be able to recite where their team sits on each one before they finish their first coffee. Show me the data on cycle time, change failure rate, deployment frequency, and mean time to restore. The relationships are not subtle. Teams that ship daily fail less often and recover faster. Velocity is not how busy people look. It is how often a working change reaches a customer who pays you.

The trap is treating story points as velocity. A team that closes 80 points a sprint while shipping nothing customers can use is not fast. It is loud.

The Clarity Stack: A Three-Layer Diagnosis

The Clarity Stack is the framework I use when I parachute into an org and have two weeks to figure out why it is slow. Three layers. I work top to bottom. Every velocity problem I have diagnosed in the last decade has lived inside one of these, or two of them at once.

Layer 1: Nobody Agrees on What “Done” Looks Like

Layer 1 is the most common failure mode I see and it is almost always invisible from the outside, which is why so many CEOs assume they have a hiring problem when they actually have a definition problem. Ask three people on the team what “done” means for the current sprint and you will get four answers. The product manager thinks done is feature parity with a competitor. The tech lead thinks done is “no P0 bugs in the queue.” The CTO thinks done is the customer demo working in three weeks. The VP of Sales thinks done is whatever it takes to close the deal she has been chasing since March.

Nobody in that lineup is wrong. They are just not aligned, and a team building toward four different finish lines burns most of its weekly energy in the gap between those lines instead of moving any of them closer.

The diagnostic is simple. Pull six engineers into a room, separately, and ask each one: what does success on this quarter’s biggest initiative look like? Six different answers means you do not have an engineering problem. You have a Layer 1 problem.

What surprises me is how often the leaders running these orgs think they have communicated the target. They have, in the sense that the words were said out loud in a Zoom meeting in February. But “I said it once” is not the same as “the team can repeat it back without looking it up.” Repeatability is the bar.

Layer 2: Priorities Live in Hallway Conversations

Layer 2 is the one where engineering leaders start to feel personally implicated, because the source is usually them. Priorities get set in side conversations, in hallway hand-offs, in the impromptu Slack DM nobody else sees. The work that goes into the sprint is technically what the team agreed to. The work pulled out of the sprint mid-week is decided by whoever has the most political weight in the most recent room.

Engineers feel this immediately. They learn to do the thing the loudest stakeholder asked for, because they have watched what happens to teammates who shipped the documented work and got reprimanded for not jumping on the unwritten request that came down through a hallway hand-off they were never copied on. That is corrosive in a specific way. It teaches the team that the documented system is theater and the real work is whatever leadership remembered to ask for last, which is the same thing as telling your best engineers their judgment about what matters does not count.

The fix is not glamorous. One source of truth for priorities. Linear, Jira, a shared Notion doc, a hand-drawn list pinned to the wall. I do not care which tool. The tool is not the point. What matters is whether every engineer on the team can open one place and get the same answer their manager would give and the same answer the CEO would give if you cornered her in the hallway and asked her cold. If three sources disagree, none of them is a source. They are all opinions.

I walked into a fintech once where the engineering org was running six prioritization systems in parallel. Two were roadmap markdown files in the GitHub repo. One was a Notion page nobody updated past Q1. One was the CTO’s head. One was a recurring meeting that produced no artifacts. One was a Slack channel called #prios where the latest message won. That is a Layer 2 catastrophe and it is more common than you would think.

Layer 3: Decisions Get Made, But Never Written Down

Layer 3 is the deepest and the one that quietly compounds the most expensive technical debt over time, even though it sounds the most boring on a slide.

Architecture decisions get made in conference rooms, often well, often by smart people thinking carefully. Then nobody writes them down. Six months later a new engineer joins and asks why the order pipeline uses Kafka instead of SQS for a particular event stream, when SQS would have been one-tenth the operational overhead for the volumes they actually hit. Nobody on the team remembers. The person who made the call left in January. The team now has three options. Dig through old Slack threads. Ask the founder. Or quietly rebuild the system as if the original decision had never been made, which is the option that runs most often by default and the one that turns a six-month replatform into an eighteen-month one. They will pick whichever feels safest, and that choice will set the next two years of the codebase.

Here is how I describe this to executives who think it is a bureaucracy problem. Every time we touch something, something else breaks. It is like load-bearing spaghetti. Nobody planned it this way. It just grew until everything was holding everything else up, and now nobody wants to touch it. That is what happens to systems whose decisions evaporated.

The fix is unsexy and durable. Architecture Decision Records. ADRs. A folder in the repo, short markdown files, one per significant call. Context, options considered, choice, consequences. Ten minutes to write. Saves entire engineering quarters down the road. I have yet to convince anyone to do this enthusiastically. I have also never seen a team regret starting.

How to Diagnose Which Layer Is Broken

Most stuck orgs have a primary broken layer and a secondary one. Diagnosing the primary one matters because the fixes are different and the order matters. Fixing Layer 3 while Layer 1 is still broken just produces beautifully documented decisions about the wrong things.

You can run this diagnostic in a week. You do not need a consultant. You need to be willing to hear answers you do not love.

What the Fix Actually Looks Like

This is where most articles like this lose me. The advice drifts into platitudes about culture and ownership and psychological safety, all of which are real, none of which give a working VP something to do on Monday morning that is different from what she did on Friday. So here are the specific moves I have seen work, in the order I usually run them.

Layer 1 fix. Write the quarter’s goal in one sentence. Read it out loud at the start of every weekly leadership meeting for six weeks. If three weeks in you cannot say it from memory, the sentence is wrong, rewrite it. Then teach every engineering manager to do the same with their own team. The thing the team can repeat back is the thing they can ship toward.

Layer 2 is harder because it asks leaders to give something up. Kill four of your five prioritization systems. Pick one tool. Make every meeting that produces a priority end with a one-line update to that tool, written in front of the room, before anyone leaves. The discipline is the move. The tool is incidental.

Layer 3 is the unsexy one. I already wrote up ADRs above so I will not repeat the whole thing. Make it a rule that no architectural change merges without one. Keep them short. Keep them honest. Include the options you rejected and why.

One myth I want to debunk before I close. The best engineering leaders eventually stop being technical. No. That is the most expensive lie in our industry. The leaders I have watched lose their orgs were the ones who stopped reading code, stopped touching the build, stopped asking “what does that actually mean in the database.” If you cannot follow your team into the work, you cannot tell when they are bluffing, and they will learn that you cannot. The Clarity Stack works only if the leader applying it can also pop the hood on the code itself. The leader who advises without ever building again is the one whose team eventually moves past them. McKinsey’s developer velocity research describes the same pattern in different language. The leaders who stay close to the craft outperform the ones who move on from it.

The Hiring Mistake That Compounds All Three Layers

I cannot write a piece about engineering velocity without naming the hiring mistake that quietly compounds all three Clarity Stack failures at once. Here it is. Promoting your best IC into management without a real transition plan. She misses the work. She resents the calendar. Around month nine she gives notice. A senior engineer follows her out the door because the team trusted her judgment more than the leadership team’s. You are now down two of your strongest people in a market that was hard to hire in last quarter and is harder this one.

This is a build vs buy decision, and most companies get it wrong by default. The build path is to take your strongest senior engineer and train them into leadership over 18 months with a coach, with a defined safety net, with the freedom to bail back into IC work if the role does not fit. The buy path is to hire an external engineering leader who has done the role before, paired with internal context support so they do not flail their first quarter. Both work. Either one works far better than the lazy default, which is “she is our best engineer, promote her, sink or swim.”

KORE1’s direct hire staffing team places engineering leaders into both paths, and their internal numbers back the math. KORE1 reports a 17-day average time-to-hire for IT roles and 92 percent 12-month retention on placements. Those are not vanity numbers. They are the difference between a leader who lands and a leader who washes out at the nine-month mark and takes two engineers with them on the way out. If your VPE seat or staff-plus engineering bench is shaky, fix that before you spend another quarter trying to ship around it.

The Bottom Line for VPs and CTOs

If your best engineers are waiting for permission to make decisions, that is not a people problem. That is a you problem. I have said that line in keynotes to nervous executive teams and watched it land like a punch every time, because most of the people in those rooms know they are the reason their senior engineers stopped pushing back.

The Clarity Stack is not a methodology. It is a diagnostic. You are not going to install it. You are going to look at your team through it, find the layer that is broken, and fix it before you start fixing anything else. Almost every “we need to hire faster software engineers” or “we need new tooling” or “we need to rewrite the platform” conversation I get pulled into is, at the root, a Clarity Stack conversation in disguise.

If you want to talk through where your org sits on the stack, connect with me on LinkedIn. If you want to talk to KORE1’s engineering hiring team directly, you can reach out here.

Questions Engineering Leaders Ask Me About This

Is engineering velocity a real metric or just leadership theater?

Real metric. The DORA team has more than a decade of evidence behind cycle time, deployment frequency, change failure rate, and mean time to restore. Show me the data on those four and I can tell you whether your org is fast.

The theater shows up when leaders measure story points or velocity-as-points instead, then point at a number that has been gently rising for three quarters in a row while shipping has not gotten any faster from the customer’s perspective. Story points are an internal accounting unit. They do not say whether a working change reached a customer. Use the DORA four. They are unfashionable enough to mean something and old enough to have survived multiple hype cycles.

How fast can a Clarity Stack diagnosis actually fix a stalled team?

Six to twelve weeks for Layer 1. One quarter for Layer 2. Twelve months for Layer 3, honestly. Anyone telling you faster is selling you something.

The Layer 1 work is rhetorical. Once a team can repeat the goal back from memory, the trajectory changes inside a sprint or two. Layer 2 is a habit change for leadership, which takes longer because old prioritization systems do not die quietly. Layer 3 is slowest because the value compounds only after enough decisions accumulate to start preventing reruns of old debates. You will feel the Layer 3 fix months before you can measure it.

What if the leadership team is the problem and they will not admit it?

Then your job is to make the diagnosis impossible to deny. Run the six-engineer interview, transcribe the answers verbatim, and read them back in the next leadership meeting.

I have done this twice. Both times the room went quiet for the better part of a minute before anyone spoke, which is the longest minute of silence you will ever experience inside an executive meeting where everyone is paid to have an answer ready. Both times the CEO heard six smart engineers describe six different finish lines and realized for the first time that the alignment problem was upstream of any individual team. You cannot argue with the raw data of your own people’s words. The most defensive leaders I have worked with still cannot argue with a transcript.

Should we build the platform internally or buy a vendor solution?

Build vs buy is rarely answered with one rule. The question is which decision creates the most expensive lock-in.

For prioritization tooling, buy. Linear, Jira, Notion are commodity. For your ADR template, build, because the format needs to match the way your team actually argues about decisions and a generic template will get ignored inside a sprint. For developer productivity dashboards, buy a baseline and only build the layer that exposes your specific business outcomes. The lazy default of “we will just build it” usually means six months of internal-tool work that two engineers end up maintaining forever instead of shipping product, and a year later nobody remembers why you stopped using the off-the-shelf option.

How do I tell a clarity problem from a real technical-debt problem?

Ask three of your engineers to name the single biggest blocker on the team. If two of them point at the same piece of code, it is technical debt. If they point at three different pieces, it is clarity.

Real technical debt is local and reproducible. Engineers can demo it. They can show you the file. They can describe the workaround they keep using and roughly how much time it costs them every sprint, which is something every engineer who has actually been burned by a piece of debt can give you within a minute of being asked. Clarity problems are diffuse. The team will tell you everything is hard but cannot agree on which thing is hardest. That is the tell. Fix the clarity layer first. Half of what you thought was tech debt will turn out to have been priority debt all along, dressed up in code that nobody wanted to write in the first place.