If you're at a company that's quite open about how the business gets run (a lot of well-run companies are), you might notice something particularly strange: you're often not included in the margins of the business.
This is really weird when you think about it. Surely you, the software engineer, should be a massive part of the margins of the business right? Engineers get paid a lot. Somehow tons of tech companies are operating unprofitably yet claim 60-90% margins.
How? How can you even have margins if you are spending more money than you make?
The answer to this question is something all new developers should know. It can guide your career, your salary negotiations, and give you perspective on what you actually do.
Unfortunately, it's not obvious to most new software engineers what they actually do.
Most folks entering the industry assume they're a highly paid, highly specialized factory worker. Tickets come in, code goes out, everyone gets a paycheck at the end of the day. Often the language we use in software exaggerates this comparison. We say we "build" things or that we are some sort of "craftsperson."
But this is very far from the truth. It's also the reason why devs on average make a lot of cash and why it's fairly unlikely that will change anytime soon.
To understand what's going on, let's take a look at how other industries work. When you buy a pair of shoes, you're paying a premium on top of what it cost to make that particular shoe. Making that shoe cost the materials, the shipping, and the assembly. Somewhere the company purchased the leather, and a factory worker likely helped stitch everything together. Then the shoe was shipped to the store and maybe the store puts a bit of a premium on top of that.
That has to happen for every shoe. What's more is that your shoe is more or less consumable. The company is banking on this; they assume you'll buy more pairs of shoes from them in the future. But when that happens, we go this process again of making the shoe, assembling it and shipping it.
So for every shoe, there's an assembly cost.
But you, the consumer, don't have just one option in shoes, you have lots of options. There's tons of companies that make shoes. If you're not super concerned about brand name, you have a lot of people you can buy your shoes from.
This means that in order to compete, the company has to sell their shoes for a lower cost. Since the materials, assembly and shipping can only be optimized so much, the business has to cut into their profits. This creates a "race to the bottom" effect where shoes get lower and lower in cost at the same time that the company aggressively tries to improve their margins by reducing the cost of the materials, assembly, and shipping.
But here's the kicker: in software, we have effectively none of these costs. In software, the actual cost of creating each individual product is almost nothing.
In most cases, there's really only an upfront cost to basically everything you make. You have to pay yourself or another engineer to build your Snapstagram, but once it is working, you can sell millions of copies with almost no added cost.
That means that the engineer is not generally an assembly cost to each unit sold. There's maintenance, sure, but the cost of maintenance is generally never nearly as high as materials, assembly and shipping like we'd see in other businesses. Even SREs build an automated solution and then they move on to the next problem.
That's basically the job of an engineer. As an engineer, you're always building the next thing. There's not tens of thousands of people at Google building Google. There's tens of thousands of people building the next Google.
Therefore the job of an engineer isn't that of a factory worker. It's growth. You don't make the company $X amount of dollars every month, you make them $X more dollars per month. You're acceleration, not fixed velocity.
It's not uncommon for tech folks to join small companies, leave when they become big, and then join another small company only to repeat the process. Regardless of whether or not you realize it, this is generally the job of an employee of a tech company.
But if you understand this unspoken job requirement it goes a long way towards understanding the incentive systems of your boss, your boss's boss and so on. It puts you much more in control of your own destiny.
This is the aspect of the tech industry that creates the "nice parts" about being a developer. When you can increase the growth of the company but aren't considered an assembly cost, your salary isn't as limited by margin-improving cost cutting. When a tech company wants to improve it's margins, it pays engineers to write more efficient code. You the developer frequently do not get included in the marginal costs of the business.
It's also the reason that it's feasible to jump jobs so often; if you can come to a company, build something that adds value and then leave, that's still a good deal for the company. Even after you leave, your code still lives on. You produce value even when you're not there.
Because your job is growth, you naturally create more software jobs in the process. If you work at a tech company, you grow their business, which causes them to have more money to invest in larger and larger projects.
It also means that your salary can be related to your impact or ability to convince others that you had impact. The effect of what you built and how you contributed can bring you more success than talent. This is something you should be aware of since you won't always have control over whether what you build is actually successful. This is often not explicitly stated anywhere and can feel unfair to folks that assume technical talent purely translates into success.
Caveats and Disclaimers
This type of thinking is heavily dependent on companies that make software products, not dev shops, contracting agencies, or support centers. When you're being paid per hour, you are an assembly cost.
It also doesn't apply to all business types. Some companies have significantly more "maintenance" costs than others; though in general these costs are quite small relative to other industries.
This isn't necessarily a "good" thing; it's just the way the economics work out. Most of the time this is pretty invisible so it can perpetuate an "in-group" and an "out-group" within some orgs. When it is known, the "value" is not always easily attributed to specific engineers. That can exacerbate social inequalities since it creates a false meritocracy that's more a representation of implicit biases rather than actual value created.
Top comments (18)
This is not really true. I am not saying pay is low, in generally it results in a comfortable living style.
As the article points out, engineers create current and future business value. They produce the source of income.
Going up the hierarchy and side stepping to sales and marketing, you see people earning much more than the engineers. Yet, the are not the source of the business value. You cannot manage a diamond out of coal. You cannot sell coal as diamonds (and see the light of day).
Important to note here is that without proper leadership and sales, coal will not turn into polished diamonds or into high-profit sales either.
Leading a team is at least as valuable as being a contributor in the team.
And selling is at least as hard of a job than creating things to sell.
Maybe in some fields sales is more difficult than building the product. But I do not agree that generally sales is harder than development. And certainly does not justify significant differences in rewarding performed work.
This is very true - it doesn't matter how talented the team producing the "raw resource" of the software is if they lack the necessary supporting teams. I'm totally guilty of falling into the "but Engineers can do anything" trap and now try to remember the necessity of leaders to choose the right product, marketers to reach and convince the customer, and operations to charge the customer and deliver the product.
To extend the running metaphor in this threads: it doesn't matter if you can create diamonds from thin air if you're doing it in a warehouse, no one except HackerNews knows about it, and everyone wants rubies anyways.
Engineers who can also sell things are a goldmine. Rare as anything though I find.
And even with diamonds, the ones who dig it out of the ground and even the ones who polish them get paid less than those who find ways to sell them. This is capitalism - the value paid at market is often unrelated to the reality of the situation.
The diamond analogy does not go that far.
Software developers do not dig out diamonds. Anybody can dig out diamonds. Developers make diamonds mostly out of thin air.
@Daragh, what you said is totally true. I worked for a startup in the beginning of my career, created a web application for blog posting, which was a huge success, then guess what! the SEO analyst(marketing guy) earned 2% of the profit from the product, when I demanded at 1% of profit, I was told that anyone can code what you did but not every one can sell what you have coded. Hence he was paid more than I did.
Being able to point to other people and say "well those people get paid more" doesn't negate the fact that engineers do, in fact, get paid a lot. The median engineer in the US makes $84k per year, which is 1.5x the median whole HOUSEHOLD income and easily enough to put these engineers in the top 10% of the country.
"...You're acceleration, not fixed velocity...." Excellently stated!
Good read, thank you. I agree that engineers are not factory workers and that they are acceleration. I dont see how this alone has a significant impact on negotiating an offer though. Should bridge engineers feel entitled to more because a lot of traffic will pass on their work for years to come?
Yes, if you want to take some risk and be a partner or shareholder of a company you believe has potential. Otherwise you get paid market rate for your profession. Or if you do get paid more its because you did an awesome job at convincing the employer how great your contribution will be.
Great article.
It is insightful that most developer work is investment and not production.
You have a glaring error however: you consistently misuse the well-known term, "fixed cost". en.wikipedia.org/wiki/Fixed_cost
In your dev-shop example: where hours of developer output has a direct effect on revenue (time and materials billing), then this is the definition of a variable cost (varies with units produced).
It is not the major point of your article to answer the question of "why are developer expenses not included in margins", but I think the actual answer to that is probably some boring accounting stuff having to do with depreciation. Or really, it isn't so arcane: investors want to know the cost to scale, and as you pointed out, scaling a software product is not dependent on hiring more developers (at least not on a smooth curve). So, for an investor to understand the company, investing in development must be classified as capitol investment ( and depreciated over time ) and a clearer view of the operation to move units is given by excluding that cost from both fixed (overhead) and variable (cost of goods) costs.
Ah! Good point.
Many people are already familiar with the term "technical debt", however I believe that a far more important part is "technical capital" which is what developers create and grow within an organization. It's easy to overlook when you only think of your developers only as operational expenditure.
Good read 🙂
Thank you...
This is only true for some Devs. Big group of Dev do a custom applications to clients. This type apps are expensive.
thank you for the explanation, Evan!!!
Other than that, well said
Good catch 👍