Tweets from the commute: Corilla’s first month in San Francisco
It started with a simple sticker on a laptop lid. And ended in a Tweetstorm.
I’ve been in San Francisco for a few weeks now and I still get amazed when I see the Corilla sticker on people’s laptops. I can never resist introducing myself and learning both how they came across us, and what we can do better for them.
It must look strange to by-standers, but this is: A) Silicon Valley after all and B) Corilla is born of an unstoppable curiosity about technical writing and content teams so… I can’t help myself but learn more.
That conversation spilled onto the Caltrain, a train service connecting Mountain View with San Francisco city. It’s a commute long enough to get some work done or, in my case, reflect on these conversations and even share a little Tweetstorm about it.
It wasn’t my intention to do a Suster here, but a bunch of DMs from the community have asked me to expand on some of these thoughts, so I’ll do my best below…
Inside the Tweetstorm
In a lot of cases it makes sense to build your own documentation toolchain. Which if we’re honest with ourselves is actually usually code for “it sounds like fun” and “how hard could it really be”?
I used to think the same. Until the day I had to upgrade the version of Fedora operating system I used at Red Hat to update a version of Publican to be able to compile the DocBook XML package to fix a typo. This example is a clue as to why we created PressGang in the first place (which in turn inspired Corilla).
Ignoring the cognitive load of subjecting writers to workflows like this, just how much was that costing the company? A writer doing literally anything to improve the customer experience is an investment. A writer wasting time on infrastructure is… a waste.
For the vast majority of the content teams out there, you can get excited about the actual writing workflow products like Corilla are optimised for. If you check out our roadmap you can see what we’re doing along the verticals of writing experience, editorial tools, collaboration and content management.
But you’re probably going to start and end with the unit economics. If even one 🦄 developer takes just one hour to create and maintain your documentation stack per month, you’ve already spent as much as using a product like Corilla.
(($90,000/50 weeks)/38 hours week) = $47 hour
We want to make content teams happy. But it doesn’t hurt that the accounting teams are happy too…
Are we doing this wrong? Part of me wonders if we should be more aggressive with things like cold email marketing campaigns — the kind my inbox fills with companies scraping AngelList.
But Corilla was born of a community of technical writers sharing solutions to the industry’s broken workflows. It’s incredibly difficult to take that sense of community out of our DNA.
I find most of my community visits in the Bay Area revolve around me just listening to what they are struggling with, understanding what’s changed since I stopped writing and started building the company, and sharing experiences with various solutions we’ve tried.
Invariably this mix of domain expertise and community curiosity fuels our product roadmap. So the question is how can we do this quicker and eventually at scale?
One of the interesting things in being a team based on a previous career in this industry is that it creates a trajectory with a long view of what we’re working towards. Which is why we’ve turned down any offer to pull either the team itself or the product proper off that journey. And why our community knows we’re in this for the long haul. After all, they were there in the very beginning, and we’ve come a long way. With a long way to go.
I describe Corilla as an infrastructure company. Maybe you don’t care about your documentation? But your support team, users, customers, auditors, and developers do. The list goes on.
I’ve written previously that GitHub and Stack Overflow’s developer surveys this year showed that documentation is the number one issue in tech.
We’ve created the momentum to tackle that. Our move back towards open source are another growing commitment to doing that as a community. And one that you should get involved with.
Even more than the growth is the geography here. The kid in me looks at the user map and remembers sitting for hours looking at a globe of the world as a child. How incredible that our community is… everywhere?
I’ve spoken to some companies recently that have been honest that we aren’t feature complete for them. And I’m transparent about our roadmap and that as a company I don’t feel we’ve quite found product-market fit yet either. Hence “The Early Edition” working group.
That should be an awkward meeting right?
Except in each case we’ve seen them sign up as a customer. The deciding factor is just spending time together as technical writers. And I’ve yet to hear a story of something they’re struggling with that isn’t less about features and more about a shared experience.
I’m learning a lot personally about how Corilla can solve those challenges, but the actual pain points? Yeah, I’ve lived that. I feel you. Here’s my ridiculous story about how we solved (or screwed up) that thing too.
This won’t scale. But it’s been amazing to see what that attitude of co-creation and full transparency in our product trajectory can achieve when we work closer together.
Open source as a whole really struggles with this. I’ve written at length on these topics, and recently agreed to lead a project that came out of the amazing SustainOSS event held at GitHub in San Francisco recently (in mid-2017).
Projects need products to provide the audience, validate the application, and generate the resources to maintain them. Imagine how much we could achieve together if we continued to enable the community to collaborate?
Hint: this is exactly what Red Hat did for Linux. That… went well.
That was a big deep-dive. I hope that answers the questions in DM but you can always contact me or leave me a comment if you have more!