Once you're senior, closing the ticket is where your job starts, not where it ends. You own whether the thing works. In practice that means knowing why it exists, agreeing up front which number proves it, shipping small, and actually going back to check that number after launch. Owning a domain is the same habit kept up for years, plus making sure you're not the only person who can do it.
You've seen this one. A feature ships. Every ticket is closed, the PR got two approvals, the demo went fine. Three weeks later someone from support asks why nobody's using it, and the honest answer is that nobody looked.
Nobody did anything wrong, exactly. Everyone finished their ticket. But nobody owned the feature, and once you can already write good code, that's most of what separates senior from mid-level. Amazon's Ownership principle says owners never say "that's not my job." Great on a poster, not much help on a Monday morning. So here it is as a habit you can actually run.
The ownership loop
- Why to Signal: how will we know?
- Signal to Ship thin: thin slice
- Ship thin to Measure: week 2
- Measure to Why: learn
- next step
- what you learned starts the next loop
- 1Why. Don't take the ticket's word for it. A ticket is someone's summary of a conversation you weren't in, so go and have that conversation: ask the PM, read the support threads, look at whatever data kicked this off. While you're at it, write down what you're not building. You'll point people at that list more often than you think.
- 2Signal. Before you write any code, pick one or two numbers that would tell you it worked. If you can't think of one, you don't understand the feature yet, and you want to find that out now, not in week three.
- 3Ship thin. Get the smallest end-to-end version in front of real users, behind a feature flag if you have to. When you spot a risk, say so that day. And send the status update before anyone has to ask you for it.
- 4Measure. Deployed isn't landed. Go and look at the number, then go round again: fix what it's telling you, or, if the feature isn't pulling its weight, say it should come out. That's a hard thing to say about your own work, which is exactly why it has to be you.
Most engineers are good at step 3. What makes you senior is doing 1, 2 and 4 when nobody asked you to.
The loop on one feature
Say you're building something unglamorous: bulk CSV export on an admin dashboard. Before you start, you and your PM agree the signal: 30% of weekly active admins export at least once.
Two weeks after launch you check, and it's at 8%. A quarter of the target. Ten minutes in the dashboards turns up two problems: exports over 10,000 rows time out, which is every big customer, and the button sits three clicks deep in a menu. Streaming the file and moving the button is two days of work.
Now imagine you'd never written that 30% down. 8% looks fine. People are using it, it shipped, the ticket's closed. It stays closed, and the feature stays a quarter as useful as it should be, and nobody ever finds out.
The owner's scoreboard
One number tells you one feature worked. If you own something for longer than a sprint, you want a few more, and you want to check them on a schedule, not when someone complains:
| Number | Question it answers | Level |
|---|---|---|
| The success signal | Is it doing its job? | Feature |
| Error rate, p95 latency | Is it healthy? | Feature |
| Support tickets tagged to it | Is it confusing people? | Feature |
| Change failure rate | Can we change it safely? | Domain |
| Time to restore | How bad is a bad day? | Domain |
| People who can ship it alone | What if you're on holiday? | Domain |
| Age of the oldest shortcut | Is the debt getting paid? | Domain |
Change failure rate and time to restore come from DORA. The last two rarely make it onto anyone's dashboard, and they're the ones that hurt most when they go wrong.
Owning a domain
Owning a domain (payments, search, onboarding) is the same loop, run for years and pointed at a whole system instead of one change. A few things get added to your plate.
You need to know the map: the data model, who depends on you, how it breaks. When someone asks to "just add a field to the invoice," you should already know which three services read that table.
You guard the edges. Other teams will want to reach straight into your tables because it's the shortest path for them. Your job is to say "not like that, use the API," and then make the API good enough that they'd rather use it anyway.
You own the boring list. Nobody outside your domain is ever going to ask for the migration, or a fix for the job that pages someone once a month. You keep that list, rank it by risk, and bring numbers from the scoreboard when you argue for it in planning.
And you make yourself replaceable. I know that sounds backwards. But if the domain falls over every time you go on holiday, you haven't owned it, you've hoarded it. Get "people who can ship it alone" to at least three: pair with them on the scary parts, put them on the on-call rota, and let one of them lead the next feature while you review.
- 1
Gatekeeping
If every change has to go through you, you're a bottleneck, not an owner. Write your rules down so people can follow them without waiting on your review.
- 2
Hero mode
Jumping on every 2am incident yourself feels like ownership, but each time the knowledge stays in your head and nowhere else. Fix the incident, then fix whatever made it need you.
- 3
Owning without authority
If you're on the hook for an outcome but someone else makes the calls that decide it, tell your manager, plainly. Carrying responsibility you can't act on is how people burn out.
So next time you close the last ticket on a feature, don't move on just yet. Put a reminder in your calendar for two weeks out and go and look at the number. That's most of it, honestly. Keep doing it and nobody will need to tell you you're senior; they'll just notice they never have to chase you.