Engineer

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
Technical

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

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

Uses code to make something with some degree of complexity, e.g.

  • Takes a feature from their team backlog and writes the code for that feature
  • Automates a regular task using Babashka or another scripting language
  • Writes appropriate infrastructure as code to add/change/remove services
Technical

Writes automated unit and end to end tests for features

Technical

Fixes or updates tests when changing existing code

Technical

Reuses existing code, e.g.

  • Uses a Clojure library in project
  • Uses a ClojureScript library in project
  • Integrates with proprietary software packages
Technical

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

  • Fixes vulnerabilities identified by security audits
  • Doesn't introduce vulnerabilities outlined in the Open Web Application Security Project (OWASP) top 10

Supporting URLs:

Technical

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

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

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 to restore a service
Technical

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

  • Sees their build is failing and finds out why using the CircleCI or GitHub interface
  • Restarts broken builds
  • Makes config changes in CircleCI/GitHub actions
  • Promotes an app from dev to production
Technical

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

  • CloudWatch
Technical

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 storing state in the client or the server - it's more complex in client but may be better UX
Communication

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
  • Writes and updates runbooks for services they work on
Communication

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
Communication

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
Communication

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.
Delivery

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
Delivery

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
Delivery

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
Delivery

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
Delivery

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

Delivery

Regularly communicates the status of work

Delivery

Asks for help or clarification on tasks when required

Delivery

Participates in delivery process, e.g.

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

Can articulate the business goal of a set of features, e.g.

  • In conversation, distinguishes between what a feature does and the benefit it should provide
  • Proposes priority or feature changes to deliver business benefits sooner
  • Explains the business benefits of work when demoing it
Leadership

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
Leadership

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
Leadership

Has worked with teams outside of their home group (where home group will be one of Customer Products, Obrizum Core, Community, Cyber Security, Internal Products, Engineering Enablement, Staff Experience and Obrizum Specialist), e.g.

  • Based in Customer Products but collaborated with developers from Obrizum 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
Leadership

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