Here’s my framework for how I think about making career decisions, arguably one of the most important decisions we make in our lives.

I break it down into four categories, ranked by how important each is to me:

1) The People

My top priority is working with great people. Everything else is secondary to that.
1a) Are these smart, passionate, high EQ people that care about their work? Would I enjoy working with them? Do they lift the rest of the team up? Are they welcoming and inclusive? Do they strive to continue learning? Would I learn from them?
1b) It’s sometimes hard to get a good gauge of the people through just interviews. If you haven’t worked with the team prior or knew them for an extended period of time, values are a good place to start.
1c) Talking to past employees at the company and past colleagues at other companies can tell you a lot. Don’t skimp on reference checks. Ask questions like:
- Would you work with that person again?
- How did they resolve disagreements?
- How much did they care?
2) The Mission

Second on my list is the mission. Because I only get to take 1 bet at a time on a company working for them, it’s important that I’m working on something I can get behind.
2a) Is it a mission that gets me excited to wake up and work on everyday? Is it actually something important? Will I be able to make an impact - not just in the company but externally as well?
2b) It’s also totally fine to work for a company not “changing the world”. IMO mission = excitement and it’s whatever will make you happy. Why spend 2,080 hours each year doing something that makes you miserable?
3) The Role

If the people and mission check out, it’s probably important to start thinking about if the role is a good fit.
3a) Does it make sense given my background and skills? Is it a role I’d be good at? Will I be in a position where I can succeed?

A good sign the role is a good fit is if it overlaps with your zone of genius.
3b) I also very much believe in compounding, especially when it comes to careers.

If a role doesn’t compound on the skills I’ve grown throughout my career, probably not a good fit. I like to reflect on the things I’m good at and not so good at and double down.
4) Lastly, upside.

Not everything has to or should be a money driven decision, but it’s important. Everyone’s financial needs are different.
4a) For me, upside has always meant “is my ownership * potential value of the company large enough to help me reach my financial goals.”

For some that could be $1m in net worth, for others $100m.
4b) A q I also frequently ask myself is if I believe this company can be worth 50-100x from today.

Stage of company drives some of this thinking. An earlier stage company can have a 100x growth ($5m -> $500m) but its also possible that a public company does too ($5b -> $500b)
And that’s it. I haven’t yet made a career decision without being able to fit a factor into one of these categories, but curious to hear what others find important as well.

More from Tech

A common misunderstanding about Agile and “Big Design Up Front”:

There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.

You’re allowed to think about a desired outcome from the beginning.

It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.

It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.

It’s not BDUF if you help every team member know what success looks like.

Agile is about reducing risk.

It’s not Agile if you increase risk by starting your sprints with complete ignorance.

It’s not Agile if you don’t research.

Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.

It would be a mistake to assume this research should only be done by designers and researchers.

Product management and developers also need to be out with the team, conducting the research.

Shared Understanding is the key objective


Big Design Up Front is a thing to avoid.

Defining all the functionality before coding is BDUF.

Drawing every screen and every pixel is BDUF.

Promising functionality (or delivery dates) to customers before development starts is BDUF.

These things shouldn’t happen in Agile.

You May Also Like