Prioritization Techniques
As engineering leaders, we’re constantly bombarded with requests. New features, bug fixes, tech debt, platform improvements, meetings… the list feels endless. I’ve seen teams paralyzed by indecision, and brilliant engineers burn out trying to juggle too much. One team I worked with was simultaneously chasing three “urgent” fire drills while a critical, revenue-impacting feature stalled for weeks. They thought everything was important, and the result was delivering little of true value.
The truth is, not everything is important. Learning to prioritize – ruthlessly – is the single most impactful skill you can develop as an engineering manager. It's not about saying "no" all the time; it's about saying "yes" to the right things, and creating space for those things to truly shine.
This isn’t about adopting the latest productivity hack. It’s about building a mindset, a framework, and a repeatable process. Here's what I've learned over two decades leading engineering teams, and how you can apply it.
Beyond Urgent vs. Important: A Multi-Dimensional View
The Eisenhower Matrix (urgent/important) is a great starting point, but it’s often insufficient. While useful for initial triage, it quickly breaks down when everything feels urgent and important, a common scenario in fast-paced engineering environments. The matrix doesn’t account for the scale of effort or the potential risks involved. We need to layer in other dimensions. I've found the following framework helpful:
- Impact: How significantly will this deliver value to our users or the business? (High, Medium, Low)
- Effort: How much engineering time (and other resources) will it take? (High, Medium, Low)
- Risk: What's the probability of this failing or causing unforeseen problems? (High, Medium, Low)
- Dependencies: Does this block other critical work? (Yes/No)
Visualizing this as a simple table can be powerful. But the real value comes from forcing honest conversations. It’s easy to overestimate the impact of our pet projects, or underestimate the effort required.
The "nth" Most Important: A Scalable Approach
We often fall into the trap of treating everything as equally critical. But what if, instead, we acknowledged that some things are more important than others? Inspired by the principle that our attention is a finite resource – a concept articulated by Vilfredo Pareto – I've found success using a tiered prioritization system.
Think of it like this:
- Tier 1 (Top 10%): These are the absolute must-dos. They directly impact key business objectives, solve critical user problems, or unlock significant new opportunities. Protect these at all costs.
- Tier 2 (Next 20%): Important, but not critical. These contribute to long-term goals, improve quality of life, or address moderate pain points.
- Tier 3 (Remaining 70%): Nice-to-haves, improvements, and experiments. These can be tackled when capacity allows, or deprioritized if necessary.
This isn’t a rigid structure, but a guide for resource allocation. When faced with conflicting requests, this framework provides a clear rationale for making tough decisions. For example, a critical security patch would fall into Tier 1, while a minor UI refinement would likely be Tier 3. It also helps manage expectations – it’s okay to say “we’ll get to that eventually,” as long as you're transparent about where it falls on the priority list.
Beyond the List: The Human Side of Prioritization
Prioritization isn’t just about what should be done; it’s about who does it, and how it impacts their motivation.
- Transparency: Share the prioritization process with your team. Explain why certain things are being prioritized over others. This builds trust and encourages buy-in.
- Empowerment: Give engineers a voice in the prioritization process. They’re often closest to the technical details and can provide valuable insights.
- Tech Debt is Real: Don’t ignore technical debt. Allocating dedicated time to address it is a long-term investment that will improve velocity and reduce risk. Studies show that unaddressed tech debt can increase maintenance costs by up to 40% over time. Treat it as a first-class citizen in your prioritization process.
- Small Wins Matter: Even if you can’t tackle the biggest challenges right away, look for opportunities to deliver small, incremental improvements. These can boost morale and demonstrate progress.
RADically Incremental: The Power of "Good Enough"
We often fall into the trap of striving for perfection. But in most cases, “good enough” is sufficient. Inspired by the principles of Rapid Application Development (RAD), popularized by Steve McConnell in his work on software construction, focus on delivering value quickly and iterating based on feedback. Don’t get bogged down in over-engineering or polishing features that nobody will use.
This isn’t about lowering quality standards; it’s about being pragmatic and prioritizing speed to market. Launch a minimum viable product (MVP), gather feedback, and iterate. This allows you to validate your assumptions and avoid wasting time on features that don’t deliver value.
Prioritization is an ongoing process, not a one-time exercise. Regularly review your priorities, adapt to changing circumstances, and be willing to make tough decisions. It’s a skill that takes practice, but the rewards – increased productivity, improved morale, and a more focused team – are well worth the effort.
Key Takeaways:
- Multi-Dimensional Prioritization: Move beyond simple urgency and importance. Consider impact, effort, risk, and dependencies.
- Tiered Approach: Use a tiered system to clearly communicate priorities and manage expectations.
- Transparency & Empowerment: Involve your team in the prioritization process to build trust and buy-in.
- Embrace Iteration: Focus on delivering value quickly and iterating based on feedback.
This week, try implementing one small change to your prioritization process. Schedule a team meeting to review your current priorities using the Impact/Effort framework, and solicit input from your engineers. You might be surprised by what you learn.