Ownership
TLDR: Ownership extends beyond technology teams and what they produce. Incorrectly identified owners create barriers, silos information, and lowers overall short and long-term efficiency. Technology leaders have a responsibility to correctly identify owners resulting in better information and skill transfer and improved efficiency throughout an org.
As technology disciplines become more accessible for an increasing amount of developers, the concept of increasing ownership in technology organizations has skyrocketed to the top of most cross-functional teams. The idea is that if you build it, you own it. You’re responsible for the end-to-end lifecycle of the thing in question. When most people think about ownership I think it is easy to immediately jump to visualizing a small group of developers owning something like a microservice. They can provision the infrastructure, manage its scale, administer the Database, build the backend and front end, etc. Anything and everything related to improving, iterating, or maintaining this microservice can and should be handled by this team. I think we all understand this concept, it’s been talked to over and over again by any prominent leader in technology.
However, it is my anecdotal experience that most organizations I’ve been around stop thinking about building a culture of ownership the moment we stop talking about very specific technology examples, such as the microservice above. To be fair, I also think it’s easy to understand why this might be the case. For technology teams, we usually produce something tangible, that has tangible components working together to perform a defined function. In this case, it’s simple to understand what skills are required to tune those components and to identify which persons have expertise in those skills to train and upskill their team.
Expanding this concept beyond technology teams is a bit more difficult and a source of dysfunction in organizations, resulting in tasks being thrown over walls and information remaining siloed. For example, let’s imagine our simple technology team from above is going through an audit and our security team has tasks that need to be finished to complete the audit. In this scenario we might be tempted to say, well the technology team built the service so they own the audit for that service. Alternatively, we might say no the security team owns the completion of the audit.
To identify our owner let’s look at what happens as a result of each team owning the tasks required to complete the audit. If our tech team is responsible, and no information is shared with security, we create a barrier that requirements need to travel over decreasing efficiency, and next year when we go through this audit, security will reach out seeking a repeat of the same tasks. Instead, if we ask our security team to own this audit and drive its tasks to completion, this team is responsible for extracting and aggregating information resulting in cross-function knowledge sharing. The requirements aren’t traveling from one team to another instead, stay within the bounds of security improving our efficiency. Finally, when we go through this audit again next year, security has already shortcut the process by being upskilled with the current information.
As technology leaders it’s our responsibility to identify when ownership has been incorrectly transferred from one team to another. Tasks and information shouldn’t need to be repeated from one event to the next and we should see information flowing from one team to another via collaboration, requirements shouldn’t need to travel across team barriers, and we should see an upskilling in our team’s abilities over time.
