I've worked exclusively at small software companies over my 13-year career, and the biggest lesson I've learned — especially applied to running my own company — is that your style of governance matters.
There's something to be said about a bit of anarchy within a company, in this regard. You're more nimble; you can move quickly, do good, do bad, learn from your mistakes, and quickly implement fixes. For example, if you deploy badly broken code to production, you can fix it and quickly implement safeguards that'll prevent it in the future. But in my experience, this is a key ingredient for any organization that you want to succeed in the long-term: learning, and moving from chaos to order as soon as possible.
Plenty of people in the startup world see organizational process and order as more buttoned-up, bureaucratic, and “corporate”; as something that stifles “disruption” or whatever bullshit they're selling. But after a few years in the business, on both sides of the managerial coin, I'm sold on process and order, in whatever form it can take.
I've seen this work before at a 4-person startup, where I really first cut my teeth on professional software development. There was an employee manual I read once and then never referenced again — from my memory, I learned most of that company's process pragmatically, on the job. For example, the scope of responsibilities for each of us was clearly defined. We had good, consistent version control and code review habits. I learned these things once and kept them throughout my time at the company — and then brought them to positions at other companies that lacked much structure.
I've often thought back to compare this with other startups that had no collaborative review process in place, or no solid plan for getting new employees up to speed, or no stated process for handling user issues. Through this lens, it's easy to see which style was more successful — both for me as an employee and the organization as a whole.
Since Write.as started transitioning from a one-man show (just me) to a full team six months ago, I've tried to standardize and communicate as much as possible about how the team should work together and get things done. It's actually harder than I'd initially thought, getting my own personal processes put into language that the team can follow. You can never anticipate how deep and intricate years of organizational knowledge can be when it's only in your head. So documentation has generally happened on an as-needed basis:
How do we handle bug reports? Let's write up a process for that. What's our refund policy? Let's outline that now. How should we write commit messages, etc.? Let's get into the details now.
Doing it this way has kept the process light and efficient — I'm not spending my days writing up procedures we'll never need, but the important questions are getting answered for the team, both present and future.
To share this information across our team as we create it, we actually use the same product we're developing every day, Write.as. In particular, we're using our own Teams service, based on WriteFreely, which gives us a private space to spread this longer-form information internally. It's been especially important for me as CEO, because I need to be able to get our distributed team on the same page in a lightweight way that doesn't waste my time. It turns out we built something pretty good for that.
For one, our Teams site gives everyone multiple blogs / sections. So I have one section where I share company strategy, monthly updates (anything from customer developments to metrics), and rationale behind various decisions we make. Then I have a “daily objectives” space where I share more frequent status updates (especially while I'm more remote, as I am now, in Japan). I have another section for the various processes we establish, one for marketing inspiration, and yet another where I'm slowly documenting the history of our company before anyone else came on board — essentially, the parts that only I know, but want the team to know, too.
CJ, our community manager, uses the site to share weekly “community heartbeats” — updates on what's happening with our users, what issues they're encountering, what features they're asking for, etc. He also uses it to draft up blog posts and other written content for the team to review before we publish it (naturally, to one of our Write.as-based blogs).
Developers on the team use the site to dive into the occasional difficult problem they solved, or to propose new features based on their own use of the product. And, of course, they can read what everyone else is publishing, so the whole team stays on the same page, in their own time.
In this way, all of our interactions actually form new company processes as they develop, because we can always go back to read what we've published and update our writing over time. Plus, the meta work of documenting our primary work reinforces the ways in which we work — implicitly forming process, without much unnecessary effort on top of it.
These are the problems I'm most interested in solving as we take our small company from its relatively chaotic early days into a more mature organization.
There is something to be said about free-flowing chaos, yes, but it's definitely not the only way — even as a young startup. The lightest bit of process and clear team communication, we're finding, is all you need to stay quick on your feet while keeping a solid ground beneath you.
Want more writing like this? You can subscribe to new posts via email in the form below — or get them
via RSS or ActivityPub.