Initiative Stalled With No Visibility: Why It Happens and How to Spot It Early

An initiative that stalls without anyone noticing usually has no villain. Nothing broke, no alert fired, and the work simply got slower in places nobody was looking at together. If you were surprised by a stall, the cause is most likely that the evidence was spread across Linear, GitHub, and people's memories, and that status reports described intent rather than activity.

This article explains why stalls stay hidden, how the gap between ticket status and real progress hides them, which signals in Linear and GitHub show them early, and what human factors sit underneath. It ends with a weekly check you can run in fifteen minutes and a look at where tooling can take over the repetitive part.

Why Stalled Initiatives Stay Invisible Until It's Late

Failures are loud and stalls are quiet. A production outage pages someone. A stalled initiative produces no event at all: tickets stop moving, pull requests wait a little longer for review, and the next update arrives a day later than it used to. Monitoring systems are built to detect things that happen, and a stall is a thing that stops happening.

Status reporting makes this worse. In most teams, initiative status lives in standups, Slack threads, and a manager's head. Self-reported status tends to lag reality, and not out of dishonesty. People who are a week behind often expect to catch up, so they report green. Reporting amber feels like raising an alarm over something that might fix itself. By the time the person is sure they will not catch up, the slip is already large.

Then there is the structural problem. An initiative typically spans many tickets, several repositories, and people on more than one team. Each contributor sees their own slice. The engineer working on the API knows their part is fine. The designer knows the mockups shipped. Nobody holds the whole picture, so nobody notices that the combined motion has slowed.

Consider an illustration. Suppose a team is running a billing migration tracked as one epic with twenty tickets. Fourteen are closed, so the dashboard reads 70% complete. The six that remain include the data backfill, the rollback plan, and two integration tickets blocked on another team. None of them has been touched in three weeks. In the weekly meeting, the owner says the work is "mostly there," and that is sincere, because the finished tickets feel like momentum. The number is accurate and the conclusion drawn from it is wrong.

The pattern is consistent: the information needed to catch the stall existed the whole time, as timestamps, review queues, and quiet branches. It just was not assembled anywhere a decision-maker would see it.

The Gap Between Ticket Status and Real Progress

Three terms are worth fixing before going further. An initiative is a cross-team goal made up of multiple projects or issues, such as "launch self-serve billing." A work stream is a thread of related work inside it, such as the payments integration or the migration tooling. A task is a single ticket. Health problems often hide at the work stream level: the initiative looks fine in aggregate while one stream has gone silent.

Why percent-complete misleads

The most common misconception is that percent-complete based on ticket counts equals progress. It does not, for two reasons. Tickets vary enormously in size, so closing ten small ones can matter less than leaving one large one open. And teams tend to do easy, well-understood work first, which leaves the hardest and least certain tickets for last. A progress bar that climbs quickly early on and then flattens is typical, and the flat part is where the real risk sits.

What each tool actually records

An issue tracker like Linear records state changes: created, assigned, moved to In Progress, closed. GitHub records code activity: commits, pull requests, reviews, merges. Each alone misses the story. A ticket can sit in In Progress while the branch behind it has no commits, which means no one is working on it. Conversely, a flurry of commits can happen against a ticket nobody updated, so the tracker looks stale while real work is happening.

That leads to a common mistake: treating In Progress as a signal of motion. It is a claim someone made on the day they moved the ticket. Tickets can hold that status for weeks, and the label gives no indication whether anyone has touched them since. Motion is something you infer from activity on the work itself, and that means reading the tracker and the code host side by side.

Early Warning Signs You Can Check in Linear and GitHub

Because a stall is an absence, the useful signals are mostly comparisons: this against that, now against last cycle. The following can all be checked by hand with filters and saved views.

• Issues with no updates for N days. Filter the initiative's open issues by last-updated date. A comment, status change, or linked commit counts as an update.
• In Progress tickets with no matching code activity. Check whether the linked branch or pull request has had a commit recently. A ticket claiming progress with a silent branch is the clearest single indicator.
• Pull requests open without review. A PR waiting days for its first review is a queue problem, and queue problems compound across an initiative.
• Branches with no commits. Long-lived branches that have gone quiet often mean the work was interrupted or hit an unknown.
• Scope growing faster than it closes. Count issues added to the initiative against issues closed over the same period. If additions outpace closures for several weeks, the finish line is moving away from you.
• Cross-team blockers nobody picks up. Look for issues marked as blocked by another team's work, then check whether that work has an assignee and recent activity.

Measuring momentum

Momentum here means whether work is accelerating or slowing. The simplest measure compares this period's merged pull requests and closed issues against the previous period for the same initiative. A single slow week means little, since holidays, releases, and incidents all distort it. Two or three consecutive periods of decline, especially while scope stays flat, is worth a conversation.

Choosing a threshold

Do not copy a generic staleness number. A team on one-week cycles should worry about a ticket untouched for three days; a team on six-week cycles may reasonably leave one alone for ten. As an example to adapt, you might flag any open initiative issue with no update for half a cycle, and escalate at a full cycle. Set the number from your own cadence, then adjust after a month of seeing which flags turned out to matter.

The Human Causes Behind a Stall

When people look back at a stall, they often reach for effort as the explanation. It is rarely the right one. The usual root causes are structural:

• Unclear ownership. Several people care about the initiative but none is accountable for its pace, so everyone assumes someone else is watching.
• Competing priorities. The same engineers are pulled between the initiative, roadmap commitments, and interrupts. Whichever demand is loudest wins.
• Hidden technical unknowns. A task that looked routine turns out to need research, and the person facing it does not want to report that a two-day ticket is now an open question.
• Key-person dependency. One engineer holds the context for a critical piece, and their availability sets the speed for everyone.

Suppose an engineer who owns a search-indexing initiative is quietly pulled onto customer support escalations for two weeks. No one reassigns the initiative, and the tickets still carry their name. On paper the initiative has an owner. In practice it has nobody working on it, and the first sign is a gap in activity that nobody is positioned to read.

Strain also tends to leave traces before delivery slips. Overload and frustration can show up as slower responses, thinner review comments, work happening at unusual hours, or a drop in activity from someone who was previously steady. These are indicators, not diagnoses. A quiet week might be a vacation, deep focus on a hard problem, or a personal matter. Treat the pattern as a reason to ask, never as a conclusion.

This is also why asking "is it on track?" in a meeting yields polite answers. In a group setting, saying "no" feels like admitting fault, so people give the answer that avoids friction. Specific, low-stakes questions asked privately work better: "What is the one thing slowing this down right now?" invites a real answer because it assumes there is a obstacle rather than accusing anyone of causing one.

Building a Visibility Habit: A Weekly Initiative Check

A lightweight routine beats an elaborate one that gets skipped in the third busy week. Aim for fifteen minutes, once a week, with the same steps each time.

1. List active initiatives. Keep this to what the team is genuinely committed to now. If the list is longer than you can scan in a minute, that is itself a finding.
2. Confirm one named owner for each. A person, not a team. If you cannot name one, fix that before anything else.
3. Review last-activity dates. For each initiative, note the most recent merged PR and the most recent issue update. Use the staleness threshold you chose for your cycle length.
4. Compare against last week. Merged PRs, closed issues, issues added. A short note in a shared document is enough to make the trend visible.
5. Ask each owner one question. "What is the one thing blocking you?" Ask it in a message or a short one-on-one rather than in front of the group.

Decide escalation rules in advance. For example, an initiative with no meaningful movement for two consecutive cycles gets a scoping conversation with the owner and their manager, and a third cycle triggers a decision to resource it, reduce it, or pause it. Setting this ahead of time removes the emotional weight at the moment it matters, because you are applying a rule you agreed on and not passing judgment on a colleague.

The limits are real. Manual checks take time, and the time grows with every initiative you add. They also drift: thresholds go unreviewed, the document stops being updated, and the person who ran the check goes on leave. A habit like this works well for a handful of initiatives and starts to creak past that.

Automating the Signals With Engineering Intelligence

The weekly check is mostly gathering and comparing, which is the kind of work software does well. Progress is an AI-native engineering intelligence platform that ingests data from tools such as Linear and GitHub and pre-computes operational signals from it. As of October 2026, those include flags for stalled work and emerging risks, initiative and work-stream health, and team momentum. Because the assessments are computed continuously, a leader opens a view that already says where the risk is rather than building one from filters.

You can also ask questions directly. Through Progress's MCP server and Claude API integration, you can put a plain-language question such as "which initiatives have slowed this month?" and receive an answer grounded in actual activity data, not a manually assembled report. That is useful when the question occurs to you in the middle of planning and you do not want to open four tabs to answer it. Confirm current capabilities against the product documentation, since features evolve.

The human layer matters here too. Progress also reads team momentum and morale, so a delivery signal can be viewed alongside a signal about strain. If an initiative slows at the same time a team's wellness read dips, that combination points toward workload or ownership rather than skill, and you can act before a deadline moves.

Be clear about what these signals are. They tell you where to look and prompt a conversation; they do not replace one. An initiative flagged as slowing might be waiting on a deliberate design decision, and only the people doing the work can say so. Use the output to ask better questions earlier.

Watch Activity, Not Status, Starting With Your Riskiest Initiative

Stalls become visible when you watch what the work is doing instead of what people say about it. Timestamps, review queues, scope growth, and period-over-period momentum all exist already; they just need to be read together on a regular rhythm, with an owner behind each initiative and an agreed trigger for escalation.

This week, pick the initiative that would hurt most if it were slipping and run the five-step check on it. Note the last merged PR, compare against the previous week, and ask the owner what is blocking them. If you would rather have stalled work surfaced for you across every initiative automatically, Learn more about our services.