Engineering Ladder Levels

Jump to: Level 1 / Level 2 / Level 3 / Level 4 / Level 5

The Engineering ladder is a tool that helps engineers and managers:

• make development and career plans
• talk about what we’re looking for from engineers in a consistent way
• set a fair level of compensation.

The ladder is a compass, not a GPS.

It's meant to be helpful. It's not meant to be a rating system for humans, free from edge cases. This is forked and modified from the Monzo original.

How does it work?

The ladder covers all the things we’re looking for from engineers at Glitch. We’re interested in five qualities:

• Communication - your ability to communicate, both verbally and in writing, with others and your ability to provide and receive feedback on your work and behaviors.
• Influence - your ability to shape change in your work, the team, and the organization. This is the skill used by individual contributors to promote positive change without directly leading a team.
• Initiative - your ability to work independently on tasks and problems. Also includes your ability to help others break down work or problems into manageable pieces and knowing when to seek help.
• Mastery - Your technical skills and abilities. There are a myriad of technical skills needed to be a good engineer including mastery of languages, infrastructure, data, computer science concepts, frameworks, engineering process, and testing, etc.
• Leadership - your ability to lead cultural, process, and technical change. This might include being a technical lead or pod lead, where the team doesn't report to you but is rather a team of peers working on a feature or problem. It includes understanding good delegation, driving collaboration, modeling behaviors that improve the culture and practice of the Engineering team.

Your manager will work with you on this. None of it will happen mysteriously behind closed doors. You’ll agree what level of progression you’re going for and what you need to improve on with your manager. It should be clear how you’re doing relative to that at all times.

Things to keep in mind

• There are many different ways to progress and be valuable to Glitch as you grow, including deep technical knowledge and ability, technical leadership and people management. All are equally valuable paths in Glitch's engineering team.
• The ladder represents a career’s worth of progression, people shouldn’t expect to fly up it in 18 months!
• Engineering progression isn’t an exact science and there will always be some ambiguity.
• As we grow we may add levels but we won’t add them until we need them.
• You can find some more information in these links. If that doesn't answer most of your questions, please ask your manager.

Give us your feedback!

This is only the first version of our ladder and we really want your feedback.

Level 1: Software Engineer I (IC1)

Software Engineer Is are at the start of their career. Being successful in all aspects of this role is the principal criteria for becoming a Software Engineer II.

Software Engineer Is have a reasonable understanding of core engineering concepts. They are focussed on expanding that understanding and growing as an engineer. They have a basic understanding of the team’s work, tools and processes and a broad introduction to engineering best practice and productivity skills. They have an appreciation and understanding of software engineering techniques like testing, source control and agile planning and are focussed on learning more about these domains.

A Software Engineer I is capable of taking small well-scoped components of larger projects, features, and bugs through to completion, often with the mentoring and assistance of more seniors engineers. More senior engineers may also help when they are blocked. These engineers contribute to documentation as they grow.

They are learning how to communicate well and how to deliver feedback to peers and their manager. When given a task with unclear requirements they are learning how to ask for clarification, identify underlying assumptions and can work with product and other engineers to help identify and clarify conflicting requirements. They will start to participate more in the technical design process.

Engineers at this level should be learning how to identify issues and learn from them to improve their skills. By the time a Software Engineer I is ready to be promoted to Engineer II they will have expertise in Engineering best practice, tools, techniques and a solid introduction to the technologies in their domain.

Communication

• "Provides regular status updates to their mentor/buddy"
• "Points out syntactical improvements in code reviews"
• "Writes PR descriptions that provide basic context for the change"
• "Seeks guidance from other engineers, rather than answers"
• "Actively communicates what they are working on"
• "Seeks out feedback"

Initiative

• "Delivers assigned tasks, working with a more senior team member, and able to take PR feedback to improve their work"
• "Independently works on small, well-defined tasks"
• Looks to optimise existing work (eg Processes, procedures, products, etc)"

Influence

• "Improves documentation that is incorrect"

Mastery

• "Learns to write semantic HTML and CSS following guidance and training materials"
• "Learns to write correct JavaScript following guidance and training materials"
• "Uses development tools effectively to increase productivity during development and debugging"
• "Implements simple components"
• "Fixes simple bugs"
• "Asks questions and actions feedback from mentors"
• "Uses git to manage the development workflow effectively"

Level 2: Software Engineer II (IC2)

There will be engineers in this role with a broad spectrum of experience. Being successful in all aspects of the role is the principal criteria for becoming a Senior Engineer.

Software Engineer IIs display solid understanding of core engineering concepts. They are focused on growing as an engineer, learning the team's tools and current processes, and developing productivity skills, as well as Engineering best-practices like testing, source control, and agile planning.

They are capable of taking well-scoped components from a larger project and completing these tasks in a reasonable time frame. Engineers at this level know when to ask for help when they are blocked. They can own their independent small-to-medium features all the way through from technical design to launch. They provide helpful and actionable feedback in code reviews in an empathetic manner.

They communicate well and are capable of delivering feedback to peers and their manager. When given a task with unclear or conflicting requirements they know how to ask for clarification, and ensure that all assumptions are vetted before work starts to reduce the need for re-work. As Engineers learn they will start to participate more in the technical design process or writing technical specs.

Engineers at this level should be improving the speed at which they learn from their mistakes. By the time an engineer is ready to be promoted to Senior Engineer they will have focused on one or more technology domains as their expertise and become capable of mentoring interns and new engineers in these areas.

Communication

• "Proactively communicates to their team what they are working on why, how it's going and what help they need"
• "Accepts feedback graciously"
• "Gives feedback to peers when asked"
• "Provides helpful and actionable feedback in code reviews in an empathetic manner"
• "Writes PR descriptions that provide context and provide rationale for significant decisions"
• "Can deliver their work to their team and others"
• "Proactively gives feedback to those they work with"

Initiative

• "Delivers assigned tasks that meet expected criteria"
• "Works for the team, focuses on tasks that contribute to team goals"
• "Tries to unblock themselves first before seeking help"
• "Manages their own time effectively, prioritises their workload well, on time for meetings, aware when blocking others and unblocks"
• "Helps the team, does what needs doing"
• "Breaks down small and medium problems into iterative steps"
• "Delivers small, well-defined tasks and projects"
• "Delegated small, well-defined task and problems to solve"

Influence

• "Proactively raises issues they spot in retrospectives"

Mastery

• "Writes semantic HTML and CSS following accepted best practices"
• "Uses appropriate algorithms and data structures to solve problems"
• "Writes automated unit and end-to-end tests following accepted best practices"
• "Demonstrates production ownership by observing the impact of code changes using appropriate telemetry"
• "Assists on the design of new features and components"
• "Integrates with backend APIs and handles successful and failed responses properly"
• "Works with users to improve new and existing simple features iteratively"
• "Demonstrates awareness of a range of security considerations, and mitigates against them"
• "Has multiple examples of where performance was considered as part of a solution"
• "Applies fundamental UX and accessibility principles to common problems such as form design"
• "Writes correct JavaScript code following accepted best practices"
• "Implements simple components following accepted best practices"
• "Uses shared libraries to reuse existing functionality"

Level 3: Senior Engineer (IC3)

Senior Engineers are the first level of technical leadership in an Engineering team. The Senior Engineer should have expertise in at least one technical domain and work well with others. They hold a depth of knowledge in systems that enables them to debug those systems effectively without issues. In addition to writing consistently high-quality code they are aware of industry best practices and trends, and have acquired at least one major skill outside of core coding such as monitoring, documentation, integration testing, visual design, or performance optimization.

The Senior Engineer can own technical design and implementation for projects of moderate complexity, and understands the tradeoffs in creating good software in their area, grabbing others for insight as necessary. They can take a complex user story, break it down into sub-tasks, and complete their sub-tasks with relative ease. The Senior Engineer shows initiative beyond knocking tasks off a list; they are able to identify and suggest areas of future work for themselves or their teams. They seek evidence to support their ideas and start to build cases for these ideas. They deliver products with confidence.

The Senior Engineer has end-to-end responsibility for projects of increasing complexity that encompass more than their own development. They contribute to the common code bases and standards for the team. They understand the business that their code supports and use this knowledge to influence their task prioritization. They assist in identifying and validating test cases and can identify regression risks in their features. In general, they can identify risks in code, features, and design, and communicate these to the appropriate parties.

The Senior Engineer is prepared to be thrown into emergency product and production situations, including ones their team has not confronted before. They are able to provide valuable insights during cases of technical urgency but also make good judgements about when to stay out of the way.

The Senior Engineer is known outside of their core team as a technology leader. They participate extensively in code reviews, and be a mentor to less senior engineers. They also share knowledge through code reviews and pairing, as well as frequently presenting at team meetings. They work effectively with non-tech members of the Glitch community.

Communication

• "Transparent about mistakes they've made, early"
• "Proactively gives timely actionable feedback to peers"
• "Proactively seeks feedback from the people around them"
• "Considers the opinions of others before defending their own"
• "Clearly communicates throughout implementation of solutions"
• "Can successfully get buy-in for their proposals"
• "Is a rigorous code reviewer, making sure to fully understand both how new code works and the decisions behind its design"
• "Is engaged an code reviewee, actively seeking to understand the reasons for individual pieces of feedback and taking the opportunity to discuss the underlying differences of opinion"

Initiative

• "Delivers large well-defined tasks and solves small scope not-well-defined problems"
• "Leads writing small to medium technical specs and contributes to larger scope specifications"
• "Thrown at fires and resolves / contributes heavily to resolving them"
• "Breaks down large problems into smaller iterative steps across multiple PRs"
• "Identifies problems to solve"
• "Takes responsibility for the success of their solutions, including post-release followup and iteration if necessary"
• "Prioritizing monitoring and visibility by considering how new work can be evaluated and debugged (including by other team members)"

Leadership

• "Onboards / mentors new engineers"
• "Contributes to maintaining the Glitch culture in their team, helping new members"
• "Instills Glitch engineering principles in other engineers"

Influence

• "Provides valuable input to ideas and technical specs from their team"
• "Asks why. Does not take truths for granted unless they understand exactly where they are coming from."
• "Proactively improves modules, services, systems and codebases they encounter, "this doesn't make sense, I'm going to do something about it""
• "Breaks down delivery and knowledge silos in their team or pod"
• "Contributes to scaling engineering hiring (e.g. leads calls, does onsite interviews)"
• "Builds tools or iterates existing tools for the benefit of all engineers"
• "Helps Product Managers and Designers to understand and consider non-functional requirements in the product development process"
• "Promotes security, accessibility, and privacy good practice and helps other engineers to deepen their knowledge"
• "Promotes performance good practice and helps other engineers to deepen their performance knowledge"

Mastery

• "Uses appropriate design patterns to solve problems"
• "Avoids over-engineered solutions and prioritizes writing simple code that others will understand and be able modify"
• "Identifies obvious deficiencies in the development processes and supports activities to improve them"
• "Assists more experienced engineers on the design of larger features"
• "Debugs and fixes complex production issues at speed"
• "Collaborates with designers and user researchers to create prototypes and to evaluate them"
• "Differentiates between user needs and desires and prioritises accordingly"
• "Reasons effectively about asynchronous code"
• "Considers metrics when developing, and uses appropriate services to check quality levels"
• "Is at home in the application environments in which they work and is typically able to unblock themself (and others) when developing or diagnosing production issues"

Level 4: Staff Engineer (IC4)

The Staff Engineer has strategic impact over some combination of a large team, a very deep technical problem, and/or a long time horizon. The problems that the staff engineer is solving are open-ended.

The Staff Engineer provides considerable high-level technical guidance across the team. They can usually anticipate and plan for technical problems. They are highly knowledgeable in major parts of our technology stack and are the technical owner of significant components of our code base. They have a sustained track record of creating improvements in business-critical systems around stability, performance, and scalability.

A Staff Engineer is still acting in a very hands-on role, and as such, they are a prolific contributor to both core projects at Glitch as well as side and experimental work. When presented with a complex problem, process or existing system they are able to reduce the complexity in order to get more done with less work. They provide guidance, direction and help colleagues build and produce better outcomes.

The Staff Engineer has strong abilities to influence without requiring reporting authority. They facilitate cross-team work and are influential beyond their individual group. They are capable of driving groups of disparate interests to decisions, and clearly communicating and seeing those decisions through to impact. The staff engineer is capable of setting short to medium term strategic direction for part of the technology stack, identifying areas of critical need based on future growth and developing roadmaps to attack those problems.

Communication

• "Proactively gives feedback 'upwards' and to people they interact with who are not in their team"
• "Transparent in making design and technical decisions"
• "Helps people in non-technical roles understand technical constraints / trade-offs"
• "Shares technical context and direction for less experienced engineers"
• "Gives direct and constructive feedback to other engineers"
• "Communicates their area’s role within the larger mission of the company"
• "Is an expert code reviewer, not looking at the change under review in isolations but considering how it affects its surrounding context and the system as whole as well as the consequences for future design decisions"
• "Is a supportive code reviewee, in particular encouraging less senior engineers fully understand how their code works and the decisions behind its design"

Initiative

• "Solves ambiguous problems"
• "Leads writing large scope technical specs and influences medium-term project planning"
• "Makes pragmatic choices about taking on tech debt"
• "Leads changes in organization-wide practices to prevent accrual of tech debt"
• "Considers multiple different solutions for solving a problem"
• "Breaks down projects into smaller iterative steps that each deliver value"
• "Can take a long-term vision and define building blocks to get there"
• "Proactively raises issues with new technical projects and product initiatves during planning phases"

Leadership

• "Gets buy-in on technical decision-making and proposed designs"
• "Proactively involves other relevant engineers"
• "Sought out for pre-coding planning and design consultations"
• "Helps the growth of engineers around them through coaching and mentoring"
• "Helps their team work together more effectively"
• "Helps facilitate team rituals"
• "Makes improvements to modules/libraries/services and goes out of their way to help others learn from it"

Influence

• "Positively influences engineers in the wider org"
• "Maintains documentation on things they know the most, makes it easy for future engineers to interact with systems/code"
• "Clears blockers for less experienced team members, provides context/guidance, or knows how to escalate"
• "Seeks to fully understand external requirements and constraints, especially with regards to regulation, compliance, etc."
• "Drives changes to engineering practices with well-reasoned arguments and a "strong opinion, weakly held' mentality""
• "Shapes the direction of systems designs with less experienced engineers"
• "Breaks down delivery and knowledge silos across the entire engineering organization"
• "Keeps up to date with industry developments and feeds specific technical and non-functional recommendations back into the business"
• "Proactively identifies opportunities to improve company culture around coding standards and non-functional requirements"

Mastery

• "Writes code that serves as a definitive example for new engineers"
• "Makes contributions to library code or other core parts of the applications"
• "Makes contributions to our development tools and build processes"
• "Reasons effectively about complex asynchronous and concurrent code (including interactions across services)"
• "Identifies optimisation opportunities in the development process and contributes to the implementation of proposed solutions"
• "Builds maintainable and flexible components and applications"
• "Leads the refactoring of complex parts of the system"
• "Identifies and fixes security weaknesses and performance bottlenecks"
• "Explains all aspects of the code to new engineers"
• "Implements services or libraries that require a deep level of domain knowledge"
• "Puts users first and can manage competing priorities effectively"
• "Strenuously avoids and helps remove overly defensive code and promotes confronting errors and failure cases head-on"
• "Has a deep understanding of the application environments in which they work and unblocks others who confront novel issues"

Level 5: Principal Engineer (IC5)

This person acts as the “chief architect” for our business. They have significant strategic vision and can take a high-level 3-5 year plan for growth at a business level and translate that into a strategic technology roadmap. They are deeply technically savvy and their primary job is focusing on the architectural and technology needs to grow the business over the longer-term horizon.

This level signifies strategic impact over the team. The Principal Engineer deals with very deep technical problems and a long time horizon. The problems that the Principal Engineer is solving are very open-ended even to the leadership who presented the problem.

The Principal Engineer is sought-after for technical guidance across the team. They have a track record of anticipating technical problems that will fall out of major products and designing solutions to overcome those problems. They are deeply knowledgeable in major parts of our technology stack and are the technical owner of large parts of our code base. They have a sustained track record of creating major improvements in large business-critical systems around stability, security, performance, and scalability.

A Principal Engineer is still acting in a very hands-on role, and as such, they are a prolific contributor to both core projects at Glitch as well as side and experimental work. When presented with a complex problem, process or existing system they are consistently able to reduce the complexity in order to get more done with less work. This ability to manage and simplify complexity is the hallmark of the Principal Engineer; working with this person should leave team members feeling like they are going to leave with something significantly better than they came into.

The Principal Engineer has broad impact across Glitch tech. They create architecture that shapes large parts of our business, and ship complex projects including many systems or major pieces of infrastructure. The impact of their work is felt across the team in the quality of the engineering that we produce, the ways we write code, the core libraries that we use, and the underlying design of systems. There are multiple obvious large technical contributions that can be pointed to as originating from this team member.

The Principal Engineer has excellent abilities to influence without requiring reporting authority to do so. They effectively facilitate cross-team work and are influential far beyond their individual group. They are capable of driving groups of disparate interests to decisions, and clearly communicating and seeing those decisions through to impact. The Principal Engineer is capable of setting short, medium and long term strategic direction for part of the technology stack, identifying areas of critical need based on future growth and developing roadmaps to attack those problems.

Communication

• "Helps other people develop themselves and regularly gives insightful, useful feedback to those around them"
• "Talks to non-technical stakeholders on appropriate level of abstraction"
• "Communicates the long-term vision & mission for the company and their area"
• "Transparent about feedback they have received and what they are going to do differently"
• "An effective and inspiring communicator internally and externally"

Initiative

• "Solves the 'hard problem' in a project and sees it through to resolution"
• "Solves larger, open-ended problems"
• "Leads incident resolutions"
• "Makes judgements about when to diverge from the immediate goal to achieve something else"
• "Leading large scale technical infrastructure projects (level 5 would originate or complete, probably)"
• "Leads writing large scope technical specs"
• "Breaks down large long-lasting projects into sensible discrete chunks that compound to achieve a large goal"
• "Helps prioritise and balance short-term and long-term investments, focusing on high impact, high value work"
• "Understands the big picture and integrates company goals into their area"
• "Accountable for delivery of large, mission critical engineering projects"
• "Originates or finishes large, horizontal engineering efforts"
• "Is the accountable exec for high-impact projects"

Leadership

• "Instills Glitch engineering principles across a whole team of engineers"
• "Works with relevant Engineering Managers & Directors to help other engineers perform and grow"
• "Fosters effective collaboration in multi-disciplinary teams and pods"
• "Delegates technical decisions with low risk and high reversibility"
• "Owns technical decisions with high risk and low reversibility"
• "Contributes to maintaining the Glitch culture in the wider company"
• "Bootstraps new teams"
• "Helps groups of teams work together more effectively"
• "Starts things that they cannot finish by themselves"
• "Delegates to make better use of their time"

Influence

• "Has strategic impact, and the ability to influence without reporting authority"
• "Provides considerable high-level technical guidance across the team"
• "Represents Glitch at conferences/events"
• "Given as reason for other engineers to join Glitch"
• "Proactively shares knowledge internally"
• "Facilitates cross-team work and is influential beyond their individual group"
• "Attracts other very senior hires"
• "Engineers around them get better and have a bigger impact, faster"
• "Sought-after for technical guidance across the team"
• "Effectively facilitate cross-team work and are influential far beyond their individual group"

Mastery

• "Makes major contributions to library code or core parts of the application"
• "Contributes to external technologies or libraries that we depend on"
• "Anticipates platform and project needs, technical debt and common issues intuitively"
• "Develops clear technical solutions from ambiguous requirements"
• "Produces technical designs for large complex projects"
• "Uncovers and fixes tricky bugs that have previously evaded detection"
• "Demonstrates a deep level of knowledge in a specific area"
• "Serves as a technical authority on a technology or an area of the codebase"
• "Reviews technical designs and pull requests for large complex projects"
• "Encourages and supports other engineers to achieve outstanding results"
• "Creates major contributions to our documentation, and creates documents that provide guidelines and best practices to other engineers"
• "Works with technical and non-technical stakeholders to identify high-level requirements and turns them into discrete technical concerns"
• "Makes major contributions to technologies and libraries that we depend on"
• "Uses a risk-based approach and manages technical debt systematically to focus the team’s design and development efforts on the most important problems"
• "Works with business and technology stakeholders to translate difficult business problems into technical designs, thereby ensuring that the organisation derives maximum value from services"
• "Identifies architecturally significant functional and non-functional requirements, identifies conflicts among them, and defines possible trade-offs scenarios"
• "Articulates high-level technical goals, concerns, trade-offs, and decisions to the rest of the company effectively"
• "Facilitates technical decision making in complex and ambiguous situations"
• "Promotes architectural thinking and good engineering practices at scale"
• "Makes improvements that affect important non-functional requirements that have an effect on the entire web-platform"
• "Serves as a technical authority in the wider engineering community"
• "Identifies and explores opportunities for service and business improvement"