Grades, Roles, Skills

In the professional software development environment, levels and titles are widely used to describe experience, responsibility, and the role of specialists. Despite their widespread adoption, the interpretation of these terms varies significantly across companies, markets, and engineering cultures.

In practice, a simplified classification based on levels such as junior, middle, and senior is most commonly used. These labels serve as a convenient model for communication and hiring, but are often applied without a clear connection to actual responsibility, autonomy, and system complexity, which leads to a dilution of their original meaning.

This note examines the origin and purpose of engineering levels and analyzes their application in the context of different organizational and technical environments.

By experience

Junior

• From (Latin iūnior) — younger, beginner
• Experience: 0 years
• Core idea: learning to work without damaging the system
• Implements clearly defined tasks
• Fixes bugs under supervision
• Follows existing patterns
• Asks many questions
• Requires close supervision
• Limited understanding of the system
• Output is fragile and local
• Radius of impact: self / small part of functionality
• Can accidentally break things
• High learning speed, low reliability

Middle

• From (Old English middel, Germanic midjaz) — between extremes
• Experience: 2–5 years
• Core idea: reliable execution
• Delivers features end to end
• Debugs non-trivial problems
• Makes limited project decisions
• Mostly works independently
• Understands their part of the system
• Needs help with complex trade-offs
• Predictable results
• Radius of impact: feature / component
• Generally safe
• Weak awareness of long-term consequences

Senior

• From (Latin senior) — older, more experienced
• Experience: 5+ years
• Core idea: ownership of systems, not tasks
• Designs subsystems
• Anticipates problems before they occur
• Reviews and improves the work of others
• Makes deliberate trade-offs
• High autonomy
• Strong debugging and judgment skills
• Mentors junior and middle engineers
• Thinks in terms of failure modes and edge cases
• Radius of impact: system / team
• Senior is the first level where the quality of judgment matters more than the volume of output

The time-based category

This is the primary category that defines cost and risk, which is why it is almost always present in job postings.

This category also has extensions.

Staff

• Core idea: scaling engineering through influence
• Designs systems across teams
• Sets technical direction for multiple teams
• Resolves architectural conflicts
• Acts as technical “glue”
• No direct authority
• Influence through trust and expertise
• Time horizon measured in years, not sprints
• Writes less code, but the code has high leverage
• Radius of impact: multiple teams / domain
• This is not “senior+”. It is a different job
• Evaluation is not based on code volume

Principal

• Core idea: technical responsibility at the organizational level
• Defines architecture for large parts of the organization
• Establishes engineering standards
• Evaluates high-stakes technical bets
• Prevents company-scale systemic failures
• Exceptionally strong judgment
• Deep and broad expertise
• Trusted advisor to leadership
• Radius of impact: organization
• A significant part of a Principal’s work consists of preventing bad decisions

Distinguished (sometimes Fellow)

• Fellow denotes recognized status within a professional community
• Core idea: long-term technical vision
• Shapes the direction of a company or industry
• Defines foundational principles
• Solves problems inaccessible to other levels
• Represents engineering at the highest level
• Rare (one per hundreds or thousands of engineers)
• Authority without formal hierarchy
• Creates new areas and directions
• Radius of impact: company / ecosystem

Summary

Middle as a formal level is rarely used in the US. It is common in Europe and the post-Soviet space and serves as an intermediate category between beginner and experienced engineers, reducing pressure for premature “promotion to senior”.

By type of contribution

Roles are also divided by type of contribution:

• IC (Individual Contributor)
• Management

IC contributes individually. Management manages people.

This separation appeared as early as Intel and IBM, following the realization that forcing engineers into people management reduces the quality of their primary work.

IC examples

Engineering / Tech

• Junior Software Engineer

• Software Engineer

• Senior Software Engineer

• Staff Software Engineer

• Principal Software Engineer

• Distinguished Engineer / Fellow

• Junior / Middle — focus on task execution

• Senior — focus on system creation

• Staff / Principal — architecture and cross-team interaction

Architecture & Deep Expertise (still IC)

• Solution Architect
• System Architect
• Security Engineer / Architect
• Performance Engineer
• Infrastructure Engineer
• Site Reliability Engineer (SRE)

These roles define technical decisions but do not manage the people who implement or maintain them.

Management roles

These roles are evaluated by team outcomes, releases, and organizational health.

Engineering Management

• Engineering Manager (EM)
• Senior Engineering Manager
• Group Engineering Manager
• Director of Engineering
• VP of Engineering
• CTO (in management-heavy organizations)

Primary responsibilities:

• Hiring and firing
• Performance evaluation
• Planning and prioritization
• Team structure
• Risk management
• Product and delivery management

Product Management

• Senior Product Manager
• Group Product Manager
• Director of Product
• Chief Product Officer (CPO)

Note: PMs are not individual contributors (IC), despite not directly managing engineers. Their output consists of decisions and alignment, not artifacts.

Process and Delivery Management

• Project Manager
• Programme Manager
• Delivery Manager
• Scrum Master (when this is a real role, not a formality)

People / Resource Management (non-technical)

• People Manager
• HR Business Partner
• Talent Manager

Hybrid roles (risk zone)

These roles combine technical and managerial functions, often unsuccessfully.

• Tech Lead
• Team Lead
• Lead Engineer
• Tech Lead Manager (TLM)
• Player-Coach

Problems:

• Split incentives
• Conflicting success metrics
• Elevated burnout risk
• Poor scalability

By role and skills

Skill-based roles emerged when systems became too complex for “generalist programmers”.

They answer the question:

• “Which domain does this person specialize in?”

They do not answer:

• level
• authority
• career stage

Example of a role and skill: Ruby Developer.

A common misconception is Engineer vs Developer.

• In some countries, Engineer is a regulated, licensed profession with legal responsibility (Canada, UK, parts of the EU).
• Where it is not regulated, Engineer is used either as a formal enhancement of the role or as an indicator of deeper requirements in computer science and software engineering compared to purely application-level development.

Conclusion

A commonly accepted job title notation:

`%LEVEL %SKILL %ROLE` → Senior Java Developer

LEVEL     → Junior / Middle / Senior / Staff / Principal
ROLE      → Engineer / Architect / Developer / SRE / Data / Security
SKILLSET  → Java / Linux / Databases / ML / Cryptography

Levels are used as a simplified model for describing engineering experience.

They serve as a shared coordinate system for the labor market and internal company structures.

A grade or level does not exist outside a specific environment. The same level in different organizations corresponds to different levels of responsibility, autonomy, and acceptable risk.

Without reference to organizational context, engineering culture, and system complexity, a title does not reflect actual work content and is used as a social marker, reference point, or expectation anchor.

Experience is the least prone to dilution and therefore serves as the primary reference point. Role is shaped inside the organization through actual work. Skill is used as specialization; over a career, typically no more than two or three senior-level specializations are formed.

History

This terminology did not appear immediately and did not originate in “IT” as we understand it today. It is the result of the convergence of three different historical streams over roughly 70 years. I will go through them chronologically, removing myths along the way.

1. Pre-IT origins (1940s–1960s): engineering and civil service

Before software development became a profession, engineering already had career ladders. Classical engineering (civil, electrical, mechanical)

Roles were informally understood as:

• Junior engineer — apprentice level, learning under supervision
• Engineer — independent competence
• Senior engineer — responsibility for systems, safety, and decisions
• Principal engineer — final authority in design

Key point:

• These titles described responsibility and legal/professional accountability, not “skill points”.

“Senior” meant: you sign, you are responsible.

This approach transferred directly into early computing systems.

2. Early computing era (1960s–1980s): mainframes and institutions

Context: Software existed within:

• government structures
• banks
• telecommunications

Military and civil ranking systems had a strong influence.

Typical structure:

• Programmer I / II / III
• Senior Programmer
• Systems Analyst
• Principal Analyst / Architect

Titles were bureaucratic and hierarchical, but the idea of gradually increasing responsibility already existed.

Important:

• There was no “career growth” culture
• Promotion was slow and tenure-based
• Technical mastery often forced people into management
• This created the first major problem: great engineers became poor managers because there was nowhere else to go

3. The management trap (1980s–1990s)

As the role of software grew:

• organizations needed deep technical expertise
• but only management was rewarded

Result:

• “Senior” engineers hit a ceiling
• The only upward path was management
• Technical quality suffered

This problem was widely recognized at:

• Bell Labs
• IBM
• Microsoft (early period)
• Intel

Intel, in particular, formalized the idea of a dual career ladder.

4. The dual career ladder (1990s)

Key contribution of Intel

Intel clearly defined:

• the Individual Contributor (IC) ladder
• the management ladder — with equal prestige and compensation

Roles such as the following were formalized:

• Senior Engineer
• Staff Engineer
• Principal Engineer

Key shift:

• Staff emerges as a level between Senior and Principal
• Staff ≠ “senior++”
• Staff = technical leadership across teams

This is where the modern level hierarchy begins to crystallize.

5. Dot-com era (1990s–2000s): title inflation

Startups “exploded”.

Problems:

• Rapid hiring was required
• Titles were used as substitutes for compensation
• No unified standards existed

Result:

• “Senior” with 2 years of experience
• “Lead” meaning anything
• “Architect” without real authority to enforce architectural decisions

Large companies, however, resisted this dilution.

6. Google and the modern level system (2000s–2010s)

Google refined the career ladder into a model that became a global reference.

Internal system:

• L3 — entry level (junior)
• L4 — intermediate (middle)
• L5 — senior
• L6 — staff
• L7 — senior staff / principal
• L8+ — distinguished / fellow

Google explicitly fixed two things:

• Senior is a terminal level
• Staff+ is about scale and influence, not code volume

Why do levels start at L3? Because the first two are:

• L1 — Trainee, still learning
• L2 — Graduate, just finished training

After Google, similar systems were adopted by:

• Meta
• Amazon
• Microsoft (in revised form)
• Netflix

This is where Junior / Middle / Senior / Staff / Principal / Distinguished become the de facto global vocabulary.