Management is the continuation of prioritization by other means. —Carl von Clausewitz
Maslow's Hierarchy of Needs is the idea that people have an inherent and universal set of priorities. If you don't have enough air to breathe or water to drink, you'd better prioritize solving that problem, or you won't be around for very long to solve any other problems. Once you have that sorted out, you can focus on loftier goals, such as "feeling loved", "experiencing beauty", and "living a meaningful life". Software engineering teams have a similar natural hierarchy, and if you're leading one of them, thinking about the lowest point in the hierarchy where your team is struggling is a good way to decide how to invest your time.
This post is also available as a Twitter thread.
As the overriding goal of life is to maximize the spread of its genes and ideas, the overriding goal of an engineering team is to maximize the value it creates for its users. Considering the sub-goals on the way to achieving this from lowest to highest priority:
Existence
Congratulations, you have an idea, or an organizational charter, or some other mandate to do something! If you don't have a team to do it with, you're probably not going to do that something. Maybe that team is just you, maybe it's scads of highly specialized non-you people... But a team of zero is not much of a team at all.
Culture
If your team is a terrible place to work, nobody's going to work there for long, and those who do aren't going to deliver very good work. Create an environment where people can succeed, where it's
"safe to take risks, and so on. If you want people to accomplish anything, create the conditions that enable it.
Engineering Velocity
Look upon thy works ye mighty and despair, you have a team of more than zero people, and they're trying to write software instead of stabbing each other in the back and hunting for a less-crappy job! Are they successfully writing software? If it's impossible to get anything done because you have no tests, or your codebase is sued by Olive Garden for theft of trade secrets, or your documentation aspires to
Finnegan's Wake levels of clarity or
The Winds of Winter levels of existence... your team is not an effective deliverer of value for your users.
Reliability
Yay, you can write software! I tried to give you a medal, but you were busy fighting production fires. And, oddly, I couldn't find a customer to write a testimonial, in spite of the large numbers of them amassed outside your headquarters with torches and pitchforks. (Next time you're going to leak and delete all of their data, try not to do it in that order.) Unreliable software doesn't deliver much value.
Market Exists
Ok, now we're actually getting somewhere. You have a team, they're writing software and doing it well. Does anyone care? Unless you're solving a problem that someone actually has, the answer is no.
Product-Market Fit
You're attempting to solve a problem that people actually have. Does your solution actually solve the problem? If so, you've achieved the vaunted
product-market fit. If not, congratulations on identifying a problem that needs solving, but your value comes from solving it, and you're not there yet.
Out-Compete
If you're effectively solving an important problem, but someone else is solving it better, why would anyone use
your solution? If the answer is "they don't", then you're not actually creating value for anybody.
Delight
If you do this well, people will be
happy that they're using your software. They'll want to use more of it, they'll want to tell other people to use it, and so on. And so more people will use it. How can you fail here if you're doing everything else on this list? Maybe your solution works pretty well but is awkward to use. Maybe it has a price or licensing terms or other cost that people will only just barely tolerate. Maybe your reputation or that of your company is terrible, so folks
hate that your solution is the best option for them.
