Matthew Butt

Roles vs Activities

Posted in programming by bnathyuw on 17 July 2013

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.

Tagged with:

3 Responses

Subscribe to comments with RSS.

  1. Goncalo said, on 17 July 2013 at 14:35

    I completely agree with the blameless post-mortem and sharing tasks like architecture but it gives way to inertia due to the lack of decision/direction.

    The same way people don’t want to be blamed they also don’t want to decide on one option as they don’t see an individual gain.

    “Consensus is an inaccurate measure of the effectiveness of a design”
    https://engineering.indeed.com/blog/2013/05/indeedeng-data-driven-product-design-slides-video/

    • bnathyuw said, on 17 July 2013 at 15:00

      I’m not sure I’m 100% clear about what you’re saying. Are you suggesting that when several people have responsibility for something, then it is very easy for no one to end up taking action?

      I have certainly seen that happen with fielding support requests, for example, and in that case we got around the problem with a rota. Now, I wonder whether a rota would be seen as returning to the notion of a role, but changing the incumbent every week, or whether it preserves the notion of an activity, and gives an indicator of who will do that activity at any time.

      Or have I misunderstood your point?

  2. Goncalo said, on 17 July 2013 at 15:20

    We can see several things happening.

    No one taking action or not trying to push enough, because they don’t feel they have ownership or the shared ownership doesn’t propagate for the rest of the company.

    Or the lower common denominator being adopted.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: