The Map of Tech Careers: What Do You Actually Want to Become?

CTO, Staff Engineer, Product Manager, Engineering Manager, Principal Engineer, Fractional CTO… Tech has hundreds of titles, but titles tell you surprisingly little. This is a framework for understanding what these jobs actually mean, and figuring out which kind of work fits you.

Introduction: I Realized I Didn’t Really Understand Tech Titles

I’ve worked in tech for years, yet the deeper I went into the industry, the more confusing job titles became.

Software Engineer makes sense.

Then you encounter Staff Engineer, Principal Engineer, Engineering Manager, Tech Lead, Architect, Head of Engineering, VP Engineering and CTO.

Move slightly toward Product and suddenly there are Product Manager, Product Owner, Technical Product Manager, Project Manager, Program Manager, Technical Program Manager, Group Product Manager and CPO.

Then come titles such as Fractional CTO, Interim CTO, Technical Advisor, Consultant, Solutions Architect, Developer Advocate and Founding Engineer.

At some point, asking “Which title is above which?” stops being useful.

A CTO at a five-person startup and a CTO at a 5,000-person company may share a title while doing almost completely different jobs. A Staff Engineer may have more organizational influence than some managers while having nobody reporting to them. A Tech Lead might be a formal position at one company and simply a temporary responsibility assigned to a Senior Engineer at another.

And becoming an Engineering Manager isn’t necessarily a promotion from Senior Engineer. It may actually mean changing careers.

So I started with one question:

How is work actually divided inside technology companies?

But that led to a more personal and interesting one:

What kind of work do I actually want to spend my career doing?

This article is my attempt to build a map: not a hierarchy of impressive titles, but a map of problems, responsibilities, scope, leverage and career directions.

Part I: Stop Thinking in Titles

A common mental model of a technology career looks something like:

Junior
  |
Engineer
  |
Senior
  |
Tech Lead
  |
Engineering Manager
  |
Director
  |
VP Engineering
  |
CTO

It looks reasonable.

It is also misleading.

It mixes levels, roles, responsibilities and career tracks.

A Tech Lead may still be an Individual Contributor. An Engineering Manager has moved into a different kind of work. A Staff Engineer may be at a comparable organizational level to a manager while managing nobody. A CTO isn’t necessarily the “highest-level engineer.”

The deeper problem is that we’re trying to represent a multidimensional career using a one-dimensional ladder.

Title, role, level and scope are different things

Title: What are you called?

Examples include Senior Software Engineer, Staff Engineer, Engineering Manager, Product Manager and CTO.

A title is primarily an organizational label. It helps with communication, recruiting, compensation and organizational structure, but titles aren’t standardized between companies.

Role: What function are you performing?

A role describes the kind of contribution expected from you.

Someone might formally be a Senior Software Engineer while performing the role of technical lead for a project. In some organizations, Tech Lead is an actual position. Elsewhere, it is a responsibility.

Level: How demanding is the work expected from you?

Level is better understood through dimensions such as complexity, autonomy, impact, judgment, leadership and influence.

Level is not the same as years of experience.

Years can help you acquire the capabilities required for a level. They don’t automatically create them.

Scope: How large is the territory affected by your work?

A useful rough model is:

Task
  → Feature
    → Project
      → System
        → Team
          → Product
            → Domain
              → Multiple teams
                → Function
                  → Company

The better question is often not “What’s above Staff Engineer?” but:

How does the expected scope change from Staff to Principal in this organization?

Scope alone doesn’t determine seniority

A company-wide system isn’t automatically more difficult than an exceptionally complex critical subsystem. Managing ten people isn’t automatically more senior than influencing five teams without authority.

We also need complexity, autonomy, accountability, authority, influence, time horizon and ambiguity.

The dimensions underneath a tech career

Scope

How much territory does your work affect?

Task → System → Team → Domain → Organization → Company

Complexity

How difficult are the problems you’re trusted to solve?

Senior work increasingly shifts from “implement this” toward “we know something is wrong; figure out what.”

Autonomy

How much direction do you need?

Progression often moves from receiving instructions about implementation toward determining the solution, and eventually helping determine which problems deserve attention.

Accountability

What outcomes are you answerable for?

At senior levels, you increasingly become accountable for outcomes you cannot personally execute.

Authority

What can you formally decide because of your position?

Influence

What can you change when nobody reports to you?

This becomes critical for Staff and Principal engineers, Product Managers, architects and advisors.

Time horizon

Are you optimizing for today’s implementation, the quarter, next year’s architecture or a multi-year technology strategy?

Ambiguity

How incomplete can the problem be before you’re expected to make progress?

At high levels, you may first need to construct the problem itself before solving it.

Part II: Careers Are About Leverage

Career progression isn’t simply:

Easy code → Harder code → Extremely hard code

It increasingly becomes:

Defined problems → Ambiguous problems

Small scope → Larger scope

Instruction → Autonomy

Personal output → Multiplier effect

Short-term decisions → Long-term decisions

Direct control → Influence

Tasks → Outcomes

Different careers create leverage differently

Think of it like different engines for the same car:

Implementation   → I build the thing
Technical        → My judgment helps many people build better
People           → I enable teams that build
Product          → I help make sure we solve valuable problems
Coordination     → I make multi-team work actually happen
Customer         → I connect tech to customer problems
Knowledge        → I make others more capable
Organizational   → I design how people operate
Business         → I decide where tech, people and capital go

Implementation leverage

I build the thing.

Common in engineering.

Technical leverage

My technical judgment helps many people build better things.

Common in Staff+, architecture and technical leadership.

People leverage

I build and enable teams that build things.

Engineering management.

Product leverage

I help ensure we’re solving valuable problems rather than merely shipping output.

Product management.

Coordination leverage

I make complicated initiatives involving many people actually happen.

Program and delivery roles.

Customer leverage

I connect technology directly to customer problems.

Solutions Engineering and Forward Deployed Engineering.

Knowledge leverage

I make other people more capable through communication.

Developer Relations, technical writing, education and advisory work.

Organizational leverage

I design systems through which other people operate.

Directors, VPs and senior organizational leaders.

Business leverage

I decide where technology, people and capital should be deployed.

Executive leadership.

This gives us a better career question:

How do you want to create leverage?

Part III: IC vs Management

An Individual Contributor is primarily evaluated through their own domain of contribution rather than through managing direct reports.

That doesn’t mean they work alone, and it certainly doesn’t mean they don’t lead.

Conceptually:

                 SENIOR ENGINEER
                        |
          +-------------+-------------+
          |                           |
    TECHNICAL IC                 MANAGEMENT
          |                           |
        Staff                         EM
          |                           |
      Principal                    Director
          |                           |
    Distinguished                   VP Eng

Same seniority ballpark. Different jobs.

This does not mean Staff equals Engineering Manager or Principal equals Director universally.

It means organizations can support increasing scope on either track instead of forcing excellent engineers into people management.

Management changes your unit of work.

As an engineer, you primarily work through technology.

As a manager, you increasingly work through people.

Your calendar changes. Your feedback loops change. Your problems change. Your definition of a productive day changes.

Engineering Manager isn’t simply the promotion after Senior Engineer. It’s a different profession built on top of engineering context.

Part IV: Leadership Is Not Management

Management usually carries formal organizational responsibilities such as hiring, performance management, compensation, staffing, career development and team structure.

Leadership is broader.

You can lead a technical direction, project, architectural decision, incident response or organizational change without managing anyone.

This is how a Principal Engineer can influence hundreds of engineers while having zero direct reports.

At sufficiently senior IC levels, “soft skills” stop being optional extras.

Communication, persuasion, credibility, relationships and context become part of the mechanism through which technical impact happens.

Part V: Company Size Changes Everything

Imagine a company with three engineers.

[ 3 engineers ]
   one big pile of work
   almost everyone does a bit of everything

There probably isn’t enough organizational complexity to justify Staff Engineer, Engineering Manager, Director Engineering, VP Engineering, Principal Engineer and Enterprise Architect simultaneously.

The underlying problems requiring those jobs may simply not exist yet.

At 30 engineers, teams emerge. Coordination appears. Technical decisions cross team boundaries. People management becomes significant work.

[ ~30 engineers ]
   Team A   Team B   Team C
      \       |       /
       shared decisions appear

At 300 engineers, entirely new classes of problems exist: cross-team architecture, organizational design, management layers, platforms, technical standards, portfolio prioritization and dependencies.

[ ~300 engineers ]
   Domain / Platform / Product org
   managers, Staff+, principals, standards
   the org itself becomes part of the system

This leads to one of the central ideas of this map:

Senior roles often emerge because organizational complexity creates a new class of problems.

A company shouldn’t necessarily create a Principal Engineer because someone has been Staff for three years.

The better question is:

Do we have Principal-sized problems for this person to own?

Sometimes career growth requires a larger problem, not another course.

Part VI: The Software Engineering IC Path

There is no universal engineering ladder.

Different companies use different levels and names. A useful general pattern is nevertheless:

Early Career → Engineer → Senior → Staff → Principal → Distinguished / Fellow

The important part isn’t memorizing the labels.

It’s understanding what changes.

Early Career: Can you successfully complete the task?

Typical scope:

Task → small feature

Primary leverage: personal implementation.

Much of the surrounding uncertainty has already been removed.

The engineer develops debugging, testing, code review, software design, production awareness, communication and the ability to recognize when they are stuck.

Developing Engineer: Can you independently solve the defined problem?

The transition is roughly:

Defined problem + defined solution

to:

Defined problem + engineer determines solution

Typical scope expands toward features and projects.

Senior Engineer: Can you own an ambiguous technical problem?

Senior doesn’t mean “really good programmer.”

The engineer increasingly receives messy problems and turns them into executable paths forward.

Typical scope:

Project → system → team

Primary leverage:

Technical expertise + project leadership

The Senior Engineer still codes substantially, but their responsibility increasingly becomes ensuring that the right technical work gets successfully completed rather than merely completing their assigned code.

Part VII: Tech Lead

Tech Lead is one of technology’s most confusing labels because it can describe a formal title, a project responsibility or an operating role.

Don’t place Tech Lead at a fixed point on a universal career ladder.

Ask:

What does this Tech Lead actually own?

A useful simplified model inside a product team is:

Product Manager → What / Why

Engineering Manager → Team / People

Tech Lead → Technical How

The boundaries overlap, but the model helps.

The Tech Lead paradox

As technical impact grows, coding time may decrease.

Suppose eight engineers are blocked by an unclear architecture.

The Tech Lead can spend six hours implementing one difficult component, or two hours resolving the architectural question and unblock eight engineers.

The second option can create far more engineering output.

This is technical leverage.

The Hero Tech Lead anti-pattern

A dangerous Tech Lead:

takes every difficult ticket;
approves every important decision;
reviews everything;
fixes every incident;
becomes indispensable.

        everyone waits
              |
              v
         [ Tech Lead ]
          /  |  |  \
     tickets reviews incidents decisions

It feels like leadership.

It can actually create a bottleneck.

A great Tech Lead should make the team less dependent on them over time.

Part VIII: Staff Engineer

Staff engineering is senior technical leadership without requiring traditional people management.

A Staff Engineer may lead architecture spanning teams, establish technical direction, resolve systemic problems, drive migrations, mentor senior engineers, influence roadmaps and establish engineering standards.

A useful conceptual transition is:

Senior Engineer

I make my immediate technical environment significantly more effective.

Staff Engineer

I create technical leverage beyond the boundaries of my immediate work.

The exact scope varies by company.

Staff is not “Senior, but better”

Consider six teams that independently created different authorization systems.

Security risk is increasing and every integration is becoming slower.

A Staff Engineer cannot solve this simply by disappearing for three weeks and writing brilliant code.

The problem involves architecture, migration, organizational alignment, incentives, roadmaps, security, communication and sequencing.

The Staff Engineer might personally write very little of the eventual implementation.

Their job is to make the organization successfully change technical direction.

Part IX: Four Staff+ Archetypes

A useful model popularized by Will Larson identifies four recurring Staff+ patterns.

                 STAFF+ WORK
        +-----------+-----------+
        |                       |
   Tech Lead              Architect
   (team success)         (long-term domain)
        |                       |
     Solver               Right Hand
   (hard unknowns)     (extend a leader)

Tech Lead

Makes a team or group technically successful.

Good fit if you enjoy systems, execution and working closely with engineers without necessarily wanting formal people management.

Architect

Owns the long-term technical direction of an important domain.

Good fit if you love deep systems thinking, technical coherence and longer horizons.

Solver

Gets the unusually difficult, high-risk problems where the approach isn’t obvious.

Good fit if you love novelty, ambiguity, difficult technical investigation and moving between problems.

Right Hand

Extends the leverage of a senior organizational or executive leader.

The problems can span technology, organization, process and business.

Good fit if you enjoy extreme breadth, executive context and high ambiguity.

This illustrates why even:

“I want to become Staff Engineer.”

isn’t yet a complete career goal.

The better question is:

What kind of Staff-level work would I actually enjoy?

Part X: Principal Engineer

As scope grows again, the organization increasingly becomes part of the system being engineered.

Principal-level work may include questions such as:

Which technical investments do we need over the next three years?
Which architecture choices prevent several product areas from scaling?
Where should platform boundaries exist?
What should we standardize?
Which technical risks threaten company strategy?
Where are teams optimizing locally at the expense of the whole?

A rough thinking aid is:

Staff

How do we make several teams or a major domain technically successful?

Principal

How do we make a major engineering organization technically successful?

This is not a universal industry definition. Actual scope must always be evaluated within the company.

Does Principal still code?

Sometimes extensively. Sometimes relatively little.

The better question is:

Where does this Principal Engineer create the most leverage?

If a three-hour prototype eliminates months of architectural uncertainty, code.

If three hours aligning four teams prevents three incompatible systems, don’t code.

Seniority increasingly includes the judgment to know which one matters.

Part XI: Distinguished Engineer and Fellow

Beyond Principal, naming becomes even less standardized.

Some organizations use Senior Principal, Distinguished Engineer and Fellow. Others don’t have those levels.

These positions are rare because the relevant problems are rare.

Their scope can involve company-wide technical direction, foundational architecture, major innovation, existential technical challenges and, occasionally, industry-level influence.

This isn’t simply:

Principal + more years.

The organization needs problems where that degree of technical leadership creates value.

Part XII: Should Every Engineer Want Staff?

No.

This is worth saying clearly in the engineering section.

Technology culture can make career stability sound like failure:

“You’ve been Senior for six years?”

But if someone loves building, earns enough, stays technically excellent, creates substantial value and doesn’t want broader organizational responsibility, why should Staff automatically be better?

Staff+ generally introduces more ambiguity, coordination, communication, influence, writing, cross-team dependencies and organizational negotiation.

Those aren’t rewards everyone wants.

They’re different work.

The goal shouldn’t be to reach the highest possible level.

Find the highest level of scope whose actual work you continue to enjoy.

Part XIII: The Great Career Intersection

Senior Engineer is one of the largest intersections on the tech career map.

                      SENIOR ENGINEER
                             |
       +---------------------+---------------------+
       |                     |                     |
     STAFF+             MANAGEMENT            OTHER PATHS
       |                     |                     |
     Staff                   EM                 Product
       |                     |                  Solutions
   Principal              Director              DevRel
       |                     |                  Consulting
Distinguished              VP Eng               Founder

The question after Senior isn’t simply:

Am I good enough to become Staff?

It is:

What kind of leverage do I want?

Technical judgment and influence?

People and teams?

Product decisions?

Customers?

Communication?

Independent expertise?

Company leadership?

That question takes us beyond the engineering ladder and into the wider map of technology careers.

Part XIV: The Career Map Framework

Instead of thinking about careers vertically, imagine your career as coordinates across several dimensions.

Code ←→ People

Technical depth ←→ Business breadth

Execution ←→ Strategy

Individual output ←→ Organizational leverage

Internal systems ←→ Customers / Market

Defined problems ←→ Ambiguous problems

Direct authority ←→ Influence

Stable environment ←→ High uncertainty

Employee ←→ Independent

Then add scope:

Task → System → Team → Domain → Organization → Company

Different careers occupy different regions of this map.

A Principal Engineer may combine high technical depth, high ambiguity, large organizational scope, strong influence and little formal people-management authority.

An Engineering Manager combines technical context, people orientation, team scope, formal authority and organizational accountability.

A Product Manager combines customer and business orientation, ambiguity and strong cross-functional influence with limited formal authority.

A CTO combines broad scope, technology and business context, long horizons, organizational leverage and executive accountability.

A Solutions Engineer combines technical context with intensive customer interaction.

A Fractional CTO adds another dimension: executive responsibility distributed across multiple organizations rather than one full-time employer.

Part XV: Don’t Ask What Title You Want

Don’t begin with:

What title do I want in five years?

Try:

What do I want my normal Tuesday to look like in five years?

Do you want four uninterrupted hours building something?

Architecture discussions?

Customer calls?

One-on-ones?

Hiring?

Product discovery?

Technical strategy?

Debugging impossible systems?

Convincing six teams to adopt a direction?

Managing budgets?

Teaching developers?

Entering struggling companies, fixing their technology organizations and moving to the next challenge?

Those answers are more revealing than:

“I want to become CTO.”

Maybe you don’t want to be CTO.

Maybe you want the prestige you associate with CTO while the work you actually enjoy looks much more like Principal Engineer.

Or perhaps you think you want to remain an engineer, but the moments you enjoy most involve customers, prioritization and connecting technology to business.

Maybe Product speaks to you.

Maybe Solutions Engineering does.

Maybe consulting does.

Maybe management does.

The title should come after understanding the work.

Part XVI: How We Should Evaluate Every Tech Role

For every role on this career map, ask the same questions:

Purpose: Why does this role exist?
Organizational problem: What became difficult enough to require this job?
Scope: What does this person own?
Complexity: What kinds of problems reach them?
Autonomy: How much direction do they receive?
Accountability: What outcomes are they answerable for?
Authority: What can they formally decide?
Influence: What must they accomplish without authority?
Leverage: How do they multiply their impact?
Time horizon: Days, quarters or years?
Technical depth: How deep must they remain?
Hands-on work: How important is direct implementation?
People management: Who reports to them?
Business exposure: How close are they to customers, revenue and strategy?
Environment: Startup, scale-up, Big Tech, enterprise or consultancy?
Organization size: When does this role become useful?
Relationships: Who do they work with and report to?
Artifacts: What do they actually produce?
Success: What does excellent performance look like?
Failure modes: What does a bad version of the role look like?
Normal week: What does the work actually feel like?
Career entry: Where do people typically come from?
Career exits: Where can this path lead?
Fit: Who is likely to enjoy this work?
Misfit: Who may love the title but hate the job?

Only then should we care about the title.

Conclusion: Don’t Choose a Title. Choose Your Problems.

This investigation started because tech titles are confusing.

But that’s not actually the most interesting problem.

We’re often asked to choose career destinations before understanding the lifestyles hidden behind them.

We tell engineers:

Become Senior. Then Lead. Then Manager. Then Director. Eventually CTO.

But why?

What if you hate managing people?

What if you love customers?

What if you want extreme technical depth?

What if you want breadth?

What if you want independence?

What if you enjoy building organizations more than systems?

What if you love solving crises but hate maintaining what comes afterward?

Those aren’t minor preferences.

They are career-defining information.

So perhaps the wrong question is:

What do I want to become?

A better one is:

What kind of problems do I want people to trust me to solve?

And then:

What kind of Tuesday do I want those problems to create?

Career progression doesn’t have to mean collecting increasingly impressive titles.

It can mean becoming capable of solving increasingly consequential versions of the problems you actually enjoy.

What this map still doesn’t cover

This article focuses on the engineering IC path and the framework behind titles.

I still want to expand it with dedicated sections on Engineering Management, Product, CTO / VP Engineering, Solutions, DevRel, consulting, fractional roles, and career transitions between tracks.

Treat this as a living map, not a finished encyclopedia.