Manage your priorities and energy.

Back when I was managing at Uber, I latched onto a thinking tool that I drilled into the teams I worked with: reach the right outcomes by prioritizing the company first, your team second, and yourself third. This “company, team, self” framework proved a helpful decision-making tool, and at the time I felt it almost always led to the correct decision. It also helped me articulate why I disagreed with some of my peers’ decisions, which violated this hierarchy by placing individual or team preferences over the company’s priorities.

As I’ve become a more experienced manager, I’ve stopped giving this advice. I still believe it’s conceptually good advice, and I continue to see managers who fail because they are missing this perspective. However, I’ve also seen some of the best leaders that I’ve worked with burn out by following this advice too loyally. A long-term career depends equally on being impactful and staying engaged.

In this post we’ll discuss:

• How I previously used the “company, team, self” framework to prioritize
• How energy management is positive-sum, and why that’s changed my model for prioritization
• How I’ve moved to an “eventual quid pro quo” framework
• Distinguishing between self-interested behavior and the appearance of self-interest
• Why it’s important to remain flexible, even with the best framework

Let’s drill into the details.

This is an unedited chapter from O’Reilly’s The Engineering Executive’s Primer, and expands on ideas I earlier wrote about in Company, Team, Self.

“Company, Team, Self” framework

As I mentioned above, I used to rely on the “company, team, self” framework to check my decision making, particularly during my time at Uber. Uber Engineering had a strong Not Invented Here bias, and frequently invested in creating its own technology like the M3 metrics system or the Mezzanine sharded storage system. While many of these systems addressed very real scalability concerns, they also tended to get their proponents promoted, and over time it became challenging to distinguish whether any particular platform was principally anchored in business impact or career progression. In that environment, pushing the team to explicitly prioritize the company and team first was extremely valuable.

Some of the concrete scenarios where I found this framework useful were:

• Deciding whether to prioritize an interim orchestration solution before a planned Mesos-based orchestration system was rolled out. Yes, we should build an interim automated solution to support Uber’s engineers while we waited for the replacement, even thought it was viewed as less promotable work than working on the delayed replacement
• Fixing hiring loops where stressed out hiring managers wanted to hire candidates who didn’t meet our hiring bar. Yes, you do need to make a hire, but no, making this hire isn’t the right outcome for the company
• Evaluating the relative priority of staffing requests within the organization. Yes, every team would benefit from additional staffing, but which would be most valuable to the wider organization?

The framework was particularly helpful within platform and infrastructure teams where our distance from end-users and revenue often obscured answers that might have been more obvious on user-facing teams with the loud signal of user feedback.

However, the more I followed the “company, team, self” approach,” the more I appreciated its biggest downside. The most valuable work at a company is rarely the most interesting nor—oddly enough–what the company itself particularly values. I frequently noticed cases where engineers did the best thing for the company, solving an urgent problem with little staffing, but weren’t recognized or promoted for their work. Those engineers would slowly become deenergized and frustrated. As this pattern got clearer, it became increasingly clear to me that always prioritizing the company’s needs was too literal a solution, and a durable approach would require balancing the company’s priorities with remaining personally energized for the long-haul.

Energy management is positive-sum

People are complex, and they get energy in complex ways. Some managers get energy from writing some software. That’s great, particularly if you avoid writing software with production dependencies. Some managers get energy from coaching others. That’s great. Some get energy from doing exploratory work. Others get energy from optimizing existing systems. That’s great, too. Some get energy from speaking at conferences. Great. Some get energy from cleaning up internal wiki’s. You get the idea: that’s great. All these things are great, not because managers should or shouldn’t program/speak at conferences/clean up wiki’s/etc, but because folks will accomplish more if you let them do some energizing work, even if some of that work itself isn’t very important.

Rigid adherence to any prioritization model, even one that’s conceptually correct like mine that prioritized the company and team first, will often lead to the right list of priorities but a team that’s got too little energy to make forward progress. It’s not only reasonable to violate perfectly correct priorities to energize yourself and your team, modestly violating priorities to energize your team in pursuit of a broader goal is an open leadership secret. Leadership is getting to the correct place quickly, it’s not necessarily about walking in the straightest line. Gleefully skipping down a haphazard path is often faster than purposeful trudging down the safest path.

There are, of course, rules to breaking the rules. The most important being that your energizing work needs to avoid creating problems for other teams. If your fun project is prototyping a throwaway service in a new programming language, then hmm, maybe that’s fine. But if you put it into production, then your energizing detour is going to be net negative on energy generation after other teams are pulled in to figure out how to support it.

Correctness and humans mix in complex ways. The most important lesson I’ve learned as I’ve become a better manager is that there is almost always a correct answer, but applying that answer to your specific situation will always be nuanced and messy. Further, the correct answer is often different if you’re taking a short-term or long-term perspective. Every specific decision is nuanced and complex, but you’ll be a better leader if your decision making modestly factors in your team’s energy than if it ignores it.

Eventual Quid Pro Quo

These days, my framework for personal prioritization merges the business-first perspective of “company, team, self” with the belief that becoming deenergized or disengaged is my biggest risk in any particular job. I think of this new framework as “eventual quid pro quo.”

The core framework is:

1. Generally, prioritize company and team priorities over my own
2. If I’m getting deenergized, artificially prioritize some energizing work. Increase the quantity until equilibrium is restored
3. If the long-term balance between energy and proper priorities can’t be balanced for more than a year, stop everything else and work on solving this (e.g. change your role or quit)

Arguably, this is a small tweak to my earlier framework, but it’s been very important for me, which is the key component of a successful framework. What makes it useful for me is that I am a very literal interpreter of frameworks, and this gives me space within the framework to maneuver and adapt. I can remain faithful to the framework without draining out my energy in the first few years in any given role.

Just because it’s the right framework for me, doesn’t mean it’ll be the right one for others. To develop an effective prioritization framework requires getting to know yourself (what work energizes you) and your priorities (career, financial, and otherwise). Until you understand those answers, no premade framework is going to produce the correct answers for you.

You’ve probably worked with someone who operated in a short-term quid pro quo mode. This person may have frequently asked what the benefit was to them to take on a given project. That approach does not work well in leadership roles. In particular, it adds friction at the wrong moment, when the requestor (typically your boss) is trying to solve the problem. Over time, short-term demands will often mean you’re considered last for valuable assignments. Decoupling timing of repayment lets you keep access to interesting work while also pushing to ensure you’re rewarded for that work in an appropriate currency. This isn’t perfect, as sometimes you won’t be rewarded for some work, but it’s generally better than the alternative if you are in, or pursuing, an executive role.

Mirrors of misalignment

One challenge with frameworks is they sometimes don’t tell the entire story. As I get further into my career, I’m acutely aware of moments when my actions are perceived as in conflict with some of the earlier mental models I used to evaluate work. For example, I’ve recently spent a fair amount of time threading a needle through Engineering to prioritize Large Language Models through our execution. If I were sitting in many of my previous roles, I would judge myself as prioritizing misaligned work. In my current role, I appreciate that there is an organizational risk budget around how and how much investment we can do to leverage potentially-but-not-necessarily transformative new techniques.

I think of this dynamic–when I prioritize work that my previous frameworks would have considered misaligned–as navigating the mirrors of alignment. There is always another layer of context that validates or invalidates any given piece of work. This is why operating from a place of curiosity is so powerful: folks who appear to be doing something nonsensical almost always have more information than you or are missing a key piece of information you have.

The place where I see these mirrors the most frequently is corporate planning and projects that bypass the corporate planning process. It’s very common for companies in dynamic markets to spend a month planning their next half, then immediately invalidate that plan by changing their priorities. This infuriated me for a long time, and my framework thinking labeled the offenders as bad planners. Now I see myself doing the same thing, and I’ve come to appreciate that many of the folks I silently accused of malpractice were balancing context that I had no idea existed.

As an executive, each time this happens is a reminder to share your context more widely, and remain curious. You’ll rarely be missing strategic context, but you’ll increasingly be missing the tactical context around how things actually work. Seniority creates just as many gaps in knowledge as it closes.

Orthogonal but not in opposition

As you think about expanding your framework to create space for energizing work, the most important guideline to remember is that while it’s okay to do a small amount of work that’s orthogonal to the company’s needs, you will always regret doing work that is opposed to those needs.

Working through some examples:

• Many folks do more public speaking, perhaps at conferences during working hours, than their company strictly values. Doing one or two speaking gigs a year may not directly help your company, but it’s also hard to argue that it’s causing any negative effects. (Whereas if you did eight or ten speaking events in a year, then it’s easy to argue that you’re encouraging others in your organization to focus away from the work at hand.)
• If you push to use a new technology on a project principally out of interest in learning that technology, then you’re creating significant execution risk and maintenance cost for your company. This might be energizing for you, but in most cases is likely in opposition to the company’s needs.
• Doing some angel investing in unrelated business verticals won’t quickly teach you a tremendous amount of relevant information, but it will slowly broaden your horizons across the industry. Further, it won’t take up too much time to do it. (Doing a tremendous amount of angel investing, or running your own syndicate, certainly might cross a line into being opposed to your core work.)

Almost any outside activity is fine when done in moderation. Almost any decision to use work projects as an opportunity to develop yourself by using non-standard tools is a bad choice. If you’re not sure, ask a friend, but it’s probably a bad sign that you’re uncertain.

Remain Flexible

If you strongly disagree with the idea of factoring in engaging work that is imperfectly aligned with your company’s goals, I’d push you to remember that humans aren’t robots. That’s surely obvious advice, but I really struggled with that idea for a long time. It was very frustrating to me that the correct answer to most prioritization and architecture projects was obvious (e.g. why is it controversial that we should use boring technology?), but teams so frequently did something incorrect instead. What folks may not understand, is that for a certain type of person, strictly adhering to the correct path is very energizing. That kind of person, a person who I used to be most of the time (and still revert into today when particularly frustrated), doesn’t need to do sub-optimal energizing work, because doing the correct work is inherently energizing.

However, I have to admit that I’ve never really seen this personality succeed in senior roles, because those roles require working with so many different people, and only a relatively small subset are energized by adherence. I’ve worked with dozens of extremely talented engineers and managers who are professionally stymied by being energized by adherence and demotivated by the lack of adherence in those around them. It is a powerful value system, but it is not a widely appreciated one. It’s particularly rare to find executives who are motivated by adherence. In some brilliant moments you’ll get to work with folks with the same values, and those will be some of your most rewarding moments, but you have to learn to turn those values off when they’re interfering with forward progress. Blunting this edge has been one of my most valuable lessons over the last decade.

Summary

While there are many prioritization frameworks for teams, such as RICE, there aren’t nearly enough to help individuals think through their priorities. Now that you’ve finished this article, you have several examples of frameworks that have (and haven’t) worked for me, and are well-positioned to think of what the right framework might be for you. There’s no one solution, but you’re going to accomplish less in your career if you’re so focused on correctness that you lose track of keeping yourself energized.