Ownerships in the night
Ever said a word so many times that you're not sure it's a real word anymore?
I joined a panel of very lovely folks on a panel at the Melbourne SRE Meetup to talk about who owns what when Platform and SRE disagree on the matter. There were a lot of great discussions - mostly centring around that word: ownership. And what I really loved was how both my peers in the panel and the audience all so deftly broke down the concept of "ownership" into concrete, describable parts when they talked about it.
It got me thinking. About ownership. About how it's my third least favourite word. And about how it's a lot like my first least favourite word...
Tech-debt.
Maybe that's two words. Either way, I feel there are few words that have done as much harm to developers goals of getting meaningful work approved as "tech-debt". A simple incantation that, on its utterance, will prompt Product Managers to fall asleep and managers to immediately don the kid gloves and gently guide you to sit back down and put your shirt back on. Saying it aloud is the finest way to ensure that nobody with any cachet in the business will listen to you, and maybe ensure that they even begin actively avoiding you.
To be clear, this isn't to say people aren't describing a real problem when they talk about tech-debt! Systems get harder to maintain over time. Shortcuts that made sense in one context lead to problems that make folks absolutely miserable in the future. This is all very, very real. You should talk to your peers, your manager, your PM, even your nan, about these problems...
...just don't describe them as tech-debt.
Why? Because it doesn't give the listener a clearer understanding of the problem than they had before they talked to you. Because it doesn't describe the action that needs to be taken. "This is tech debt" doesn't describe the problem. "We should fix our tech debt" doesn't describe a plan.
"Tech-debt" is an emotionally loaded term. It's a value-judgement. It implies all the things we associate with debt - frivolity, poor decision making, irresponsibility (even if that's not intended). It focuses on negative characterisation of your current technology over making a business case for your idea. People get suspicious when you appeal to emotion in technical discussions, and every person in a leadership position has seen the term abused, ad nauseam, by engineers who are struggling to make a positive case for a new idea.
But worst of all, you can say "tech debt is bad" and have a bunch of people who don't agree with you... well, agree with you. You're not inviting your peers to help you scrutinise the substantive content of your argument (something you should want to do very badly). You're inviting them to reach false consensus based on fashion.
Why do we say it? I don't know! The alternative is so much easier and more effective: Describe the concrete thing that's wrong. Propose a solution. Make a case for why the solution is better. This invites discussion. It allows people to engage with a substantive proposal, not abstract dogma.
Feel free to get me on the phone to talk about this - I'll talk your ear off about it. But we're not here to talk about tech-debt today, we're here to talk about...
Ownership.
What's one term got to do with the other? Nothing! What do they have in common? They both help you and your peers think you agree with each other when you in fact, don't. Join me on a journey:
Picture a meeting. We've booked it in to discuss some growing tensions between team Battle Cat and team Fighter Jet (we're an enterprise so our VP of Engineering's main job is giving our teams dynamic sounding names) around the ownership of some CI/CD pipelines that both teams develop together and use to manage their team's services.
The meeting goes excellently! Team Battlecat agree to own the pipelines, much to the elation of both parties, who then go their separate ways. A few of them even kiss before leaving.
Shortly after, however, tensions flare when Team Battlecat put a review gate on the code for the pipelines that requires PR approval from one of their members. Matters further escalate when a member of Team Battlecat is woken up at 3am by a page for errors coming from Team Fighter Jet's deployment failures . Things go completely Lord of the Flies when Team Battlecat's inbox starts filling up with feature requests for the pipelines from people they've never met before who have started using the pipelines in their services.
My little fiction here is a but purple, but you get the idea. We all agreed to our favourite parts of ownership in the meeting, assumed the bits we didn't like didn't apply, and the elephant was thoroughly mishandled by everyone in the room.
The word "ownership" is a lot like "tech-debt". You can say it and simply paper over the substantive parts of a discussion. You can reach furious agreement with peers who furiously disagree with you. This is the opposite of what you want! As peaceful as agreement is, it's painful when you realise you never had it 6 months later.
So what do we say instead? One thing I really liked that someone (me) described at the meetup was a "taxonomy of ownership". Much like "tech-debt", the best way to remove ambiguity is to... actually say the things:
- We'll be responsible for ensuring the code that runs the pipelines is well tested and doesn't have defects
- The main way we'll collaborate with other teams is by accepting PRs to the codebase. We'll have final say on what goes in and doesn't
- We'll probably not accept feature requests unless we can secure dedicated resources to work on this code.
- We encourage other teams to use the code for their pipelines, but we will not operationally support instances other than our own
There! We said it. Maybe Team Battlecat will like that arrangement and Team Fighter Jet will hate it! But now they can at least have the discussion.
This list will be different each time you have this discussion. Ergo, you probably don't want to try and define "ownership" with any finality. Rather, you want to work to agree on a list of "building blocks" - the atomic parts of ownership, your "taxonomy" - that become a common language between you and other teams when discussion how ownership will work.
Yes, you have to work through a bit of embarrassment to do this. Nobody wants to admit that they don't know what ownership means. We all want to look like we've been in the industry long enough that ownership means the same thing to us as it does for everyone else. Fight through that - it's just fashion, and fashion has no place in an industry where people dress the way software developers do.
From there you can find the parts of the definition that don't match your plans. Maybe another team wants to add features to their pipelines faster than a PR-based contribution model will support. Maybe they want to be able to add features you don't want, which will prompt a discussion about working together to make the pipelines more composable.
And then the most important bit... you can take all the little bits of the taxonomy and... align them. You can start to draw lines and say "hey, we're holding the pager for this service, but we're running other people's code. That doesn't sound sustainable". It gives you a chance to do the thing that's really important here - making sure that everywhere you have agency you have accountability (and vice-versa).
It's all a very long way of saying to think about the words you use, and the work they're doing for you. "Tech-debt" and "ownership" don't really work very hard for you. They don't help the people who disagree with you strengthen your ideas. They don't describe the details of what you're saying, and it's only ever the details that matter. Don't settle for words that make you feel clever now, and silly later.
(For those who were wondering, my second least favourite word is "should").