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, stories or projects
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
Leadership
Actively fosters an inclusive team culture, e.g.
Celebrates good work publicly and encourages the team to do the same
Spots problems between team members and helps to resolve them or escalate them as appropriate
Models inclusive behaviour to the rest of the team
《The Software Engineering Competency Model (SWECOM)》
在《The Software Engineering Competency Model (SWECOM)》提及
通识素养
