Oh god, here comes the managing editor. It’s 2008, and I’m hunched over my computer, a mere associate editor with a feature story past due. I’m hoping she’ll pass by, but she won’t. She stands in the doorway of my infinitesimal office until I turn around. She doesn’t speak before the excuses spill from my mouth.
“My writer is late with his draft! I am waiting for the fact checkers! This computer is slow!”
She shakes her head. “Tomorrow,” she says. “Tomorrow morning.”
There are a dozen of us on the team, and I’m a junior member, only a few years into my time in magazineland. She’s not my boss—that’s the editor in chief—but what she says goes. That’s how the process works.
Dammit. We’d been friends a week earlier, joking and chatting and drinking coffee. Very likely we’ll be friends again a week from now. But today we are not friends. Today, I am a broken pipe in the plumbing.
In tech, it’s different. In tech, no one seems quite so... afraid.
In media, whether a team of editors publishes The New Yorker or the Poughkeepsie Beekeeping Ladies’ Annual, the process reduces a publication to a series of reproducible units, each expressed in terms of length (word count, or pages, or column inches) and form (story, or feature, or profile). Some things, like special issues, they plan a year ahead; others, like spelling fixes, they can do at the very last minute.
At my former magazine job, when the editorial team was late the penalties were severe. If the giant printing company did not find files on the FTP servers by a certain time, the presses would sit empty, not rotating at all. We’d have to pay hundreds of thousands of dollars in fines: whole salaries gone in the minute between midnight and 12:01. So we threw ourselves—all of us—in front of that deadline like the Secret service in front of a president. Then, we’d pick ourselves up and do it all over again.
While I loved working in media, I am enamored with software. To me, software is meta-media: a way to take all the ideas that people have written down over thousands of years and turn them into toys (and tools), a way to make them come alive. It took a while to admit that preference to myself. But, at first awkwardly, and then with increasing confidence, I switched careers. Now, more than a decade later, I’m the CEO of a medium-sized software development firm. And I’m still connected to media: About a third of our work is custom CMS builds and front end redesigns for media companies.
But that’s today. When I first transitioned to building software, I noticed something was different. I’d give another programmer my code, knowing it was awful but working. They’d have feedback, sure, but more often than not they’d just... accept it. That it worked was enough—a terrible bit of knowledge to have. Unlike at my magazine job, with software we knew (for the most part) that the penalties were not as costly. Plus there was always something else to build, some new feature to push out. With code, the work is incremental. We could fix it later. Maybe.
The editorial process—by which something ephemeral (ideas, art) gets translated into a product (articles, issues)—changes according to the pace. The editorial organization behind a large newspaper must compromise quickly, pulling any story that doesn’t work or pass legal muster by a daily, if not more frequent, deadline. The small team publishing a quarterly journal can pet each paragraph until it purrs. Across town, a crew of writers and producers working in nightly TV has to feed an enormous, ever-burning fire with words, props, guests, and jokes. But it’s a scalable process: A thousand journalists at a newswire or a two-person literary zine all work backward from a sense of finality.
Software people love a good process. Maybe that’s because it’s more fun to talk about the work than do the work. More likely it’s because software benefits from many short development cycles in which a team can work in parallel. I’m a convert, I guess: I like uppercase Agile and lowercase agile. I like GitFlow, lean, standups, kanban, continuous integration, story points, T-shirt sizing, scrum, use cases, velocity, user research, personas, Jobs to Be Done, design sprints, all of it.
But I still know, deep in my heart, that the editorial process at a well-run media organization is better than any software process I’ve ever seen.
Yes, it’s archaic, it’s reliant on human lore and relationships, it’s deadline- instead of sprint-driven, and it’s often on literal paper. But it also tames chaos, manages risk, produces shared ownership, allows for ideas to come from anywhere (in the form of pitches from writers), and results in something huge, complex, and interlocking every day, week, or month.
I’m always glad when our software company does media work because it’s a chance to drop into another industry culture to see what we can learn: the all-consuming need to ship the magazine, update the website, launch the thing. Editorial teams, from editor in chief to editorial assistant, are all afraid of the same monster: the deadline. It has calendars for teeth and its eyes shoot emails. I want product managers, engineers, and designers to see it up close.
Co-running a software company, I (with my cofounder) am the monster. I sell the work, and that work has deadlines. It’s not as easy as being on a team that has its collective back against the wall, fighting an impersonal foe, but it’s honest work. I see other similarities with my magazineland past. In the era of launching early and deploying hourly, development is starting to look, in weird ways, like media.
Increasingly software is built from small changes—unit tests and pull requests—and to do it from scratch is the labor of fools, dreamers, and academics. Software is also built reactively. We see it in App Store release notes: We’re fixing bugs, yes, but we’re also integrating with third parties. We also use sensible databases, cloud services, and React on the frontend. We containerize our apps and deploy them at regular intervals. We use the features in our SDKs.
Fifteen years ago, a software launch really was something. People were up all night. Cowboy (or cowperson) coders were slinging code every which way. When it was done, the team would flip the switch and celebrate with champagne in the conference room. In 2019 we celebrate a feature release to the App Store with champagne emoji in a Slack channel.
In media and in software, a ship date can inspire fear of failure. After a while, it can also become a test: Can I make this thing I’m doing (writing, editing, coding) really good—even great—knowing that no deadline extension is possible? And how will I pull it off?
Successful software and media processes are all about speed—specifically, increasing speed while improving quality. I love to hear that we’re developing software without whole components that were previously deemed necessary, using serverless Lambda functions instead of standing up servers, or dropping an API-generation layer right on top of the database so we don’t write any middleware code. It’s not cheating to skip a step. It’s progress. The only way to do more is to start by doing less.
Years ago, a very smart West Coast software person said to me, “My god, you people in New York”—i.e., media people—“are so lazy. You just go home at the end of the day!” First of all: Is that so bad? Second: If editorial teams can go home at night, it’s because they also can’t put on a backpack and head to Southeast Asia for a few months after a big launch. Instead, they tend to the steady, never-ending need to publish new things—a pace that, more and more, software teams are matching.
Here’s what I’d like software teams to know about their media counterparts: The editorial process has never had a brand name. No one calls it the Reactive Publishing Process or the Grid-Driven Nightly News Framework. But it’s the only thing that determines whether the issue goes out or the episode airs.
The process is held in trust by the team that does the work: No one asks why it exists, much less about its right to exist. Their understanding is that the thing they’re working on is bigger than them, and that their responsibility is to carry it forward. The process exists between people. If that all sounds fragile compared to a nice checklist, well, it is. If it sounds utterly dependent on talent and a shared sense of responsibilities, it is. It’s very hierarchical, too. You know who your boss is, and what they have the power to do.
But the editorial process can work for decades, sometimes more than a century, without interruption. (Measure your team’s process in uptime.) And when there’s a lot of talent in the room, and the work is happening, you won’t hear talk about brand-name methodologies. Instead, you’ll see people keeping each other accountable, standing at the door, tapping their feet, and moving the whole thing forward. Good process doesn’t have a name because it doesn’t need one.
If you want to measure how your team is working, measure how little they discuss their process.