🛠️ Backend Engineering Framework

💬 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

💥 Impact

  • Delivers assigned tasks, working with a more senior team member, and able to take PR feedback to improve their work

👩‍💼 Leadership

✨ Influence

  • Improves documentation that is incorrect

🛠️ Mastery

  • Learns to write correct Go code, following guidance and training materials
  • Fixes simple bugs

💬 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
    • Take a look at the levelling up your code reviews talk for some ideas
  • Writes PR descriptions that provide context and provide rationale for significant decisions
    • I decided to X instead of Y here, I also considered Z but for these reasons I went with X

💥 Impact

  • 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/medium problems into iterative steps

👩‍💼 Leadership

✨ Influence

  • Proactively raises issues they spot in retrospectives

🛠️ Mastery

  • Designs simple database tables
  • Implements asynchronous messaging between services
  • Deploys services to staging and production
  • Handles simple error cases in RPC handlers and message consumers
  • Fixes bugs involving a number of services and can investigate production issues
  • Uses appropriate algorithms and data structures to solve problems
  • Writes automated unit and acceptance tests
  • Implements simple RPC handlers
    • Basic CRUD handlers
    • Internal/external API proxies
  • Writes correct Go code following accepted best practices
    • Follows our Coding Conventions & Best Practices, uses language-level primitives correctly

💬 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

💥 Impact

  • Delivers large well-defined tasks and solves small scope not-well-defined problems
  • Contributes to writing proposals (Co-authors with more experienced Engineer)
  • Breaks down large problems into smaller iterative steps across multiple PRs

👩‍💼 Leadership

  • Onboards / mentors new engineers
  • Finds learning opportunities for others when reviewing their code and follows it up
    • I think this code could be improved by doing X, let’s pair on it and I’ll talk through why X is good for this

✨ Influence

  • Provides valuable input to proposals from their team
  • Proactively improves modules, services, systems and codebases they encounter, ’this doesn’t make sense, I’m going to do something about it'
  • Contributes to scaling engineering hiring (e.g. leads calls, does onsite interviews)
  • Builds simple tools or iterates existing tools for the benefit of all engineers

🛠️ Mastery

  • Uses appropriate design patterns
  • Designs new schemas comprising multiple tables
  • Implements complex asynchronous messaging flows
  • Co-ordinates complex deployments and database migrations
  • Implements distributed systems consisting of multiple interacting services
  • Produces technical designs that include a consideration of scalability
  • Handles complex error cases in RPC handlers and message consumers
  • Debugs production issues
  • Considers metrics when building a new system
  • Writes idiomatic Go code
  • Mitigates race conditions and partial failure states in distributed systems
    • Uses locking where appropriate, writes code that is “self-healing” when dealing with distributed failure (e.g. data needs to be written in two or more services)
  • Implements complex RPC handlers
    • Implements complex business logic, orchestrates multi-stage processes, deals with idempotency or distributed data sources
  • Proactively considers security implications of their work
    • Appropriately ties down internal access to resources they’re working with (e.g. RPC blacklisting, BigQuery permissions)
    • Evaluates security risks when contributing to proposals
    • Highlights potential security issues when raising and reviewing pull requests - e.g. adding rate limiting in an API, or leaving a code comment to explain why we choose not to
    • “There’s a risk here of X, Y but given Z, I think this is OK”
    • Loops in Security when their squad is unsure about something by posting in #security-requests

💬 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

💥 Impact

  • Solves ambiguous problems
  • Leads writing small/medium scope proposals
  • Thrown at fires and resolves / contributes heavily to resolving them
  • Makes pragmatic choices about taking on tech debt
  • Considers multiple different solutions for solving a problem
  • Breaks down projects into smaller iterative steps that each deliver value

👩‍💼 Leadership

  • Contributes to maintaining the Dummy Co culture in their team, helping new joiners
  • Gets buy-in on technical decision-making and proposed designs
  • Proactively involves other relevant engineers
  • Sought out for code reviews
  • Instills Dummy Co engineering principles in other engineers
  • Helps the growth of engineers around them through coaching and mentoring
  • Helps their squad work together more effectively
  • Helps facilitate team/squad rituals
  • Makes improvements to modules/libraries/services and goes out of their way to help others learn from it
    • I’ve used RxJava for the first time here, I’m going to do a talk about why I’ve done this, here’s some great blog posts on 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 junior team members, provides context/guidance, or knows how to escalate
  • Asks why. Does not take truths for granted unless they understand exactly where they are coming from (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 in their squad

🛠️ Mastery

  • Writes code that serves as a definitive example for new engineers
  • Leads the refactoring (de-cruftification) of complex systems
  • Debugs complex production issues at speed
  • Identifies and fixes security vulnerabilities
  • Identifies and fixes performance bottlenecks in individual services
  • Explains all aspects of the platform to new engineers
  • Includes actionable dashboarding as part of a new system
  • Implements services or libraries that require a deep level of domain knowledge
    • Mastercard message parsing
    • Credit decisioning
    • CASS scheduling
    • Google Pay
  • Makes contributions to library code or core services
    • Bug fixes, small improvements; things that don’t result in a major change in the public API
  • Builds systems that scale reliably without intervention
    • Services can withstand a year’s worth of growth in load/user base without needing first aid

💬 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

💥 Impact

  • Solves the ‘hard problem’ in a project e.g. Mastercard crypto and sees it through to resolution
  • Solves larger ambiguous 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 proposals
  • 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

👩‍💼 Leadership

  • Instills Dummy Co engineering principles across a whole squad of engineers
  • Works with relevant Engineering Managers to help other engineers perform and grow
  • Fosters effective collaboration in multi-disciplinary squads (backend, mobile, data, design, web)
  • Delegates technical decisions with low risk and high reversibility
  • Owns technical decisions with high risk and low reversibility
  • Contributes to maintaining the Dummy Co culture in the wider company
  • Bootstraps new teams

✨ Influence

  • Represents Dummy Co at conferences/events
  • Given as reason for other engineers to join Dummy Co
  • Proactively shares knowledge internally
  • Acts as the ‘sole proprietor’, in the CEO mindset, their ego/agenda is not a factor in their thinking or decision making

🛠️ Mastery

  • Builds systems that serve as definitive examples for new engineers
  • Makes major contributions to library code or core services
  • Contributes to external technologies or libraries that we depend on
  • Develops clear technical solutions from ambiguous requirements
  • Uncovers and fixes tricky bugs that have previously evaded detection
  • Implements security improvements that impact multiple services
  • Implements performance improvements that impact multiple services
  • Demonstrates a deep level of knowledge in a specific area
  • Serves as a technical authority on a technology or an area of the codebase
  • Creates dashboards that broadly impact all engineers
  • Produces clear technical designs for large complex projects
    • Outbound and Inbound MasterCard clearing proposals

💬 Communication

  • Transparent about feedback they have received and what they are going to do differently

💥 Impact

  • Accountable for delivery of large, mission critical engineering projects
  • Originates or finishes large, horizontal engineering efforts

👩‍💼 Leadership

  • Helps groups of squads work together more effectively
  • Starts things that they cannot finish by themselves
  • Delegates to make better use of their time

✨ Influence

  • Attracts other very senior hires
  • Engineers around them get better and have a bigger impact, faster

🛠️ Mastery

  • Makes major contributions to technologies and libraries that we depend on
  • Makes improvements to the stability, performance or security of the entire platform
  • Serves as a technical authority in the wider engineering community

About our engineering progression frameworks

The engineering progression framework 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 framework 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.

How does it work?

The framework covers all the things we’re looking for from engineers at Dummy Co. We’re interested in these five elements:

  • Mastery - Your Dummy Co knowledge and technical capability
  • Impact - The size, scope and value of what you deliver
  • Influence - How you change the world around you for the better
  • Comms & Feedback - How you interact with others
  • Leadership - How people around you become better and more impactful

We sort them into six levels, and we try to give specific examples of behaviours we expect for each. Each of those levels has a fairly wide salary range associated with it, and within each level you can progress in sub-levels, labelled A–E. So even if you’re at level 3 for a couple of years, you’ll still be able to see that you’re moving forward. Basically, the more behaviours you show from your level, the more you’ll progress.

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 Dummy Co as you grow, including deep technical knowledge and ability, technical leadership and people management. All are equally valuable paths in Dummy Co’s engineering team.
  • The framework 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.
  • This isn’t a checklist – it’s possible to progress up a level without showing all the behaviours in that level.
  • There will be levels on top (eg ‘Inventor of Android’ or ‘Author of Go’), 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 framework and we really want your feedback.

We’re particularly keen to add as many examples to the behaviours as possible, to further clarify them.