Nobody owned it. Everyone did their part. And the thing still shipped broken, because doing your part correctly and owning the outcome are two completely different jobs, and only one of them is what makes you senior.
The outage was nobody’s fault. That was the problem.
I mean that literally. We did the postmortem, and we went around the room, and every single person had done their part correctly. The backend engineer built the endpoint to spec. The frontend engineer consumed it exactly as documented. The ticket was clear. The code was reviewed. The tests passed.
And it shipped broken anyway.
Because the spec was subtly wrong, and everyone had followed it perfectly off a cliff. Each person looked at their slice, did it well, and passed it on. Nobody looked at the whole thing and asked whether it actually made sense. Not because they were lazy. Because that was not their job, technically. They each did their job. Technically.
That is the sentence I have come to fear more than any other. “I just did what the ticket said.”
It is always true. That is what makes it so dangerous. You can say it with a completely clean conscience, because you did do what the ticket said, and if the ticket was wrong, well, you did not write the ticket. It is airtight. It is also the exact opposite of what a senior engineer does, and I did not understand that for an embarrassingly long time.
Here is the thing nobody explains when you are coming up.
Early on, your job is to do the thing well. Take the ticket, implement it, get it right. That is the whole job, and it is enough, and it should be enough. You are learning. Doing your part correctly is a real achievement when you are starting out.
Then, at some point that nobody announces, the job quietly changes. And a lot of people miss the moment it changes.
The job stops being “do your part correctly” and becomes “make sure the right thing happens.” Those sound similar. They are not even close. The first one ends at the edge of your ticket. The second one does not have an edge. The second one means that when the spec looks wrong, you say so, even though writing the spec was not your job. When the thing two teams over is going to break what you are building, you raise it, even though nobody asked. When the whole plan is subtly pointed at a wall, you are the one who says “wait, are we sure about this,” even though sitting quietly and shipping your slice would be easier and technically sufficient and nobody could ever blame you for it.
That is ownership. And it is basically the entire difference between an engineer who gets handed bigger and bigger things and one who stays where they are, doing their slice well, wondering why the scope never grows.
I learned this from the wrong side, obviously. That is the only way anyone learns it.
I had shipped my part. It was correct. I was, if I am honest, a little proud of how clean it was. And when the whole feature fell over, my first instinct, my genuine gut reaction, was relief that the broken part was not mine. I remember the feeling. “Not my code.” I actually felt lighter.
And a senior engineer on the team, someone I respected, did not say “whose fault is this.” He said, to the room, “how did all of us let this ship.” All of us. Including the people whose parts worked. Including me.
That reframe rearranged something in my head permanently. He was not looking for the broken component. He was asking why nobody had been watching the whole thing. Why five competent people had each done their piece and no one had owned the sum of the pieces. That was the actual failure. Not the bad spec. The bad spec was just a thing that happened. The failure was that it sailed through five people who could each have caught it and each assumed it was not their job to.
I think about that a lot now, because the pull toward “I did my part” is strong and it gets stronger the more competent you are.
When you are good at your slice, it is genuinely tempting to just do your slice brilliantly and let the rest be someone else’s problem. It feels responsible. You are delivering. You are hitting your commitments. And you can hide in that, for years, doing excellent work that is bounded exactly by the edges of your assignments, and never quite understand why you are not being trusted with more, when the reason is that being trusted with more requires demonstrating that you watch the whole thing, and you have been carefully, competently, only ever watching your part.
The engineers who get the scope are the ones who act like the outcome is theirs even when the task was not.
They read the spec and go “this doesn’t add up” instead of implementing it faithfully. They notice the thing outside their lane and flag it instead of driving past. They cannot actually be given a broken thing to ship, because they will stop and ask about it, which is exactly why they get given the important things, because “I did what the ticket said” is not a sentence they know how to say. They would be embarrassed to say it. To them it is not a defense, it is a confession.
None of this means do everyone’s job. You cannot own everything, you would drown, and there is a real skill in knowing which things are actually yours to catch. But it does mean the edge of your ticket is not the edge of your responsibility, and the moment you start believing it is, you have quietly capped your own level, and you might not find out for years, until you watch someone with less raw skill than you get handed the thing you wanted and realize the difference was never skill. It was that they acted like they owned it and you acted like you did your part.
The ticket is where your work starts. It was never supposed to be where your thinking stops.
“I did what the ticket said” is true, and clean, and safe, and it is the most quietly limiting sentence in this entire job. The people who stopped saying it are the people whose careers kept moving. I stopped saying it the day I felt relieved that broken code was not mine, and heard how small that relief was, and decided I did not want to be the engineer whose best defense was that the disaster technically happened somewhere else.
The shift from doing your part to owning the outcome, the judgment that makes you the person handed the important things, and the rest of what actually separates the trusted engineers from the merely competent ones, is the whole spine of The Senior Backend Engineer Handbook. If your scope has stopped growing and you cannot figure out why, this is usually it.
The Senior Backend Engineer Handbook: From 3 AM Outages to Senior Offers
longer writing goes out through my newsletter:
Devrim’s Engineering Notes | Substack
The Most Dangerous Sentence in Engineering Is “I Just Did What the Ticket Said” was originally published in Javarevisited on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More