In football, even the best manager in the league can be out-earned by the player who puts the ball in the net. One of them scores. The other stands on the touchline and explains, very intelligently, why the ball went where it went. The market looked at both jobs and decided, with no hesitation, that explaining is worth less than doing.
That is the one part of sport we have carefully refused to copy.
In sport, the desired outcome is winning, and value follows whoever is closest to it. The striker outscores the coach, so the striker out-earns the coach, and nobody publishes a think-piece about the injustice. In IT, we also have a desired outcome — delivery. By analogy, value should follow the people closest to delivery.
You already know it does not. Which leaves only one conclusion.
Delivery is not the desired outcome. Talking about delivery is.
In our sport, the commentator out-earns the striker — a man who has never touched the ball, let alone played in a real game.
What Software Delivery Is
Talking about delivery without defining it is the commentator’s move. So what is delivery, actually?
Software delivery is everything between “we should build this” and a smile on a real user’s face when it finally works:
understanding the problem,
designing the change,
building it,
testing it,
deploying it,
surviving production,
and learning whether it made anyone’s day better.
That is the happy path. The version that fits on a slide. The real version is uglier.
You do it inside a team, inside an organisation, sometimes with fifty other engineers elbow-deep in the same code at the same time. The deadline is immovable. The sprint is shrinking by the hour. You sleep badly. You show up to every standup and confirm, confidently, that everything is fine.
Then, somewhere in the middle, you find the one thing nobody could have known until someone tried to build it — the thing that quietly detonates the design. So you redraw it. You fix it. And on an ordinary Tuesday, you break something for a fifth team you did not know existed.
After all of that, someone calls you a resource.
How the IT Club Is Organised
A football club is not eleven players and nothing else. Every role exists for one reason: to put someone in a position to score, and to send the fans home happy. IT is the same club with the badges renamed:
The business owns the club.
The product owner decides what winning means.
The engineering manager picks the team.
The architect sets the shape.
Platform and ops keep the players alive.
The users are the fans.
And the engineers? They are the ones who have to put the ball in the net.
We read the same org chart and inverted it. We put the person with the status deck near the top and called the person fixing production a resource.
0.4 of a human.
Anyone who has ever shipped software knows you do not call that person a resource. You learn their name. You ask what they need. You make sure they do not leave. “Resource” is usually said by people who walk onto the pitch with a whistle and mistake that for playing football.
What Can You Do?
Sport did not get less valuable when it started measuring more. It got more valuable.
Thirty years ago, you watched the score. Now you watch the score, the assists, the saves, the pass accuracy, the expected goals, the distance covered, the heat maps, and one man’s entire emotional collapse in slow motion. Technology made the game measurable. Value followed.
However, the next day nobody says: “Yes, we lost 2–0, but possession was excellent.” They look at the result first. Then they look at who contributed to it.
That is the part engineering keeps missing. So bring the scoreboard, and measure the outcome, not the activity. Not how often you touch the ball. Count goals.
That is the hardest part for us. We are not used to it. And it is easy to say what not to measure. The hard part is what to measure, how to show it, and what it actually buys you. You only find that out by doing it.
Most teams do not measure outcome because outcome is inconvenient. Measuring activity — keystrokes, number of pull requests, how many Jira tickets marched bravely from left to right — is easier. Activity has dashboards. Outcome has consequences.
Put up a rude scoreboard. Not velocity. Not story points — astrology with a Jira board. Not the number of meetings with “delivery” in the title.
When value is not measured, it is easy to ignore. When it is measured badly, it gets abused. But when it is measured well, it becomes harder to pretend the person shipping the work is just “a resource.”
So measure the engineering version of winning:
What shipped?
Is it in front of real users?
Did they use it?
Did it solve the problem?
How often did delivery break?
How fast did we recover?
How much rework did we create?
How much manual work disappeared?
How much cost, risk, waiting, or pain went away?
How much was first time right?
That is not bureaucracy. That is the scoreboard. And once engineering has a real scoreboard, value becomes harder to hide.
Ask What Shipped
Switch focus away from the buzzwords. “Align.” “Enable.” “Drive.” Beautiful words. Very fit. Never tired. Never seen in production.
Not what is in flight. Not what we are de-risking. What is in front of a real user right now? Show me the data. Tell me what my fan is experiencing this minute. Tell me if we won. And if not, why we did not.
You can keep playing the sport where the commentator wins. Narrate the delivery. Align on the delivery. Enable the delivery. Never once be caught delivering. It pays well. It promotes early. The perks are excellent.
Or you put up a scoreboard, point at what actually shipped, and accept the genuinely terrifying risk that someone might check.
It is not easy. It will create tension. Good.
Our industry made value blurry and then acted surprised when everyone learned to hide inside the fog. But that is where the value sits. Sport learned this without a transformation program.
And remember this: a club that rewards the commentator more than the striker should not be surprised when everyone learns to commentate. Why play at all, when it pays better to sit and explain the game?
Keeping score is engineering.
Talking is a sport with no ball.
By order of thebeanengineer.com — keep score. Be an engineer.