Seven Tools, No Story: Why Your Delivery Pipeline Loses Context Between Intent and Outcome
The ticket said "Done." The CI pipeline was green. The deploy went through at 3:14 PM on a Thursday. And then the customer opened a support ticket on Friday asking why the feature they were promised three months ago still wasn't there.
Nobody lied. Nobody dropped the ball. The work happened. But somewhere between the product manager writing the requirement and the customer opening their browser, the thread snapped — and now nobody can explain where.
This is not a failure of discipline. It is a structural problem with how delivery information moves through modern engineering stacks.
The Seven-Tool Sprint
Count the tools in a typical sprint. Jira or Linear for tickets. GitHub or GitLab for code. Slack for decisions. Jenkins or GitHub Actions for CI/CD. LaunchDarkly or Unleash for feature flags. Datadog or Grafana for observability. Zendesk or Intercom when it breaks.
That is seven separate systems, each with its own data model, its own access controls, and its own idea of what "done" means. Jira's done means a ticket moved to the Done column. GitHub's done means a PR merged. CI's done means tests passed. Feature flags' done means the flag toggled. Observability's done means no alerts fired. Support's done means no tickets opened.
None of these definitions talk to each other. None of them hold the whole story.
The DORA State of DevOps research — published annually by Google Cloud and DORA — tracks what separates elite engineering teams from the rest. Elite teams aren't just faster; they maintain what the report calls "deployment stability." They can deploy frequently without breaking things because they have tight feedback loops. The key word is loops — not silos. Information flows back and corrects course. In fragmented stacks, information flows in but never back.
What Delivery Context Actually Is
Delivery context is the trail of decisions, signals, and dependencies that explains how a business requirement became a deployed outcome.
It is the why behind the what. Why was this ticket prioritized? Why did this PR exist? Why was the flag defaulted to off? Why did the incident on Wednesday matter to this feature?
When delivery context is intact, an engineer joining a three-month-old project can read back through the trail and understand every decision. When it is fragmented, they have to reconstruct it from archaeology — grep commits, dig Slack threads, find the Jira comment from a person who left the company.
Platform engineering teams at companies like Spotify, Netflix, and Airbnb didn't build internal developer platforms (IDPs) because they were bored. They built them because fragmented context was costing real money. The DORA research is consistent: low-performing teams spend 1.6x more time on unplanned work than elite teams. Unplanned work is almost always caused by context loss — somebody making a decision without the information that would have changed it.
The Gap That Builds Invisibly
Context loss is not an event. It is an accumulation.
A requirement gets written in a Google Doc, summarized into a Jira ticket, broken into sub-tasks, implemented across three PRs, deployed behind a flag, partially rolled out to 10% of users, and then abandoned when the sprint ended and the team moved on to the next thing. At each step, something gets left behind. The Doc never gets linked to the ticket. The sub-task doesn't say which PR covers it. The flag has no description. The rollout percentage has no owner.
Six months later, someone asks: why does this flag still exist? And nobody knows.
The question that exposes delivery context loss in any team is: "How long would it take you to explain the full history of this feature to a new engineer?" If the answer is more than thirty minutes, context has already been lost. If the answer is "we'd have to pull it together from multiple systems," you have fragmented delivery.
Teams normalize this. They call it tribal knowledge. They call it documentation debt. They write runbooks. None of it fixes the structural problem that seven separate systems are each holding a different slice of the same story with no mechanism to stitch them together.
[This problem has a close cousin in developer cognition — the cognitive cost of managing too many tools is a separate but related issue explored in the post on AI and developer tool overload.]
Platform Engineering as a Context Layer
The IDP movement is, at its core, a delivery context problem in search of a solution.
Tools like Backstage (open-source, from Spotify), Port, and Cortex all make the same bet: that a unified layer above your existing tools — not replacing them, but connecting them — creates the context trail that teams currently reconstruct by hand.
The mechanism is service catalog plus dependency graph plus activity feed. Every service knows its owners, its dependencies, its deployment history, its on-call runbook, and its relationship to the business domain that commissioned it. When an incident fires, you don't start from scratch. The IDP is already holding most of the context.
Backstage has over 1.4 million weekly downloads as of 2024 and is adopted by companies including American Airlines, Spotify, and Netflix. It is not a niche experiment. It is what happens when teams get serious about delivery context at scale.
The 2023 Humanitec Platform Engineering Report found that 94% of platform engineers cite "reducing cognitive load" as a primary goal. They are not building pretty dashboards. They are building context systems.
Why This Is Harder Than It Looks
The technical architecture of an IDP is not the hard part. Most engineering teams can wire together APIs, build a service catalog, and pipe deployment events into a central feed.
The hard part is discipline around context creation at the source.
If the Jira ticket has no acceptance criteria, the IDP can only surface an empty ticket. If the PR has no description linking it to the requirement, the IDP shows an orphan commit. If the feature flag has no expiry date and no owner, the IDP surfaces technical debt it cannot resolve.
IDPs amplify the quality of context that goes into them. They do not create context from nothing.
This means the real organizational change is upstream: teams need to treat context creation as part of the work, not documentation added after. The PR description is not overhead. It is the explanation of why the code exists. The Jira ticket's acceptance criteria are not bureaucracy. They are the definition of done that every downstream system will inherit.
The teams that get the most out of platform engineering are the ones that understood this before they built the IDP. The teams that struggle built the tool and then discovered they were surfacing chaos in a cleaner interface.
The Metric That Matters
DORA tracks deployment frequency, lead time, change failure rate, and time to restore service. These are the right measures of delivery performance.
But there is an informal metric that platform teams talk about internally: mean time to explain (MTTE). How long does it take to reconstruct what happened to a feature from first ticket to customer hand? Elite teams have short MTTEs because the context is preserved. Struggling teams have long MTTEs because every reconstruction is an expedition.
MTTE does not appear on any dashboard. It shows up in how long your postmortems take, how many people need to be in the room to answer one question, and how often you hear "let me go look that up" in planning meetings.
The seven-tool sprint is not going away. Adding an eighth tool that actually stitches the story together might be the most valuable engineering investment a team makes this year.
Photo by Daniil Komov via Pexels