How to Track Engineering Progress Without a Project Manager
How to track engineering progress without a project manager: PR review backlog, ticket throughput, and the tool-by-tool workflow that actually covers it.
Search “how to track engineering progress without a project manager” and the results scatter. A construction-industry site turns up for “project tracking.” Generic project-management software guides assume you’re buying a dashboard. Forum threads argue about whether a Scrum Master owns status reporting. The closest matches are written for a company that already has a technical program manager, and are really about what a TPM does, not how to cover the job before you have one.
None of it is written for the actual situation at a 10 to 75 person engineering team: nobody holds the program-management title, nobody is about to hire for it this year, and the status update still has to happen every week regardless.
This is that version: what tracking engineering progress actually means without a dedicated PM, what a status update genuinely needs to answer, the tool-by-tool workflow for pulling it from GitHub and Linear, and the point where the coordination work outgrows what one person or one agent can hold.
What does tracking engineering progress actually mean without a dedicated PM?
At a company with a technical program manager or an engineering program manager (EPM), tracking progress is a job: someone pulls the sprint burndown, reconciles it against the roadmap, chases down blockers, and writes the update a founder or a board actually reads. At a startup with no PM headcount, none of that work disappears when the title does. It gets absorbed: the engineering lead compiles a status the night before the all-hands, a founder scrolls GitHub and Linear separately trying to reconstruct what actually shipped, and “what’s blocking the release” becomes a Slack thread instead of a number anyone tracks.
That absorption holds for a while, the same way it does in every function without a dedicated owner. It breaks with a slow drift rather than one dramatic miss. Stale PRs pile up in the review queue because nobody is watching it continuously. Tickets sit in progress past their expected window because checking cycle time competes with actually writing code. The status update quietly turns optimistic by omission, not by anyone lying, because assembling the honest picture from two separate tools takes longer than anyone reliably has on a Friday afternoon.
The founder’s guide to running operations without an ops team makes the general case for this pattern across every function. Engineering status is simply the sharpest version of it, because the two systems holding the truth, the repo and the issue tracker, rarely get read together by the same person on the same day.
What should a weekly engineering status update actually include?
Job postings for TPMs and EPMs list a long scope. In practice, the recurring status update that a founder or a board actually reads is a much shorter list, and the items differ sharply in how much of that data GitHub and Linear already hold versus how much still needs a person’s read.
| What a status update needs | Can GitHub + Linear cover it? | Why |
|---|---|---|
| PR review backlog: what’s open, how long, who’s blocked | Yes, almost entirely | GitHub natively tracks every PR’s age, reviewers, and merge state |
| Ticket throughput: planned versus completed this cycle | Yes, almost entirely | Linear’s issue state and completion timestamps are exactly this data |
| What’s actually blocking a release | Partially | Linear shows a ticket is blocked; it doesn’t know why a person hasn’t unblocked it |
| Whether the roadmap is still realistic | No | Requires judgment about scope tradeoffs, not a ticket count |
| Incident status and on-call load | No | Neither connector reads pager or incident tooling |
| Code quality and technical debt trend | No | Neither connector reads static analysis, test coverage, or lint trends |
| Team capacity and burnout risk | No | Requires reading people, not tickets |
The pattern: the highest-volume, most mechanical items, PR backlog and ticket throughput, are also the items GitHub and Linear already hold as structured data. The items that actually need a program manager’s judgment, roadmap realism, incident load, capacity, sit outside what either tool can answer on its own.
What tools does a small engineering team already have to cover this?
Most startups with no PM headcount already have the two systems this actually needs: GitHub for pull requests and code review, Linear for tickets and cycles. Neither was bought to solve status reporting, and that is exactly why the data sits there unread. GitHub knows precisely how old every open PR is and who it is waiting on. Linear knows precisely how many tickets a cycle planned versus completed and when each one moved to done.
What these two tools do not cover matters as much as what they do. CI/CD pipeline health, deployment frequency, and infrastructure incidents live in separate systems most early startups don’t have wired into a reporting layer at all. Code quality signals, test coverage trend, static analysis findings, sit in yet another tool. A status process built only on GitHub and Linear should say so honestly rather than imply it covers “engineering operations” broadly. It covers exactly two things well: who is waiting on a review, and how much got shipped.
How do you turn GitHub PRs and Linear tickets into one status view without a PM?
This is the part every generic PM guide skips, because it assumes the dashboard is the hard part. The dashboard is not the hard part. Concretely, whoever is holding this by hand is doing four things on a recurring basis.
PR review backlog, in GitHub. Filtering open PRs by age, checking which ones have a review requested but no response, and cross-referencing against who’s actually available that day versus out or heads-down on something else. Done by hand, this means opening the pull requests tab, sorting by last activity, and mentally tracking who owes a review.
Ticket throughput, in Linear. Comparing what the cycle planned against what actually moved to done, and separating “still in progress and on track” from “in progress and quietly stuck.” Done by hand, this is scrolling the cycle board and eyeballing which cards haven’t moved in a few days.
Blocker triage, across both. A ticket marked blocked in Linear often traces back to a PR sitting unreviewed in GitHub, or the reverse: a PR can’t merge because the ticket it depends on isn’t actually done. Catching this requires holding both systems in your head at once, which is exactly the kind of cross-tool reasoning a single dashboard in either tool cannot do.
The weekly status write-up, across everything. Assembling a short, honest view: what shipped, what’s at risk, what’s blocked and why, what needs a decision. This is the task that gets described as “twenty minutes on Friday” and is actually closer to an hour once the tool-switching and double-checking is counted.
An AI agent that reads GitHub and Linear continuously, rather than a person doing this in a weekly pass, covers all four as ongoing background work instead of a task someone has to remember to run before the status meeting. The Playbook it builds from corrections, “flag a PR unreviewed after three days, not seven,” “don’t count a ticket blocked if the dependency merged this morning,” carries the specific judgment a status owner would otherwise have to reapply by hand every single week.
Why does continuous tracking beat a weekly status pass?
The standard advice, run a Friday review and keep the board tidy, assumes the bottleneck is discipline. It’s really coverage. A weekly pass catches what drifted over a week. An agent reading GitHub and Linear continuously catches a PR going stale on day three, not day seven, because it isn’t waiting for Friday to look.
That gap compounds specifically in engineering, because a stalled PR blocks whatever depends on it, and a status update that only surfaces the miss after a week has already cost the week. A ticket that’s been silently blocked for four days is a much smaller problem caught on day four than the same ticket discovered in Friday’s status meeting, already threatening the release date.
The design that matters is the same one that applies across every function covered this way: one agent holding GitHub and Linear together, rather than two separate dashboards that each show half the picture and require a person to be the one who reconciles them. A PR-only view can’t tell you a ticket is actually done even though its PR sat open for a week over a merge conflict. A ticket-only view can’t tell you a release is at risk because three PRs against it are waiting on the same reviewer.
Manual tracking, a PM dashboard tool, or an AI agent: which actually covers the work?
Once a team decides it isn’t ready to hire a dedicated program manager, the real choice is usually between three options, and most comparisons only weigh two of them.
| Manual tracking (eng lead by hand) | PM dashboard software | AI agent (YAGNI) | |
|---|---|---|---|
| Covers PR backlog age and review load | Yes, if someone remembers to check | Yes, if configured and someone reads it | Yes, continuously |
| Covers ticket throughput and velocity | Yes, manually compiled | Yes, this is the tool’s core job | Yes, continuously |
| Covers blockers spanning GitHub and Linear together | Rarely, needs manual cross-referencing | Rarely, most dashboards read one system | Yes, reads both together |
| Typical cost | Existing salary, hours of manual work weekly | Roughly $10 to $30 per user per month | Priced per workspace, scoped to the work |
| Time to value | Immediate, recurring cost every week | Days to weeks to configure dashboards well | Hours to days to connect tools |
| Roadmap and scope judgment | Stays with the eng lead | Not covered, a person still decides | Stays with a person |
| What breaks it | Whoever does it burns out or leaves | Nobody reads the dashboard into a decision | Judgment calls stay with a person by design |
The honest read: a dashboard tool is good at showing the numbers, once someone configures it well and keeps checking it. It was never built to notice a stalled PR on its own or to reconcile a blocker across GitHub and Linear without a person doing the cross-referencing. Manual tracking works exactly as long as one person has the bandwidth and the memory to keep doing it every week, which is the same failure mode behind “our status updates got vague” at almost every team that tried to hold this by hand alone.
Running the recurring compilation through an agent first, and keeping the roadmap and scope calls with the engineering lead, covers both halves without waiting for headcount to justify a dedicated hire. This mirrors the sequencing in AI agent vs hiring an ops person: cover the repeatable volume with an agent, see what judgment work is genuinely left, and hire into that gap specifically, not into the compilation work an agent was always going to cover cheaper.
When should you actually hire a dedicated program manager?
There’s no single headcount number that recurs across engineering-org guidance the way ticket volume does for support, and that absence is itself informative: the real trigger is cross-team coordination complexity, not a fixed team size.
Concretely, that shows up as: multiple pods or squads each running their own roadmap that need active sequencing against each other, a release that depends on three or more teams shipping in a coordinated order, stakeholder reporting that has outgrown a single weekly update into something board-grade and recurring, or dependency mapping across teams that’s become a full-time job rather than something one lead tracks in their head. None of those are volume problems an agent or a rotating owner solves. They’re coordination and judgment problems that need a person who owns the sequencing and can be held accountable for the call.
Until then, the sequence that avoids the expensive false start, hiring a program manager before the coordination work justifies it, is: name one engineer as the accountable status owner, cover the recurring PR and ticket compilation with an agent, and bring in a dedicated hire specifically when cross-team sequencing, not reporting volume, becomes the actual bottleneck. That combination covers what a first PM hire does for status tracking specifically, for a fraction of the cost, and it tells you honestly when the coordination work has grown enough to justify the dedicated role.
YAGNI gives engineering status its own Team, reading GitHub and Linear continuously so the PR review backlog, ticket throughput, and weekly status write-up happen without anyone remembering to compile them by hand. If the PR backlog itself, not just the status report, is the actual problem, see clearing a pull request review backlog without a tech lead. See how the same pattern plays out in running revenue operations without a RevOps hire and running recruiting operations without a dedicated recruiter. Pricing is per workspace. Start at yagni.app.