Say you’re aiming for outcome-based product teams that write and operate software. Maybe you hire for roles in these teams like Software Developer, Product Owner, Designer, Tester. How do you define each role?
We usually ask, what does each person do?
A typical job description includes: what does the person do? What are they responsible for?
A product owner, um, grooms the backlog — with the team, that is. They are responsible for the delivery of features — no wait, the whole team is responsible for that.
A tester tests the software. In pairs, yeah. They are responsible for finding problems before release. (Along with all the devs?)
A software developer implements features in the code. Also they participate in testing, backlog grooming, writing user stories. They are responsible for writing correct, secure code, performant, accessible, observable, fully tested, autoscaling, continuously delivered, appealing, profitable — oh, let’s just say “quality,” that covers it all — high-quality code and supporting it in production.
Somehow this doesn’t express the team-ownership, outcome-based product orientation we’re going for. It also doesn’t capture the essence of the work.
If we want outcomes, why focus on activities?
Maybe defining roles by activity doesn’t lead to outcome. Maybe defining roles by responsibility doesn’t lead to shared ownership. How else could we define them?
Well, building software is knowledge work.
What does each person know?
A product owner knows why each feature is valuable to the business, and how to measure that. They know what the software does and how it fits into the larger business sustem.
A tester knows what the product does, and where to check for whether it really does, and how to recognize value drains like a glitchy UI.
A software developer knows how the system works, and how to troubleshoot it. And they how we want it to work, and can put that knowledge into code. Each software developer knows how to use the programming language and runtime. Each person knows varying amounts about infrastructure, delivery pipelines, security usability, tracing, monitoring, scaling, accessibility, and the other -ilities.
Everyone on the team has a shared understanding of how the system works and how it fits in with the larger business. Areas of knowledge are not evenly distributed. Every person contributes their knowledge to the team, and all that knowledge goes into the product.
Of course no one starts out knowing all about the system. And no one ever knows everything about the business or the technology; the world is changing and there’s always more. So it’s more like, “what does each person increasingly know?”
Then we can derive activities!
How do they increase and contribute that knowledge?
How does each person contribute their knowledge? And how do they increase it?
A product owner spends time with stakeholders and customers. They learn what is important and why. They contribute this knowledge to the backlog grooming and to user story creation. When a developer has a question like “Why do we collect this sensitive data anyway?” the product owner knows who to ask, thereby increasing their knowledge and contributing it. When presenting forecasts to the business, they take responsibility that the plans contain the whole team’s knowledge.
The tester spends time poking at the product, getting to know it intimately. They also look at customer complaints, and talk to customers to find out how they use the product. Then they contribute this knowledge by pointing out places where an improvement can make a big difference. The delivered software reflects the tester’s knowledge of its use.
A software developer learns how the system works by reading code, by troubleshooting, and by experimenting. They contribute their knowledge directly to the software by programming, automating checks, and improving tools like the delivery pipeline. They contribute their knowledge to the team in pairing and helping each other, by writing user stories, by speaking up in backlog grooming, and in retrospectives. In code review, they take responsibility that the code reflects their knowledge.
Every developer knows how the system works overall, but no one person knows every aspect deeply. That’s why we have a team! Someone knows the delivery pipeline intimately, and keeps up with advances in delivery in the industry. Someone is extra security-conscious and keeps up with the latest vulnerability reports on their frameworks and runtimes. Someone is the go-to for performance questions, and if they don’t know yet, they’ll find out. (This is how expertise happens.) Developers increase their knowledge through deliberate learning and practice in the code, and they contribute their knowledge to the software by typing and to the whole team in dialogue.
When we start with areas of knowledge, we can notice activities and responsibilities. We can get to “what does each person do?” without stomping all over collective ownership of outcomes.
Define roles by the knowledge we contribute and seek.
When we recognize the core contribution of each team member as increasing knowledge, we respect learning and we respect time spent sharing that knowledge.
Product development is knowledge work, not factory work. If you want outcomes, don’t measure activity. If you want collaboration, don’t assign territory.
What does each person on your team increasingly know?