User Valued Work#
We often need to balance prioritization between user-facing work and internal or developer-facing work. It’s helpful to distinguish between these in conversations of prioritization and measuring success.
User-valued work#
This is work that directly affects users. It solves their pain and gives them a delightful experience. It includes work like the following:
Features that solve user pain
Features that delight users
Documentation that many people read and engage with
Directly answering user questions
Developer-valued work#
This is work that mostly developers see.
Paying down technical debt
Fixing CI
Writing well thought out technical documentation, even if it isn’t widely read
Discovering bugs or problems in the system
Writing design documents
Developing features behind a feature flag
Developing features but not releasing them or releasing them only very recently so that most users don’t have them yet
Benchmarking to track success and avoid regressions
Developer valued work is valuable, but only in that it makes us faster in delivering user-valued work to users.
Timing and Judgement#
We are judged as a team on user-valued work in the long term. Developer-valued work is good, but only in service of helping us to perform user-valued work more effectively. It’s great to do developer-valued work for a week or a month, but beyond that it comes into question.
In a professional context when upper-management judges the performance of a team, user-valued changes are typically what matter. This matches how the public judges our work.
Usually a well-functioning team will do both. Focusing entirely on user-focused work tends to be a sign that the team is under short-term pressure. Focusing entirely on developer-focused work for months at a time may be a sign that the team lacks a strong prioritization function.