Who pays you? And why?

Originally posted 2024-05-02

Obligatory disclaimer: all opinions are mine and not of my employer

I get asked for career advice from time to time. While each situation is different, a recurring theme is disempowerment - feeling like there’s nothing you can do to advance your career. To help diagnose, I like to ask two questions: Who pays you? And why? These two questions encourage you to leave the comfort zone of job descriptions and confront the reality of what it’ll take to get to the next level at your current job, or potentially a new job.

I’ll explain how I think about these questions (mostly from a software engineering perspective), and this hopefully helps you think through your own situation.

Why software engineers get paid

Fundamentally, software engineers get paid a lot because one person can write code that generates high profit margins over millions of machines. In the same way that traders scale their efforts across money and executives scale their efforts across people, software engineers scale their effort across machines.

Since pay is correlated with scale of impact, the next question is, what limits software scaling? I’d say technical and conceptual complexity, which can come about from bad product management, bad engineering decisions, cascading tech debt, and just plain old lack of skill. Fortunately, software engineers have been chipping away at the complexity problem for decades. Engineers today benefit from better documentation, better code editors, better linters and test runners, better languages, better compilers, better code search tools, better cluster infrastructure, better libraries, better experience sharing, better understanding of Conway’s law, etc..

To maximize your impact as a software engineer means the following:

Getting better at picking more impactful problems to solve. You could dominate the bingo card market but how much does that even earn you?
Continually trying new ways of working.
Building simple code that doesn’t collapse under its own abstraction weight.
Teaching other engineers to work more efficiently and to build simpler code, either 1 on 1, through writing, or through creating languages/tools/infra that shapes the way they work.
Influencing other engineers to work on more impactful problems.

These ideas are often expressed in some sort of performance review rubric, whose purpose is to directly educate and incentivize you to be maximally useful to the company in the way that only software engineers can. The rubrics are typically public and yet these ideas are not understood by many. (See: the popularity of Tanya Reilly’s excellent Glue Work essay.)

Who pays software engineers

I should also differentiate here between software companies (rough heuristic: competes with FAANG for talent) and companies that use software (basically everyone else). The difference is that software companies are built bottom-up without humans in their critical business loops, allowing software to scale without bound. You can retroactively try to streamline a human-centric organization, but the people involved will resist furiously. There is simply no way that a traditional ad agency built atop ad salesmen and weeks-long business cycles could transform into an organization capable of milliseconds-long ad auctions, as Google implements. Thus, Google’s ad engineers each generate 10-100x as much business value as a traditional ad agency’s IT folks, and are paid probably 5-25x as much.

Thinking beyond job descriptions

Understanding how to answer who and why helps you navigate ambiguous job descriptions, or to even invent them from scratch.

Consider the “data scientist” job title, which became increasingly popular in the 2010s, especially among scientists fleeing academia. While the job description read “data scientists get paid to build models”, anybody who took that job description at face value found themselves looking for a new job in a year or two. The real reason data scientists are paid is to drive better business decisions. Data and science are optional.

Nowadays, job titles like “AI engineer” or “LLM engineer” or “AI researcher” get thrown around. Who pays these people, and why? The cynic would say they’re getting paid because clueless business people are buying into unsubstantiated hype. And honestly, the cynic is right. Nobody knows what business value to expect from LLMs. But what I can tell you is that there are thousands of startups, tinkerers, consultants, and research groups trying to answer “who” and “why”. The people that succeed in answering these questions will create a lot of value, and depending on their strategic positioning, capture some of that value. Those who don’t understand why they are being paid will be surprised when the hype train moves on and their projects are cancelled.

Finally, you’ll find that staff engineers’s job descriptions inevitably include some statement about navigating ambiguity. This is what ultimately differentiates staff from senior: the ability to navigate business ambiguity as well as technical ambiguity

Finding personal alignment

I’ve been answering questions about “who and why” in the abstract. But your personal answers will be more tactical. The who is your manager, or perhaps your skip-manager. The why may relate to short-term projects or perverse incentives that you might not agree with. And you shouldn’t necessarily trust your manager/skip managers/organization to tell you what they want you to do and why.

Finding career success and satisfaction is very much about finding personal alignment with an organization’s goals. You have to understand what you need, what the organization needs, what the alignment is between the two, and finally, decide whether that alignment is enough to keep you happy. If that doesn’t sound hard enough, all of these factors are also changing over time: you grow as a person in what you find challenging and rewarding, while the organization responds to market conditions in terms of what sort of work is needed. What might have been a dream job may be a dead-end job in a short few years, especially in a field as dynamic as tech. Ask me how I know.

Trust your gut. In my experience, people get thoroughly boiled before they finally decide to jump out of the pot. If you feel like something’s not right, you have to understand where that feeling is coming from. Switching teams, jobs, or sometimes even switching careers is often a necessary step towards reaching career satisfaction.

Once you figure out how to find personal alignment, you’ll also be well-equipped to handle one of the harder problems facing management: how to maximize your team’s output by figuring out how to align others’ personal needs with organizational needs.

Reimagining your experiences

Let’s say you’ve decided to switch teams/jobs. How you talk about your past experience reveals a significant amount about how well you understand the answers to who and why.

There’s a famous story about three bricklayers in which three people doing identical work describe themselves as “laying bricks”, “building a cathedral”, and “spreading the word of God”. The tech equivalent of laying bricks might be “Improved test runners”, “Optimized continuous integration suite runtime by 50%”, and “Created a rapid iteration culture by increasing release cadence from monthly to weekly”. It’s clear that these three resumé lines are written by a junior, senior, and staff software engineer, respectively.

I strongly recommend the exercise of rewriting your resumé from the perspective of the next rung on the job ladder. You might feel dishonest claiming credit for things you don’t feel like you did, when all you did was lay bricks - but think of it this way - why should your manager get to claim credit for the cathedral you built? If you can understand the vision and you’ve been helping guide yourself and your teammates towards that vision, then you’ve been doing next level work, regardless of what the org chart says.

Concluding thoughts

I’ve been told by former coworkers that they wished they could be as decisive as me when it came to pivoting my career. Truthfully, it doesn’t come easily to me, either. I’ve switched career tracks three times so far. The first time was when I dropped out of grad school and pivoted into software, then I was fired from HubSpot and pivoted into machine learning, and finally when I got laid off from Google and joined a successful LLM startup. I didn’t even initiate two of those three career pivots! I was scared of change and didn’t take the necessary steps for 6-12 months. But once I had taken the plunge (voluntarily or not), I found that within a few months, I had newfound clarity about what I wanted to do next, and from there on it was just about finding the right company that aligned with the work I wanted to do.

I see a lot of people stuck in jobs they’re not happy in. As tech workers, our outsized salaries grant us more flexibility to take more career risks and find better personal satisfaction from our job. Oftentimes the grass really is greener on the other side - come and find out!