heighttechnicalAPP-111

The Height Engineering Team Lead

#height#project-management#engineering#tasks#sprints#linear-alternative

Aha Moment

“What was the moment this product clicked?” —

Identity

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.

Intention

What are they trying to do? —

Outcome

What do they produce? —

Goals

→Manage engineering tasks and sprints alongside cross-functional project work without switching tools
→Give leadership visibility into project status without requiring them to navigate the task layer
→Automate the workflow updates that currently require manual status maintenance

Frustrations

—A smaller ecosystem than Linear or Jira — fewer integrations, fewer community resources
—Onboarding that requires more hand-holding than competitors for non-technical teammates
—Feature gaps that emerge at the edges of complex project structures
—The "are we making a bet on the right tool?" uncertainty that comes with a less-established product

Worldview

Engineering tools should be built by people who understand engineering — not adapted from generic PM tools
Cross-functional visibility should not require a separate reporting tool
Automation is how a small team keeps a large task graph current

Scenario

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.

Context

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.

Impact

→GitHub integration that auto-updates task status from PR state (opened, reviewed, merged)
→removes the manual "move to done" step that engineering teams reliably skip
→Project template system that lets team leads configure standard sprint and
→project structures once and copy them without rebuilding removes the setup
→overhead per quarter and per new project type
→Executive summary view that rolls up project status across all active workstreams
→without exposing the task layer removes the "can you give me a status update?"
→interruption from leadership
→Onboarding flow for non-engineering teammates that explains the tool's structure
→from their role's perspective removes the "I don't understand how this maps to my work" dropout

Composability Notes

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.