Back to blog

The Five Levels Nobody Told You About: From Junior Dev to CTO

The real hierarchy of technical talent - from junior dev to CTO - and why understanding these levels prevents expensive hiring mistakes.

hiringlevelscareermarket-education

Header image

The Five Levels Nobody Told You About: From Junior Dev to CTO

Most companies talk about “junior vs senior” like there are only two settings:

  • Cheap
  • Expensive

Reality is more like five distinct levels of impact, each with a completely different scope and economic value.

If you don’t understand these levels, you:

  • Overpay the wrong people
  • Underpay the right people
  • Promote based on vibes
  • And end up wondering why your “senior dev” can’t unfuck your platform

Here’s the map nobody gave you.

1. The Five Levels (as I actually see them)

You’ll see different naming schemes in different orgs, but functionally:

  1. Junior Developer – Learner. Needs direction.
  2. Mid-Level Developer – Solid executor. Can own well-defined chunks.
  3. Senior Developer – Owns features and domains. Trusted problem-solver.
  4. Principal / Staff Engineer – Cross-cutting technical leadership. System-level thinking.
  5. Architect / CTO – Owns the whole system as a business asset. Strategy + risk + org impact.

Titles are noise. Scope is everything.

2. Level 1 – Junior Developer

What they do:

  • Implement tasks with clear specs.
  • Fix bugs where the blast radius is small.
  • Learn the stack, tools, and domain.

Scope:

  • One function, one module, one feature at a time.
  • Needs reviews, guardrails, and guidance.

Value:

  • Great for:
    • repetitive implementation work
    • internal tools
    • low-risk improvements

Cost (rough order of magnitude, US):

  • Salary: ~$70K–$100K
  • Hourly contractors: maybe $35–$60/hr

Biggest misconception:

“We’ll hire juniors and they’ll grow into seniors and architects and fix everything.”

No. Not without serious mentorship and leadership above them.

3. Level 2 – Mid-Level Developer

What they do:

  • Can take a user story or feature and get it done with minimal hand-holding.
  • Understands the existing patterns and mostly follows them.
  • Does decent design within the box they’ve been given.

Scope:

  • Owns features end-to-end under an existing architecture.
  • Solid at:
    • CRUD + validation
    • hooking up APIs
    • integrating within known boundaries

Value:

  • They’re your “workhorse devs.”
  • They keep feature velocity going.

Cost:

  • Salary: ~$100K–$140K
  • Hourly: ~$60–$90/hr

Biggest misconception:

“A few good mid-level devs are all we need.”

They’ll build a lot of code.
Whether that code forms a coherent, long-lived system is not their job.

4. Level 3 – Senior Developer

What they do:

  • Architect within a domain:
    • Picks patterns
    • Chooses libraries
    • Designs sane data models and flows for specific features or subsystems
  • Can debug ugly, cross-module issues.
  • Mentors juniors and mids.

Scope:

  • Owns one or more domains:
    • e.g., billing, onboarding, reporting
  • Trusted to:
    • design & implement
    • anticipate edge cases
    • avoid obvious footguns

Value:

  • They move beyond “code monkey”:
    • They see tradeoffs.
    • They care about maintainability in their area.
  • They reduce drag for the rest of the team.

Cost:

  • Salary: ~$130K–$180K+
  • Hourly: ~$90–$150/hr

Biggest misconception:

“Our senior dev can handle overall architecture and CTO-level thinking.”

Sometimes one person can span both. Usually they can’t, and you burn them out by dumping strategic risk on someone hired for feature ownership.

5. Level 4 – Principal / Staff Engineer

What they do:

  • Think in systems, not features:
    • data flows
    • failure modes
    • performance characteristics
  • Set technical direction:
    • patterns that others follow
    • guardrails for future changes
  • Work horizontally:
    • connect teams
    • kill bad patterns before they spread
    • solve cross-cutting problems

Scope:

  • The whole codebase, or large chunks of it.
  • Multiple teams / domains.
  • Often the person others go to when “nobody else can figure it out.”

Value:

  • They prevent:
    • fragmentation
    • incompatible designs
    • people reinventing the same thing six ways
  • They are leverage:
    • One principal can unblock and guide 5–15 devs.

Cost:

  • Salary: ~$170K–$230K+ (often more in big markets)
  • Hourly: ~$150–$250/hr+

Biggest misconception:

“Principal = super-senior dev who just codes harder.”

No. The real value is in the design, diagnosis, and prevention, not line count.

Scope visualization

6. Level 5 – Architect / CTO

You can split these into two roles, but the core is the same: this level thinks about systems as business assets, not just code.

What they do:

  • Decide:
    • what to build,
    • how to structure it,
    • what not to build.
  • Own:
    • architecture,
    • risk,
    • long-term viability.
  • Translate between:
    • business goals,
    • constraints,
    • tech realities.

Scope:

  • Entire platform.
  • Entire tech org.
  • Contracts, SLAs, compliance, and how the system behaves under real-world stress.

Value:

  • They can:
    • prevent catastrophic rewrites,
    • avoid multi-million dollar mistakes,
    • design systems that last a decade+.
  • Their decisions affect:
    • revenue,
    • margin,
    • churn,
    • company valuation.

Cost:

  • Salary (full-time CTO): $200K–$400K+ depending on stage/market.
  • Fractional architect/CTO: effectively $250–$600/hr+ depending on engagement.

Biggest misconception:

“They’re just expensive coders.”

No. They should be writing fewer lines of code and making more decisions that keep everyone else’s code from torpedoing the business.

7. The 100x Value Difference

Is an architect “100x more productive” line-for-line than a junior dev? No.

But in value terms, yes, easily.

Example:

  • A junior dev:

    • Implements a feature that saves support staff 10 hours/month.
    • Over a year, that’s maybe a few thousand dollars of value.

  • An architect:

    • Makes a call that avoids a $5M rewrite.
    • Or designs the system in a way that keeps a $2M/year contract from churning due to reliability.
    • Or structures the platform so adding new products is cheap instead of painful.

Same time input (a few weeks of thinking and decisions)
completely different value surface area.

That's the 100x.

The 100x difference

8. Real Project Examples by Level

Same company, different levels.

Junior:

  • Builds the UI for updating customer info.
  • Adds fields, hooks up form validation, fixes small bugs.

Mid-Level:

  • Owns “Customer Profile” feature.
  • Implements:
    • forms,
    • endpoints,
    • simple permissions,
    • tests.

Senior:

  • Designs the entire “Account & Identity” domain.
  • Normalizes how users, orgs, roles, and permissions are modeled.
  • Makes sure that:
    • a year from now, you’re not hacking permissions into 12 places.

Principal / Staff:

  • Realizes:
    • reporting and billing need consistent identity + account data.
  • Aligns data models across teams.
  • Adds events and read models so every team isn’t querying production tables raw.
  • Removes performance and coupling landmines before scale hits.

Architect / CTO:

  • Decides:
    • how identity ties into external SSO providers,
    • how multi-tenant vs single-tenant customers are handled,
    • what compliance and audit requirements mean for logging and data retention.
  • Signs off on:
    • which parts must be boring and durable,
    • where it’s safe to experiment.

Same arena (identity/accounts), wildly different impact.

9. The Market Failure: Why Companies Hire Wrong

Common failure modes:

  • Hiring a senior dev and expecting them to:
    • fix architecture,
    • own infra strategy,
    • carry CTO responsibilities.
  • Hiring a CTO who is really a dev lead:
    • they spend all their time coding and reviewing PRs,
    • nobody owns risk and long-term design.
  • Treating titles as interchangeable:
    • “We have a principal engineer, so we’re covered,”
    • when they’re actually operating as a high-end feature dev.

Why it happens:

  • Non-technical founders don’t understand the levels.
  • Technical leads are often too busy to articulate the difference.
  • Job descriptions are written by HR and copy-pasted from LinkedIn.

Result:

  • Underpowered people thrown at over-scoped problems.
  • Burnout at the top.
  • Architecture by accident.

10. Career Progression: How You Actually Move Through These Levels

This is not:

  • “X years of experience”
  • “Y languages on a resume”

It’s about what problems you own and how you think.

Roughly:

  • Junior → Mid:

    • You can take a ticket and get it done without hand-holding.
    • You understand the stack enough to make small decisions.

  • Mid → Senior:

    • You stop just “writing code that works” and:
      • think about edge cases,
      • think about maintainability,
      • think about how your piece fits into the system.
    • You mentor others.
    • People trust you with ambiguous features.

  • Senior → Principal:

    • You zoom out:
      • “How do these systems interact?”
      • “How do we avoid painting ourselves into a corner?”
    • You care deeply about:
      • boundaries,
      • patterns,
      • shared infrastructure.
    • You’re pulled into cross-team messes, not just your own.

  • Principal → Architect / CTO:

    • You start thinking in:
      • contracts,
      • SLAs,
      • compliance,
      • hiring,
      • budgets.
    • You weigh tech decisions against:
      • revenue,
      • margin,
      • risk.
    • You say “no” or “not now” a lot more.

What people get wrong:

  • Trying to “skip levels” without ever owning the problems at the current level.
  • Measuring progress by:
    • framework count,
    • language count,
    • “years of experience,” instead of scope and impact.

If You’re a Dev

Figure out:

  • What level you’re actually operating at.
  • What level you want.
  • What problems that level owns.
  • Then deliberately go after those problems, not just new tools.

If You’re a Founder / Manager

Stop asking:

“Is this person senior?”

Start asking:

“What is the largest problem I can safely hand this person and not worry about it?”

That answer tells you their level.

And if you expect CTO-level outcomes from a mid-level dev "because they're smart," you're not being frugal.

You're being reckless.

Context → Decision → Outcome → Metric

  • Context: Companies hiring developers without understanding scope differences; expecting senior devs to solve architecture problems; promoting based on seniority rather than scope ownership.
  • Decision: Developed a five-level framework based on scope (junior → mid → senior → principal → architect/CTO) and trained myself to assess hires and promotions based on "what's the largest problem I can safely hand them?"
  • Outcome: Teams staffed appropriately for the problems at hand. Fewer burned-out senior devs carrying CTO responsibilities. Better matches between role expectations and actual capability.
  • Metric: When architecture decisions were made by architect-level thinkers, zero full rewrites needed. When dumped on senior devs, multiple near-rewrites and extended timelines.

Anecdote: The Senior Dev Who Burned Out

In 2017, a startup hired a great senior developer. Smart. Fast. Shipped features like crazy.

Then they asked him to also handle architecture. And infrastructure decisions. And vendor selection. And technical due diligence for a potential acquisition.

He tried to do it all. For about eight months, he looked like a hero.

Then he burned out. Left the company. The codebase he'd built was excellent at the feature level but had no coherent architecture underneath. The next team spent six months untangling decisions that should have been made at a different level.

The company didn't need a "senior dev who could also do CTO stuff." They needed a senior dev AND a fractional architect. They got neither by asking one person to be both.

Anecdote: The 100x Question That Clarified Everything

A founder asked me: "Why should I pay $400/hour for an architect when I can get a dev for $100/hour?"

I asked back: "What's the largest problem you can safely hand to the $100/hour dev?"

He thought for a moment. "A feature. Maybe a small module."

"And what's the largest problem you need solved right now?"

"Whether to rebuild our platform or try to scale what we have. That decision is worth probably $2-3 million over the next three years."

"So you're asking a feature-level person to make a platform-level decision?"

He hired the architect.

Mini Checklist: Matching Level to Problem

  • [ ] Identified the scope of the problem: feature, domain, system, or platform?
  • [ ] Matched the hire/promotion to the scope: juniors for tasks, seniors for domains, principals for systems, architects for platforms
  • [ ] Stopped asking senior devs to carry CTO responsibilities without the title, scope, or pay
  • [ ] Used the "largest problem I can safely hand them" test for assessing candidates
  • [ ] Understood that 100x value difference comes from scope of impact, not speed of typing
Back to blog