Read a ladder as one employer’s model
The GitLab engineering career framework is a public example of how an organization describes growth. Its staff-level page is evidence of GitLab’s expectations, not a universal industry definition.
When assessing a role, ask what decisions the engineer owns, what support is available and how success is evaluated. Two positions with the same title can involve different system scope, operational responsibility and influence.
Compare evidence at increasing scope
Use the following editorial matrix to prepare a development conversation. It is not a promotion policy or a claim that every employer uses these levels.
| Scope | Example evidence | Useful next question |
|---|---|---|
| Bounded task | Delivers a small change with tests and asks timely questions | Can the reasoning be explained clearly? |
| Feature or service | Coordinates design, rollout and failure handling | What risks were anticipated? |
| Cross-team problem | Aligns interfaces and helps others make decisions | Does the improvement survive without constant intervention? |
Progress is not simply producing larger pull requests. A smaller change that prevents repeated incidents or clarifies an interface can have broader impact than a large feature whose maintenance burden is hidden.
Separate growth from title negotiation
Choose one capability to strengthen over a review period: debugging an unfamiliar service, writing a design document or planning a reversible rollout. Define what evidence would show improvement. Discuss access to suitable work with a manager or mentor rather than waiting for a title to create the opportunity.
Keep examples of tradeoffs, feedback and outcomes. If a result was not measured, describe what was observed instead of inventing a percentage improvement. The resume guide shows how to express contribution honestly.
Explore leadership without assuming management
Technical leadership can involve architecture, mentoring or coordinating difficult work. People management adds responsibilities such as staffing, feedback and performance conversations. Neither path is automatically the next step for every engineer.
Read the actual job description and ask for examples of a typical week. Use the system-design preparation guide to practice explaining decisions at different scopes. If you are starting out, return to the full software engineering workflow before specializing too early.
