This note was orginally written for the Wonderbly dev team in 2017. At the time, the team had about 20 devs, split into three squads, each with a tech lead who was also the line manager. I have since shared it with a few other folks within other companies, who have found it useful. Adding here for posterity.

This document is to help you understand how engineering career progression works at Wonderbly. It explains our principles, roles within engineering and how to make progress.

Defining a linear career progression is not the point of this doc. It’s impossible for a single title to describe you and where you are in your career. There are no accepted industry definitions to follow and what denotes seniority at one company can have mean something very different at another. It’s also perfectly possible for two people with different but equally valuable skills and have the same title.

So therefore the goal of this document is help you understand your next move and provide guidance to your manager to help get you there.

Underlying principles

It’s helpful to have some principles to help us think about titles, careers and progression and the like. These principles reflect our culture, a desire to not constrain people and finally reflect industry experience.

  • We’re all engineers - software development is a complex business and requires all kinds of people with different skills and sensibilities to make it a success. Whatever role you fulfill you are first and foremost an engineer, treated on equal terms to all others

  • Jobs not titles - we don’t believe titles can act as a label to wholly represent who you are. As much as possible the title should represent the job you do. Statue and authority come by doing

  • Grow in any direction - there’s no set path. People and businesses move non-linearly and it’s perfectly possible, even preferable, that career paths do the same.

  • Working here is a badge of honour - having Wonderbly on your CV, regardless of your title, should be the best signifier of your talents. To do that we need to strive to make Wonderbly a renowned place to work in London

  • Help others first - always prioritise others; helping each other encourages learning for everybody, spreads information and break down silos

Engineering Roles

The following descriptions contain an outline of what we expect to see from each role. This is by no means meant to be exhaustive and instead intending to act as guide for career planning.

The numerical suffixes (eg Engineer II) need not be public - they are there to help you and your manager with career planning to allow you to master the role and ultimately progress.

Position Influence Behavioural traits Ownership
Software Engineer Yourself and their work Implements well defined tasks fully / Takes on guidance and mentoring when needed None yet; currently learning with others. Expected timeframe to progress: 6-12 months
Software Engineer - II Their project and team Trusted to deliver features end-to-end / Improves overall quality / Provides useful feedback through code review / Valuable contributor to team design discussions Co-owns areas within team responsibility, with some guidance. Expected timeframe to progress: 1-3 years
Software Engineer - III Their project and team Reduces complexity, not adds to it / Routinely unblocks others but also knows when to seek help Fully owns key area within teams responsibility. Expected timeframe to progress: 1-3 years
Senior Software Engineer Their domain Uses experience and charm to steer tech strategy within domain / Always on-hand to provide guidance to team / Creates momentum for tech initiatives / Resists poor quality Ownership of 1 key system and contributes to others. Expected timeframe to progress: 3+ years
Principal Software Engineer All of Engineering and relevant community Uses experience and charm to steer tech strategy for entire org / Owns long-running, complex initiatives (eg multi-year) / Key voice of Engineering to rest of co and community Ownership of systems across the org. Last point of failure in emergencies
Tech Team Lead Their domain, team and product owner Disseminates requirements into manageable workstreams for engineers in their team / Develops people as well as they develop code / Defines a smooth, light touch development process that works for their team Ownership of delivery of business roadmap on behalf of POs

Describing your title in public

Engineers can specialise in certain areas, such as a specific domain like QA, Infrastructure or Payments, Front-end etc. If you feel it represents you better then feel free to use that specialism can be used in your title, as a prefix.

There’s no need to seek permission to add a prefix to your Engineer title on social profiles, Linkedin etc. Just remember that we’re in a rapidly changing business and industry and the term might become out of date.

Examples:

  • Engineer, Front-end
  • Engineer, Platform
  • Full stack Developer
  • QA Engineer

It tends to make less sense to call out specialisms the more senior you are. For Seniors and Principals the focus is at a domain level, so generally there’s always some element of front-end, back-end, infra etc in the role.

Difference between “developer”, “engineer”, “hacker”, “bit twiddler” etc

We make no distinction between those terms. We default to Engineer but refer to yourself with whatever term you feel is more appropriate.

Creating a career plan

A career plan is

  • An agreed set of quarterly goals that enable you to exhibit qualities we expect to see of a person in their next role
  • Generally the plan is over 6-12 months
  • The outcome is a recognition of your personal development (eg title/salary etc), depending on how the goals are met
  • Everybody’s plan will be different because we come from different places, but the overall goals are largely the same
  • Crafted between you and your line manager

Mastering the Engineer role

The first crucial step in your career is to master the “Engineer” role by incrementally taking on more responsibility by meeting the scopes of level II and III.

Remember the use of numbers, eg “Engineer II”, is a step in your progression towards mastering the Engineer role. It’s not something we expect to put in a contract or callout on social media. Instead it will be used to guide career planning, generally around annual review time.

Remuneration we will reward your progress towards mastery of the Engineering role with your annual raise, decided at your yearly review.

Moving to Senior Engineer

To move to senior you will need to first master the Engineer role (see above).

Then, if your TTL agrees that the opportunity is available within the team, and you are ready, you can work together to create a career plan for a move to senior. This will won’t be easy and we will be looking for you to take on challenges that reflect increasing levels of responsibility and stewardship. A promotion to senior marks an important milestone in your professional development.

Remuneration we will celebrate this promotion with a change in title, a raise to reflect your increased responsibility, rounds of applause and lots of treats.

Moving to TTL or Principal

From senior onwards there are two paths open to you, depending on your interests and needs of the team. You can either grow to take responsibility for a tech team and the engineers in it by becoming the Tech Team Lead. Alternatively you can focus on growing your technical responsibilities by becoming a Principal and help shape our technical strategy.

To move on to either requires the same plan as moving to Senior, except agreed with Head of Engineering.

It’s also perfectly fine to move between roles. People’s situations change as the does the company’s. There’s no defined route that you must take that can never be looked at again. It’s more to do with providing a structure to ask the right questions.