Three Prioritization Frameworks To Make The Most Impact On The Business

Problem

I prefer to build teams that are oriented towards what matters to the business. I try to recruit and foster a high-level business-oriented perspective so that individual contributors understand what they are working on and recognize what should be prioritized. I think that having empathy and awareness of what the business objectives are and how they connect to the work gives individuals the orientation they need to make game time decisions. Below I describe a few effective tools to ensure that every engineer within the organization is prioritizing what will be the most impactful for the business.

Actions taken

OKRs - objectives and key results I think the process of quarterly goal-setting is extremely important. By and large, teams should be taking on OKRs that ladder up in some way to business metrics. These objectives should be one level up from the initiatives and projects. Having goals and tracking those objectives week-over-week reminds the team of what they should be working on and why. This is especially true when it comes time to prioritize because then people have the context of what really matters. SLO - service-level objective Discuss and define a service-level objective that specifies the details of what your customer should expect from you. What are the different tiers of issues? What are the response times that are acceptable for those tiers? Think in terms of first response, resolution target, and performance standards. This objective is a useful tool for defining internal goals while also holding your team accountable to a certain standard. It elicits understanding of what matters to the business and to your customers, thus giving individuals the how and why to prioritizing issues. Bug Zero Policy This is a belief that if you are carrying a large number of bugs then you are weakening the quality and speed of your product. Higher quality means the ability to move more quickly, so when bugs are coming in - regardless of priority - you either resolve the bug or kill it in some way. This philosophy aggressively manages the bug count by prioritizing them above all other work. If you have a high degree of bugs coming in that are slowing you down, this is incentive to improve your velocity thereby improving your quality. The team, then, is working to try to improve the overall throughput to the business. While I don't necessarily advocate for this approach, I do appreciate the importance of maintaining quality and the need to spend time killing bugs.

Lessons learned

• When developing OKRs be careful not to aim too high. It is dangerous to take a goal that is too high up the business hierarchy. An example of this would be an objective that focuses on hitting the revenue targets. Instead, set a goal that influences revenue thus enabling the business to target acquisition activities to a specific group.
• Google's SRE workbook - which is wholly available online - is a great resource for site reliability engineering. In fact it has an entire chapter dedicated to implementing SLOs.
• I once worked at a company that had a whole team dedicated resolving technical issues in hopes that it would allow other teams to focus on new work and new features. It didn't work and led to some really bad dysfunctions. The tech issues team supported the whole burden of problems coming in, they didn't always know the best way to fix bugs, and the overall response time was poor. More so, the rest of the teams were blind to the support burden that their software was imposing on the business. They didn't know how their products were being used in the field, if they were being used as intended, or the level of their quality. Therefore, it disempowered the squads from owning their products. This was a poor attempt at removing technical problems rather than prioritizing and facing them head on.