Continuous Delivery in software is about providing incremental value to customers daily and improving their satisfaction with what’s already been delivered. In a software delivery system, many elements need to function correctly for this to work effectively.
In any software delivery system, there are capacity limitations. Every hour that an engineer is working on improving the delivery system is an engineer that isn’t working on adding features or improving the value proposition of your product. There are always capacity limitations, which means you need to say no to worthwhile initiatives in favour of more meaningful ones.
As a leader, the dilemma often lies in deciding what to prioritise. How do you determine which initiatives are more important when they all seem meaningful?
In my team, we’ve bounced from one initiative to another as pressing issues emerge — a situation I referred to as ‘whack-a-mole’ in a recent post. I’ve experienced the consequence of playing whack-a-mole and spreading my team thinly over numerous initiatives. It’s not fun.
I was recently introduced to the “Engineering Team Needs Model” developed by Wires Uncrossed, which has proved extremely helpful. This model, inspired by Maslow’s Hierarchy of Needs, ranks needs in a software delivery system at different levels, suggesting you should meet basic needs before moving on to higher-order ones.
A broad overview of the Engineering Team Needs Model presents a hierarchical representation of the software team’s necessities. It comprises five different levels. I’ll work my way from the bottom up:
- Basic Needs allow you to build and alter an application.
- Managed Work: These ensure repeatable work and maintain the quality of modifications.
- Effective Ownership: These focus on long-term services and standardise architecture.
- Sustainability: These enable adaptive teams and systems.
- Flow: These fosters a consistent flow of value, ensuring high customer trust and team proficiency.
To prioritise initiatives effectively, determine the level of each initiative and then prioritise the ones lower in the hierarchy first. For instance, if two areas require attention—Career Growth of Software Engineers vs. Operating Rhythm, Career Growth would sit at the Sustainability level, and Operating Rhythm sits at the Basic Needs level. Thus, you would first focus on the lower-order need (in this case, Operating Rhythm) before progressing to the higher-level need (Career Growth).
The Engineering Team Needs model has provided an excellent conceptual framework for identifying higher-order vs. lower-order needs and is highly recommended.
