You build something and maintain it - forever? You build a new feature from scratch, and have to reinvent a wheel, an axle, and a steering column?

You have some challenges after attrition, team re-orgs (agile or top-down), and de-prioritized cross-training has left engineers frantically searching email archives for “fixed content deployment” or staring blankly as git blame lists only their most talented former colleagues. If only there were a structured way to have ensured these services lived on.

You have to deliver a new service that talks to vendors around the world, and you know we’re using AWS now, but you’re not sure what a secure network looks like, and you’ve only got a week to get it live, so you leave it open for now and hope you’ll get to go back around and fix it when you’ve got time. If only there were a structured way to peer with an engineer who could have provided that information in context when it was cheaper and less risky.

There is a structured way to have a centralized team of sustaining engineers tasked with preventing these and similar problems. Think Brownfields-focused SREs.

Sustaining engineering is a discipline that allows for continuous long term support of services, tight feedback loops, and growth for junior engineers.

• Jack-of-all-trades, which is different from full-stack.
• Degree in biotech, past life in broadband engineering (and wine, cheese, A/V, suits…) I was a working adult for 10 years before IT.
• Only