Don't Standardize Your Teams. Standardize the Data.

The board asks a question that sounds simple: is the AI investment working?

Fourteen teams. Three Jira instances, one of them inherited from an acquisition nobody has finished absorbing. GitHub in most places, GitLab in the platform org. Four CI systems, because four capable tech leads made four reasonable decisions in four different years.

Someone gets handed the question. It takes a quarter. Two analysts pull exports, a staff engineer writes glue scripts, and a spreadsheet grows tabs and a color code that only its author understands. The answer arrives with an asterisk. Everyone in the room can tell the asterisk is doing more work than the number.

TL;DR — The question tax: in a large organization, every cross-org question is a project — and the output is a number nobody in the room will defend under pressure.

Consolidating tools doesn't fix it, because the rollup breaks on definitions, not on sprawl. Standardize the record instead: map each source once into a shared event model, compute metric definitions centrally, and let teams keep their process.

The problem isn't that you have too many tools

It's tempting to blame the sprawl. Consolidate the stack, the thinking goes, and the reporting problem goes away. But the sprawl isn't what breaks the rollup. Definitions are.

Take cycle time. One team starts the clock when a ticket is created. Another starts it at first commit, because their tickets sit in a backlog for weeks and they got tired of the noise. A third has an “In Refinement” state that legitimately holds work for days. All three report cycle time. All three are honest. None of them are measuring the same thing.

Now average them. You've done arithmetic on incomparable units and produced a number with the shape of an insight. Your metrics didn't survive contact with a second team.

This is why the quarter-long analysis doesn't actually settle anything. The work wasn't hard because the data was spread across systems. It was hard because someone had to make a hundred judgment calls about what counted as what — and the next person to run the analysis will make them differently.

The fix everyone reaches for

So the org launches the consolidation program. One Jira. One CI. One definition of done, ratified by a working group. Three things tend to happen:

• It takes years — You're not migrating tools, you're renegotiating how a dozen teams work.
• It costs autonomy — The teams with the most unusual process often have the best reason for it, and they're asked to change for someone else's dashboard.
• It never finishes — There's always an acquisition, a new tool a team genuinely needs, or an exception granted for a good reason.

Even in the version where it works, you end up with standardized tools. You still don't have standardized meaning. Two teams on the same Jira instance can use it entirely differently, and usually do. You paid for the reporting benefit up front, in change management, and you're still paying — forever, in enforcement.

Teams differ at the process layer. They're identical at the event layer.

Process is where teams legitimately differ, and where they should. How you groom a backlog, how many review states you use, whether you cut a release branch — those are local decisions made by people who understand local constraints. Flattening them is a real cost and often a bad trade. But underneath process, there's a layer where nothing differs at all.

A commit is a commit. A review is a review. A build ran or it didn't. A deploy went out at a specific time. These aren't opinions about process. They're things that happened — in every team, in every tool, in every org, regardless of workflow philosophy.

That's the layer to standardize. Not the teams — the record of what they did.

What that looks like in practice

Each source system or a project gets mapped once, when it's connected. That's where the normalization work happens: this instance's states, this pipeline's stages, translated into a shared event model. It's configuration, not migration. Nothing about how the team works changes.

From there, metric definitions live in one place and get computed from events, centrally. “Cycle time” stops being a thing each team interprets and becomes a thing the platform derives the same way every time, from the same underlying record. Same question, same answer, whoever asks and whenever they ask it.

And because the mapping lives at the source connection, adding a new one later doesn't disturb what's already there. A team adopts a different CI system, or an acquisition arrives with an unfamiliar stack — you connect it and map it. You don't re-instrument the sources already running.

One honest limit, because it matters — If a team's workflow never captures a particular state, we don't invent it. That team won't have the metrics that depend on it. What you get instead is a visible gap — this org can't report on review latency because the state isn't tracked — rather than a missing input silently averaged into a company-wide number. In our experience that gap is often the more valuable finding.

The consolidation project you don't have to run

It's worth being explicit about what this means you're not doing. There's no migration plan. No working group ratifying a definition of done that three teams will quietly ignore. No team asked to change how it works so that someone else's dashboard resolves cleanly. Nobody spends eighteen months moving repositories and then discovers the reporting problem followed them across.

It works against the organization you have right now — including the parts you would have consolidated last. The acquisition you haven't absorbed is a source you connect, not a program you schedule. The platform team's unusual pipeline is a mapping, not an exception request. And when the estate changes again, because it will, you connect the new thing rather than reopening the program.

To be fair to consolidation: there are good reasons to do it. Licensing cost. Security posture. Genuine operational simplicity for the people running the tools. If those are your reasons, consolidate, and this doesn't change your plan.

But if the reason on the business case is so we can finally see across the org — that one was never worth the war. You can have the answer without the migration, and you can have it this quarter instead of after the next reorg.

Why this stopped being a nuisance

For a long time, fragmentation was survivable. The questions were quarterly, and a quarterly question can absorb a quarter of analysis. The QBR deck got built, the asterisk got explained, everyone moved on. That's not the shape of the questions anymore.

AI accelerated every stage of the pipeline at once — requirements get drafted faster, code gets generated faster, tests get written faster. The one thing that didn't scale is human review and judgment. So the questions leaders are being asked have gone continuous: is this safe to ship, is the investment actually paying off, is that dependency about to cost us the date. Those get asked at the pace work moves now, and a number that takes a quarter to assemble is a number that arrives after the decision.

You cannot answer a continuous question with a periodic, hand-stitched process — not because your analysts aren't good, but because the tax compounds.

Every question is a new project. Every project produces a number with an asterisk. And leaders stop asking, which is the worst outcome of all — not bad data-driven decisions, but the quiet return to deciding on instinct because the data was too expensive to trust.

The two questions

This is what CleverDev is built for. We connect to the tools your teams already run, capture engineering events as they happen, and build the lineage behind every line of code — why it was written, why it changed, who changed it, what it touches downstream. The teams keep their tools and their process. The organization gets one consistent record underneath.

That's the foundation, not the point. The point is what it lets you answer, in real time, however the code gets written — typed or prompted.

Here's what you get

One consistent record, underneath the org you already have

Start a POC conversation →