About me: I'm an unrepentant generalist finding my way in a world of specialists. I started this blog to review books, but I now talk about topics ranging from management to cognition to social software.
email me if you have any questions or comments.
Using WordPress
2.2
(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.
Previous: The Humane Interface, by Jef Raskin | Next: Why Howard Dean should leave the race
[…] Part of the issue is the unwillingness of management to give up control to their subordinates. Even when they do give up control, they often restrict behavior with processes and SOPs to such an extent that the subordinates have no freedom of action. There’s some good reasons for that - the processes are often put in place to prevent bad things from happening to the company. However, by not giving the employee any freedom of action, the company is also preventing its employees from contributing in new and unforeseen ways. In other words, it’s a balance between “doing no harm” to the company, and the risk/reward of giving employees control. […]
[…] Rules are merely the codification of a good idea, as Shirky observes about business processes. A rule was a solution for a given time and place. But when we treat that rule as an absolute and obey it unthinkingly, we forget those localized caveats and what made it appropriate in that situation. In Carse’s terminology, when we take judgment and fossilize it into an absolute rule, we are changing things from an infinite game to a finite game. […]
[…] I perked up when I heard that. It ties in perfectly with Clay Shirky’s observation that “Process is an embedded reaction to prior stupidity”. In fact, I’ll quote more from Shirky’s article to make the point: “We need a process to ensure that the client does not get half-finished design sketches” is code for “Greg fucked up.” The problem, of course, is that much of this process nevertheless gets put in place, meaning that an organization slowly forms around avoiding the dumbest behaviors of its mediocre employees, resulting in layers of gunk that keep its best employees from doing interesting work, because they too have to sign The Form Designed to Keep You From Doing The Stupid Thing That One Guy Did Three Years Ago. […]
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.
[…] his work. Several early posts on this blog were commentary on his articles covering topics such as process and situated software. As a faculty member of the ITP program at NYU, he writes incisively about […]
[…] was recently brought to my attention after reading an article by Clay Shirky, previously mentioned in this blog. As usual, I agree with much of what Shirky has to say. But apparently, he ignited quite a […]
[…] idea above that it is the process that is important, not the end result. You may recall that I am scornful at best of process in the workplace, preferring to put my trust in the resourcefulness of people. So how can I support this idea of […]