As consumers, I think we can identify with the basic principle that we pay for goods and services. It’s how we interact with companies. As employees of a company ourselves, we have an intuitive sense that this is how our customers interact with our product or service:

+----------+      Pays Money        +----------+
|          +------------------------>          |
| Your     |                        | Your     |
| Customer |                        | Product  |
|          <------------------------+          |
+----------+     Receives Value     +----------+

As an Individual Contributor, that is, someone whose work is evaluated based on their own individual output, you might intuitively understand this same dynamic.

+----------+      Pays Money        +----------+
|          +------------------------>          |
| Your     |                        | Your     |
| Employer |                        | Output   |
|          <------------------------+          |
+----------+     Receives Value     +----------+

Note that here I’m saying “your output” and not “your time” for reasons discussed in a previous post: Fellow Engineers: This is where your money comes from.

But… how should a manager think about their job? We know that if you zoom way out, our customers pay us for our product. And, if you zoom way in, we have a company paying an individual for their individual work product. But, managers in the middle aren’t directly in either of these situations. Managers might view themselves as “glue” between the two. Their jobs might feel amorphous. Many managers, particularly new ones have a very hard time evaluating their own performance and success. Although it may not seem obvious, I think a useful framework for thinking about this is staring us right in the face:

               Allocates Resources
 +----------+    Pays You Money      +----------+
 |          +------------------------> Your     |
 | Your     |                        | Teams'   |
 | Employer |                        | Output   |
 |          <------------------------+          |
 +----------+     Receives Value     +----------+

The big shift here is twofold: (1) You are allocated resources beyond a paycheck and tools for individual work: you’ve got other people working at your direction, and (2) You’re now accountable for their collective output.

There are plenty of ways to get lost in the sea of things you’re now responsible for. You might beat yourself up about the fact that you implemented a new story points system but people aren’t estimating well. You might be upset that one of your team members is unhappy about how another team member, or some process, or the company at large. You might in fact think you’re successful because you see your team working very hard. Or, you might think you’re failing because the team is working too hard. You might be stressed out about defect rates, delivery dates, technical debt, work/life balance, quality and quantity of meetings, technical documentation, and on and on and on. Indeed you need to pay attention to them – but don’t forget these are all means to an end.

The end is the collective output of your team. Ideally you have plenty of autonomy and creativity to bring to bear to improve this. But, all of those tactics are in the name of output. If you ever find yourself getting lost in the weeds, focus on things with the greatest impact on your teams’ output.

But, there’s another dimension at work here as you traverse the IC -> manager -> company continuum: The degree to which you decide what you produce (what problem you’re solving), and the consequences of that decision. At the highest level, if a company does not provide a product or service that anyone pays for – they don’t find Product-Market Fit – it dies. The consequences are existential and the vastness of what they could choose to produce is infinite.

At the IC level, you aren’t typically responsible for deciding what problem you’re solving. Your company/boss/product manager explains what it is they’d like you to build, and you operate within that boundary. You attempt to build something that’s high quality, on time, performant, etc. But, if you were asked to build the wrong thing, you’re not accountable for that. Typically you don’t face any consequences for building the wrong thing, since that decision was not your responsibility.

And here we are again, in the middle, as a manager. Not only are you responsible for the collective output of your team, but as your scope increases, so too does your accountability for what problems your team is solving. The question of “are we working on the right thing?” is increasingly borne by you as you move up the organization. That, in fact, may become the question that eats at you on a daily basis more than any other. You’ve learned how to deliver solutions. You can help and advise members of your team to do the same. But… now you also have to start taking ownership of whether you’re solving the right problems.

Most companies fail. Their founders are usually unsuccessful at creating a viable business. But, here’s the good news, managers: you’re not a founder. The odds are not so long for you. You don’t have to deal with an infinite set of possibilities and mistakes are likely not existential. What you need to do is spend considerable time aligning yourself with the business.

In the diagrams above, your responsibility is on the right. The party on the left is the party you need to care about to be successful. For anyone but the top brass, you’ve got a comparatively straightforward answer as to who that is. At a minimum, it’s your boss. But, unlike an IC, your boss is probably not telling you what to do. They’re hopefully telling you what problems they want solved, what metrics they want moved, what products they want shipped. If they’re not telling you that, it’s your job to either extract that information from them, or decide what you think success looks like and ensure they know what problem you’re solving.

Then, execute.

Recently I saw some rather surprising conversations on Reddit’s /r/cscareerquestions which is generally a great place to talk through different CS Career issues people are having and try to help out.

In a thread about Coinbase mistreating a candidate (a legitimate complaint, it seems) someone made the assertion:

You programmers are crazy with the free work. Someone tells me they want anything over an hour and a half of my time, I will decline.

This was in the context of the interview process, mind you.

Another thread which really got my mind whirring was this one: How can I pursue technical excellence above all else, while still getting paid well? which includes this dilemma:

Ultimately, I want a profitable product to be a byproduct of my excellent engineering, not have my engineering be just a means to an end, of getting to a profitable product.

But, I also want to be paid well.

My worldview is so far misaligned with the framing of these questions that it’s hard for me to engage with them directly. If you’re an engineer building a product or service, and you care about getting paid, I think the most important thing you should be thinking about is where does that money come from?

There are a lot of valid answers to that question, but I think most of the time the calculus reduces to: we get our money from our customers. Sure, you may be early stage and getting paid by investment money for now… but the reason they’re paying you that money is because they’re betting that eventually you’ll have built a real business and customers are going to pay for your product or service.

So, if the money that pays your paycheck can be traced back to your customers… how do you justify getting paid more money? At that point it’s simple… find a ways to impact the value your company is delivering to customers. But, there are a few subtleties here:

• Your customers are not paying you for your time (slightly different for consultants).
• Your customers are not paying you for your education.
• Your customers aren’t even paying you for your individual output.

That last one can be counter-intuitive, but your customers are paying your company for the value your company delivers to them.

If you want to spend your life crafting beautiful code with headphones on, you can absolutely do that. You will get paid just fine for that. But if you’re not influencing others and helping the broader team execute, you’re setting a ceiling on the degree to which you can contribute to the company’s output. All you can contribute is what your own two hands can code.  In basketball, there’s a metric they started tracking in recent years called on-off splits. Simply, it’s meant to capture how much better your team is with a given player on or off the court. I love this metric because it’s an attempt to measure an individual’s impact on a team’s performance with an acknowledgement that individual statistics can’t paint the full picture.

This is why engineering career ladders start to layer in responsibilities for things that a single individual can’t accomplish themselves. This doesn’t mean you need to become a manager, but it does mean you need to look beyond yourself to maximize the value you’re able to bring to the people who are ultimately paying you.

There are other jobs where this is not the case. If you’re a cashier at a store where you have no real control over whether 0 people walk through the door that hour or 100 people, then you’re in a scenario where you’re simply being paid for your time. The value you’re delivering to customers is marginally within your control. In software, this isn’t the case at all. There’s no limit to what you can build, nor a cap on the value you can deliver.

I’m not trying to make a simple capitalist argument here either. Pretend you’re doing open source for free. Do you care if anyone on planet Earth ever uses that library you built? If so, your focus again is going to need to be on the value you’re delivering to your customers. They’re not using it because you put a lot of hours into it. They’re not using it because you went to a good school and read a lot of academic papers. You know this first hand, because you yourself are a user of open source projects and that’s not how you choose them. Subtract the money part of the equation and the premise still holds.

But wait! You may be saying… my job is a lot more like that cashier scenario… I have no control over how many customers walk through our door. And yes, this is the reason why if you care about how much you get paid, you need to evaluate the company too. You know this, and you even do this… but you may not have directly linked these two concepts together. In order for the value you’re creating to be realized by customers, a lot of other components of the business need to be working well. If you go to work on Google search, you’re walking into a situation where they’ve already solved the problem of attracting billions of searches per day. Lucky you – you’re handed an opportunity where you can directly deliver value to users.  However, if you’re joining a stealth startup… there’s a lot more risk there. Is the company solving a meaningful problem for customers? Are we starting with the right featureset? Is our marketing team going to be successful in marketing it, and our sales team to sell it? This stuff has a direct impact on you, because it deals with where your money comes from.

This is why I struggle with scenarios where people discuss pay and work without considering value. If you want to increase your compensation over time, continue to put yourself in a position where you can deliver the most value.