--- title: "Vertical vs horizontal work · DeliverySheet" description: "Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an \"epic\"." canonical_url: "https://www.deliverysheet.com/blog/vertical-and-horizontal-work" last_updated: 2026-08-04 meta: author: "Tan Gravam" "og:description": "Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an \"epic\"." "og:image": "https://www.deliverysheet.com/_og/s/o_12471cd3b6d5ba53.png" "og:image:alt": "Vertical and horizontal work: the distinction planning tools miss — DeliverySheet essay card" "og:image:height": "600" "og:image:type": image/png "og:image:width": "1200" "og:title": "Vertical and horizontal work: the distinction planning tools miss — DeliverySheet" "twitter:description": "Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an \"epic\"." "twitter:image": "https://www.deliverysheet.com/_og/s/o_12471cd3b6d5ba53.png" "twitter:image:alt": "Vertical and horizontal work: the distinction planning tools miss — DeliverySheet essay card" "twitter:title": "Vertical and horizontal work: the distinction planning tools miss — DeliverySheet" --- > Index of every page on this site: [llms.txt](https://www.deliverysheet.com/llms.txt) [← All writing](https://www.deliverysheet.com/blog) # **Vertical and horizontal work: the distinction planning tools miss** 4 August 2026 · 5 min read · by [Tan Gravam](https://www.deliverysheet.com/about) ## **How is vertical work different from horizontal work in delivery planning?** **The short answer ** Vertical work is a delivery stream owned by one team that produces end-to-end value in its lane — frontend, backend, data, mobile, platform. Horizontal work is a cross-cutting concern that pulses into several verticals at specific gates — security review, legal, compliance, design, accessibility, privacy. Verticals consume capacity continuously; horizontals consume it in bursts and gate other people's progress. Planning them with the same object, usually called an "epic", is why cross-cutting reviews are the most common cause of late-stage delay. Ask a planning tool to represent "build the new checkout" and "get the new checkout through security review" and it will offer you the same object for both. An epic, a project, a parent ticket — one shape, two very different kinds of work. That collapse is convenient for the tool and expensive for the plan, because the two kinds of work consume capacity differently, fail differently, and need different questions asked of them. ## The two shapes [**Vertical work**](https://www.deliverysheet.com/glossary/vertical-work) is a delivery stream owned by a single team or discipline that produces end-to-end value inside its own lane. Frontend, backend, data, mobile, platform, DevOps. A vertical runs in parallel with other verticals and has its own cadence. Its capacity profile is continuous: it occupies some fraction of a team for some number of weeks. [**Horizontal work**](https://www.deliverysheet.com/glossary/horizontal-work) is a cross-cutting concern that pulses into several verticals at specific gates. Security review, legal, compliance, design, accessibility, internationalisation, privacy. A horizontal is rarely a standalone deliverable. Its function is to gate other people's progress, and its capacity profile is bursty: nothing, nothing, nothing, then a hard demand on a small specialist group, usually at the point where several verticals arrive at the same gate in the same week. ## Why the distinction changes the plan Four things behave differently once you stop treating both as epics. **Capacity planning.** A vertical can be planned as a rate — this team, this fraction, these months. A horizontal cannot, because its load is driven by *other people's* schedules. If four verticals plan to reach a security gate in the same fortnight, the security group's month is decided by four plans none of which mention it. This is the single most common cause of a "surprise" bottleneck, and it is fully predictable in advance if the horizontals are modelled as horizontals. **Dependency tracking.** Vertical-to-vertical dependencies are usually one-to-one and visible: backend needs the schema before frontend can finish. Horizontal dependencies are one-to-many and invisible, because each vertical experiences its own instance of the dependency and nobody sees the aggregate. Asking "what does this demand need from elsewhere" per demand is necessary but not sufficient; someone has to look down the column. **Risk.** A vertical slipping delays a lane. A horizontal slipping delays every lane it gates, and it does so late, because gates sit near the end. This asymmetry means horizontal risk deserves to be surfaced earlier and weighted harder than its size suggests. **Reporting.** Verticals report progress — how far along the lane is. Horizontals report coverage — which of the things that need review have been reviewed. Reporting a horizontal as "60% complete" is close to meaningless; reporting it as "9 of 15 demands have cleared privacy" is actionable. ## The failure mode this produces When both are epics, an entirely typical quarter looks like this. Every lane reports green through week eight, because within each lane things genuinely are green. In week nine the first vertical arrives at the security gate and discovers a two-week queue. In week ten the second arrives and the queue is three weeks. By week eleven the programme is late and the retrospective concludes that "security was a bottleneck". Security was not a bottleneck. Security was a two-person group whose quarter was allocated by four teams who never told them, using a planning model that had no way to express the thing that was about to happen. Each of those gates arrives on a specific plan as [a dependency you have no authority over](https://www.deliverysheet.com/blog/the-dependency-you-dont-own) , which is a different object from a task with a different assignee. ## What to do about it without buying anything You can get most of the value with a habit rather than a tool. - When a demand is planned, ask explicitly: *what does this need from a cross-cutting group, and at roughly which week?* Not "are there dependencies" — that question gets a no. Name the usual suspects: security, legal, privacy, design, accessibility, data protection, procurement. - Keep one view per horizontal group across all demands, and read it as a calendar rather than a list. You are looking for clustering, not volume. - Give the horizontal groups a veto on the *timing* of gates, not on the work. They are the only people who can see their own aggregate load, and currently nobody asks them until the queue exists. - Treat an unconfirmed horizontal dependency as a genuine blocker to committing, in the same category as unconfirmed capacity. It is one. ## Where DeliverySheet sits on this Being straight about the boundary: the vertical / horizontal distinction is part of how DeliverySheet models delivery, and it is the decomposition model I would build toward — Initiative → Vertical or Horizontal → Work Package → Task, three levels and no more, because two is a bag of tickets and four is procrastination with a Gantt chart. That depth is not built today. What is shipped and in daily use today is the governance half: a demand's Plan stage holds dependencies, decisions, capacity per team and risks, each one able to be honestly marked *none known*, and a demand cannot be recorded as committed while a high or critical risk is still open unless someone signs an exception. What a committed demand carries today is a flat delivery-execution list — the concrete work behind that one commitment — not the multi-level tree described above; DeliverySheet does not yet replace Jira or Linear for day-to-day execution, and I would rather say that here than let you find out after paying. The distinction is worth adopting whether or not you ever use my product. It costs one extra question at planning time and removes the most reliably surprising failure in delivery. Defined in the glossary: [Vertical work](https://www.deliverysheet.com/glossary/vertical-work), [Horizontal work](https://www.deliverysheet.com/glossary/horizontal-work) I'm Tan Gravam. I build **DeliverySheet** — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date. $189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself. [**Start 7-day trial **](https://www.deliverysheet.com/login?next=/app) [**See pricing **](https://www.deliverysheet.com/pricing) Not ready for that? Play [eight rounds of Request or topic?](https://www.deliverysheet.com/spot-the-request) It takes two minutes and needs no sign-up. ## **More on planning that stays honest** [Read the overview: Planning that stays honest →](https://www.deliverysheet.com/topics/planning) - [A risk register that gets read: mitigate it, accept it, or it blocks](https://www.deliverysheet.com/blog/risk-register-that-gets-read) A project risk register in five columns, the three ways a risk can leave it, and the rule that makes people read it: a serious open risk blocks the commitment. - [The dependency you don't own](https://www.deliverysheet.com/blog/the-dependency-you-dont-own) Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control. - [AI should draft and challenge. It should not decide.](https://www.deliverysheet.com/blog/ai-should-suggest-not-decide) Where an LLM genuinely helps in delivery planning, where it must not be trusted, and the design rule that keeps the two apart. ```json {"@context":"https://schema.org","@graph":[{"@id":"https://www.deliverysheet.com/#website","@type":"WebSite","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date. AI-assisted shaping, planning and commitment governance for engineering leaders.","name":"DeliverySheet","url":"https://www.deliverysheet.com/","publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#webpage","dateModified":"2026-08-04","datePublished":"2026-08-04","description":"Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an \"epic\".","name":"Vertical vs horizontal work","url":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work","@type":["WebPage","FAQPage"],"breadcrumb":{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#breadcrumb"},"isPartOf":{"@id":"https://www.deliverysheet.com/#website"},"mainEntity":[{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#/schema/question/1"}],"potentialAction":[{"@type":"ReadAction","target":["https://www.deliverysheet.com/blog/vertical-and-horizontal-work"]}],"primaryImageOfPage":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/#identity","@type":"Organization","alternateName":"Delivery Sheet","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date.","name":"DeliverySheet","url":"https://www.deliverysheet.com","founder":{"@type":"Person","@id":"https://www.deliverysheet.com/about#person","name":"Tan Gravam"},"logo":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Home","item":"https://www.deliverysheet.com","position":1},{"@type":"ListItem","name":"Writing","item":"https://www.deliverysheet.com/blog","position":2},{"@type":"ListItem","name":"Vertical and horizontal work: the distinction planning tools miss","item":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work","position":3}]},{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#article","@type":"Article","dateModified":"2026-08-04","datePublished":"2026-08-04","description":"Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an \"epic\".","headline":"Vertical and horizontal work: the distinction planning tools miss","inLanguage":"en","thumbnailUrl":"https://www.deliverysheet.com/_og/s/o_12471cd3b6d5ba53.png","about":[{"@id":"https://www.deliverysheet.com/glossary/vertical-work#term"},{"@id":"https://www.deliverysheet.com/glossary/horizontal-work#term"}],"author":{"@id":"https://www.deliverysheet.com/about#person"},"image":{"@id":"https://www.deliverysheet.com/#/schema/image/1"},"isPartOf":{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#webpage"},"keywords":["planning","dependencies","architecture"],"mainEntityOfPage":{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#webpage"},"publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/vertical-and-horizontal-work#/schema/question/1","@type":"Question","inLanguage":"en","name":"How is vertical work different from horizontal work in delivery planning?","acceptedAnswer":{"@type":"Answer","text":"Vertical work is a delivery stream owned by one team that produces end-to-end value in its lane — frontend, backend, data, mobile, platform. Horizontal work is a cross-cutting concern that pulses into several verticals at specific gates — security review, legal, compliance, design, accessibility, privacy. Verticals consume capacity continuously; horizontals consume it in bursts and gate other people's progress. Planning them with the same object, usually called an \"epic\", is why cross-cutting reviews are the most common cause of late-stage delay."}},{"@id":"https://www.deliverysheet.com/about#person","@type":"Person","jobTitle":"Founder","name":"Tan Gravam","url":"https://www.deliverysheet.com/about","sameAs":["https://gravam.com","https://twitter.com/TanGravam","https://github.com/TanGravam"]},{"@id":"https://www.deliverysheet.com/#logo","@type":"ImageObject","caption":"DeliverySheet","contentUrl":"https://www.deliverysheet.com/logo.png","inLanguage":"en","url":"https://www.deliverysheet.com/logo.png"},{"@id":"https://www.deliverysheet.com/#/schema/image/1","@type":"ImageObject","contentUrl":"https://www.deliverysheet.com/_og/s/o_12471cd3b6d5ba53.png","inLanguage":"en","url":"https://www.deliverysheet.com/_og/s/o_12471cd3b6d5ba53.png"}]} ``` ## Sitemap See the full [sitemap](https://www.deliverysheet.com/sitemap.md) for all pages.