Mid level engineers should be proficient in the technical systems that they are working on. They should be aware and guided by the wider context of their work. They should take responsibility for their work and own their personal development. They should be working as part of a team to achieve the shared goals of the team.

The competencies for Engineer are outlined below. Before reviewing them, it is helpful to review how to use these competencies.

Area Competency

Is responsible for and maintains their computer and local development environment, e.g.

  • Keeps local tools up to date
  • Follows instructions to get software projects running locally

Uses version control to manage development workflow, e.g.

  • Git specific example: clone, branch, add, commit, push, rebase

Uses code to make something, e.g.

  • Takes a feature from their team backlog and writes the code for that feature
  • Automates a regular task using Python
  • Writes a CloudFormation template

Writes automated unit and end to end tests for features


Fixes or updates tests when changing existing code


Reuses existing code, e.g.

  • Uses a python package in project
  • Uses a node package in project
  • Integrates with proprietary software packages
  • Uses Origami

Maintains the security of the systems they work on, e.g.

  • Fixes vulnerabilities in dependencies raised by Snyk
  • Fixes vulnerabilities raised by the cyber security team
  • Doesn't introduce vulnerabilities outlined in the Open Web Application Security Project (OWASP) top 10

Supporting URLs:


Regularly and independently debugs and fixes bugs in their own code, e.g.

  • Fixes broken tests caused by changes in their code
  • Uses logging or a debugger to find the root cause when a new feature is not working as expected

Gets involved in fixing live incidents in production, e.g.

  • Notices that an AWS region is down so fails over to another region
  • Responds to alerts for services in production by investigating errors and beginning remedial action
  • Works as home teams' "ops cop", liaising with Operations and Reliability to restore a service

Uses continuous delivery or build pipelines for automation, e.g.

  • Sees their build is failing and finds out why using the CircleCI or Jenkins interface
  • Restarts broken builds
  • Makes config changes in CircleCI
  • Adds a build status badge to their project
  • Promotes an app from staging to production in Heroku

Uses monitoring (but doesn't necessarily implement monitoring), e.g.

  • Pingdom, grafana

Makes pragmatic decisions about technical trade-offs within their own code, e.g.

  • Weighs up the benefits of making code more abstract vs specific
  • Reasons about making an API call from the client or from the server - it's easier from the client but core experience will be worse

Maintains documentation on the systems they work on, making it easy for future engineers to interact with systems and code, e.g.

  • Writes READMEs with the appropriate level of detail for getting the project set up
  • Documents common issues with the codebase in a troubleshooting section in the README
  • Finds some documentation they are reading is out of date so opens a Pull Request to improve it
  • Writes good commit messages that explain why a change was made
  • Puts line comments around any 'magic' bits of code
  • Writes and updates runbooks for services they work on

Provides feedback on peer’s work, e.g.

  • Reviews pull requests and gives actionable empathetic feedback
  • Recognises when a more senior colleague has not given enough detail in an explanation, and asks for clarification
  • Gives realtime feedback in mob programming sessions

Writes clear tickets, issues and bug reports that contain the necessary amount of detail to be picked up by other engineers, e.g.

  • Adds links to the pages that are affected by a bug
  • Writes steps to reproduce an issue that they've found
  • Adds screenshots to a ticket to help explain a display bug

Receives feedback and acts upon it, e.g.

  • Implements requested changes on a pull request
  • Responds to comments on a Google document
  • Receives feedback from the team that sometimes they don't seem well prepared for morning stand-ups, so takes 5 minutes before stand-ups to gather thoughts about what the status of their work is

Regularly gives timely actionable feedback to colleagues, e.g.

  • Emails positive feedback to a colleague's line manager, after the colleague was especially helpful.
  • Notices that someone in the team has invited everyone to a meeting without an agenda. Asks them to add one so people know what the meeting is for and can prepare properly.

Presents their own work clearly to a product owner or tech lead, e.g.

  • Talks about their progress in standup without going into deep technical detail
  • Explains their approach to a technical problem to their tech lead
  • Gives a live demo of a feature that they worked on to their team

Works on the most important task, e.g.

  • Picks the story from the top of a prioritised backlog rather than picking the one that most interests them
  • Creates tickets to capture non-trivial tech debt, rather than getting side-tracked by things not needed to complete the current task

Uses user research or data to inform decisions, e.g.

  • Attends customer based user research for a feature being worked on
  • Sets up a testing session with peers for a new bit of tooling
  • Finds a common pain point among teammates and proposes/builds a solution for it

Leads on getting well defined tasks from backlog to production, e.g.

  • Turns a user story into a technical implementation in production
  • Raises blockers in timely way

Regularly collaborates with team members from other disciplines to deliver features, e.g.

  • Pairs with the designer who worked on visuals or wire-frames for a feature
  • Sits with their product owner to discuss some edge-cases in a feature
  • Helps to debug a cross-browser issue with a tester

Regularly contributes openly to team meetings and encourages others to do so


Regularly communicates the status of work


Asks for help or clarification on tasks when required


Participates in delivery process, e.g.

  • Moves tickets to done column when they are complete
  • Goes to stand-ups and communicates progress

Knows who their project's stakeholders are


Acts with integrity, honesty and accountability


Positively contributes to an inclusive team culture, e.g.

  • Reminds others that team members may have child care duties
  • Draws people working remotely into planning conversations
  • Tactfully calls out exclusive or alienating behaviours from others
  • Organises a leaving collection for a colleague
  • Documents team norms to help new starters
  • Checks in with team members who appear stressed

Shares knowledge with peers informally, e.g.

  • Pairs on a feature with a more junior colleague
  • Helps onboard a new hire, acting as their go-to person for questions
  • Comes back from a conference and shares their learnings with others

Has worked with teams outside of their home group (where home group will be one of Customer Products, FT Core, Internal Products, Operations and Reliability, Enterprise Services and Security, FT Group Products or FT Labs), e.g.

  • Based in Customer Products but collaborated with developers from FT Core to build a new API endpoint for content
  • Has done a bootcamp with another group
  • Had done a secondment to Operations and Reliability
  • Works in the Interactive Graphics team and collaborates with someone from Editorial on a project
  • Works in Internal Products and collaborates with the Origami team on a new feature in a component

Takes ownership of their personal development, e.g.

  • Sees some code that they don't understand, and researches how it works
  • Proactively learns how to use a new tool/language feature
  • Reads blog posts about technology
  • Studies for and attains a technical certification
  • Finds a training course and takes it
  • Attends meet-ups or conferences