An engineering manager or head of engineering at a startup of 20–150 engineers
who uses Linear at the issue level to track work and at the Projects level to
communicate progress. The ICs live in issues and cycles. The EM lives in projects
and the roadmap view. They're the translation layer between "what the team is
building" and "what the company thinks we're building" — and Linear Projects is
the interface they use to close that gap.
Intention
What are they trying to do? —
Outcome
What do they produce? —
Goals
→Know the health of every active project without a weekly status sync that pulls
→people out of work
→Give product and leadership an accurate, current view of the roadmap without
→maintaining a separate document
→Surface blockers at the project level before they become schedule slips at the
→roadmap level
Frustrations
—Project status that's accurate when it's updated and stale 48 hours later
—The gap between Linear project health and the roadmap slide in the board deck —
—they're never the same thing
—Projects that are "In Progress" and have been for 6 weeks without a meaningful update
—Engineering work that doesn't map cleanly to a project because it's cross-cutting
—or infrastructure that serves no one feature specifically
Worldview
A roadmap is a commitment with uncertainty, not a schedule with certainty
Status updates that require manual entry will eventually not be updated
The best project management is the one the team uses naturally — forcing a workflow
that fights how engineers think produces bad data
Scenario
It's Thursday. The product review is Monday. Four projects are active.
One is on track. One is 2 weeks behind but the team hasn't updated the status.
One has a blocker that the EM knows about from a Slack message but that's not
reflected in Linear. One was completed last week but nobody marked it done.
They're spending 40 minutes updating Linear before the Monday review so the
dashboard reflects reality. This is the work that shouldn't exist.
Context
Manages 3–8 active projects across 2–4 engineering teams. Uses Linear's roadmap
view as their primary interface. Reviews project milestones and status weekly.
Creates projects from cycle issues that have reached sufficient size and scope.
Links projects to product initiatives. Shares roadmap views with the VP of Product
and occasionally the CEO. Has tried to get ICs to update project status themselves.
The hit rate is 60%. They update the rest themselves.
Impact
→Project health inference from issue velocity and cycle completion rate replaces
→the manual status update as the primary signal — reducing the EM's Thursday cleanup
→Blocker escalation that surfaces Slack-linked blockers in the project view
→closes the gap between what the team knows and what the project reflects
→Roadmap views that non-engineers can read without a Linear account removes
→the "send me a screenshot" step from every executive roadmap request
→Cross-cutting work attribution that lets infrastructure and platform work roll
→up to impacted product areas makes invisible work visible in roadmap reporting
Composability Notes
Pairs with `linear-primary-user` (the IC cycle-level user) for the full team workflow from issue to project.
Contrast with `jira-primary-user` for the flexible-modern vs. process-heavy planning tool philosophy.
Use with `pitch-primary-user` for the engineering roadmap-to-board-deck workflow translation.