Open Source & More - Blog | Tidelift

Long live the SFD

Written by Tidelift | May 31, 2018

This is a first draft; raw and unedited. You’re seeing it as it came out of my head. Conversational, informal but free.  This is a shitty first draft—or SFD—and I love it.

The idea is simple: just get something—anything—down on a page. By calling it a SFD, we are, in essence, apologizing ahead of time for it not being perfect—and giving the work the space to breathe, away from harsh judgement. The benefits of this can be huge for you, your colleagues, and your company.

Writer’s block: we’ve all been there. Often getting things out of your head and onto a page can be hugely stressful. They have to be well informed, well articulated… damned-near perfect to convince your audience of your arguments, your proposal, your ideas. Last year I worried so much about my writing that I employed a writing coach for a year, but very quickly that stress has subsided at Tidelift, due to the SFD approach.

Chris Grams brought the idea to us from his previous company, New Kind. But the idea itself isn’t enough to bring about the increased productivity it can create; you need to build a company culture that supports it.

A culture that’s about mutual trust and respect for each other. A culture that accepts that we’re not always at our best and that mistakes are a byproduct of creativity. A culture that encourages the creation of a shared pool of meaning and intent before beginning to chisel, hone, and otherwise craft artifacts.

The SFD is particularly important for new organisations trying to establish a team around a new idea. It’s also essential for remote organisations where asynchronous communication is a key part of the fabric holding teams together. And as a result I think it’s a great philosophy for open source projects to adopt, too.

Open source projects—and the maintainers behind them—are often constrained by time. And yet most have the tools needed to chisel and hone those artifacts in the face of a rough cut. I may even argue that putting out a SFD document, design, or prototype may encourage the kind of communication between contributors and users that leads to a better informed, more effective community in the end, while enabling newer contributors to take part and feel like a more involved member of the community than a commit to fix a lint error might provide.

So let’s all be a little freer with our thought and more accepting of mistakes as part of the process.