| title | date | blogpost | author | category |
|---|---|---|---|---|
User Valued Work |
2022-08-24 |
true |
Matthew Rocklin |
engineering |
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.
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
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.
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.