👩‍💻 Mobile Engineering Framework

💬 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

Uses appropriate algorithms and data structures to solve problems
Uses appropriate design patterns
Responsible for building small to medium sized new features inside the app
Modifies and improves existing parts of the app (and reasons about the improvements)
Adds basic UI tests or snapshots
Adds basic unit tests
Proactively learns new things and seeks out people who can help them
Manages the release master process
Contributes to Android or iOS chat
Appropriately uses common functional reactive programming concepts
Designs database models
Appropriately handles errors or failure conditions in their code
Works with designers to handle empty, error, and loading states in multi screen flows
Integrates with new APIs
- Can add an integration with a new backend endpoint and handle return data
- Can add an integration with a documented third party API
Uses concurrency appropriately
- Can reason whether to use asynchronous or synchronous operations
- Understands impact on app performance to use either

💬 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 tools to diagnose and improve performance issues
Builds non-trivial, coordinated app flows with multiple services and data sources
Builds complex UI layouts in code or via IDE
Contributes to group standards, impactful in improving our processes
Proactively improves empty, error and loading states in screens & flows they encounter, works closely with designers to identify problem areas and suggest improvements
Adds migrations to handle changes between old and new app versions
- Owning migration from major language versions
- Handling complex changes to third party dependencies
- Writing migrations from one data schema to another

💬 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
Identifies and fixes security vulnerabilities
Sought out for reviewing complex changes or commenting on larger scale proposals
Builds flows that serve as an example of high quality interaction design
Owns and coordinates large scale architectural changes to the entire codebase
- Researches potential solutions and evaluates how they solve the problem.
- Able to articulate why a change in architecture is needed and the impact this will have on the team and business.
- Dissects into discrete tasks and works with other team members to resolve issues.
- Examples include network request lifecycle and authorisation, model layer and persistence, app navigation and coordination (eg deep links), and modularisation
Debugs complex problems across a variety of subject areas
- Seeks out technical knowledge to compliment their own, researches and patches third party libraries where needed. Uses reasoning to debug and find the root cause of issues.
- Articulates problem and proposed solution to both technical and non technical peers.
Writes proposals and architects complex app flows
- Coordinates with backend developers around API specifications and requirements.
- Able to digest into discrete tasks and work with peers to solve problem in an efficient manner to avoid blockers.

💬 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

Anticipates large or significant platform changes, work with team to define possible solutions. Starts or finishes these projects.
Takes high level requirements and turns them into discrete technical concerns
Instills and maintains a culture of high quality interaction design in their discipline
Coordinates group efforts across horizontal
- A technical authority for iOS/Android on multiple teams, working with team leads and other engineers across the company.
Anticipates platform/project needs from other teams, technical debt and common problems
- Proactively seeks out solutions for problems not owned by product teams, works with others to scope and identify solutions. Justifies effort to PMs in order to schedule work.
Takes charge of low level deep dives when debugging complex issues.
- Able to handle situations where domain knowledge does not exist in the company and can lead the effort to resolve them.
- For example, resolving issues with our compiler and mapping out code paths for ‘hard to reproduce’ issues

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.