This project is currently in BETA, it's ready to use, but wording and examples may still change.

Mid to Senior 1

Senior 1 (S1) engineers are expected to improve the performance of those around them. This could be through additional official responsibilities such as line managing or tech leading, or through unofficial means such as mentoring or regular pairing. S1 engineers should be able to tackle more complicated technical problems, and explain and justify their approaches to their team. We expect S1 engineers to pick up work outside of their delivery team and manage that work effectively against their delivery team’s priorities. S1 engineers require very little oversight beyond high level direction.

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

Area Competency
Technical Builds products ensuring they take adequate steps to protect sensitive data, e.g.
  • Databases have encryption at rest
  • Sensitive data is masked or in restricted indexes in Splunk
  • Data is retained only for as long as it is needed
  • Dummy/fictional data is used in staging environments and in tests
  • Suppliers don't get access to data unless they have gone through the Procurement Management Application process
Technical Implements appropriate observability and monitoring when building a solution, e.g.
  • When adding a new dependency to a system, adds a healthcheck to monitor the dependency's state
  • Adds logging that is well-structured and captures useful information about the state of a system
  • Builds a Grafana dashboard that visualises normal and abnormal operation of a system
Technical Evaluates third-party software to use in projects, e.g.
  • Can choose between similar Node libraries evaluating code quality, ease of integration, future maintenance, and security concerns
  • May be involved in evaluating paid-for third party supplier code
Technical Leads on fixing live incidents in production, e.g.
  • Takes proactive action when an incident is reported on a system they support and resolves it satisfactorily
  • Responds to critical issues raised in #ft-tech-incidents taking the initiative to fix them and reports back
Technical Understands the security attack vectors for their area of technology and mitigates against them, e.g.
  • Uses Snyk.io on projects
  • Sanitises user input to mitigate against XSS attacks
  • Applies security patches to an operating system
  • Protecting public API endpoints
  • Articulates security risks/benefits when evaluating third party software
  • Uses Fastly WAF to protect from malicious requests
Technical Makes pragmatic decisions about technical trade-offs within their project, e.g.
  • Knows when to stop work on a feature that has fulfilled the requirements vs. spending an extra week on making it perfect but delivering little additional value
  • When pressed for time, focuses on ensuring test coverage of the most critical system functionality
  • Manages technical debt, understands consequences of technical debt vs the cost of fixing it and acts accordingly
  • Can explain when something is worth refactoring even when it will impact the speed of delivery
Technical Delivers high quality code and solutions, e.g.
  • Refactors solutions to improve clarity and maintainability
Technical Encourages others to deliver high quality code and solutions, e.g.
  • Implements tooling to enforce high standards
  • Reviews pull requests fairly & critically in such away that team members produce better code
Technical Regularly and independently debugs and fixes bugs regardless of origin, e.g.
  • Picks up and debugs an urgent issue that comes in to the team, despite having not written the code originally
Technical Builds software or services considering resilience, performance and failure modes, e.g.
  • Combines multiple data sources in a feature, caching, polling etc as appropriate to cope with problems in downstream services
  • Adds healthchecks to a system that detect different ways in which it can fail
Technical Chooses the appropriate tool, technology or software for a task, e.g.
  • If starting a new project, uses tools already understood by the team unless there is an agreed good reason to change
Technical Builds and works with systems involving multiple, independent technical parts, e.g.
  • Adds data sources to or optimises performance of a data pipeline
  • Publishes a new origami component that uses other components
  • Implements a CDN / gateway that routes to a suite of underlying microservices
  • Designs and implements a build pipeline
Technical Considers the technical direction of their group or the wider department when coming up with technical solutions, e.g.
  • Understands how their work feeds into their group's tech strategy
  • Can articulate and justify the total cost of ownership of their technical solutions
  • Follows their group's Engineering Principles when building technical solutions
Communication Communicates technical concepts clearly and adapts that communication to the audience, e.g.
  • Explains their work in standups knowing which technical details to leave out to make the message meaningful to everyone in the room
  • Teaches more junior engineers
  • Creates diagrams to document how the different parts of systems interact
  • Presents their own work clearly to stakeholders
Communication Facilitates productive discussions with clear outcomes, e.g.
  • Runs meetings with clear agendas and outcomes
  • Obtains wide feedback on technical proposals and takes ownership of seeing it through
Communication Contributes to hiring process, e.g.
  • Participates in hiring panels or technical interviews
  • Attends recruitment events
  • Publicly shares links to open roles
  • Goes for coffee with potential hires to talk about what working at the Financial Times is like
  • Shares our work publicly, (through blogging, speaking, etc) to show the kinds of work we do here
  • Reviews CVs
  • Reviews tech tests
Delivery Prioritises technical work for the team (usually with others)
Delivery Breaks down large complex technical proposals into discrete tasks, e.g.
  • Creates the user stories for the ticket with a delivery lead
Delivery Communicates team/work's status upwards to a Principal or Technical Director
Delivery Where appropriate, builds on other teams' work to solve problems, e.g.
  • Uses origami components to style a web page
  • Uses Biz Ops as a source of system data rather than creating a new system registry
Delivery Moves blockers to enable more junior engineers to work, e.g.
  • Reviews pull requests
  • Suggests someone to talk to eg “[X] knows the most about [technology Y], you could ask them”
Delivery Tackles simple cross team technical issues, e.g.
  • Notices a tool used by lots of teams has broken, identifies the problem and fixes (or reports it to the owner of the tool)
Delivery Actively seeks the views of other teams to help guide work, e.g.
  • Attends cross team meetings
  • Asks other teams for input and opinions on decisions that affect them
Delivery Improves delivery process and encourages others to do the same, e.g.
  • Updates the scrum process to fit the changing needs of the team
  • Champions technical issues that affect delivery such as release cycles, dealing with tech debt and bug fixes
  • Encourages other engineers to participate in agile team rituals
Delivery Manages, prioritises and communicates own workload
Leadership Influences a community of practice, e.g.
  • Is an active member of a Guild
  • Answers questions in the #engineering Slack channel
  • Gives a tech talk (internally or externally)
  • Writes a blog post
  • Shares industry relevant content/links with team members that may be interested
Leadership Is an ambassador for their team across FT technology, e.g.
  • Positively represents their team in interactions with other people by seeking to understand their perspectives, values and needs
  • Consistently contributes to their team being positively perceived by stakeholders (or by other engineering teams to which they provide support)
Leadership Contributes to the personal development of more junior people, e.g.
  • Is a line manager or mentor
  • Is a designated buddy to a new starter
  • Regularly meets up with more junior peers to provide guidance
  • Pairs with more junior team members
  • Writes blog posts to share knowledge
  • Gives talks at meet-ups or conferences to share knowledge
Leadership Shows technical leadership, e.g.
  • Is a tech lead
  • Runs, or is on the organising team for a Guild
  • Leads on large features or stories
Leadership Shares knowledge with others internally, e.g.
  • Gives a workshop on Git
  • Runs a regular 101 session for the rest of the business
  • More informal knowledge sharing through mentorship