Fellow Engineering Managers: This is what your job is

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.

Leave a Reply

Your email address will not be published. Required fields are marked *