No C in Teamwork

The best you should realistically expect from any career was put beautifully in Jerry Maguire by his mentor, Dickie Fox:

I don’t have all the answers. In life, to be honest, I’ve failed as much as I’ve succeeded. But I love my wife. I love my life. I wish you my kind of success.

To fail as much as you succeed. Quite stark when you put it like that. I think when I got into IT I’d really been expecting to succeed most of the time, and I don’t think that was unrealistic - I mean, I knew I’d have to fail sometimes, hopefully for reasons beyond my own control etc. And failure isn’t all bad - each one teaches us something, keeps us grounded, and that humility makes those successes all the more sweeter.

But, fair enough, fifty-fifty isn’t too bad. Being on a high half the time sounds OK.

If only the statistics suggested it was that good..

In fact, given figures quoted all over the web these days it would be entirely plausible for an IT individual to live out their entire working life and not see a project go live, work as per customer expectations, cost (roughly) what was predicted, adapt to change or be delivered (roughly) on time. The oft-quoted Standish Report consistently shows project success hovering around the one-quarter level, with the remaining 75% either failing outright or being what they call ‘challenged’ (i.e. not meeting qualitative expectations in one way or another).

It’s pretty sobering to think that every time you start a new project you have, statistically, only a one in four chance of succeeding.

Of course, success is a largely subjective concept, and just because your project doesn’t deliver to the customer, doesn’t make it a completely useless experience for you. Some of my most enjoyable times have been on death marches, where gallows humour and camaraderie were the only things that kept us sane.

But I’ve had many outright successes too, and if there’s one thing that marks out the difference between the wins and the loses, it’s teamwork. Not teamwork as in co-operation, collaboration, or consensus, which imply a group of equals, all good-naturedly listening and facilitating the crap out of each other, like Stepford wives at a bake sale. That’s not real teamwork - that’s magnolia coloured, half-arsed, wishy-washy, averageness.

You see there’s harmonious working together, which is great, and there’s success, which is also great. The big problem is that they aren’t always the same thing.

Let’s walk through some basics. When you are in a group, project team, or company, your goals are not your own. They are set externally to your collective. Your objective is to meet those goals, fully, and in the most efficient, elegant, way you can. Together. Ultimately, it doesn’t matter whether you agree with the goals, it only matters whether you achieve them. And I say ‘ultimately’ because, of course, initially, your input into the refinement of the goals is crucial. You’re not a robot, and if the goals stink, or are simply unachievable, then this needs to be known. You won’t have achieved your objective elegantly, efficiently and fully if you don’t contribute everything you can when you can. But once you have been heard, the team must take precedence. Otherwise your objectives become simply about you and your desire to make your views known.

The one exception to this is when you personally are in the box marked ‘accountable’ and, if it all fails horribly, you will look down to find the baby fast asleep in your arms, the buck stopped at your desk, and the red phone marked ‘CEO’ ringing. However, with accountability must come the scope to change any parameters that make you uncomfortable. If yours doesn’t, then buy a copy of Ed Yourdon’s Death March and either enjoy the ride or get out. Accountability without the authority to deliver against it is the classic sign of a megaproject.

Nobody would be happier than me if everybody could just agree and get on with it, but that’s the flaw in the c-word thinking - humans aren’t like that. We’re complex, political, aspirational and we each come with markedly different emotional histories. That’s a good thing, of course. But, from differences come disagreements, not consensus, and strong characters will display those differences longer and with a more insidious effect than others.

The arbiter of disagreement is management - the force that makes a team a team. Management is the inspiration, the focus, the sounding board and the direction, that points all eyes to the goal and away from the squabbles. So a team isn’t a collection of equals, it’s a pyramid of management. By that, I don’t mean it should be a hierarchy of egos and bureaucracy, just that each group within the group has to focus on how it contributes to the overall goals, and make timely decisions to continually move toward them.

In the early nineties, I worked for a well-known consultancy on a competitive bid for a major government project. I was a Unix sys-admin and C coder at the time, and a pretty good one, but rather more full of my own charms than perhaps was warranted. The Lead Architect was a guy called Geoff: madly eccentric, allergic to all natural fibres, and with two PhDs (or so rumour had it). Geoff also couldn’t code and had that annoying habit some people have of loitering around the back of your chair, watching you work, his nylon suit reflecting in the monitor glass.

The requirements for this bid were onerous to say the least. We had to build a search engine that would scour millions upon millions of unstructured data records and return matches within sub-second response times. Easy nowadays, but the hardware for this project was predefined, and not exactly buzzing with processing power. Geoff’s design spec was unconventional and made little sense and, being the kind of guy he was, he made a bit of a fist of his attempts to communicate it. I was sure we would fail, and I was sure we’d chase Geoff’s spec around in circles before we realised we were doomed, by which time it would be too late. Something had to be done to replace the spec, and soon.

And then a funny thing happened.

Two developers of a similar mind and I discussed the possibility of a revolt late one night. We weren’t keen to rebel without an alternative approach, so we walked through a few designs of our own. But, however we cut it, we could not construct a design that would guarantee success any more than Geoff’s would. So we decided, as a team, to build Geoff’s design faster than the plan said, to get us to the doomsday scenario sooner and hopefully with enough time to switch to something more appropriate.

We worked all-nighters and weekends for eight solid weeks. We harassed Geoff for details, got him to write pseudo-code, my fingers ached from the typing, but we built it all.

And it bloody well worked. Not just a bit, but magnificently. It beat all the non-functional requirements by miles. We did our demo to the potential client early and blew them away. Our nearest competitor in the bid couldn’t touch us, so we won the business hands down.

Geoff never knew that we came close to rebellion over his design, and thus we never actually had to apologise for doubting him (I still feel bad for that). What it taught me though, was that if you can’t beat someone’s idea, then you have to support it, no matter what you think of it, because you might be wrong.

About ten years ago, I found myself in Geoff’s shoes - proposing an approach, which on the surface at least seemed a bit unconventional. I’d researched plenty of alternatives, but because of where the company was financially and because of what it had in terms of capability and where it wanted to be aspirationally, nothing else quite fitted. I knew this idea would require some effort to get right, but it also represented an opportunity to steal a march on our competitors, so the effort would be worth it.

Unfortunately not everyone subscribed to the notion described above and we entered a bizarre cycle of proposal, grudging acceptance, passive resistance, confusion and communication, and very little progress. It was doubly sad because not only did the initiative largely fail, the company missed a magic moment to build a strategic future and break the pernicious cycle of quick-fix and support that had plagued it for years.

And yet during this time nobody would have questioned for a second the notion that they were team players.

There’s a hard lesson to learn in this. Individual agenda’s are driven by value. In chaotic organisations one or two individuals (the heroes) can appear to add a lot of value, especially if they maintain key relationships with the business. Any move to change this, however well-intentioned, is a threat to this, so teamwork naturally becomes about protecting this perceived value-add. Giving up that fight requires a leap of faith that any new proposal might just allow more value to be added. Co-operate, collaborate, and consensus are tools to maintain the old faith, not take the leap.

There are no easy answers, except to recognise that it’s not worth fighting c-thinking head on. Driving the decision from the business side is one option, as it uses the power of the hero relationship to make co-operation with the new way of thinking a measure of value-add. Illustrating the power of new concepts, via a pilot or proof of concept, is another as it highlights flaws in the hero’s value-add perception without explicitly having to say there are flaws - the possibility that heroism will lie elsewhere in future is often enough to broker a constructive conversation. A measured, gently-paced logical approach and buckets of patience though are sometimes the only choices.

As Dickie Fox also said:

Roll with the punches. Tomorrow is another day.

As a final thought, in the book Artful Making, Robert Austin and Lee Devin describe a concept that’s far more productive than teamwork. It’s called ‘Ensemble’. Used mostly in the theatrical world, it means a coming together of people to create something greater than the sum of the parts. Not enabling an average outcome, but a group dynamic that suspends or even sacrifices personal goals to explore the art of the possible. The realisation of a greater objective, made better by the input and experience of each member of the cast - but shaped and governed by the director.

I don’t know much about theatre, but I like that. That sounds like it has a better than fifty-fifty chance of being successful. If it works for artists, it should work for IT (creative discipline, fickle customer base). There is no C in teamwork, but perhaps there’s an E.