The Engineering Hierarchy of Needs: Balancing Urgency with Importance

In software engineering, urgent issues often eclipse important ones. Here's how to realign your team's priorities for sustainable success.

??vs?? Fix the build or patch the security vulnerability? Before asking teams about security and cost reduction work, first enquire about the performance of their build pipeline and local dev environment.

At Wires Uncrossed, we believe there is a clear hierarchy of needs within an Engineering team. You see this play out daily in teams' decisions on what to work on. Lower-level, basic needs will always trump higher-order responsibilities. So when leaders need teams to work on reliability or governance, first acknowledge that lower-level pain points will take precedence and then proceed accordingly. We have been modelling a hierarchy of engineering needs for several years and want to share a high-level overview of how we apply it.

The Daily Grind: Immediate vs Important

Imagine you're Mika, a team lead in a 10-year-old tech company.?

You're two weeks from a delivery milestone, a month behind what was promised to customers. You're wondering about a cloud cost alert notification on the way to work. Humm, I must look into that.?

Mika's week reveals a recurring theme in engineering—urgent issues often derail focus from longer-term but increasingly essential objectives.

Monday morning

• The production database is degraded and almost offline.

• The front-end build is broken.

Action >> Must fix the database.

Tuesday

• The build is still broken
• Security scanning picked up a vulnerability in an open-source package

Action >> Fix the build

Wednesday

• Reports say the vulnerability is serious
• One of the team's project templates needs updating

Action >> Mitigate the vulnerability

Thursday

• The template still needs patching & rollout
• There are two graduates to onboard

Action >> Patch the template

Friday

• The grads are confused and idle
• Someone is asking about recent compute cost spikes

Action >> Take care of the grads. The $ can wait till Monday ( or maybe Tuesday ??)

We could go on, but you get the idea. Just like in our daily lives, when we get sick or hungry, in a matter of hours, that becomes the most critical priority for us. Forget about everything else. And so it is with software teams. If we expect teams to proactively manage reliability, security and all the other things, we should first understand how well their delivery system meets their basic needs.

The Solution: A Hierarchy of Needs

We model these needs in our?Hierarchy of Engineering Needs, which you can apply in various ways to diagnose and prioritise initiatives across Engineering experience.?The model has three layers of detail, starting with the five primary levels of need:

• Basic Needs: Essentials for any team to build and deploy an application.
• Managed Work: Requirements for making work repeatable and quality-controllable.
• Effective Ownership: Necessities for owning and operating services in production.
• Sustainability: Elements for team growth and yearly maturation.
• Flow: Indicators of long-term productivity and customer trust.

Each area is then broken down into individual needs (e.g. compute, quality engineering) with an associated definition and examples. Throughout, we avoid mentioning specific technologies and instead focus on the need a tool or technology should address.?

Conclusion

To sustainably lift the maturity and capability of a software delivery system, we must acknowledge that immediate needs will always trump important ones. For example, we may first need to support teams on their deployment pipeline performance to advance our templates or golden paths.?

All models are wrong, some are useful - George Box

Useful to you?

The model is beneficial to us in having to understand multiple and varied delivery systems, but take a look yourself and let me know your thoughts on how you might apply it.