Plug in to LeadDev  ## Metadata - Author: [[Saimon Sharif]] - Full Title: Plug in to LeadDev - Category: #articles - Document Note: --- tags: - #engineering-management - #prioritization - #productivity Author: Saimon Sharif Source: LeadDev Reference: https://leaddev.com/process/building-prioritization-framework date created: 2025-08-22 00:00 --- # Title: Building a Pragmatic Prioritization Framework for Engineering Teams ## Table of Contents: - [📌 References](#-references) - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references-1) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - LeadDev article: “Building a prioritization framework” by Saimon Sharif. ## 📝 Summary: The article argues that effective prioritization for engineering managers hinges on three pillars: doing pre-work to build credibility and intuition, choosing a pragmatic and familiar framework (Eisenhower Matrix, Rocks–Pebbles–Sand, or RICE), and setting/managing expectations across stakeholders. It emphasizes that capacity is always constrained, so prioritization is inherently uncomfortable but can be made less painful with shared language, transparent trade-offs, and short-term mitigations when high-value work is deferred. Key lines: - “If everything is a priority then nothing is a priority.” - “Effective prioritization requires doing the pre-work to obtain credibility and intuition; choosing a pragmatic framework; and handling expectations.” ## 📖 Main Content: The piece is a practical guide for engineering leaders facing timeboxed planning cycles (e.g., quarterly). It first establishes the necessity of pre-work: credibility (trust in your decisions) and intuition (deep context on team and org goals). With those foundations, the article recommends adopting a known, shareable framework to avoid meta-debates about process. It then details three frameworks: - Eisenhower Matrix: simple four-quadrant approach; may produce an overfull “important and urgent” bucket. - Rocks–Pebbles–Sand: shared language for time-budgeting; good for planning discussions. - RICE (Reach, Impact, Confidence, Effort): metric-driven, best when projects are numerous and quantifiable. Finally, it covers expectation management: anticipate contention around cutlines, engage respectfully with differing views, and provide near-term workarounds paired with longer-term plans (e.g., pointing to a standard Redis archetype when self-service automation can’t fit this quarter). Personal reflections and connections: - These practices mirror open-source triage and roadmap processes, where trust, context, and transparent criteria are vital. The recommendation to prefer familiar frameworks aligns with community norms and reduces cognitive overhead. - The layered approach—broad filter (Eisenhower), discussion language (RPS), quantitative tie-breaker (RICE)—maps well to product/engineering cross-functional planning. ### 🗒️ Notes - Why prioritization matters - Scarcity: “There will always be more projects than… capacity and time.” - Anti-pattern: If everything is priority, nothing is. - Scope: Applies to quarterly plans, feature sets, or sprint tickets. - Pre-work: Setting the stage - Credibility - Trust in decision-making; especially crucial when new to org/role. - Low credibility → skepticism, “tedious demands for more data.” - Build via healthy relationships: across, down, and up. - Prioritization repeats; credibility compounds over quarters. - Intuition - Inward-facing understanding of team problems and org goals. - Guides which reasonable projects to prefer now vs later. - Compensate with research when intuition is low: - Qualitative: interviews with engineering teams. - Quantitative: observability/metrics. - High intuition reduces necessary research overhead. - Choosing a pragmatic framework - Prefer existing/familiar frameworks to avoid process debates. - Three recommended options: - Eisenhower Matrix - Four quadrants: important/urgent combos. - Risk: “important and urgent” bucket overflows; refine further. - Rocks–Pebbles–Sand (RPS) - Shared language; sparks discussion. - Rocks = high-impact, long-running; pebbles = smaller projects; sand = tasks. - Example: automated deployments (rock) vs simple dependency bump (sand). - RICE - Reach, Impact, Confidence, Effort; best with many projects and measurable inputs. - Requires defining metrics; produces scores for stack-ranking and cutlines. - Setting and managing expectations - Anticipate discomfort and strong reactions at cutlines. - Make it explicit: not all projects will be prioritized; disagreement is okay if respectful. - Leaders must understand teammates’ reasons; feasibility may still block. - Offer short-term mitigations + long-term plan: - Example: point to archetypal Redis cluster/docs now; defer self-service creation to next quarter. - Looking forward - Skill improves with practice; alignment reduces pain though planning is rarely “pleasant.” ## 📖 References: - Eisenhower Matrix explainer (general background): The framework divides tasks by urgency and importance and is often attributed to Dwight D. Eisenhower. - RICE framework (general background): Popularized by Intercom and product management communities. - Rocks–Pebbles–Sand metaphor: Time management analogy attributed to Stephen Covey’s teachings. ## 🗣️ Paraphrase: 1) Original idea: “If everything is a priority then nothing is a priority… It’s important to recognize there will always be more projects than capacity.” - Paraphrase: Because demand consistently outstrips engineering bandwidth, you must accept that not all work can be treated as urgent or important. Calling everything a priority dilutes focus and makes meaningful progress impossible. 2) Original idea: “Choose a framework your organization already knows… otherwise you’ll spend time litigating the framework rather than doing the hard work.” - Paraphrase: Favor a familiar prioritization method to avoid meta-arguments about process. The goal is to direct energy toward evaluating projects, not debating the tool used to rank them. ## 📰 Newsletter: This week in the Web Dev world: sharpen your roadmap chops. Prioritization season is upon us, and if your backlog looks like a yard sale, Saimon Sharif’s guide on pragmatic frameworks is your new best friend. TL;DR: build trust and context first, then pick a framework your team already understands—Eisenhower for simplicity, Rocks–Pebbles–Sand for planning language, and RICE when you need to math your way through too many good ideas. While you’re leveling up, check out learning paths for modern JS tooling, PHP 8.2 niceties, and accessibility testing tips to future-proof your sites. Community shout-outs to contributors shipping new Gutenberg patterns and to maintainers experimenting with RICE to triage plugin issues faster. New plugin watch: performance profiling helpers and a “content notes” tool to capture editorial feedback inline. Keep it friendly; keep it shippable; and remember: if everything’s P1, nothing is. Recommended reading: “Building a prioritization framework” on LeadDev. ## ✅ Action Items: A prompt tailored to your role and goals: - “Given this article on prioritization for engineering teams, explain how its recommendations can be translated to: - Open-source advocacy in WordPress (e.g., triaging issues, creating transparent cutlines in community roadmaps). - Contributor engagement (e.g., using Rocks–Pebbles–Sand to scope first-contribution issues vs mentorship ‘rocks’; employing RICE to rank Docs, Core, and Community tasks). - Summary: Prioritizing projects for engineering teams is crucial for engineering managers during key planning periods. This article provides frameworks and strategies to help with effective prioritization. The author emphasizes the importance of credibility and intuition in making decisions and suggests doing pre-work to build these attributes within the organization. The article also highlights three prioritization frameworks: the Eisenhower Matrix, Rocks Pebbles Sand, and RICE. Additionally, the author discusses the need to set and manage expectations during the prioritization process to ensure buy-in and address potential conflicts. - URL: https://leaddev.com/process/building-prioritization-framework You have **0** further articles remaining this month. [Join LeadDev.com for free](https://leaddev.com/register?s=dw) to read unlimited articles. During key planning periods, it’s important for engineering managers to ruthlessly prioritize projects for their teams. Here are some frameworks to help you get there. 2023 Conferences & Events Events  ##### 2023 Calendar - Join us in San Francisco and Berlin this year Get unparalleled access to industry leaders. Learn from diverse voices in tech. Develop your skills as an engineering leader. As [engineering leaders](https://leaddev.com/personal-development/three-key-skills-hone-moving-developer-engineering-leader), one of the highest leverage activities we can perform is helping our teams, colleagues, and organization [effectively prioritize](https://leaddev.com/reporting-metrics/communicating-engineering-priorities-your-ceo). In this context, prioritization refers to taking a set of actions – requests, projects, and other day-to-day activities – and determining their importance and urgency relative to each other over a given time period of time. It’s important to recognize that there will always be more projects than there is engineering capacity and time, and if *everything* is a priority then *nothing* is a priority. Given these two conflicting statements, prioritization can often feel impossible. However, we can prioritize effectively and with less toil by: * Doing the pre-work required to set the stage for prioritization * Choosing a pragmatic prioritization framework * Setting and managing expectations throughout the process In this article, I will use the example of prioritizing a team’s roadmap for a quarter where there are many stakeholders involved. We will assume any prioritization is part of a strictly timeboxed planning period, but these concepts can apply within other situations, such as prioritizing features for a given project, or prioritization across tickets within a sprint. ### Setting the stage It’s important to define the pre-work necessary for prioritization. This helps build credibility both within our organization and intuition about our organization. Developing these attributes requires longer than our assigned planning period, and requires us to take action ahead of time. #### Credibility Credibility comes when others have [trust about our decision-making](https://leaddev.com/building-happy-teams/three-strategies-building-trust-your-engineering-teams) capabilities. For leaders new to an organization or their role, this is especially precarious. Most of their colleagues are unlikely to have a good mental model or intuition about their abilities. With low credibility, our choices will likely be met with more skepticism, as manifested through pointed questions, or tedious demands for more data. Of course, a certain level of skepticism is healthy, but low credibility may lead to unproductive interrogation. It is possible to prioritize and plan without credibility, but it will be more [difficult to get buy-in for our choices](https://leaddev.com/process/how-get-leadership-buy-your-tech-strategy). Regardless, credibility is an attribute we can obtain through healthy relationships with colleagues, our direct teams, managers, and skip-level managers. A proxy for credibility may be how effective we are at managing across, managing down, and [managing above](https://leaddev.com/personal-development/getting-best-your-team-effectively-managing-upwards). A silver lining here is that prioritization is a repeated exercise. There is always an opportunity to be more effective in future quarters by investing in these relationships. #### Intuition In the way that credibility is outward facing, intuition is inward facing. As leaders, we need to acknowledge how deeply we understand our team’s problems and our organization’s goals. This context is important to help us determine what to prioritize and when. Without this intuition, we are likely missing the context necessary to make the right decisions. For example, standardizing deployments across services and adding observability tooling may both be reasonable projects on our team’s roadmap. If we know that the wider engineering team is having difficulty debugging during production incidents, we would prioritize adding observability tooling over standardizing deployments. If we are low on intuition, we will need to compensate with a mix of qualitative and quantitative research. Using an [internal platform team](https://leaddev.com/process/platform-engineering-engineering-managers) as an example, qualitative research can include activities like interviewing the engineering team about their needs, whereas quantitative research can include diving into metrics through specific observability tooling. Of course, even with intuition, we should do some research – the main factor is how much is required. With low intuition, we will likely need to devote time to extensive research. With high intuition, we can save time by aggressively limiting the amount of research performed. ### Choosing a pragmatic framework Of the many prioritization frameworks available, I recommend choosing one your organization has already adopted or is most familiar with. Unless the framework is truly untenable, there is likely little value-add in adopting a new one. Adopting a new framework will likely add additional friction to the prioritization process by increasing the possibility that you will spend time litigating the framework itself, versus doing the hard work necessary to prioritize projects. If your organization doesn’t have an applicable framework, there are three that I’ve had success with in the past: the [Eisenhower Matrix](https://asana.com/resources/eisenhower-matrix); [Rocks, Pebbles, Sand](https://longform.asmartbear.com/rocks-pebbles-sand/); and [RICE (Reach, Impact, Confidence, Effort)](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/). All three frameworks are relatively well-known and have [readily available easily-shareable high-quality written and video explanations](https://www.youtube.com/playlist?list=PLj-QjMUfWLvnm8Vr8qVxx9JVU8HYk3Dyf). In general, I would recommend choosing a framework that’s easy for you to explain and get buy-in for. At least initially, there is little value in rolling your own prioritization framework – it’s easier to borrow explanations and guidelines from existing ones. If desired, in later quarters, you can always tweak the framework to meet your team’s needs. [](https://leaddev.com/sites/default/files/2023-07/EisenhowerMatrixTemplate__LDMO__.pdf) Of the three frameworks, the [Eisenhower Matrix](https://asana.com/resources/eisenhower-matrix) (above, [or download it for yourself](https://leaddev.com/sites/default/files/2023-07/EisenhowerMatrixTemplate__LDMO__.pdf)) is the easiest to explain and the most intuitive. Your team may already be following it intuitively. It involves dividing tasks along four quadrants – important and urgent; important and not urgent; not important and urgent; and not important and not urgent. Unfortunately, the important and urgent bucket may become too full to truly prioritize. In this case, we can use one of the two other frameworks to further refine this bucket. The [Rocks, Pebbles, Sand](https://longform.asmartbear.com/rocks-pebbles-sand/) framework provides a more granular shared language within a team, and is good for generating discussions. In this framework, ‘rocks’ refers to longer-running projects with high impact, ‘pebbles’ to smaller projects, and ‘sand’ to small tasks. For example, adding automated deployments to a service is likely a ‘rock’ whereas upgrading a simple dependency is ‘sand’. [RICE (Reach, Impact, Confidence, Effort)](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) is the most complex of the three frameworks. I would recommend exposing your team to the core concepts asynchronously, and then aligning synchronously within a meeting. RICE excels when there are many projects, and each has obtainable metrics. Note that you will need to spend time defining the metric. The resulting score from RICE makes it easier to stack-rank projects and develop an appropriate cutline for prioritization. ### Setting and managing expectations Prioritization is likely to feel uncomfortable for you, your team, and your organization. Even in mature organizations with experienced colleagues, there is always a possibility that there will be a strong reaction if a project falls below a cutline or is deprioritized until a later quarter. Therefore, during any prioritization exercise, it is important for us to set and manage expectations. That is, all parties involved should understand that their project may not get prioritized; the process itself may be contentious; and teammates may (respectfully) disagree with the plan. As leaders, it is our responsibility to understand why a teammate may feel strongly about a project, even if we don’t agree with their reasoning. Of course, their reasoning may be sound, but may not be feasible given other constraints on time and resources. Ideally, we are able to provide short-term solutions for any blockers alongside a plan for the long-term. For example, if a Platform team has a request for self-service Redis cluster creation, but is unable to prioritize it for the quarter, they can point to an existing archetypal Redis cluster and documentation for a short-term solution, while deferring truly self-service functionality until the next quarter. ### Looking forward Effective prioritization requires doing the pre-work to obtain credibility and intuition; choosing a pragmatic framework; and handling expectations. Although it may feel uncomfortable in the moment, prioritization is a skill we can all improve. At the same time, there are benefits to bringing our teams and organizations along on this journey. Prioritization and planning are unlikely to ever be pleasant, but with alignment, we can certainly make it less painful., Plug in to LeadDev, Saimon Sharif, 01h5mfvm8x07d7cejhdzx3cr2z.