Why developers who think in business economics earn twice as much
I noticed something had changed when I stopped asking "how much does my work cost" and started asking "how much does my work cost the business."
It's not about job grades or salary negotiation. It's about who you are in the room: the person executing the task, or the person who understands why the task exists.
The income gap between those two is real. The difference in the actual work is bigger.
Executor vs owner: what it actually looks like
An executor answers "how do I do this." An owner asks "why are we doing this at all."
In practice: a task comes in — "Add a one-click buy button to the product card." One developer looks at the mockup, writes the code, ships it. Another asks: "We have 28,000 SKUs and 2.1% conversion. Which pages would benefit most from this?" Then pulls Hotjar, sees that 70% of dropoffs happen on mobile during checkout, and proposes fixing the checkout flow first rather than adding the button.
Not smarter. A different question at the start.
The gap between these approaches is invisible in a sprint. It shows up over a quarter — and in how clients talk about you.
One more signal: how you react to ambiguity. The executor writes in Slack: "Can you clarify the task?" The owner looks at what exists, builds a hypothesis, validates it cheaply, and brings a proposal with reasoning. The hypothesis might not match what the client expected, but the conversation is already different.
What business thinking looks like in a PHP project
A few years ago, a client came with a request: "Rewrite Bitrix to a modern stack. Budget $40K. Ready to start next month."
I could've said: "Great, let's sign." Instead I spent three days in the prod logs.
What I found: 40 SQL queries per category page. LCP 4.2s on mobile. 68% of traffic was mobile. Average order value around $35, conversion 2.1%.
Then I did the math. A full rewrite takes 8-12 months. During that time, the store keeps running on the current stack with the same problems. If instead we optimized queries through Elasticsearch and moved the frontend to Next.js with Bitrix as the backend, LCP drops to 1.4s within 3 months. With a +23% lift in mobile conversion, that's money the store starts earning now rather than after a year.
I turned down the contract and proposed a different project. The client agreed.
That's what business thinking looks like in a PHP project: not "how do we implement this requirement," but "which solution gets to a result faster and cheaper."
A second example: faceted search. The client wanted to "improve search," and the initial brief was "add brand and price filters." Hotjar showed the existing facets occupied positions 14 through 37 with the first 13 slots empty. The color facet sat at position 22 and got under 1% of clicks. We reordered facets by actual usage frequency and added quick-filter chips above the catalog. Filter click rate went up 2.4x, catalog-to-cart conversion up 14%.
Same task. Different solution. Because the question was different.
Three conversations I handled differently
On refactoring. I used to say: "We need to extract the logic into a service layer, otherwise the code becomes unmaintainable." The client heard: "The developer wants to play with architecture." Now I say: "Right now every new feature takes 6 hours instead of 1, because logic is mixed into templates. That's roughly 60 extra hours per quarter — around $2,400 at current rates." The conversation changes.
On timelines. "We'll go faster if we add another developer" — that's executor logic. "The critical path right now is the 1C integration. If we don't resolve it in two weeks, launch slips by a month. Is it worth bringing in an external 1C consultant for a week?" — that's a different conversation. And a different outcome.
On priorities. Clients want everything at once. I used to quietly prioritize by my own logic. Now I ask: "Which of these directly affects revenue next month?" That question removes half the backlog without pushback.
All three cases are about the same thing: I understand what matters to the business, not just what matters to the code.
The financial literacy minimum for an engineer
You don't need to be a CFO. You need to understand a few things — and they're enough.
How does this business actually make money? If it's e-commerce: average order × conversion rate × sessions = revenue. If you improve conversion by 1%, what does that mean in dollars? You can calculate it in a minute.
What does a delay cost? A project that ships a month late doesn't just "miss the deadline." It costs the business a month of revenue from the new feature — or from a store that didn't open on time. That's a concrete number, not a vague risk.
Can you translate technical debt into money rather than metaphors? "The code is bad" isn't an argument. "Because of this architecture we spend 60 extra hours per quarter" is one. Put it in dollars and the conversation changes.
That's not an MBA. It's the skill that puts you in the room where strategy gets discussed, rather than the room where tasks get handed out.
One exercise for your next meeting
At your next client meeting or planning session, ask one question: "If we do this, what changes for the business in 90 days?"
If nobody knows the answer, the task isn't well-defined. If they do know, you've got a success criterion. And you're already having a different conversation — one about outcomes, not tickets.
This isn't about becoming a business consultant. It's about understanding the context you're working in. That understanding changes what you get paid — and what kind of work you get asked to do.
The difference between "how much does my work cost" and "how much does my work cost the business" is small as a phrase. As a career move, it's significant.
I turned down $40K because I calculated the client's economics. They signed a different contract — smaller, but with a better result for them. That's the conversation I want to keep having.
→ On closing risks, not tickets: I stopped closing tickets. I started closing risks. → On translating technical debt into money: Tech debt in plain money: how I talk refactoring to non-technical clients