Many development managers dread that one day one of their staff in a regular catch up will ask “What do I have to do to get promoted?”. This is daft really, because having staff that are motivated to develop themselves is a critical part of a high performing team. Of course, such a question could really be referring to a desire to be recognised—perhaps they don’t feel their title reflects their progress so far. Perhaps they are not satisfied with their salary. Or perhaps they are simply asking where their manager feels they should be concentrating their efforts to learn. This post is about what we have done recently at Auto Trader to help development managers work through this question with their staff.

Currently our developer job titles are prefixed with Apprentice, Graduate, Professional, Senior or Principal. Many years ago we moved away from standardised frameworks and over time it’s fair to say that the shared understanding of what the distinction is between roles has eroded. We have attempted to address this a number of times but these exercises rarely got beyond the post-its on the wall stage—as a large group we struggled to come to a consensus. Perhaps we had too many people involved, perhaps we tried to define them all at once, perhaps we weren’t convinced we were improving the situation.

Gradually over the last couple of years (starting with a session to define what the difference was between a Professional and Senior Developer was), we have managed to define most of these levels based on crowd-sourced ideas distilled, paraphrased and iterated by a handful of us. We were all very keen that the output of this process would not read as a check box of things to tick off to get promoted, and that it reflected the range of behaviours we would expect someone to display at each level. For that reason, we have avoided making these descriptions overly technical, or at all quantitative.

These descriptions build on the established Auto Trader values: humility, determination, reliability, curiosity & inspiration. You can watch Auto Trader’s CEO Trevor Mather talking about these values on our About Us site.

Shouldn’t we all just be called ‘Engineer’?

We are aware that plenty of organisations are moving towards more generic titles to match their flatter structured, perhaps even abandoning any idea of a level and just using the term ‘Engineer’. There are obvious positives to this approach. One is that it eliminates the ability to ‘pull rank’, instead requiring collaboration and consensus. Another is that it reduces the expectation of significant promotion related pay rises allowing instead for progression and contribution to be recognised continually by incremental steps. It could also reduce alienation between ‘proper’ developers and other roles which write code—now everyone can be respected for the fact they apply technical knowledge to solve problems.

But it can’t be ignored that this also causes anxiety amongst some (especially early career) developers, who struggle to see that they are making progress and worry that not being able to describe their title undermines their ability to explain their progression to future employers.

Does it work?

We have trialled these role descriptions in performance development conversations with our developers with very positive feedback. By describing what we expect to see of our developers in various aspects of their role at each level we have a less subjective opinion-based discussion and highlight to developers that a lot of what they need to focus on is not writing code.

It is important to point out that these are not the entry requirements to a role—they are a complete description of the possible requirements. In fact, those carrying out each role will usually not exhibit all of the qualities described.

The suggestions we crowd-sourced were grouped into themes, and these themes carry throughout Professional, Senior & Principal (with extra themes appearing from Senior onwards).

The aim is that developers have a clear idea of the range of skills and behaviours they need to focus on at each stage in their career.

The themes are:

  • Delivery—how we get stuff done
  • Coding—the way we build applications
  • Testing—the way we avoid negative impact to customers
  • Communication—influencing styles and sharing information
  • Collaboration—how you work with others in your team

Then from Senior onwards:

  • Commercial Awareness—having knowledge and understanding of how the rest of the business operates
  • Coaching—developing those around you
  • Live Support/Operations—considering and assisting in the operation of the products you own

How is it used?

We ask developers to look at the description of their current role, thinking about whether it fit with their current perception of their progression. Where it does not, they might find it useful to discuss this with their those involved in their personal development, to see whether they agree about their progress.

We suggest they might find it interesting to read the description for the next level, to see if it matches their perception of what they need to focus on to improve.

We also use these descriptions when discussing the prospect of promotion, so that we have a more consistent approach to the level we feel our developers have reached.

We hope others outside Auto Trader may find the below descriptions useful, and we would like you to consider them as available for use under a Creative Commons licence.

Professional Developer

Delivery

Their tech lead is able to depend on them to work unsupervised on moderately challenging tasks, without having to actively enquire as to their progress. They are reliable and meet the commitments they make to the team. They make sure they are aware how their work impacts the road-map and other teams. They take steps to prevent interruption of service or delivery while they work on a feature. Their approach balances short-term solutions and longer-term architecture.

Coding

They are curious as to alternative approaches and technologies and show a desire to improve their knowledge base. They demonstrate a competence in the use of the language features and tools used on a daily basis. They can describe our web stack and appreciate the adjacent layers to their daily work (particularly HTTP).

They actively (without prompting) use their IDE to apply refactoring to improve their design and deliver clean code, proactively improving code they come into contact with. They have started to demonstrate critical thinking around solutions, considering the context of the Auto Trader infrastructure.

Testing

They understand and can describe the advantages of using test-driven development, and their design is positively–not negatively—impacted by it. They are comfortable applying tests at different levels of abstraction and the level they choose is usually appropriate. They have an appreciation of the trade-offs that are made by testing at different levels. They are aware of the importance of writing testable code and demonstrate a basic competence. They refactor their code, and their tests as part of the test-driven process—they give equal weight to their production and test code.

Communication

They adopt a style of communication which fits the current audience. They regularly communicate progress and implementation without having to be prompted (particularly when tasks are taking longer than expected), and when they do there is an appropriate level of detail. If they are questioned about their reasoning they are able to explicitly explain their thought process. If they do not understand or agree with a decision they challenge it with humility until a consensus is reached.

Collaboration

They are considered to be a well-rounded and amicable person by their peers. They can take on board criticism maturely and where necessary provide it to others without causing offence. They seek to work with others, collaborating with other teams where appropriate. Pairing is second nature to them and they have learned to apply pairing etiquette. They have a good balance of asking questions and providing inspiration in appropriate contexts. They are open to the needs and requirements of other squads and can balance the interests of all parties.

Senior Developer

Delivery

Can be expected to deliver tasks reliably and at an acceptable rate. Will lead the delivery of mid-to-large projects, managing task breakdown and taking responsibility for their decisions. Will balance their determination to complete tasks with the need to involve others, breaking work into manageable chunks to ensure effective reporting. Will assume tasks from tech leads and promote expected behaviours in the team when necessary.

Coding

Maintains a critical outlook when appraising decisions. Has learnt to be pragmatic and strategic in the design process, balancing the needs of effective delivery and technological elegance. Is able to design solutions to system level problems, understanding any assumptions made and able to defend decisions professionally when challenged. Proactively addresses code quality and ensures this is not affected by pressure without due consideration, that there are fewer bugs & that code is unambiguous/easy for others to understand. Inspires others to deliver clean code, offering professional development sessions to others.

Testing

Knows that B/TDD can be an anti-behaviour if used inappropriately. Is able to easily identify the unit under test and can justify the chosen system boundaries. They are able to discuss the strategy for the automated testing of an entire product. They proactively work to ensure that tests are well balanced across appropriate test levels.

Communication

Is reflective on both the technical and non-technical aspects of the squad, suggesting ways to improve both. Can critique and review other’s work without driving defensive responses. Is able to justify decisions in a way that can be understood by non-technical colleagues, providing useful insight into the process. Will communicate progress and identify blockers in a timely manner without having to be prompted. Engage with other teams as it is appropriate to communicate changes and discuss design.

Collaboration

Is recognised by others as a source of knowledge and is often asked for help/opinions on problems/ideas.

Commercial Awareness

Is able to take a constructive part of the discussions regarding the commercial drive for a product or decision.

Coaching

Is inspirational and influential when discussing development points. Can motivate others to follow the Auto Trader values. Is able to constructively advise graduate and professional developers and has opinions which are respected accordingly.

Live Support/Operations

Is aware of their responsibilities around problems caused in production by applications they are responsible for. They do not pass the buck and are able to own the issue up to its completion, ensuring that learnings from problems feed back into the development of the product, improving stability or mitigating problems with quality documentation/logging. They proactively provide support for their product. Rather than waiting for a customer to report an issue, they take steps to make sure the right people will be alerted in a timely fashion and in a useful way. They are mindful of the impact their product’s development has on operational staff and they engage them at appropriate times to discuss this.

Principal Developer

Delivery

Principal developers drive work independently. In the absence of team leadership, they deputise in meetings at all levels and step in to lead projects technically and manage delivery (tackling slow moving tasks), ensuring that the usual team activities take place. They apply pragmatism to their approach, and the decisions they are accountable for can be proved to be sound in terms of design, technology, architecture, commercial impact, skills availability & project management. This pragmatism ensures that they do not sacrifice the delivery of value.

Coding

Principal developers regularly teach other developers using techniques such as pairing and code review to discuss code design and technical architecture. They use this as a platform to promote simple, elegant, clean code which is easy to maintain. They understand the context in which their application runs, including the runtime it runs within (e.g. JVM) and the operating system beneath it. This context includes being comfortable profiling, debugging and diagnosing problems with an application.

They have a breadth of experience in a number of different technologies, projects, languages and methodologies. They could step in and take the role of technical lead, reaching decisions by consensus with their team (where possible) and ensuring that everyone feels heard & understands the rationale behind it where a consensus is not possible. They are considered to be a go-to person for assistance by their colleagues, and their collaboration style is valued by their colleagues when working together.

They understand the technical estate their products sit within and how parts of that estate relate to and impact each other. The quality of their work is good—their code is clean and easy to maintain and rarely causes a negative impact to their users. They promote the responsible reduction of technical debt and take steps to minimise the accrual of further imprudent debt. They work strategically to improve solutions and the technical estate. In general, they can work independently on challenging work.

When faced with an unfamiliar code base or technology they are not daunted and are able to explore or research to get up to speed in a reasonable amount of time.

Testing

Principal Developers treat tests as they treat production code, looking out for cleanliness & maintainability and applying techniques such as refactoring and code review to them. They aim to create reusable code in tests to help improve the maintainability of tests and make them easier to create. Their tests are thoughtful and provide good coverage. They coach others along these lines and make sure that missing coverage (as indicated by production issues) is addressed to prevent regression.

Communication

Principal Developers are considered to be good communicators and adapt their communication style to suit the audience they are addressing. They appreciate that non-technical staff normally struggle to understand technical concepts when they are explained badly, not because of any deficiency on the listener’s part, and put the appropriate effort into their own explanations. This allows them to communicate complex concepts to less technical people without condescending them, and use questioning and body language to establish that they are being understood. They are comfortable speaking to a wider audience and similarly in a smaller group with senior staff, about progress and strategy.

They regularly communicate status to their colleagues such that others understand their progress without having to ask. They also communicate their knowledge to other engineers in both focussed and larger groups such as knowledge shares.

Collaboration

A Principal Developer works across the business with the appropriate stakeholders and collaborators as they make changes. This includes but is not limited to discussing the technical impact on other systems and architectural considerations across multiple applications.

They inform their product and delivery colleagues of risks and challenges as part of the delivery process. They are considered to be a strong collaborator, and colleagues appreciate the opportunity to work with them. As part of collaboration, they naturally include the transfer of knowledge and technique, developing those they work with on technical and non-technical fronts.

Commercial Awareness

A Principal Developer takes a strategic view of the squad, its purpose and position within the tribe, and ensures that the direction of the squad contributes at each level (squad, tribe and organisation) to the strategic priorities of the business. They understand what the squad is measured on, and do not focus on technical delivery in isolation of those KPIs. They are an advocate for their users—and can identify the appropriate trade-offs between conflicting requirements—identifying the most appropriate choices to drive our strategic objectives.

They actively seek out conversations with commercial colleagues, keeping them informed and part of the delivery process—helping their insight to feed into development. They make sure that decisions taken are informed by factors such as coordinated commercial activity around a release (for example).

Coaching

They are comfortable with a number of coaching styles and know how and when to deploy these (and they do on a day to day basis). They comfortably adopt the role of mentor where appropriate and are considered a technical authority. They understand how people’s motivations must be understood and taken into account while coaching, and this helps them to avoid confrontation when providing feedback.

When they identify problems (whether they be technical, procedural or other) they take others on the journey to resolve the problem rather than simply jumping in and fixing the issue. Refactoring is carried out with appropriate involvement from those who would benefit and rather than changing how the team work they share the recognition of the problem and help the team to find a solution.

In general, they seek to support the learning of all of their colleagues appropriately to share all that they have learned.

Live Support/Operations

They champion the concept of designing for failure, understanding that at some point every component of a system will fail. They design for this failure and ensure that the best outcome is achieved, with measures taken to ensure systems recover as quickly as possible and with minimal human intervention. Operational staff appreciate the assistance they provide when problems are encountered and they spread the mindset of operational awareness to all appropriate members of the team.

Enjoyed that? Read some other posts.