The Jira question

Why not just use Jira? Answering Andrew Warner’s question

By the CodPal team · 19 September 2026

Yesterday Deckgauge was one of the repos in "Top Repos Explained" on The Next New Thing, Andrew Warner's weekly GitHub-repos show. And Andrew did what Andrew does: he pushed on the soft spot. He had, he said, gone back and forth with the creator many times on one question — why can't you put everything in Jira and have all those tasks come in from there? Why take tasks out of Jira, GitHub and the rest and put them into your own thing?

He then clicked into the live demo on air, walked the board, and concluded that the case for the unified view was a good one — an internal tool, in his words, given away in the spirit of letting other people learn from each other.

The question deserves more than 38 seconds, so here is the full answer — the one that apparently held up under Andrew's cross-examination.

The real answer: it's a manager's cockpit, not a second Jira

The honest answer to Andrew's question starts with how the tool was born. As a fractional CTO, you land inside development divisions that are already running — and you have days, not months, to be useful. The questions in week one are always the same: where does this division actually stand? What's pending, and what's parked that nobody is picking up? Are the developers working the roadmap, or drifting off it? Who are the stars this company needs to keep? Who is struggling and needs a manager conversation right now?

Those answers are scattered across Jira, GitHub, GitLab and Azure DevOps — four logins, four vocabularies, no single picture. With Deckgauge, the first sync produces one board with all of the tasks on it. You sit down with the tech managers, walk the board together, comment on the tasks, set estimates and due dates — and in the next meeting you go over those comments and see what actually moved. The board becomes the shared working memory of the engagement.

Underneath the board, the intelligence widgets read the same history the tools already hold: what's moving and what's stuck, review queues, work that was started and quietly cancelled, who is carrying the load. Not to rank individuals for a scorecard — to know which manager conversation to have first. That is what makes this a cockpit for the person running the division, rather than another tracker for the people doing the work.

Jira records the ticket. It doesn't record the delivery.

A Jira issue is a claim about work: someone moved the card to "In Progress", and later — hopefully — to "Done". What Jira cannot show you, on its own, is what actually happened in between:

• the pull request the ticket refers to, and how long it waited for review,
• the commits behind it, and which of them were written with AI assistance,
• the deployment that carried it to production — which Jira never sees, and which two of the four DORA metrics structurally require (see our honest accounting of DORA from Jira),
• the same story for the GitHub repo, the GitLab project and the Azure DevOps project next door.

You can absolutely put every task in Jira. Teams do. But the delivery evidence stays split across systems, and the moment you want the real picture — where delivery is slow, which team's review queue is the bottleneck, what the quarter actually produced — you are back to assembling it by hand. That assembly is the entire job Deckgauge does.

Nothing is taken out of anywhere

The phrasing of the question — "take tasks out of Jira" — hides a wrong assumption worth correcting, because it is the most common one we hear. Deckgauge never writes to Jira, GitHub, GitLab or Azure DevOps. Connections are read-only; your trackers stay the source of truth; your teams keep working exactly where they work. Deckgauge syncs issues, pull requests, commits and review activity into its own store — Postgres and ClickHouse that you host — and derives the board, the flow metrics and the DORA widgets from that history.

The board is a lens, not a new home. Delete Deckgauge tomorrow and your Jira is exactly as it was.

What Andrew clicked: the demo is open

In the segment, Andrew opens the hosted demo and pokes around the board. That demo is public: deckgauge.com/try. It runs a fictional company with two boards carrying 240 items, a roadmap, comparison dashboards, a 25-person org chart, timesheets, and six months of engineering history feeding the intelligence widgets — so the DORA, flow and review numbers are computed from real (synthetic) history rather than painted on. Read-only, nothing to install, no trial clock.

And if you would rather run it where nobody else can see it — which is rather the point — the whole platform is source-available and deploys with Docker: four commands in the quickstart.

The video, for the impatient

The full episode covers ten repos, from Alibaba's Open Code Review to agent-skill tooling; Deckgauge's chapter starts at 24:05. Subscribe to The Next New Thing while you are there — it is a good weekly scan of what is actually moving on GitHub, and not only because they had good taste this week.

Frequently asked

Why not just use Jira for everything?

Because Jira only holds what Jira holds. A Jira issue says a task is "In Progress" — it does not show the pull request behind it, the review that has been sitting for three days, the commit that landed, or the deployment that carried it. Those live in GitHub, GitLab and Azure DevOps. You can move every task into Jira, and many teams do, but the delivery evidence stays split across systems, and assembling the picture by hand is exactly the work Deckgauge automates.

Does Deckgauge take tasks OUT of Jira?

No. Deckgauge reads from Jira, GitHub, GitLab and Azure DevOps with read-only credentials — it never writes to them. Your trackers stay the source of truth; Deckgauge builds one board and one set of metrics over them. "Taking tasks out" is the wrong mental model: nothing leaves, nothing is duplicated as the master record, and teams keep working in the tools they already use.

What did The Next New Thing say about Deckgauge?

In the 18 September 2026 episode, host Andrew Warner walked through Deckgauge as one of the week’s featured GitHub repos. He described going back and forth with the creator on exactly the "why not just Jira?" question, said the case for a unified board was a good one, opened the live demo on air, and framed the project as an internal tool whose creator published the source so other teams could learn from it. The segment starts at 24:05 in the episode.

Can I try the demo from the video?

Yes — the same hosted demo Andrew clicked on air is at deckgauge.com/try. It is seeded with a fictional company: two boards with 240 items, a roadmap, comparison dashboards, a 25-person org chart and six months of engineering history behind the intelligence widgets. Read-only, no install, no card, and it is reset periodically.

If the Jira question was yours too, the wider argument is in where did the engineering quarter actually go? — and the tracker-by-tracker series covers Jira, Azure DevOps, GitHub and GitLab.