Roles vs Activities

At work, Gonçalo sent round a link to an article by Michael Lopp on management and engineers. Lots of discussion ensued, much of it fairly tangential.

This discussion got me thinking about the difference between roles and activities, and I’m going to sketch out these ideas here.

Roles

It is easy to talk about roles: a Project Manager does X, a Product Manager does Y; a Developer does φ, a Tester does χ, and Architect does ψ. This thinking encourages us to assign roles to people: to turn them into jobs.

Lopp talks about ownership, and certainly, if a role is assigned to a person, you know where to go to to get answers in that domain. If I have a Project Manager, I know who will give me updates on the progress of the project; if I have a Tester, I know who to ask to test a piece of functionality.

But it’s also about blame. If I have a Project Manager, then I know who to shout at if the project falls behind schedule; if I have a Tester, I know who to sack if a vulnerability is released that leaks personal data.

And I wonder whether the focus on individuals filling roles not only encourages this focus on blame, but remains attractive when a culture of blame persists.

Getting away from blame

At my work, when something goes horribly wrong, we carry out a blame-free post mortem. We establish the facts of the incident, acknowledge the aggravating factors, take note of the mitigating factors, and come up with a plan for the future. During this process we recognise that people did things, but don’t get hung up on criticising them for their actions; rather we try to understand why they acted in the way they did, and how we can make this better next time.

This approach differs radically from the traditional approach of declaring ‘heads will roll’, initiating a witch hunt, and ensuring that the persons responsible are at the very least made to feel thoroughly shitty, and quite possibly relieved of their duties.

In conducting a blame-free post mortem, we are not interested in roles and responsibilities, we are interested in actions and activities. It matters less who acted than what action was taken; not who failed to act, but what action would have helped.

Activities

Recover from incidents is smoother if we focus on activities rather than roles, actions rather than people; can this shift in emphasis help elsewhere? I think it can.

Again, where I work we don’t have Architects. This doesn’t mean we don’t do Architecture: we do it all the time. Our team whiteboards are decorated with particoloured diagrams of the systems we’re building. We treat Architecture as an activity, not as a role, and this means that many people are involved, understanding of the decisions is pervasive, assumptions are more likely to be challenged, and single points of failure are less likely to exist.

And what happens if we make a catastrophically bad architectural decision? Well, there is no one to point the finger at, no convenient repository for blame, as the decision was collective and consensual. Instead, we can recognise that the decision was poor, learn from that, and adapt and move on.

Conclusion

I have seen how a limited shift in focus from roles to activities can work well. I wonder whether a more comprehensive shift would have further advantages. This isn’t to suggest that everyone should be engaged in all activities all of the time, but rather that by introducing flexibility, collaboration and sharing, we might be able to move further away from a culture of blame.