Engineers Who Understand Margin Get Promoted. The Rest Get Managed.

I'm going to make a claim you might not like. The single biggest thing separating the technical leads who get handed bigger and bigger work from the ones who stay where they are is not technical depth. It's whether they can read the money.

Not do the accounts. Read the money. There is a difference and it takes about an afternoon to learn.

Price is what the client pays. Cost is what it takes you to deliver. Margin is the gap, usually expressed as a percentage of the price.

That's it. That's the whole vocabulary, and I went about seven years into my career without anyone sitting me down and saying it, because there is a quiet assumption in most engineering organisations that commercials are somebody else's department and you would find them boring.

Here's the bit that actually matters, and it's the bit that gets left out. Margin is not a number that gets decided once by someone in a suit and then reported afterwards. It gets decided a hundred times, in small pieces, by the person running the delivery. That is you. You are making commercial decisions every week whether you know it or not. The only question is whether you're making them on purpose.

Two examples of what I mean, both of them things I have watched happen.

A lead puts his two strongest engineers on a piece of integration work because they'll do it well and he trusts them. Perfectly reasonable. Those two also happen to be the most expensive people on the team, and the work is genuinely mid level. Over four months that choice costs a visible chunk of the margin, and it buys quality that the client could not have told apart from the mid level version.

A different lead, same organisation, decides to do the discovery workshops on site rather than remotely because the conversations go better in a room. She's right, they do. It also adds travel and two days of non billable time per engineer per trip. Nobody ever put that on a spreadsheet next to the benefit.

Neither of those decisions is wrong. Both of them are commercial decisions made by a technical person who was thinking purely about the technical outcome.

This is the distinction that changes how you see your own project.

Sold margin is what the proposal assumed. Someone built a model before the work started, with estimated days, assumed seniority mix, assumed travel, assumed a certain amount of the client's own people turning up on time. It was signed off and it went into a forecast. It is a prediction.

Delivered margin is what actually happened. It is the only one that's real, and you find out what it was somewhere between month four and the closing report.

The gap between them is created almost entirely during delivery, by things that live squarely inside your control:

Who you staff. A senior day and a mid level day are not the same cost, and a lot of work does not need the senior.

How long people stay on. Somebody kept on the project "just in case" for three weeks past their useful contribution is pure margin gone, and it's the most common one I see.

Rework. Every time a design gets redone because the requirement was fuzzy, you are paying twice for one deliverable.

Absorbed scope. Work you did for free that nobody recorded. See the previous post on that one, I'm still bitter about it.

Waiting. An engineer blocked for six days on a client firewall change is an engineer being paid to wait.

None of those are exotic. All of them are visible to you weeks before they show up in a finance report, and largely invisible to the finance report until it's too late to act.

Take a network refresh for a ferry operator. Round numbers, because the shape is the point.

Sold at four hundred thousand. The model assumed three hundred thousand of cost. That leaves a hundred thousand of margin, twenty five per cent. Comfortable. Everyone signs.

Delivery starts. Four things happen, none of them dramatic.

The client's vessel surveys run three weeks late, because two of the ships stay on their summer rotation longer than planned, and rather than stand the team down, the lead keeps two engineers on doing preparation work. Cost of that decision, roughly fifteen thousand.

A senior architect stays on for the full build phase instead of stepping back after design, because she's good and the team likes having her. Cost, maybe eighteen thousand over the price of the mid level engineer who could have done it.

Two vessels get re-cabled after a measurement error. Eight thousand.

And the lead absorbs a config standardisation request across a handful of extra switches, twice, because it seemed small. Call it six thousand.

Add them up. Forty seven thousand. Margin drops from a hundred thousand to fifty three thousand, and the percentage falls from twenty five to about thirteen.

Now, the bit that matters for your career. Not one of those four things was a failure of engineering. The network was built properly. The client was happy. And the delivery lost nearly half its margin through four decisions that any competent technical leader would consider routine scheduling.

When the closing report lands, somebody senior will look at that thirteen per cent and form a view about the person who ran it. If that person can walk into the room and say "here are the four decisions, here is what each one cost, here is the one I'd take again and the three I wouldn't", they get the bigger project. If they say "I didn't really see the numbers", they get a project manager assigned to them next time.

That's the whole thesis of this post. Commercial awareness isn't about protecting the company's money out of loyalty. It's about being the person who can explain their own decisions in the language the decision gets judged in.

Someone always objects at this point, and it's a fair objection: if I start optimising for margin, I'll start making worse technical choices. Cheaper people, thinner testing, corners cut.

That's a real risk and I've seen leaders fall into it. So hold the line here. Protecting margin by shipping something fragile is not protecting anything, it's moving the cost into next year's support budget and someone else's weekend. A decision that wins on cost and loses on quality, on the people, and on what the client thinks of you in eighteen months is a bad decision, and you should be able to say that out loud with the numbers in front of you.

Knowing the numbers is what earns you the right to argue for the expensive option when the expensive option is correct. Leads who can't read the money can only ever say "trust me, we need it". Leads who can say "yes it costs twelve thousand more and here's the failure it prevents" tend to get the twelve thousand.

Find out your project's sold margin. Just that one number. Go to whoever owns the commercial side, say you want to understand the shape of the deal you're delivering, and ask what margin it was sold at and what the biggest cost line is.

Some organisations will tell you immediately. Some will hesitate, because they've never had a technical lead ask. Ask anyway. The hesitation is worth watching, and the asking changes how they see you from that day.