What does service ownership mean to you?

#discuss

What does it mean to have ownership of a software service?

Top comments (2)

🤔 I feel like I own services at work, but I'm not sure I've thought about what it means explicitly. "I know it when I see it." In practice, I think there are things that make me feel like I own the service:

I built it. Even if I adopted some initial version, I've designed, architected, and/or implemented the significant parts of the service as it is now.
I'm now the primary (or, at various points, the only) developer.
I review all the code that goes into the service.
I know the code base like the back of my hand. Honestly, sometimes I surprise myself when I can recall the exact source code for something from memory.
New features requests have to go through me to assess feasibility, design considerations, etc.
I set the course. Not only do I field external requests, I have internal features to develop without anyone telling me to do so - because I know what the problems are.
I'm the source of answers about the service. Anyone with a question automatically goes to me.

It's with a degree of guilt that I recognize some of these as antipatterns. Reviewing everything can just be gatekeeping. Being the source of answers can just be bus factor. Being the primary developer could just mean I'm a lone wolf in a silo. Knowing everything can just lead to unspoken institutional knowledge. While my sense of ownership comes from being a control freak, "real" ownership bears some social responsibility:

With the whole system living in my head, it's incumbent upon me to share the information. I onboard new developers, leave documentation to answer questions before they come up, and get the internal roadmap out of my head (e.g., with ticketing).
I don't only own the parts of the service that work. I have to take responsibility when things break. A lot of the time, I only have myself to blame - I wrote the code! Just as I'm a go-to for business questions, I'm the go-to for outages. I know and debug the failure modes.
Tying those two thoughts together, in a healthy organization I should theoretically be responsible for ensuring everyone else can respond to outages. That's not really been my experience (my company's bus factors run high), and it's perhaps out of scope when talking about ownership per se versus healthy team dynamics.
I have to do everything in my power to maintain quality. Testing, API docs, style, reliability. This gives me a sense of ownership alone just by being the one who sets the standards.
I should at least have a handle on what happens on the "other side" of the code. I have an idea of how the deploy works (even if I don't own the pipeline), how the service affects the user experience, whether the spirit of a feature (not just the "letter of the law") works as intended, and so on.

Maybe this is more a list of symptoms of ownership than what ownership means, but it's the shape of what I think about when I say I "own" a system.