You’re Not Managing a Team of Software Engineers, You’re Managing a Team of Writers

I once asked an engineer who I greatly admired, how he started building the system that he (successfully) submitted for his PhD. I’m not sure what I was expecting, but probably something about careful structural design, some deep thinking about architecture, maybe some blinding insight.

Instead, he said, “I started pulling on threads”, which really took me by surprise. It was such a casual admission that he had been finding the system rather than building from a detailed plan. But I also felt a recognition: it just sounded right. It matched how I had been building my own systems up to then, but not really admitting it. I made plans, sketched some architecture, and then started pulling on threads of ideas to begin to find out what the system wanted to be.

Writing Software Is, Well, Writing

Managing software projects is notoriously hard. The results are unpredictable, the problems are often understood in detail only by a very few, and the personalities can be strong and opinionated.

The job would be made easier, I think, if we admitted what we are really doing: managing a team of writers.

We write software: we use language to create a thing that has an existence from an idea, an abstraction.

The ideas are approximated as documents, sketches, conversations, white-board diagrams, wire-frames. We translate the ideas into a thing that has meaning, to us, and to the machine that dumbly runs it.

Anyone who’s tried writing a story will know how much goes into the translation of an idea (“a detective falls in love with a woman who he betrays in 1970’s San Francisco”), and the finished result. As we write the story, we pull on some creative source, our knowledge of language, and our skill and experience, to take the idea and build it, with all of the detail and implications that are revealed as we write.

Certainly some software is rote, in the some way that some writing is rote: the five hundredth episode of a cop show is pretty well understood before the writing takes place.

But the interesting stuff is not: it’s creative, uncertain, made up as we go along.

The Environment: It’s All Business

So we’re managing a team of writers.

Not only that, but we are usually managing in a business environment. Our creation is constrained by time and budget, and there are often competing (sometimes strongly competing) ideas about what we’re building, and, more crucially, why. The ideas we are translating into language are open to interpretation, and different groups (the CEO, Marketing, the customer) can have wildly different interpretations.

Not only that, but the stakes can be high: the survival of a company, the value of years of stock grants (sometimes measured in numbers that most of the world can only gasp at), the first (or last) shot at making it big, careers, jobs, futures.

We are managing a creative process which is by its nature unpredictable and personal, in an environment which craves certainty, predictability and consistency.

If we think of the software team as “engineers”, the uncertainty and constant variation feels like a central bug in the process, and a stressful one at that. If we think of a software team as “writers”, it’s clearer what’s going on, and our approaches make more sense.

Managing Software Creators as Writers: Some Implications

Guidance, Not Control