TL;DR
- Cloud engineers plateau at senior not because they lack skills, but because they've expanded technical depth without expanding their accountability surface. More certifications don't fix this - the gate is scope-shaped.
- The single biggest plateau: senior engineers who keep taking on harder tickets without ever owning a cross-team problem. They're going deeper, not wider, and promotion to Staff requires demonstrable width.
- Compensation arc (general US ranges): Junior $85-115K, Senior $115-155K, Staff/Principal $150-200K+ depending on cloud platform depth and architecture scope.
- Realistic timeframe: Junior to Senior takes 3-5 years with deliberate scope expansion. Senior to Staff/Principal takes 4-8 more years and is driven by visible cross-team impact, not certification count.
- Will Larson's Staff Engineer (2021) documented that promotion to Staff/Principal requires a "Staff Project" - a project with multi-stakeholder, cross-team evidence. Most cloud engineers don't know this is what's being evaluated.
- Career advancement is one of the top goal types in recent MentorCruise applications - and 65.3% of all applicants explicitly ask for a structured roadmap rather than open-ended advice.
The cloud engineer level ladder
The first thing I do with a cloud engineer who's stuck is run through this ladder. Not to tell them where they should be - to show them exactly what the gate looks like at the next level. Most people I work with have been measuring the wrong thing. The table below is the map. Find your level, then read that phase.
| Level | Typical tenure | What unlocks advancement | Most common plateau |
|---|---|---|---|
| Junior | 0-2 years | Consistently delivering assigned infrastructure tasks without supervision; owning one platform component end-to-end | Waiting for assignments rather than proactively identifying improvement opportunities |
| Mid | 2-5 years | Owning a system or service end-to-end; making architecture decisions within the team without senior sign-off on every choice | Deepening cert knowledge and tool coverage while staying inside team scope - never owning a cross-functional problem |
| Senior | 5-8 years | Cross-team infrastructure influence: architecture patterns other teams adopt, cost optimization programmes with measurable savings, ownership of an SLA across multiple services | Accumulating certifications without expanding accountability surface - the "stuck senior" pattern |
| Staff/Principal | 8-12 years | Defining the infrastructure strategy that shapes how the entire engineering org builds on cloud; documented "Staff Project" with multi-stakeholder evidence (Larson 2021) | Taking on coordination-adjacent work instead of building the technical-influence record that makes the Staff case |
| Distinguished/VP Eng | 12+ years | Org-wide cloud strategy ownership; published or internally recognized frameworks; cross-org cost and reliability accountability | Trying to skip from Senior to this level without building the Staff-level influence record first |
Where are you now?
Before you read the phase sections, answer these five questions. They're designed to be uncomfortable - they're not asking whether you're good at your job. They're asking about the accountability surface you've built. The answers will tell you where your work actually is on the ladder, not where your job title is.
- Do you own the architecture decision on at least one of your team's systems - meaning the final call is yours, not a senior's rubber stamp?
- Have you driven a change that was adopted by engineers outside your immediate team (a new IaC pattern, a shared module, a cost reduction initiative)?
- Have you written a credible business case for a cloud infrastructure investment and had it accepted by a non-engineering stakeholder (product manager, finance, or a VP)?
- Are you the named DRI when something goes wrong in your platform area at 2am?
- Has a junior or mid engineer from another team sought you out specifically because of your platform expertise - not just your availability?
Routing key:
- Yes to 1-2: you're at Junior-Mid. Start at Phase 1.
- Yes to 3: you're at Mid. Start at Phase 2.
- Yes to 4: you're at Senior. Start at Phase 3.
- Yes to 5: you're approaching Staff. Start at Phase 4.
Phase 1: Junior - becoming reliable
What I see in junior cloud engineers who get stuck here: they're optimizing for tool coverage. AWS this week, Kubernetes next month, Terraform after that. The issue isn't the tools. It's that they're chasing breadth before proving reliability on a single platform. The Phase 1 gate isn't another cert. It's becoming the person who owns a specific infrastructure component and makes it not your manager's problem anymore.
What we keep seeing in MentorCruise applications at this level: engineers who know roughly where they need to go but can't translate direction into a concrete ownership record. The first step is stopping the cert chase long enough to ask: what do I actually own?
| Dimension | Pre-role / first week | This phase |
|---|---|---|
| Scope | Observing and completing specific tasks assigned | Owning one component end-to-end (e.g. the CI/CD pipeline, the staging environment) |
| Decision ownership | Every change reviewed by senior | Autonomous on implementation; escalates architecture questions |
| Stakeholder surface | Team only | Occasional cross-team dependency (shared services, handoffs) |
| Failure mode | Needing help with basic tasks | Staying in task execution mode - waiting for assignments rather than spotting problems |
Before you move to Phase 2, you need:
- Own at least one infrastructure component end-to-end without requiring senior sign-off on routine changes
- Demonstrate one instance of identifying and fixing a problem before being asked
- Completed one production incident response - not just observation, but documented RCA ownership
- Deployed one production-grade IaC module (Terraform, CDK, Pulumi, or equivalent) that another team member actively uses
If you're working through these milestones and want accountability on the scope-expansion piece, a cloud mentor at this level is most useful for IaC best practice review and the end-to-end ownership conversation. See also the cloud certifications guide for cert sequencing specific to Phases 1-2.
Phase 2: Mid - expanding scope
The mid-level plateau I see most often in cloud engineering applications: an engineer with three years of experience and a SAA-C03 who has never owned a cross-team problem. They're technically skilled. They can explain Kubernetes networking to anyone. But when I ask "what has changed in how your organization builds on cloud because of you?" - silence. That question is the Phase 2 gate.
The engineers who get stuck here are often the most technically impressive people on their team inside their team scope. They've gone deep on certifications, they're reliable, they solve problems fast. What they haven't done is taken on a problem that sits outside their team's boundary. The pattern I keep seeing: three years in, solid cert stack, but no ownership record beyond team scope. The challenge isn't technical skill - it's translating direction into a prioritized roadmap and making credible business cases to leadership. That's the Phase 2 gap.
| Dimension | Phase 1 | This phase |
|---|---|---|
| Scope | Single component | System or service end-to-end |
| Decision ownership | Implementation only | Architecture decisions within the team - yours to make |
| Stakeholder surface | Team | Adjacent teams (shared services, cross-team dependencies) |
| Failure mode | Waiting for assignments | Being the most technically skilled person inside team scope, never outside it |
Before you move to Phase 3, you need:
- Designed and implemented a system-level change that affects at least two other teams (e.g. a shared service, a multi-account IAM architecture, a new observability stack adopted by other teams)
- Run one cost optimization exercise with documented before/after results - not just flagged, but executed and measured
- Made at least one architecture decision that was documented, challenged, and defended without a senior engineer's override
- Mentored a junior engineer on a specific infrastructure problem and can describe what they learned from it
Phase 3: Senior - moving from execution to influence
Senior is where I see the widest gap between what engineers think is required and what actually opens the next conversation. Most senior cloud engineers I work with are technically excellent - the stall is the same thing that stalled them at mid: solving harder technical problems without increasing their accountability surface. Will Larson's Staff Engineer: Leadership Beyond the Management Track puts it directly - the gate isn't skills, it's demonstrated cross-team influence. The specific mechanism he documents: promotion to Staff/Principal requires a "Staff Project" - a project with documented multi-stakeholder, cross-team evidence. That's the evidence record most senior engineers don't know they need to be building.
What changes at this phase is the nature of the accountability. At Mid, you owned a system inside your team. At Senior, you own infrastructure decisions that other teams build on top of. The shift from "our team's architecture" to "the patterns other teams adopt" is the scope expansion that opens the Staff conversation.
| Dimension | Phase 2 | This phase |
|---|---|---|
| Scope | System/service | Cross-team infrastructure patterns - standards other teams adopt |
| Decision ownership | Team architecture | Defining what the team and adjacent teams build on top of |
| Stakeholder surface | Adjacent technical teams | Engineering leadership + product + finance (cost accountability) |
| Failure mode | Staying inside technical excellence | Not translating technical impact into business-impact language that leadership can act on |
Before you move to Phase 4, you need:
- Documented at least one architecture decision that was adopted as a standard by teams you don't manage
- Delivered at least one cloud cost optimization programme with measurable, reported savings ($50K+ annualised is a reasonable floor for mid-size orgs)
- Ran a project involving at least 3 stakeholders outside your immediate engineering team
- Named as the DRI on a platform SLA or reliability commitment for a system other teams depend on
For the cross-team architecture decisions specifically - a system design mentor at Phase 3 is useful for the "how do I structure the multi-stakeholder architecture decision record" conversation that the Staff Project framework requires.
Phase 4: Staff/Principal - building the platform strategy
A pattern I keep seeing in MentorCruise conversations - engineers moving into roles they haven't operated at before - has a common shape. They know the technical problem. They don't know how to build the organizational case for the solution. Staff and Principal cloud engineers aren't doing harder technical work. They're doing harder translation work: turning infrastructure decisions into engineering-org strategy, and building the evidence record that makes that translation credible.
The specific thing that separates Phase 4 from Phase 3 isn't scope - it's scope level. At Senior, you're defining standards that adjacent teams adopt. At Staff/Principal, you're defining the platform direction that shapes how the entire engineering organization builds on cloud. And the evidence record required to make that case - Will Larson calls it a "Staff Project" in Staff Engineer: Leadership Beyond the Management Track - is a project with documented multi-stakeholder, cross-team evidence. Most engineers who plateau before Staff have the technical ability. They don't have the documented multi-stakeholder record.
| Dimension | Phase 3 | This phase |
|---|---|---|
| Scope | Cross-team standards | Engineering-org platform strategy |
| Decision ownership | Standards adopted by teams you don't manage | Org-wide platform decisions - you own the recommendation |
| Stakeholder surface | Engineering leadership | CTO/VPE + finance + product leadership |
| Failure mode | Being a "super-senior" doing faster, harder IC work | Missing the translation layer between technical decisions and business impact |
Operating at Staff/Principal level looks like:
- Can name a platform decision you made that materially changed how your engineering org builds - not how your team builds
- Have a documented "Staff Project" with multi-stakeholder evidence - Will Larson's definition is the one to use (staffeng.com/book/)
- Regularly present infrastructure strategy to engineering leadership, not implementation plans
- Are the named person your org looks to when a significant cloud cost or reliability question needs an answer at the leadership level
An architecture mentor is most useful at this phase for org-level platform strategy. For the translation layer - converting technical decisions into business-strategy language for CTO or VP-level conversations - a leadership mentor provides the complementary framing.
Common roadblocks
The roadblocks that stop cloud engineers advancing aren't random. They cluster. I've listed the five most common ones here - each with the mechanism behind it and the specific thing that actually resolves it. Read the "Why it happens" column carefully. Most of the time, engineers misdiagnose the problem, which is why what they've been trying isn't working.
| Roadblock | Why it happens | What actually unlocks it |
|---|---|---|
| Stuck at senior with 7 years' experience | Adding certifications and deeper technical skills without expanding the accountability surface - the scope isn't growing, just the complexity of the tickets | Take on a cross-team project where you are the named architecture owner, not a participant |
| Can't make the business case for infrastructure investment | Technical framing only - cost savings expressed as performance metrics, not financial impact | Translate every cost optimization or reliability improvement into a dollar figure or risk-reduction statement before presenting upward |
| Gets passed over for Staff despite strong engineering output | Strong IC output but no "Staff Project" evidence - no single project with documented multi-stakeholder, cross-team impact | Identify one project in the next quarter where you can create the multi-stakeholder record, then document it explicitly with Larson's framework |
| Platform generalist who can't differentiate | Multi-cloud breadth without a depth story - can do everything adequately but nothing demonstrably better than specialists | Choose one cloud platform to become the authoritative resource on within your org; build depth that generates internal demand |
| Keeps solving the same class of problem | Comfort with execution over strategy - reverts to building when asked to design | Practice writing ADRs (Architecture Decision Records) first, building second; the writing forces the strategic framing |
Tools and resources
I'm not going to give you a certification list. Everything here is mapped to the phase where it's actually useful. Most of the Phase 1-2 resources are for building the reliability and ownership habits. Phase 3-4 resources are for building the evidence record and the language to make the case. Don't read ahead - use what's relevant to where you are.
Phases 1-2 (Junior to Mid):
- Cloud mentor on MentorCruise - for scope-expansion accountability and IaC best practice review at this level
- Cloud certifications guide - for cert sequencing specific to Phases 1-2
Phase 3 (Senior):
- System design mentor - for cross-team architecture decisions and scope expansion beyond your team
- Will Larson, Staff Engineer: Leadership Beyond the Management Track - the source for the Staff Project concept. staffeng.com/book/ is free to read; the book is available on Amazon.
Phase 4 (Staff/Principal):
- Architecture mentor - for org-level platform strategy
- Leadership mentor - for the translation layer between technical decisions and business strategy
If you're working through the scope-expansion problem at Phase 3 or Phase 4, the right cloud mentor is someone who has already navigated the Staff transition - not just someone who's technically strong. We accept fewer than 5% of mentor applicants. There's a 7-day free trial, so there's no commitment to finding out if the match is right.
FAQs
Four questions I get consistently from cloud engineers at every level. Each answer opens with the direct answer - no restating the question, no "it depends" openers. If you have a question that's not here, it's probably answered in one of the phase sections above.
How long does it take to reach Senior Cloud Engineer?
Most cloud engineers reach Senior in 4-7 years - but that range is wide because it tracks accountability expansion, not time served. Engineers who actively seek cross-team scope in years 2-4 consistently reach Senior faster than those who go deep on certifications without expanding ownership. The timeline compresses when you're deliberate about the Phase 2 milestone gates.
Do certifications actually matter for advancement?
Yes - at Phases 1 and 2. A relevant certification (AWS SAA, GCP ACE, CKA) signals technical foundation and opens doors to roles and conversations. Past Senior, certifications stop being advancement levers. What opens the Staff conversation is the evidence record: documented cross-team impact, a Staff Project with multi-stakeholder evidence, cost accountability. No certification substitutes for that.
What separates a Senior from a Staff/Principal Cloud Engineer?
The gap is scope of accountability, not technical skill. A Senior Cloud Engineer owns systems and standards within their team and adjacent teams. A Staff/Principal owns the platform strategy that determines how the entire engineering org builds on cloud. The specific gate is what Will Larson calls a "Staff Project" in Staff Engineer: Leadership Beyond the Management Track (2021) - a cross-team, multi-stakeholder project with documented impact. That's the evidence record that makes the promotion case.
Is it better to specialise on one cloud platform or stay multi-cloud?
Specialise first. At Phases 1-3, depth on one platform (AWS, GCP, or Azure) builds the authoritative internal reputation that generates cross-team demand. Multi-cloud breadth becomes relevant at Phase 4 when you're building org-level strategy across platforms. Engineers who try to cover all three platforms at Phase 2 often end up as generalists with no differentiation story - which is the platform-generalist roadblock in the table above.
