Here’s another post drawn from nearly 40 years in software development and 30 years as a manager, CTO, and VP of engineering.
Every team I've worked on, for about as long as I can remember, runs on two systems shared between product and engineering. One is source control. There used to be real competition there — plenty of systems, plenty of opinions. There isn't anymore. It's Git, and specifically GitHub. That's pretty much the whole conversation now.
The other system is whatever you use to track tickets. For years that was Jira. Jira has gotten pretty clunky and hard to use, so Linear has taken over at a lot of companies — including the last two I worked at.
The product team lives in Linear. It's the literal handoff point between product and engineering. GitHub is where the engineering work actually gets done. And when that work wraps up, Linear is supposed to get updated to reflect it. Supposed to.
Linear has a GitHub integration built for exactly this: when an engineer picks up a ticket and opens a PR, Linear tracks it through review and merge, updating the ticket status as it goes. It's a genuinely good idea. The problem is that reality doesn't stay inside that clean workflow. PRs get modified, split, reverted, rerouted — and the automatic sync quietly falls out of step with what's actually true.
So here's what happens in practice. At the end of every sprint, leadership wants a sprint report: how did the team do, what actually got merged, and — critically — when did a given fix actually go out? To production, if you're a consumer product. To a specific customer, if you're running an enterprise single-tenant or multi-tenant setup. By that point everyone already knows Linear and GitHub have drifted apart, so somebody has to go reconcile them — pulling data out of Linear, sometimes by hand, and compiling it into a report. At some companies I've worked at, leadership wants that report back in a very specific Google Sheets format, so results can be rolled up consistently across teams and pods. That's a completely reasonable ask.
So — we're all engineers here — why not just automate the whole thing? You can, and you should. But my advice, on this and on most things, is: never automate a process unless you're confident the underlying data is correct. Otherwise you're not automating a report. You're automating mistakes.
Which is why keeping Linear in sync with what actually happened in GitHub during a sprint usually falls to a product manager — sometimes working with the team lead, sometimes in a dedicated meeting held just to close out the sprint. It eats real time and energy, and because it's a manual process, it introduces its own mistakes.
Here's my thesis, sitting here in 2026, squarely in — or maybe just at the start of — the AI era of product engineering: keeping GitHub and Linear in sync is no longer a nice-to-have. A product manager I work with recently called it "incredible" that this could be automated. I told him it should be the bare minimum.
It's genuinely straightforward now to build a skill — I use Claude Code — that diffs Linear against GitHub for a team and fixes the discrepancies, all inside of maybe half an hour. And there's no reason to only run that at the end of a sprint. Do it daily. That alone meaningfully raises the quality of the data.
I'm not claiming the data will ever be perfect. We're early, and we need more real-world experience with this kind of thing. But I believe it's where every company should be headed, and I'm genuinely curious what the results look like — both at my own company and at others trying the same thing. If you're experimenting with this, I'd like to hear how it's going.
Because Linear should be the source of truth for what's actually happening inside your product and engineering org. And once it actually is, pulling a report out of it — in whatever format you need — should be trivial. Using AI, using Claude's connectors, you can output that report in essentially any format you want. Reporting back to leadership stops being a tradeoff between "easy" and "right." It becomes both.