Have you ever watched those shows on the Discovery channel (or similar) where the huge construction project goes a bit wrong? If it were more mainstream programming the story would pretty quickly stop being about the stuff and start being about the people, but since it is intended for 14-year old boys of every age these programmes don't quite go down that route. Big yellow machines, yum! But they do always have that drama to them. Drama comes form conflict and in these shows the conflict is between what the plan says should happen and the conditions in the world. A smooth and straightforward project would be less than gripping.
There are lots of those, but they wouldn't make great television. I find that many of these shows still don't make especially great television anyway because what actually happens is that, for example, a smooth technocrat (often German, the best sort) arrives, points out a few alternatives, gets everything back on track and off we go to a successful delivery. That's how it mostly is in the grown-up world of proper stuff. Risks materialise as issues (as it is expected they will, from time to time) and are dealt with in a calm and orderly way. There's the occasional stopppage, the odd bout of overtime, the best crane driver in the world has to be lured out of retirement for this one last job or whatever it may be. But there's no food fight. Food fight? Bear with me.
Scott Berkun has an essay out called "
Ugly Teams Win", a part of the forthcoming
Beautiful Teams. He presents an...interesting model:
[...] when things get tough, it's the ugly teams that win. People from ugly teams expect things to go wrong and show up anyway.
Well. He passes through some interesting observations about the, what shall we say?
challenging personalities of several stellar individuals in several fields. You might be very happy to have a Picasso in your house, but to have had Picasso himself would be a different matter. Fine. Of course, a gang of stellar performers is a very different thing from a well-performing team.
However, Berkun's point is well made that the best people to have on your project for the good of the project might not appear to be the best people generally, in all sorts of ways. Building effective teams is a tricky business. He goes further, though:
The only use of beauty applied to teams that makes sense is the Japanese concept of wabi-sabi. Roughly, wabi-sabi means there is a special beauty found in things that have been used.
I'm not sure that it does, although things that have been used often end up
wabi-sabi. Here's
a description of wabi-sabi as I've come to understand it
Wabi refers to that which is humble, simple, normal, and healthy, while sabi refers to elegant detachment and the rustic maturity that comes to something as it grows old. It is seen in the quiet loneliness of a garden in which the stones have become covered with moss or an old twig fence that seems to grow naturally from the ground. In the tearoom it is seen in the rusty tea kettle (sabi literally means rusty). The total effect of wabi and sabi is not gloominess or shabbiness, however, but one of peace and tranquillity
In summary "
wabi-sabi refers to the delicate balance between the pleasure we get from things and the pleasure we get from freedom from things"
One interesting aspect of this is that things made from natural materials (wood, stone, leather) may acquire charm with wear, but things made form synthetic materials seem not to. Objects can become
wabi-sabi through use, wear, or the simple passage of time and the natural processes that they take part in. Berkun wants that to apply to teams:
In this sense, the ugly teams I described at the beginning of this chapter, the underdog, the misfit, represent the wabi-sabi teams
That seems like a huge leap to me, especially when we find out what he means for a team to be
used. Here's how he describes the early days of a project, the "Channels" functionality of IE 4:
The deals we made forced legal contracts into the hands of the development team: the use of data [...] had many restrictions and we had to follow them, despite the fact that few doing the design work had seen them before they were signed. Like the day the Titanic set sail with thousands of defective rivets, our fate was sealed well before the screaming began. Despite months of work, the [...] team failed to deliver. The demos were embarrassing. The answers to basic questions were worse.
"Our fate was sealed well before the screaming began" Oooh-kay. And this is the steady-state:
somewhere in our fourth reorg, under our third general manager and with our fifth project manager for Channels, the gallows humor began. It is here that the seeds of team wabi-sabi are sown. Pushed so far beyond what any of us expected, our sense of humor shifted into black-death Beckett mode. It began when we were facing yet another ridiculous, idiotic, self-destructive decision where all options were comically bad. "Feel the love," someone would say.
At least one of Berkun and I have completely and utterly failed to understand what wabi-sabi means.
But that's the least of the issues I have with this. It looks to me as if this team is not being used in the way that an old shoe was used (and so gained its comfort, charm, personality and identity). This team is being
abused. Here's how they ended up:
Late in the project, I became the sixth, and last, program manager for Channels. My job was to get something out quickly for the final beta release, and do what damage control I could before it went out the door in the final release. When we pulled it off and found a mostly positive response from the world, we had the craziest ship party I'd ever seen. It wasn't the champagne, or the venue, or even how many people showed up. It was how little of the many tables of food was eaten: in just a few minutes, most of it had been lovingly thrown at teammates and managers.
And there's the food-fight. Don't be distracted by the hysterical high-jinks (as bad a sign as they are). Note that they've had six programme managers by this point. The end-point of the project is described in terms of damage control. Does that sound like the
wabi-sabi of the moss-covered stone lantern in the quiet garden? Does it in fact sound like an in any way attractive or desirable outcome? Berkun certainly seems to want to call this a success. He says "The few who remained to work on Internet Explorer 5.0 had a special bond". No doubt they did, no doubt they did.
Here's where this story starts to turn my stomach a little. You see, after going through this dreadful experience "the few that remained" went on to make "Internet Explorer 5.0 [...] the best project team I'd ever work on, and one of the best software releases in Microsoft's history" Maybe so. But at what cost? The majority that didn't remain (it's hard not to imagine them being considered washouts, dropouts, failures), how did they feel about being placed in this outrageous position on IE4? And what are we to infer about teams toughing it out through pre-doomed projects?
One of the few cogent points to have emerged form the recent spasm of interest in so-called Software Craftsmanship is the idea that
a "craftsman" has a line that they will not cross, things that they will not do. I tend to agree. I think that the industry would be in globally better shape if more people were prepared to locally say "no" to destructive madness of, well, of exactly the kind reported here for IE4 Channels. I don't consider the members of that team heroic for having made it through and bonded and all that stuff. Well, certainly not "the few". I'm inferring that some folks gave up on this project, walked away from the screaming and got on with something less harmful to themselves. Those are the folks I want to celebrate. And at every scale.
I'm very disturbed that a story such as this one is going to make it into a book about "beautiful teams", even if the point of it is supposed to be the subsequent success of the IE 5 team after their traumatic bonding experience.
This story celebrates failure. And it celebrates a particularly seductive kind of failure, one with which the IT industry is riddled. It celebrates a macho bullshit kind of failure that looks like success to stupid, evil people. It celebrates a kind of failure that too many programmers have come to (secretly) enjoy, and that too many businesses have come to expect that their programmers will (secretly) enjoy and therefore put up with.
In the grown-up world of proper stuff stupid, doomed, destructive projects get cancelled. And that is a successful outcome. We should do more of that.
