Raik's Hierarchy of Engineering Needs
Maslow’s Hierarchy of Needs explains human motivation in a structured way — from basic survival needs to higher-level self-actualisation. Engineering teams operate under a similar principle: before they can innovate and grow, they must first ensure system stability and ongoing maintenance.
Raik’s Engineering Hierarchy of Needs defines the four key levels that engineering teams must prioritise in order. At the foundation is incident response, ensuring immediate recovery from system failures. The next levels focus on keeping systems running, keeping existing customers happy and maintaining security, and, finally, when all that is under control enabling new initiatives and innovation.
Senior business leaders sometimes ask "why aren't we shipping features fast enough" or "why is the engineering team spending so much time tinkering in the system", or "why is engineering requesting more resources when they don't seem to be making much progress". The answer is often found in all the things that engineering teams have to do before they get to the shiny visible features, and the good news is, once you understand them, you can make conscious effective tradeoffs.
Let’s break down each level from the bottom up.
1. Incident Response – Emergency Resolution
At the base of the hierarchy is the most urgent priority: getting the system back online when it goes down. No other work matters if the product or service is completely unavailable.
Key Focus Areas:
When an outage occurs, this becomes an all-hands-on-deck situation. The faster recovery happens, the less impact it has on customers and business operations.
2. Keep the Lights On (KLO) – Managing Risk
Once immediate incidents are resolved, engineering teams focus on maintaining stable and reliable systems. This level ensures that outages happen less frequently and that core services remain predictable.
Key Focus Areas:
Without this layer, teams would be stuck in a cycle of constant firefighting, leaving no room for growth.
3. Business As Usual – Churn Reduction
At this stage, engineering efforts shift toward improving the customer experience. Bug fixes, performance tuning, and workflow optimizations help keep users engaged and prevent them from leaving for competitors.
Key Focus Areas:
Without prioritising this level, user frustration grows, leading to increased churn and lost revenue and opens the door for competitors.
领英推荐
4. New Initiatives – Growth and Innovation
At the top of the hierarchy is the ability to drive new growth. Once the lower levels are handled, engineering teams can shift focus to building new features, experimenting with fresh ideas, and expanding the business.
Key Focus Areas:
This level represents true innovation, but it is only sustainable if the lower layers—incident response, stability, and risk management—are well maintained.
Strategic Trade-offs
Once business leaders understand Raik’s Engineering Hierarchy of Needs, they can make conscious, strategic trade-offs based on where their product is in its lifecycle and what challenges the business is facing. Engineering effort is not a fixed allocation—it should shift dynamically to match business priorities, risk tolerance, and growth opportunities.
For example, in a high-growth startup phase, churn may be low simply because the market is expanding, and new customer acquisition outweighs customer losses. In this case, leadership might choose to deprioritize some BAU efforts (like optimizations and cost efficiency) in favor of rapid feature development and scaling. However, this comes with risks—neglecting BAU for too long can lead to technical debt, performance bottlenecks, and future instability.
On the other hand, if a company is facing frequent incidents, then Keep the Lights On (KLO) work must take priority. When outages and instability affect customer trust or regulatory compliance, every other initiative—including new features—must take a backseat. Some businesses, such as those handling high-risk data (finance, healthcare, critical infrastructure), will always need strong KLO investments to avoid catastrophic failures. In these cases, reducing risk outweighs short-term revenue gains from shipping new features.
Similarly, if a business is entering a mature or competitive market, churn reduction and customer satisfaction become more critical. At this stage, BAU work such as workflow optimisations, bug fixes, and performance improvements may take precedence over aggressive innovation. Losing customers due to poor reliability or frustrating user experiences can be more damaging than failing to launch a new feature.
By applying this framework, business leaders can intentionally shift engineering resources based on what matters most at a given time. The key is that these are deliberate decisions— not reactive ones. Instead of constantly questioning engineering priorities, leaders can confidently align effort, investment, and risk tolerance with the company’s current strategy.
Final Thoughts
Raik’s Engineering Hierarchy of Needs provides a clear prioritisation framework for engineering teams. Just as humans must first meet their basic needs before seeking fulfilment, engineering teams must first ensure stability and risk management before pursuing growth and innovation, and they can this in a strategic way and direct effort where its needed based on the situation and strategy of the company.
By focusing on each layer in order, organisations can build a resilient, efficient, and innovative engineering culture that drives real business impact.
Side Note: I'm running a 6-hour in-person in-Melbourne after-work intensive crash course on technology leadership, so if want to learn more about this topic and other issues that impact engineering and how to handle them, come join me.
BH: Product Manager at Damstra Technology, AH: Musical Comedian
1 周I love this model, Simon Raik-Allen! As a product manager I’ve sometimes struggled with finding the right balance between adding cool new stuff to products vs support, KLO and BAU.? This is some great food for thought!
Chairman(Retired) at Allen Consulting Group P/L
2 周Nice work Simon
Advisor, mentor, strategist, coder.
2 周Thanks for all the comments and messages. Let me respond here to a few of them. Reducing Tech Debt - I consider this to be a task that occurs at all levels, all the time. No matter what you are working on you should always be cleaning up as you. This allows you and the team to remain productive. But once again its a tradeoff how much work you do on this and when. Support - Engineering teams are often brought in to support customers when others in the company have exhausted all other avenues. This can obviously be a big drain on resource and should be addressed with KLO if it builds up too much, because when a custom needs help, this is an incident. However, its not in the hierarchy because not all support requests are urgent and take precedence over everything else. KLO - Pronounced "Kay Low". Most people bundle this into BAU - but its not and its dangerous to do that because they are very different and often funded differently. BAU is customer beneficial, KLO is system beneficial and masking one in the other hides the true cost of running and maintaining a system.
Really enjoyed your article, Simon Raik-Allen! The 'Raik's Hierarchy of Engineering Needs' is a brilliant way to visualise the progression of engineering maturity. The emphasis on foundational elements like stability and security is spot on. It got me thinking about how, while the hierarchy is a valuable tool, the real key is establishing and maintaining consistent good habits. If we can build a culture of continuous improvement, we can proactively address these needs and operate at the higher levels of the hierarchy, focusing on optimisation and innovation as a matter of course. Thanks for the thought-provoking piece! ??
Chief Product & Technology Officer
3 周Great to see you publish Simon and interesting to see where you landed on the relationship between levels 3 and 4. I think your commentary around the impact of the business life stage is really insightful here.