Here is a statistic that should make you uncomfortable. According to PMI’s Pulse of the Profession research, 52% of projects experienced scope creep in the previous twelve months, up from 43% just five years earlier. In cloud infrastructure and platform engineering, where delivery cycles run to eight months or more and dependencies span networking, security, FinOps and application teams simultaneously, that figure is almost certainly higher. The Standish Group’s CHAOS research, which has tracked project failure since 1994, names an incomplete statement of requirements and constantly changing specifications among the top causes of failed delivery, while identifying a clear statement of requirements as one of the top three success factors. The uncomfortable truth about unclear project scope is not that it makes your work harder. It is that it makes your career harder, in ways that are slow, cumulative and easy to miss until the damage is done.
The instinct of a conscientious cloud engineer facing an under-specified project is to absorb the ambiguity and get on with it. This reads internally as professionalism. To senior stakeholders, it reads as something else entirely: availability. The engineer who takes unclear work and quietly delivers something becomes the reliable person to whom unclear work gets assigned. Meanwhile, the engineer who writes the RFC, surfaces the risk, names the dependency that nobody wanted to talk about, and gets the scope agreed before a single resource is provisioned gets associated with predictable delivery. The gap between those two career trajectories is not a gap in technical skill. IT Jobs Watch shows the median salary for a Senior Cloud Engineer sitting at around £75,000. The Staff and Principal band at UK financial institutions and technology companies begins at £130,000. That 70%+ jump is overwhelmingly a scope-and-influence gap, not a coding-skill gap.
The good news is that the escape from the scope trap is learnable. It does not require confrontational conversations or political manoeuvring. It requires four habits applied consistently at the start and during every significant delivery: anchoring scope in a written artefact before work begins, reframing ambiguity in the risk language that stakeholders already understand, interrogating assumptions at initiation rather than discovering them mid-sprint, and escalating scope changes formally rather than absorbing them silently. Engineers who build these habits get associated with successful, well-scoped delivery. Engineers who do not, however technically capable, repeatedly get associated with the overruns and re-work that follow when nobody agreed what “done” meant. The rest of this post explains how to build each habit, and why the evidence for doing so is considerably stronger than the industry’s cheerful willingness to ship against unclear requirements might suggest.
Why Cloud Projects Are a Scope-Trap Accelerator
Before treating this as a personal failure mode, it is worth understanding why cloud infrastructure projects are structurally more exposed to scope drift than most other engineering work.
A McKinsey survey of around 450 CIOs found that 75% of cloud migrations go over budget, with the average company spending 14% more in migration spend than planned each year. McKinsey estimated that this wasted spend threatens to wipe out more than $500 billion in shareholder value over the course of typical three-year migration programmes. The causes are not mysterious. Cloud migrations involve application-dependency mapping that is almost always incomplete at initiation, security and compliance requirements that expand as the scope of what is being moved becomes clearer, networking design decisions that cascade across every workstream, and business requirements that shift during the months it takes to actually move production systems. Each of these is a vector for scope to expand without anyone formally deciding it has.
The UK public sector provides the most documented examples of what happens when that expansion goes unchecked. The NHS National Programme for IT, initially estimated at around £2.3 billion over three years, ultimately cost an estimated £9.8 billion before it was dismantled in 2011. The National Audit Office later found that contract scope was unclear and much of the work to agree key contract parameters had to be completed after contract award. The Home Office Emergency Services Network was forecast at £6.2 billion in 2015 and had risen to £9.3 billion by 2019, with the NAO finding that the Home Office and Motorola had never agreed the true scope of Motorola’s role in integrating ESN systems end-to-end. HMRC’s Aspire contract, planned at around £4.1 billion, reached £10.4 billion: the NAO attributed the gap directly to HMRC commissioning much more work through Aspire than was modelled when the contract was let. These are extreme cases, but the root cause in each of them is not technical failure. It is scope that was never properly defined.
For the individual cloud engineer, the mechanism is the same at a smaller scale. When scope is ambiguous at initiation, the first consequence is that work expands to fill whatever the team can tolerate. The second consequence is rework. DORA’s State of DevOps research found that high-performing teams spend 49% of their time on new work and 21% on unplanned work or rework, while low-performing teams spend only 38% on new work and 27% on rework. That 6-point gap in rework percentage is the single most reliable signal of whether a team has scope under control, and every hour in the rework column is an hour not available for the cross-team, architectural, mentorship-and-influence work that defines performance at Staff and Principal level. DORA added rework rate as a fifth metric in 2024 precisely because reactive churn was the hidden drag the original four metrics did not capture.
The Behavioural Default That Keeps You Stuck
Understanding the mechanism does not automatically change the behaviour. The reason capable engineers keep absorbing unclear scope, even when they know better, traces to a combination of professional culture and psychology that is worth naming directly.
UK delivery culture prizes the engineer who quietly ships. The person who asks hard scoping questions in a kick-off meeting is read as a blocker, at least in the short term. The person who takes the ticket and gets on with it is read as a team player. The problem is that the culture’s time horizon is wrong. Quiet absorption of unclear work signals availability to stakeholders who have no particular interest in your career trajectory; it signals openness to receive more unclear work; and it guarantees that when the project overruns (which, per the statistics above, it usually does), the engineer who “owned” the technical work absorbs a share of the blame for a root cause they were never in a position to fix.
Amy Edmondson’s psychological safety research, which underpinned Google’s Project Aristotle study of 180 teams, is frequently misread as a mandate for niceness. Edmondson is explicit that this is the opposite of her finding. Psychological safety, as she defines it, is the belief that you will not be punished for speaking up, for admitting you do not know something, or for flagging a problem. It is the precondition for challenging assumptions, surfacing risks and saying “we cannot start this work until we agree what it includes.” A team where nobody pushes back on vague scope is not safe. It is silently accumulating risk.
Will Larson, in Staff Engineer, draws the distinction that matters for career progression. Senior engineers, he observes, typically receive well-scoped problems and are judged on execution quality. Staff engineers “have to find the problems worth solving” and are judged on the quality of their decisions, the risks they identified, and the ambiguity they navigated. The ability to define scope, not just deliver against it, is the primary behavioural difference between the two levels. As explored in our guide to high-stakes performance for cloud professionals, the transition to Staff is fundamentally a shift from execution identity to decision identity.
The Four-Move Playbook
Move One: Anchor Scope Before Work Starts
The most durable protection against scope drift is a written artefact, agreed by stakeholders, that exists before a single resource is provisioned. The specific format matters less than the habit of creating one.
RFCs (Requests for Comments) are the tool of choice at organisations including Google, Stripe and Shopify. An RFC proposes an approach and explicitly lists what is in scope and what is not. The non-goals section is, arguably, the most valuable part of the document: it records, with stakeholder agreement, what the team is deliberately not doing. Six months later, when a product manager asks why the solution does not include a feature that was never discussed, the non-goals section is the answer. Architecture Decision Records (ADRs), popularised by Michael Nygard, serve a complementary function. Where an RFC is written before work begins to gather input, an ADR is written at the moment a significant decision is made to capture why the boundary was drawn where it was. Together, they create what practitioners call the “memory of your architecture”: a timestamped record that prevents the decision amnesia that causes scope to quietly re-open months after it was closed.
The discipline is not onerous. A scope-anchoring document for a cloud workstream need not be longer than a single page: in-scope deliverables, explicit non-goals, key assumptions, and known cross-team dependencies, circulated for comment and signed off before work begins. The moment when you cannot get sign-off on the non-goals section is itself valuable information: it is the strongest possible signal that the project is not ready to start, and surfacing that signal early is exactly the kind of strategic judgement that promotion committees are looking for.
Move Two: Reframe Ambiguity as Quantified Risk
PMs, delivery leads and senior stakeholders are fluent in risk language. They often tune out when an engineer says “the requirements are vague” and pay immediate attention when the same engineer logs a risk entry that reads: “The data-migration workstream scope for the payments system integration is undefined. If not resolved by [date], delivery confidence for the Q3 milestone drops and the timeline slips by an estimated four to six weeks.”
Scope risk is a named, recognised category in project risk management. Translating ambiguity into the register converts it from a personal burden, something you are carrying privately, into a documented, jointly-owned decision with a named owner and a deadline. This does two things simultaneously. It makes the ambiguity visible to someone with the authority to resolve it, and it reframes you from the engineer complaining about vague requirements to the engineer managing risk well. The dependency-mapping equivalent in cloud migration terms is a formal application-dependency audit before any workstream begins: the research consistently shows that organisations conducting a readiness assessment of this kind have materially better migration outcomes.
The specific language of the risk entry matters. Write it in impact terms (timeline, budget, feasibility, downstream dependencies), not in technical terms. The person who needs to act on it is usually not an engineer. State the probability, the impact, the owner and the response plan. Then update the project status to amber if the risk is unresolved. A status colour change is not an act of aggression; it is an accurate representation of reality that forces a conversation that needs to happen.
Move Three: Interrogate Assumptions Before the First Sprint
The cheapest scope clarity is always bought at initiation. Michael Watkins’ STARS framework, from The First 90 Days, is worth applying not just to role transitions but to project initiations. Diagnosing whether a workstream is a Start-up (build from scratch), Turnaround (rescue a failing delivery), Realignment (course-correct before crisis) or Sustaining-success (maintain a healthy system) determines what kind of scoping approach is appropriate: a turnaround tolerates decisive scope cuts made quickly; a sustaining-success context requires consensus-building before any boundary is redrawn.
Beyond the situational diagnosis, the single most valuable question an engineer can ask at project kick-off is: “What are you assuming is true about this work?” The PMBOK definition of an assumption is a factor considered true, real or certain without proof, which makes assumptions a named source of risk. Getting every stakeholder to surface their assumptions in the first week of a project is a lightweight exercise that consistently exposes the hidden requirements, the infrastructure-team expectations, the “of course the networking team will handle that” beliefs, and the business-side “surely you’re including monitoring out of the box” assumptions that otherwise surface as scope expansions four months in.
For decision ownership, applying DACI (Driver, Approver, Contributor, Informed) to scope decisions specifically is more useful than RACI. The critical insight from the framework literature is that RACI lacks a clear Decider role, so teams using it for scope decisions routinely deadlock. DACI names a single Approver for every significant decision. For a cloud engineer, knowing who the Approver is for a scope change is half the battle: it means that when a scope expansion request arrives, you know immediately whose calendar you need to be in to get a decision, rather than spending two weeks watching it get batted between teams while the timeline slips.
Move Four: Escalate Scope Changes Formally, Not Personally
When scope expands mid-delivery, the instinct of most engineers is either to absorb it silently or to express frustration in a way that reads as interpersonal rather than structural. Neither approach serves the career.
The Staff-plus move is to escalate cleanly and visibly. The pattern that works: state the problem clearly in two or three sentences stripped of technical jargon; answer “so what” by quantifying the impact on timeline, budget or delivery confidence; state exactly what you need and by when, with a specific date; and update the project status to reflect that a decision is outstanding. This is not aggressive. It is accurate. The point is to convert a scope change from a personal burden into a documented, jointly-owned problem that sits with someone who has the authority to resolve it.
Two principles matter in how this is done. First, escalate the problem, not the person: the language should be “this dependency was not in the original scope and we need a decision on how to handle it,” not “the platform team added this at the last minute.” Second, reduce the surprise factor wherever possible. Stakeholders who receive scope-change escalations they were not pre-warned about feel blindsided; stakeholders who have been updated weekly that a particular risk was live and unresolved are much better positioned to respond calmly. The weekly status update, unglamorous as it is, is a fundamental tool of scope protection.
It is worth noting that this approach is entirely consistent with being a collaborative, trusted member of a team. The engineers who resist scope creep effectively are rarely the ones creating conflict; they are the ones who have made the boundaries and the trade-offs legible to everyone, so that when a scope change happens it is a joint decision rather than a unilateral one.
The Career-Protection Dividend
Everything above protects your delivery. The second-order benefit is that it protects your career in performance cycles and promotion discussions.
When a project overruns and the post-mortem begins, the engineer with a timestamped RFC defining the agreed scope, a risk register entry flagging the ambiguity months before it materialised, and an escalation trail showing they raised the scope change formally is demonstrably not the cause of the overrun. The engineer without that paper trail absorbs the blame by default, not because anyone is trying to be unfair, but because the absence of documentation creates a vacuum that the attribution conversation fills with the path of least resistance.
The promotion dynamic is the same. Staff and Principal promotion committees, per both Larson’s Staff Engineer framework and consistent practitioner accounts, care less about what you built and more about the decisions you made. Did you identify risks early? Did you say no to the wrong solutions? Did you navigate ambiguity effectively? A well-documented history of scope management, ADRs written before significant decisions, risk entries that pre-dated the problems they described, and escalation trails where you raised issues cleanly is the most legible possible demonstration of strategic thinking. This matters because promotions are lagging indicators: you are promoted once you are already operating at the next level, and the paper trail you build now is the evidence that makes that case.
The salary arithmetic is worth making explicit. The jump from Senior Cloud Engineer at around £75,000 to the Staff/Principal band at £130,000 to £180,000 represents an increase of 70% to 140% in base compensation. At that level, the technical skills are table stakes. The differentiating factor, consistently, is the ability to shape the work before it starts: to define what done means, to identify what is out of scope before someone assumes it is in, and to manage the boundary through delivery without either absorbing expansion silently or creating conflict. That is what scope discipline is, and it is why the engineers who have it compound their career value faster than those who rely on technical excellence alone. Our post on technical mentoring as career capital covers the related dynamic of how influence at scale, rather than individual execution, is what ultimately commands the top of the IC pay range.
Measuring Whether It Is Working
The clearest signal that scope discipline is paying off is a change in how you spend your time. If you are spending more than 25% of your working hours on unplanned work or rework, that is DORA’s low-performer benchmark and a reliable indicator that scope is not under control. The target, for teams with strong scope discipline, is under 21% combined unplanned-work-and-rework time, with the balance going to new, planned delivery.
At a career level, the signal is the quality of what you are being invited to. Engineers who have developed a reputation for scope clarity start getting pulled into project initiations rather than just mid-delivery delivery. They get asked to review RFCs and design documents before work starts. They get consulted on whether a given workstream is ready to begin. These are not merely nice-to-haves; they are the conditions under which the “Staff Projects” that Larson identifies as essential promotion evidence become available. High-visibility, multi-stakeholder, ambiguous deliveries where you are the person who defined what done meant are the career artefacts that justify a Staff or Principal title. They become accessible precisely because you have demonstrated that you are the engineer who, when handed ambiguity, produces clarity rather than quietly absorbing chaos.
The ROI of Scope Discipline
The investment in scope discipline at project initiation runs to four to eight hours of focused work: drafting the scope-anchoring document, circulating it, running the assumption-surfacing conversation, and setting up the DACI for scope decisions. The return on that investment, when it prevents a scope-driven overrun on a twelve-month cloud migration, is measured in weeks of wasted delivery effort avoided. On a team of five engineers at Senior-to-Staff level, four weeks of scope-driven rework represents roughly £35,000 to £55,000 in salary cost alone, before the indirect costs of delayed business outcomes and the reputational cost to the individuals attached to the programme.
The personal career ROI is harder to quantify in the same way, but the direction is clear. Engineers who consistently get associated with well-scoped, successful delivery move faster through the Senior-to-Staff transition, which is worth £50,000 to £100,000 per year in base salary at the point of transition, sustained for the rest of the career. The four hours at project initiation is not a small investment with a moderate return. It is one of the highest-leverage uses of time available to a cloud engineer targeting the top of the individual-contributor pay range.
Scope Traps to Avoid
Even with the four-move playbook in place, a handful of failure modes recur often enough to name directly.
The most common is treating the scope document as a one-time exercise rather than a living reference. An RFC or design doc written at initiation and never consulted again provides its protection only against challenges that arise in the first week. The engineers who get the most value from scope documentation are the ones who reference it explicitly in sprint reviews, in stakeholder updates, and in scope-change conversations: “That’s a great idea, but it’s outside the non-goals we agreed in the RFC in March. If we want to include it, we need to treat it as a change request and agree the timeline impact.”
The second failure mode is escalating scope changes in a way that reads as complaint rather than risk management. The language of the escalation matters as much as the act of escalating. “I’m struggling to deliver this because the requirements keep changing” and “There’s a scope risk on the data-migration workstream that needs a decision this week to protect the Q3 milestone” describe the same situation to very different effect.
The third is applying the frameworks too heavily in contexts where they create more overhead than value. On a small team with no cross-functional dependencies and a three-week delivery window, a full RFC process is bureaucracy, not discipline. The principle (define scope before work starts, document changes when they happen, escalate when you need a decision) scales down to fit the work. What does not scale is the habit of absorbing ambiguity silently, at any project size.
As explored in our post on the AI-augmented cloud engineer, the 2025 DORA research found that AI tooling amplifies the characteristics of the teams using it: engineers with strong scope and process discipline get more leverage from AI assistance, while engineers who already struggle with unplanned work find AI adds more interruptions rather than fewer. Scope clarity is becoming a force multiplier, not just a delivery hygiene practice.
Next Steps
The habits that constitute scope discipline are not complex, but they do need to be deliberately installed. Working through these in order will get you there faster.
- Write a scope-anchoring document for your current or next project before opening your IDE. One page: in-scope deliverables, non-goals, key assumptions, known dependencies. Circulate it and get explicit agreement from at least one stakeholder who has authority over the work.
- Audit your last three months of delivery time. Estimate accurately how much went to unplanned work or rework versus planned delivery. If the rework share is above 25%, that is the problem to solve, and scope discipline is the lever.
- For the next scope change request you receive, write a risk entry before responding. Quantify the impact. Name the owner. Set a decision deadline. Then escalate it in that form rather than absorbing it informally.
- Create an ADR for the last significant technical decision your team made. Back-filling the documentation for past decisions is useful practice and produces immediate value the next time that decision is challenged.
- Identify who the DACI Approver is for scope decisions on each of your active workstreams. If there is no clear Approver, that ambiguity itself belongs in the risk register.
The payoff from these five actions is visible within a single project cycle. The cumulative payoff, across several years of delivery where scope is consistently under control and the documentation exists to prove it, is a career trajectory that looks materially different from the alternative.
Useful Links
- DORA State of DevOps 2024 Report
- NAO: Managing and replacing the Aspire contract (2014)
- NAO: Universal Credit early progress (2013)
- NAO: The challenges in implementing digital change (2021)
- IT Jobs Watch: Cloud Engineer salary trends
- Will Larson: Staff Engineer (book)
- Michael Nygard: Architecture Decision Records
