"Can you own this?" "Can you take care of this?" is phrases I use a lot at with my team. I suspect most engineering managers do the same. The problem is that we rarely stop to say what we mean by it, so everyone fills in their own definition, and those definitions are usually smaller than the one in the manager's head, especially young folks, they just translate based on what they no, no confirm back on direction or getting advisor if it's not clear
The tweet from Thorsten Ball did hit me and I want to share it, in a short note about how he expand the word "ownership" - owning the solution to a problem end to end, "from 'we have a problem' to 'we don't have to think about it again.'"
That last part is the whole point. Ownership does not end at the merged pull request. It ends when nobody has to think about the problem anymore.
What "end to end" covers
Thorsten spells out what he expects when someone says they own a thing. I am paraphrasing his list here, because I think every item on it is one that people skip without noticing.
Start with the problem, not the solution. "We need to migrate from X to Y" is not a problem. It is a solution. The problem is more like "performance is bad" or "it fails for customer X". Once you name the real problem, other solutions show up, and you can weigh the trade-offs instead of defending the first idea you had.
Think about edge cases and failures. Which edge cases matter and which can you ignore? Network calls will fail, so what happens then? Retry? How many times, and for how long?
Think about the data. How much is there? Does anything need to be migrated or cleaned up? What assumptions are you making about the shape of the data that you have not actually checked? How do you get real data to test with?
Decide how you will know it works. Are automated tests enough? Do you need to poke at it by hand? Would the difference show up in a screenshot or a video?
Think about how it fits and how you would announce it. Can you picture the announcement? Does it fit the roadmap? If something feels off here, push back and ask. That is part of owning it too.
Do the work properly. Thorsten's phrasing is "with precision, with care, with a sense of urgency, with calmness." Before you merge, ask: am I proud of this? Would I show it to a future version of myself and explain the constraints and trade-offs without flinching?
Test it manually. Yes, there are tests. But in almost every case you can also run the thing yourself, poke at the data before and after, ask an agent to walk through scenarios, take screenshots, make a demo. The question is not "do the tests pass" but "am I sure this actually solves the problem?"
Make sure it lands in production and works there. Did the deploy succeed? Is there a feature flag? Does the flag work? Can you confirm it is really live?
Tell the people who need to know. Colleagues, if it is a new convention or a behaviour change they should be aware of. Thorsten calls this peripheral vision: knowing that someone changed how Z works yesterday can save a colleague three hours of debugging today. Customers, if someone reported the bug or was blocked. The world, if it is a feature worth announcing.
Follow up. Check the logs a week later. Make sure it is still working.
His closing line is the one I want my team to remember. Asking for help is fine. Asking questions is fine. Redoing work and triple-checking is fine. "What's not okay is to implicitly assume that someone else will do the things here that you haven't thought about."
credit to https://thorstenball.com/