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.
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
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
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
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
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
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
Delivers high quality code and solutions, e.g.
- Implements tooling to enforce high standards
- Refactors solutions to improve clarity and maintainability
Encourages others to delivery high quality code and solutions, e.g.
- Reviews pull requests fairly & critically in such away that team members produce better code
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
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
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
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
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
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
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
Prioritises technical work for the team (usually with others)
Breaks down large complex technical proposals into discrete tasks, e.g.
- Creates the user stories for the ticket with a delivery lead
Communicates team/work's status upwards to a Principal or Technical Director
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
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”
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)
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
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
Manages, prioritises and communicates own workload
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
Is an ambassador for their team across FT technology and colleagues in the rest of the business, 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)
Has responsibility for others’ professional development, 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
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
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