Deciding which problems to focus on requires a product mindset. The DevEx team should get clear on what their role is in helping the company achieve its goals, then consider the areas of friction as well as the estimated effort in solving those problems, before creating a roadmap.
Thankfully, product prioritization is a well-covered topic, and DevEx teams can rely on what external-facing product teams have learned (e.g., Lenny Rachitsky is a great resource).
This chapter will offer questions that DevEx teams can use to inform their planning. These questions are broken into three areas: the company’s goals, the impact of each problem, and the effort to solve each problem.
Is the company experiencing existential issues? Will Larson says this is the first place to look for work that matters: “Running out of money, like my experience at Digg, can be the most obvious issue, but not every existential issue is financial, like Twitter’s fail whale stability challenges or adapting to the shifts caused by the Covid-19 pandemic. If something dire is happening at your company, then that’s the place to be engaged. Nothing else will matter if it doesn’t get addressed.” If there are no existing existential issues, we can continue on to the next questions.
What problems are top-of-mind for the VPs and CTO? Understand what problems are top-of-mind for executives. Use that knowledge as a lens for recognizing the projects that would contribute to those business needs.
How important is it to developers that this problem should be prioritized? During the data gathering phase, ask developers to rank the priority of the areas they’d most like to see improved. Just because an area is causing a lot of friction doesn’t mean it is important to solve. Similarly, an area that does cause a lot of friction but is experienced every day, could be important to solve.
“You’re not necessarily looking for the obvious pain points, but rather the pebble in their shoe. A lot of times, engineers have been at a place for long enough where they’ve developed workarounds or become used to problems. It’s become a known experience. So we have to look at their workflow to see what the pebbles are and then remove them.” – Michael Galloway, Platform Leader at Doma (interview)
Is the problem isolated to a specific team or systemic across the organization? DevEx teams can think about their scope as being split into two categories: things they can change first and then influence, and things they can only influence.
Which developer persona do we need to serve? If there are engineering teams focused on mission-critical projects, it may be worth prioritizing the issues experienced by those groups first. (To learn how Twitter considers personas as part of their DevEx prioritization, listen to this interview.)
What is the cost of the problem? We’ve seen teams take different approaches to calculating the cost:
How early are we (the DevEx team)? Teams getting started should look for quick wins, ideally projects that have mid- to high impact and are relatively easy to complete.
What do we believe will solve these problems, and how much work is required to build the solutions? Develop hypotheses around what the team believes will solve the problem. (These ideas will likely emerge in the data gathering stage, where the team uses surveys or interviews to understand the friction developers are experiencing.) Estimate the effort required to solve the problem by talking with the people who will be implementing it.
What level of ongoing work will this problem require moving forward? An introduction of a new tool will likely require support and maintenance. If the investment is in a process, like documentation, a team may consider whether they need to continue coaching teams on how to write or find documentation moving forward. Or technical debt: is the problem specific to an area of the codebase and fixable within a time period, or should the DevEx team instead focus on preventing high interest tech debt longer-term?
Do we currently have the capacity to solve this problem? How much time does the team spend maintaining projects or handling support or feature requests? At a certain stage, DevEx teams may split ‘support work’ and ‘strategic bets’ into two separate teams.
Borrowing a framework from Lenny Rachitsky (below), DevEx teams can take ideas and rate them across two attributes: estimated impact and estimated effort. Discuss and make decisions as a team.