“It happened mid-workflow — sprint planning is Monday.. height handled something they'd been doing manually, and it just worked. That was the moment it stopped being a tool they were evaluating and became one they relied on.”
When I'm sprint planning is monday, I want to manage engineering tasks and sprints alongside cross-functional project work without switching tools, so I can give leadership visibility into project status without requiring them to navigate the task layer.
An engineering team lead or technical PM at a company of 20–150 people who evaluated Linear and wanted more — more project hierarchy, more cross-functional visibility, more flexibility for non-engineering teams to work alongside engineering in the same tool. They chose Height. They're building their system in it. They like that it feels like a tool built by people who understand engineering workflows, not a project management tool that engineering is expected to tolerate. They're still learning the edges of it.
To manage engineering tasks and sprints alongside cross-functional project work without switching tools — reliably, without workarounds, and without becoming the team's single point of failure for height.
A engineering team lead or technical pm who trusts their setup. Manage engineering tasks and sprints alongside cross-functional project work without switching tools is reliable enough that they've stopped checking. GitHub integration that auto-updates task status from PR state (opened, reviewed, merged). They've moved from configuring height to using it.
Sprint planning is Monday. The team lead is in Height reviewing the backlog. They've triaged 14 tasks from the previous week's retro and added them to the backlog. They're assigning tasks to the sprint, setting points, and linking tasks to the relevant project milestone. The milestone is visible to the VP of Product without them needing to enter the sprint view. The automation they set up sends a Height summary to Slack every Friday. They check it looks right. It does. This is working.
Uses Height as the primary engineering task manager. Has projects for 3–6 active workstreams. Works with a team of 4–20 engineers plus cross-functional partners in design and product. Has connected Height to GitHub for PR-to-task linking. Uses Height's sprint view for engineering and project view for cross-functional work. Has built 3–8 automations. Reviews Height's roadmap and changelog for features they've been waiting for. Is in the Height community Slack. Has filed a feature request.
Two things you'd notice: they reference height in conversation without being asked, and they've built workflows on top of it that weren't in the original plan. Manage engineering tasks and sprints alongside cross-functional project work without switching tools is consistent and expanding. They're now focused on give leadership visibility into project status without requiring them to navigate the task layer — a sign the basics are solved.
The trigger is specific: onboarding that requires more hand-holding than competitors for non-technical teammates, combined with a high-stakes deadline. height fails them at exactly the wrong moment. That evening, they're reading comparison posts. What makes it irreversible: they fundamentally believe engineering tools should be built by people who understand engineering — not adapted from generic PM tools, and height just proved it doesn't share that belief.
Pairs with `linear-primary-user` to map the engineering-focused vs. cross-functional-project-aware task tool philosophy. Contrast with `jira-primary-user` for the modern-engineering-native vs. enterprise-PM-inherited project management experience. Use with `github-primary-user` for the engineering workflow that connects code review to task management.