The Importance of Ownership in Engineering

One day I was working with a client to investigate a recurring issue in their environment. There were multiple people on this call trying to understand how to handle a use-case in a graceful manner, instead of erroring out abruptly. I must confess, it was tedious parsing their logs and architectural flow to understand what was causing it. While investigating, one of the builders had said “I can never be a tech, I would rather just build things and not have to troubleshoot them”. It got me thinking, I hadn’t built this workflow and here I was trying to figure it out with them. More importantly, I realized that this pattern of thinking is the cause of many problems in software products.

If you’ve worked in tech, it is commonplace to find projects that were not properly polished before being deployed publicly. It could be due to multiple reasons, perhaps the team may have been focused on capturing the market, or beating a competitor. While this is not a terrible thing, it is important to have a plan to stabilize the product, and fix any issues that may cause poor customer experience. I’ve seen instances where the development team keeps adding features and updating the product, since they don’t have to directly support it. In such cases, the technical support team has to find a way to pacify the customer, and come up with workarounds to help them achieve their goal. This is normal human behavior, if it’s someone else’s job to deal with the problem, why bother yourself about creating a well-built system?

The quality products I’ve seen are usually the ones that are also supported by the teams who built them. When you have vested interest in ensuring that your application is easy to debug, you would usually build it in a way that it’s easy to troubleshoot. No one likes to be paged at night because of an outage and see an error message that is difficult to understand. No one wants to spend hours diagnosing an error that is a bunch of useless hexadecimal numbers. In such a scenario, it helps if the message states the problem concisely, and even better, if it tells you how to fix it.

Ownership would therefore imply that the engineering team is involved in the entire lifecycle of the product: building, deploying, maintaining, and the users’ perspective. When the tech team puts themselves in the customer’s shoes continuously (i.e. before building and after deploying), they’ll build the product in a way that it is easy and intuitive for the user to interact with the product or service. When the engineering team is also involved in maintaining and supporting the product, they would make it as easy as possible to troubleshoot issues.

Taking Ownership is no easy task, but it brings huge rewards for everyone involved, from engineering, to customer, and support. This mindset change would mitigate many of the problems we observe in the tech landscape today. I hope the builder client sees this and says, “We need to improve the product to make it easier to troubleshoot”.