my engineering standards

  • It was conceived, prioritised and executed using our standard product development and engineering processes.
  • Key engineering decisions were made based on thorough investigation, experimentation and analysis rather than weak understanding and/or guesswork.
  • Work was ordered to eliminate risks instead of making linear progress.
  • Where possible it was built from standard technologies.
  • There is sufficient instrumentation that the system is considered observable, especially in times out outage.
  • It was shipped in many small releases rather than one bigger release.
  • As assessed, individual changes were derisked by leveraging feature flags, especially when high throughput, complex or unfamiliar code paths were touched.
  • Each change was tested and validated after it went to production to assess if it worked and to see if it broke something else.
  • We added a small number of high signal paging alarms to ensure we knew when customer-facing functionality broke.
  • We are confident that it won’t run out of capacity due to predictable growth.
  • There is sufficient, discoverable documentation such that someone else can maintain and evolve things from here.
  • The systems should be recoverable by a shared out-of-hours oncall team.
  • We were deliberate about communicating, getting peer review and feedback from the relevant people/teams all along the way.

--

--

--

VP of Engineering @Intercom

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rich Archbold

Rich Archbold

VP of Engineering @Intercom

More from Medium

My first week at Everest Engineering

The Bleak Tech Market’s Silver Lining

The hidden costs of outsourcing Software Development

3 Ways to Foster a Great Remote Engineering Culture