Clay Shirky on Process

(written 9/25/03) I’ve been starting to read more blogs recently, including VentureBlog, Corante and that of my friend DocBug, and I figure it’s time for me to start posting thoughts on the web again. We’ll see how long this lasts.

The post in particular that inspired me to post was over at Corante, by Clay Shirky (who wrote a really great article on the perils of grouphood that introduced me to corante in the first place). In this article, Shirky makes the claim “Process is an embedded reaction to prior stupidity”.

I’ve been thinking about process recently, as I’ve gone from working at a freewheeling startup to working at a larger, established company with a process for everything. Every decision is accompanied by reams and reams of paper. We even had to be trained on the processes so that we could understand what was going on. It’s crazy.

In light of that, I like Shirky’s statement a lot. It’s clear that many of the processes that have been put in place are to correct mistakes that were made in the past. It’s a way of institutionalizing knowledge gained. And that’s a good thing. But when the processes ossify and get in the way of the main objective, which is to build great products, then it seems like more reflection is necessary. In other words, when the process becomes the end, rather than the means, it’s time to re-evaluate the process.

I’d even extend Shirky’s statement further. Process is a way of covering your ass as a manager. If you go “by the book”, then you can’t be criticized, even if the book tells you to do something patently stupid. As people used to say, “You’ll never get fired for buying Microsoft” (or IBM before that).

As in all things, there has to be a balance. Process is a good guide to the past, to what has come before. But it should not limit what can be done in the future.

9 thoughts on “Clay Shirky on Process

  1. Take a quick read through the (Joel recommended) book “Slack”. The author makes an interesting observation about process: the hard part is not covered by the process.

    For example, to fix a bug:
    a) create a branch
    b) create a test
    c) when the work lasts more than 4 hours, write a spec
    d) fix the code
    e) checkin and test

    Obviously, the real work is in b & d and maybe c, but the process doesn’t help you do that. The process is helping with the easy things.

Leave a Reply to Dion Dock Cancel reply

Your email address will not be published.