Avoiding the dumbest behaviors of mediocre employees
by Volker Weber
While reading Clay Shirky's piece about Wikis, Grafitti, and Process, I came across this gem:
Process is an embedded reaction to prior stupidity. When I was CTO of a web design firm, I noticed in staff meetings that we only ever talked about process when we were avoiding talking about people. "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
I may add that processes are often designed by people who assume that everyone else is at least as dumb as they are themselves. :-)
Comments
I have to disagree. Implicit in Clay's statement and interpretation is the idea that only mediocre employees screw up. This is not true at all. Look at Microsoft. Nobody believes that Microsoft's employees are dumb. In fact, it is well known that their hiring process selects at least as much for raw creative intelligence than for specific skills -- and that's an across-the-board practice, not just for engineers. Bill Gates himself is certainly far from mediocre -- no matter how many bad things we want to say about him, we have to admit that the man is highly intelligent. And yet Microsoft, it's employees, and even Bill Gates have definitely screwed up on multiple occasions... and will continue to do so.
Much of the time, screw-ups are the not the result of just one person's mistake. As often as not, they are the result of a breakdown in communication between two or more intelligent people, each of whom has incomplete information, each of whom thinks they are doing the right thing, or who erroneously thinks the other person has done the necessary thing already.
I can give a very concrete example of a terrible screw-up by an ISP that could only have been corrected by an improved process. I ordered a fractional T1 from the ISP. It was provisioned by the phone company and configured by the ISP and brought into service under a one year contract. Six months later, I ordered an upgrade to a full T1, and in order to qualify for a special pricing deal I had to initiate a new one year contract. Can you guess what happened? Another six months passed, and suddenly the T1 was turned off, because the original contract expired. The person who authorized the disconnect order was doing her job. The person who had filed the new contract had done his job, too. Nobody had done the job of transferring the circuit from one contract to the other because communication had broken down between the sales, provisioning, and administration departments. There had been no clear definition of whose job it was to transfer circuits from one contract to another. Everybody thought someone else was responsible for taking care of it. The only solution to this would have been an improved process that assured that somebody took responsibility for the one step that was missing.
In addition to that, an organization of more than a few people simply can't assume that the same people will be doing all the same job for more than a brief time period, and they especially can't presume that the transition of information about responsibilities from one employee to the next on a particular job will always be perfect. An ongoing software development project that has made it to the oh... let's pick a number out of thin air ;-)... the 6.5 and 7.0 releases of its life cycle will have gone through at least three or four nearly complete turnovers of most areas of responsibility. Despite the fact that each particular group of employees taking on any one area of responsibility may consist entirely of people with outstanding abilities, it's inevitable that some vital information is going to be lost along the way. Even a well-defined development process or methodology can't fix this problem entirely; but the purpose of a process is to minimize the problems that will occur.
Richard, you are implying that I believe in two things:
1. Smart people don't make mistakes.
2. Processes are useless.
Both assumptions are wrong and I don't disagree with your statements.
However, I have seen exactly the situations that Clay describes. And you probably don't have to think very long to find some good examples of "the right thing" made impossible by processes.
How did it ever happen that people made their way through the continent to California? Through speed limits and traffic regulations? Do I assume they are useless?
i have to agree.
i work for a small telecom software company where we have more managers and directors for the number of employees, where 75% of the week is spent in endless meetings talking over and over about dumb shit (pardon) that's just a bunch of endlessly discussed details (such as "how many minutes should we take to assess problems before calling the client", now, this is somewhat of a valid question, unless you want to talk about it every single day over a period of 1 month).
we have a CTO (although i seriously question why a web design firm has such a position in the first place) too, he has 2 MIT PhDs, he's a cultured man, fun to work with, but the poor chap is clueless and disconnected from the reality of it all. and he makes a fair amount of money for typing up "pre-pre-deployment strategic attack plan" documents.
you'd think those poor fucks would've lost their jobs when the bubble burst.
(/rant)
Actually, Volker, it was Clay that I was disagreeing with. Sorry for not making that clear. Clay turns a good phrase, and I frequently find his writing to be on the mark, but here I think he's wrong. He's making a good point about Wikis, and yes I have seen situations where the "right thing" was made impossible by a process -- I've been in those situations on both sides, and I'll even admit to creating some processes that created the possibility that such situations could occur! -- but Clay generalized too much by saying that "an organization slowly forms around avoiding avoiding the dumbest behaviors of its mediocre employees, resulting in layers of gunk that keep its best employees from doing interesting work". He's implying that most (if not all) formal processes would be unnecessary if it weren't for those mediocre people, and I believe that he's wrong to discount other legitimate reasons that have nothing to do with mediocre people. So, unless he puts the word "sometimes" in front of it, I think that his statement that "Process is an embedded reaction to prior stupidity" lacks credibility and it would be harmful if managers took it seriously.
And as for California, these days it appears that they all made their way there to run for Governor ;-)
-rich
Our company recently got a tax assessment of a non-negligible amount , payable within 30 days. We called, wrote letters and finally got this assessment revoked to what it should have been at the start, zero. Now, a few weeks later we get another letter from the tax authorities - a payment request of about 300 EUR surcharge because of overdue/outstanding payment of that first assessment.
I call up the person handling our case.
- "No, you have got the wrong person, the letter "P" is now handled by Soandso". He tries to connect me to Soandso, without success.
- "Could you maybe help me?".
- "Well..., mmmhhh, ok. The surcharge/penalty is because you have not payed this tax."
- "Yes, but please check, we had it reduced to zero, why do we need to pay this fine?"
He checks his system and reads " tax has been assessed to X EUR,... and has then been reduced to 0... Yes, but you see, when the amount had been finally reduced to zero, you were already overdue, so therefore you have to pay the fine."
- "Don't you think, this is slightly comical: to have to pay a fine for a tax assessment which has been annulled?"
"This fine might seem absurd to you, ('skurril' was the word he used), but there is a logic to it"
"This IS absurd. So what can we do about it?"
"Well, you would need to write a formal letter to Soandso, asking for that fine to be annulled." ('Erlaßantrag stellen')
"Couldn't you do that straight away?"
"That's out of my hands, I don't deal anylonger with company names beginning with 'P'."
"Well, you mentioned that before. By the way, since when don't you do 'P's anymore?"
"Oh, mmmmhh, since yesterday."
Rather than more and improved processes, I often wish that employees would be encouraged to make "common sense" decisions.
Doesn't a formalised process try to define human interaction as if it was all one big machine with clear options (yes/no/else)?
Isn't more formality leading to even more bureaucracy and problematic exception handling?
How about improved visions and guidelines for our ever more fuzzy, groovey, sourceforgy, chatty, SiMSy, bloggy, wiki world?
There is another aspect to the whole story: "... talked about process when avoiding talking about people ...". This is an behavior I can wittness quite often. It is not about processes, it is about the lack of what I would call conflict culture. It seems to me a corporate no-no to put blame & glory where they belog to: to the people. Admittingly it's the high art of communication: separate people from problems (like: Paul screwed up and he is still a valuable member of the team). Once you get the habit to do honest post-mortem briefings (both for success and failure) like: insights gained (the good ones), lessons learned (the bad ones) your processes envolve around best practices...
Of course don't let "Organisationsabteilung" (org department) highjack your processes .
A gem, indeed. Worse than what Clay describes is a scenario that I have seen where a company resorts to technology rather than process when "Greg fucks up." Lacking the leadership or responsibility to enforce process, technology is beckoned. This further entrenches the anti-conflict culture, as Stephan described.
I know this will be seen as being politically incorrect, but I would love to see an organization where "honesty and openness" is the culture of the organization. Mistakes happen. Call them for what they are. All members of the organization make them. Future success depends upon members learning from the mistakes so that they are not repeated. If someone makes a mistake, publicize it so that others may learn from the experience. Don't beat the person to death. "Sam screwed up by doing this." Say it in clear simple language so that all understand. Move on! Organizations waste incredible amounts of money by "beating around the bush."
