The Engineering Hierarchy of Needs

Most engineering managers try to balance the needs of their engineering team with the needs of the business. This either/or is stressful and unnecessary. It stems from a fundamental misunderstanding about what truly high-performing engineers really want and need, which is a human conditions as old as the pyramids.

Maslow’s Hierarchy of Needs is a useful model for understanding how certain general human needs, such as friendship, are predicated on the existence of others, such as safety and food. For engineers, there are actually two parallel hierarchies–pertaining to our needs as individuals, and our needs as part of a group.

It looks like this:

Starting from the bottom, subsistence for the individual means earning the right to keep living and working the way you want to; for the company it is earning the right to continue its mission. Failure at this level happens quite simply when funding runs out before the company breaks even, or when a lack of profitability leads to layoffs for some individuals or even to shutdown for whole the organisation.

Surviving is essential, but it is not the same thing as truly living. It is at the next level that this happens, and here the individual’s own needs for themselves diverge from their needs in relation to the group. On a personal level, once the bills are being paid, engineers want engagement. We want to do challenging things with interesting people and exciting technology. Some form of this wording often makes its way into recruitment literature, because this is something we engineers in particular crave.

This experience that can be had outside of a company–through study projects, sponsored challenges, and open-source software contributions. It is no surprise that simulating this experience is often part of a hiring process unique to engineers, in the form of whiteboard interviews and coding tests that are usually intellectually interesting, but often divorced from any real business needs. In the end, one-off group-based puzzle solving, apart from rarely being a paid activity, also fails to promote any sense of cumulative progress.

Engineers who have discovered this want to be part of the evolution of an organisation–to help the company to grow, thrive, adapt, and change. The best and most successful teams embrace this, looking to create meaningful outcomes for the business instead of just churning out one-off features or fixing bugs. They want to know the strategy and understand the high-level objectives. They want “why”, not just “what”. (And they certainly don’t want to just be told “how”.)

With each new generation of engineers, I see this more and more. Gone are the stereotypes of basement-dwellers divorced from reality, human tools who must be wielded by others in service to business needs via rigid design specifications. That whole model is frankly better suited to AI. Truly high-performing engineers want to contribute more than an elegant solution–they want to contribute one that is meaningful and which advances the cause of the group as well.

Speaking of causes, the two capstone qualities are about just that. As individuals, the best engineers want to continually advance–to learn and grow and further their career as a technical practitioner, leader, or both. We are our own best cause, and some very good engineers advance themselves by hopping from company to company when the going gets rough or the learning runs out. They constantly shoot up and out the left side of the pyramid like sparklers.

The great ones, though, want not only to grow, but to be part of something bigger than themselves.

At the highest level, we want to make an impact. We want to be part of a company that changes the world in some way. This is why introverted technical makers flock to charismatic visionaries who can promise them just that. We all crave significance, and few of us can achieve it on our own. At its best, engineering is using what we are good at, in a field we enjoy, to do create something that matters that would be impossible to make on our own.

Most managers forget that engineers, despite their reputation for introversion, are social beings with a need for significance. Managing to the “left side” individual needs is a recipe for continual employee turnover. Managing exclusively to the right side can feel ephemeral and even rote if not grounded in engaging, growth-filled work along the way.

Moreover, most organisations don’t understand the hierarchical nature of these needs, and instead focus on only a handful of factors, such as high salaries (subsistence), smart colleagues (engagement), business contribution (evolution), or skills and prestige (advancement). For some, it’s enough. For the teams that do amazing things, however, these are just building blocks along the way.

Speaking of blocks, the engineers who built the pyramids probably had the same needs as those who built LinkedIn. Foundations are essential, but for those truly great engineers, without the golden capstone, you’re just shifting around a big pile of rocks.

Interested in leading your whole team fully to their next level of high performance? Perhaps I can help