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

We tend to react to these pressures by grasping for control. If we have “good management” — firm enough deadlines, detailed enough wireframes, daily checkins, monthly project reviews — then we can keep the whole thing together.

Control is not the right paradigm. The job is guidance, sometimes tight, sometimes loose. Sometimes the “writing” is flowing, sometimes it needs to coaxed and forced. The manager (a better word is “producer”) has to understand the creative process: what is needed? what does the work want?

Own the Goals

Your writers are deep in their code. That’s where you want them, and where they want to be. They are “pulling on threads”, discovering in language what needs to be built. The writing of the code requires that they, to some extent, lose sight of the purpose of the writing. Not because they don’t care, or because they are irresponsible, but because they have to be able to be open to where the writing takes them.

Your job is to hold the purpose of the team, the goals.

You own the goals so the team can be continually course-correcting towards them. Your holding the goals (today, this week, this month, this year), constantly communicating the goals, adjusting the work so it’s directed towards the goals, is a vital service to the team.

Tight Processes, Loosely Held

Your job is to balance loose and tight process. Deadlines are good. Deadlines at the expense of a brilliant burst of creativity aren’t. Brainstorming is good. Too much brainstorming moves away from the real work. A small team working with only a notional idea of a goal may produce terrific results. A large team without a clear destination will fail.

A well-designed process allows a writer the freedom to create by limiting their boundaries. An unduly “stiff” process chafes, and rubs against the organic business of creating.

Writers are Individuals

The act of translating a concept into language is not rational, linear, open to easy analysis. Writers know that some days it comes easy, and some days it feels like it’s gone forever.

Like writers, software creators have a massively broad range of skills, approaches and personalities. What they create is a reflection of who they are. There are structure-people, speed-freaks, intuitive idea generators, generalists, specialists, language pedants, brilliant mess makers and steady, reliable builders, among many others.

How they create is equally individual: some need a complete and rigorous architecture before they can bear to start. Some just need a keyboard. Some take a week doing apparently nothing before they suddenly spit out a completed work. Some work daily, predictable hours.

Some are motivated by money and stock options. Some by the beauty of what they can create. Some by the connection that comes from working intensely side by side with other brilliant people who share their craft.

Your job is to understand these creative, highly variable human beings and get them what they need to work well.

In particular, you need to fit the job to the writer. If you want something to go fast, find a speed-freak — a writer for whom an incredibly fast solution is a thing of beauty. If you want a strong, stable, long-term architecture, find the person who loves structure, elegance and has the strength of personality to stand up for it. If you want a gorgeous UX, look for the team member with the spectacular personal website.

We are drawn to what we are drawn to — for some reason this fundamental piece of human nature is obscured, or down-played in business. Find what your writers are drawn to, and let them revel in it.

Love the Mystery

Your job is to balance the mysterious business of creativity with the hard-edged requirements of business. If you love the mystery, then the surprises, the uncertainties, the impassioned arguments about apparently tiny details — all the passionate business of creating something new in the world — will take you deeper into the work, will align you with your group.

If you are afraid of the mystery, find its unpredictability difficult, then you will be constantly wrong-footed as you try, and continually fail, to have it completely under your thumb. Control will take only you so far — a smallish (maybe ten person) group, a few years of managing. To go further, you need to love the mystery.

Why We Do It

In the software industry (which these days is almost every industry), we take abstractions, concepts, visions and turn them into something that works. And we do it inside timelines and budgets, and we do it for high stakes.

Building a great piece of software is a constant balancing act of creativity, structure, improvisation and deliberation. At the heart of it is the act of writing, an act of will, inspiration, craft and (often) sheer effort.

The job of managing software is to guide creative, brilliant, massively varied writers un writing their best work. A privilege and a joy.