Every company I walk into as a fractional CTO runs a different mix of trackers, and my first week is always the same: pull the data before anyone tells me the narrative. Do that enough times and you notice each tracker has a personality. It admits some truths and buries others.
Here's what six years of walking into other people's tooling has taught me about what each one reveals — and what it hides.
Jira: what the team believes is happening
Jira gives you the richest picture of intended work — sprints, estimates, the epic hierarchy, the whole planned universe. That's also its weakness: it's self-reported. "In Progress" can mean three weeks of nothing. "90% done" is a mood, not a status.
Jira tells you what the team believes is happening. Git tells you what actually happened. Neither one lies, but I've never once seen a department where the two matched — and the size of the gap is the cheapest audit you'll ever run.
GitHub and GitLab: ground truth, with no context
Commits, review latency, who actually reviews whom — this is the real collaboration network, and it never matches the org chart.
The org chart says the team reports to one lead. The review data says every pull request actually goes through one senior engineer. I trust the second document.
What git platforms can't see: priority, scope, or why the work exists. A commit is a fact about a file, not a fact about a plan. You can't read a roadmap out of a commit log, and you can't see the ticket that was quietly deprioritized three sprints ago.
Azure DevOps: the enterprise split-brain
ADO should be the dream — work items and repos in the same tool, data pre-joined. In practice, every team customizes their process template until they speak different dialects of the same tool. The biggest ADO estates I've inherited were also the least readable: inherited template, five workflow states nobody remembers adding, and fields that are mandatory and empty.
If your company runs on ADO, this is not a criticism — it's a warning about what a decade of customization does to a schema.
The punchline: your lead time isn't a metric
Lead time is the metric everyone quotes and almost nobody measures. The clock starts when the ticket moves, and it stops when the pipeline deploys. If those two events live in different tools — and in every company I've worked with, they do — your lead time isn't a metric. It's a guess with decimals.
That's the whole argument for one board over all four trackers. Not "unified dashboards are nice" — that basic, load-bearing numbers cannot be computed inside any single tracker, because each one only sees its half of the lifecycle.
This is why I stopped doing this work with exports. Three CSVs from three tools, a long evening in a spreadsheet, and an answer that's stale the moment anyone moves a ticket.
What we did about it
We built the tool that does the joining — one board over Jira, GitHub, GitLab and Azure DevOps, read-only from every source, self-hosted — and after it changed how our first week in every company goes, we open-sourced it.
Repo: https://github.com/Codpal-Limited/deckgauge — there's a live demo with a fictional org at https://demo.deckgauge.com if you want to see what the four trackers look like as one picture.
I'm Yaniv — fractional CTO and founder of Codpal. What your trackers reveal and what they hide is basically my job description at this point, so I'm curious: which one lies to you most?
Top comments (0)