One person in standup lists nine tickets. Another says they spent the day reading. Six months later, the area the second person owns has no incidents, no midnight pages and no rewrite.
The board rewards the first person. The system rewards the second one. Those are not the same measurement, and the gap explains a lot of bad promotion decisions.
Deletion does not produce a ticket
The visible unit of work is code added. The valuable unit is often code removed: a feature nobody uses, a service that existed for one customer, a dependency that pulled in forty more, a config flag that has been true since 2023.
Deleting all of that shows up as a small diff and a line in the changelog. It also removes a permanent maintenance cost. Nobody puts "deleted 4,000 lines" on a performance review, which is why so few people optimise for it.
The first day is reading, not typing
A senior engineer starts by finding out where the data comes from, who calls the function, what the last three commits touched and whether the bug reports share a cause. That looks like nothing is happening. It is the cheapest way to avoid building the wrong thing quickly.
Juniors are usually told to start coding to show progress. The advice is well meant and expensive. Progress that has to be thrown away is not progress, it is a rehearsal.
The cheapest bug is the feature you refuse
Scope negotiation gets a bad name because it sounds like obstruction. In practice, asking "do we need this at all" is the most valuable review available. A shipped feature costs maintenance, documentation, support, tests and attention for as long as the product exists. A feature that never ships costs one conversation.
The engineer who kills a bad idea in a planning meeting has saved more work than the one who ships it cleanly. Only one of them has something to demo.
Boring choices are a feature
Postgres. A cron job. A single server. A monolith. The senior picks whatever the team can operate at 3am, not whatever looks best in a design doc. Interesting technology is a cost that gets paid by whoever is on call, usually someone who did not choose it.
This is also why the most experienced person in the room is often the least excited about the new framework. They have watched a migration before, and they remember who did the work.
The work with no diff
A lot of senior output never reaches a commit:
- Answering the question that stops a junior from building the wrong abstraction.
- Reviewing the pull request that would have taken production down.
- Writing the paragraph in the README that ends ten future questions.
- Fixing the flaky test everyone else retries.
- Sitting with the new hire until the codebase stops feeling hostile.
None of that appears in a commit graph. All of it compounds.
How to tell slow from senior
Both look the same in a standup. The difference is what the system looks like afterwards. Drift leaves the mess where it was and adds a bit more. Seniority leaves the system quieter: fewer alerts, fewer surprises at release, fewer places where one person is the only one who understands it.
So ask three questions about the last month: what did you remove, what did you talk the team out of, and who did you unblock? If all three answers are "nothing", it is not seniority you are looking at. It is someone waiting for a ticket.
The obvious counterpoint
None of this excuses missing deadlines. A senior who ships nothing is just expensive, and "I was thinking about architecture" is not a deliverable. Output still matters. The argument is about where the effort lands: less new surface area, more reliability, fewer things that need babysitting later.
The best engineer on your team probably cannot prove what they did last sprint. Look at what stopped breaking.
What is the last thing you deleted at work? The answers usually say more about a team than any velocity chart.
