Member-only story
Ownership and on-call
At many modern tech companies, teams build services and run them too. I watched this shift take place at the first company I worked at as the DevOps movement was taking off. Rather than writing code on one team, then throwing it over a wall to another team to operate the code, companies started combining the “development” and the “operations” into one team, hence, DevOps. This approach enables teams to build both product knowledge and technical leverage, since the team gets to see how their product and tech decisions fare in production. Every time a team sees user frustration, high latencies, or unexpected failure modes, it see new opportunities to improve the UI, the UX, or the level of service going forward. This learning is crucial for success, and it can only come when a team is responsible for their code in production.
Production responsibility places demands on the team however. One such demand is on-call. On-call is the practice of setting an engineer up with a pager (typically an app on your computer or phone) that can notify the engineer when something breaks. The engineer must respond to any production issues that they get paged for. While on-call isn’t the most pleasant part of the job, it is an important part of providing a consistent level of service to customers. In my own experience, it’s also a great way to rapidly learn from technical mistakes (which allows you to build more technical…
