What Developers Are: Why an Unprofitable Company Can Have 70% Margins

If you're at a company that's quite open about how the business gets run (a lot of well-run smaller 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. In fact, somehow tons of tech companies are operating unprofitably yet claim 60-90% margins. How? How can you can you 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.

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 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 a fixed cost.

But you 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 I make. I have to pay myself or another engineer to build my Snapstagram, but once it is working, I can sell millions of copies with almost no added cost.

That means that the engineer is not generally a fixed 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 a fixed cost, your salary is limited by the amount you're likely to produce, not as an attempt to cut costs.

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 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 a fixed 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.

Who are you?

I make Quirk, a for-profit open-source app for Cognitive Behavioral Therapy, the de-facto standard for treating depression and anxiety.

Quirk's designed for day-to-day problems; so if you're feeling a lot of imposter syndrome lately but don't feel like you're really "anxious" or "depressed" then you might want to check it out. Feel free to send me an email too if you need to talk: ejc @ quirk.fyi

Since Quirk became a real "company," I've been spending a lot of time thinking about how to use natural incentive systems of tech companies to create real positive social impact.