Together.
For the last year and a half, I’ve been working with a great team on a text editor called Editorially. While working on it, friends often asked me to compare it to Nathan Kontny’s Draft.
There was a lot I could have said about Draft’s features or UI or layout or workflow, but the thing I always thought was interesting was that Draft is one guy, while Editorially was a team.
When I worked at Apple a few years ago, everyone on my team had their own office. People often suggest that open-plan offices are better because collaboration is so easy (or even unavoidable), but we spent plenty of time in each other’s offices, scribbling on whiteboards or stepping through code together. Everyone was always on chat. Even remote teams I worked with probably spent as much doing online code reviews and giving feedback as they did actually writing new code. I rarely felt a lack of collaboration, but I know a closed door and a quiet room is a much more effective way to focus than a pair of headphones.
Today, I’m doing freelance software development in San Francisco. One of my clients is a team of very talented people in an open office, but the absence of close collaboration there is palpable. There are a few whiteboards around, but I rarely see multiple people using them together. Nobody comments on pull requests or code commits. Everyone owns their part of the system and people almost never stick their fingers in each other’s pie.
A former manager of mine recently showed me a project he’s been working on at a small startup that’s still in top-secret “stealth mode.” He mentioned that they use Git, but not GitHub—depending on somebody else’s service isn’t secure enough, private enough, or even reliable enough. After all, you can run your own Git server pretty easily. But I think that’s missing the whole point of GitHub. GitHub’s central feature isn’t Git. It’s comments on commits and pull requests. It’s feedback. It’s critique. It’s discussion.
My friend Uday recently left a big team at Citrix to become the director of user experience at a startup. He’s the only designer there. He recently tweeted:
‘As “team of one,” I miss the “sounding board” of a big in-house UX team. Chats with @alissadesigns @SChhen & @lynneux help make it up! :-)’
When we ran into each other at a party, he talked about how he’s been putting giant sheets of sketch paper on walls and working to get people scribbling on and talking around them.
A good friend and former coworker of mine has a nice little side project he’s been working on for a few years. He raves about PullReview, a service that automatically reviews and gives feedback on his code. He also occasionally contracts with friends to help out where they have expertise or to give advice.
So, back to Editorially and Draft. Sadly, Editorially is now shutting down. Paul Lloyd recently wrote about his search for alternatives to it and had the following to say about Draft:
“So much of what makes a good writing experience comes down to the details, though, and I can’t say I enjoyed using Draft. The distraction-free interface comes at the cost of lengthy menus and modal windows, with the interface lacking consistency in these areas.”
When people ask me about Draft, I usually say it’s a pretty decent product made by a pretty good guy named Nate. It’s got a slew of useful features (plenty more than Editorially had) and more are coming at an incredibly fast clip.
We had more people working full time on Editorially, but we couldn’t match Draft’s speed or features. It took us a while to do things that one person with a simple idea might be able able to bang out pretty quickly.
At Editorially, I could pretty much guarantee that the first attempt any of us made at anything would be quickly followed by a deluge of ideas for how it could be approached differently, coexist better with some other part of the product, or how it could simply be improved. I threw out so much great code because it wasn’t the right code. I doubt we ever built anything less than twice. Our pull requests often featured very active discussions, annotated screenshots, and animated gifs demonstrating ideas.
It took us much longer than Nate to get these things done. Sometimes I worried that we were too slow. But I knew, very surely, that the product was dramatically better for the time and effort we took to work together. Where Draft had lengthy menus, an inconsistent interface, or an imperfect workflow, Editorially shone.1
Of course, we also had our share of miscommunications and mistakes. Sometimes we locked horns. I wish we’d collaborated as well around the code as we did around the user experience. There were still plenty of bugs. No collaboration is perfect.
When Paul concludes:
“It’s important to remember that many of these tools are built as side-projects, whereas Editorially benefited from a full-time team working on the product for a year. There is plenty of promise in each of these apps, and with continued development we may see a worthy successor.”
I think of all the teams I’ve known that don’t collaborate well. I think, too, of all the individuals and side projects I’ve seen be highly successful because of a few close collaborators. And I think of everyone I could depend on at Editorially to push back on my hare-brained schemes, sometimes encourage them, and always force me to think more critically about my work.
The strength of our collaborations just might be the most essential part of every endeavor we take on.
Of course, a better product certainly doesn’t imply a better or more sustainable business. That Editorially ran out of money and shut down demonstrates that clearly.↩