Introduction
This handbook is comprised of content in two main categories:
- Company Policies and Workflows
- Tips and Advise for Startups
There could also be a third category, Research and Development, but these posts always end up in The Alfa Jango Blog.
Company Policies and Workflows
These are policies and workflows that we've developed to improve the process of developing software for startups. We don't come by these lightly. We run our company by the same philosophies by which we advise startups to run. And one of the most crippling mistakes we've seen other startups (and even large companies) make is to expend resources on premature optimization.
For any policy or workflow you see in this handbook, there was a hard-fast and recurrent problem which prompted its formulation, and much discussion and research which led to its solution. For a policy or workflow to be effective, it's important that everyone on the team understands the problem and buys into the solution. This is why each policy or workflow always starts with a "Why this is needed" section.
From my answer to a Hacker News thread titled, "Ask HN: Percent of time spent developing internal tools?":
For our company, we don't develop internal tools for any given problem until it's a real pain. You'll know when it's an actual pain (as opposed to just an idea), because you'll keep seeing it crop up in your day-to-day work, and if you talk about it with others on your team, they'll say, "Yeah! I know exactly what you mean, I was thinking about that the other day."
We wait until it's a real pain for a couple reasons:
We want to make sure we're not wasting our time; we're mostly engineers, and we all get real, unadulterated enjoyment from building things. It's only too easy for our enjoyment and enthusiasm for building a solution to fool us into thinking there's a problem. But usually, if everyone on the team is instantly excited about the prospect of solving some problem, that's usually a good indicator that it's a real problem.
The longer we can put off something, the more information we'll have when we go to solve it. In other words, we give ourselves time to figure out first how we want to work, and then find or build tools around that, rather than trying to fit our system to some tool.
The second reason is really important too, because when we sit down to really think about every facet of a problem, how it affects our work and how we have been putting up with it and working around it, we'll often realize the best solution isn't some new piece of software; it's merely leveraging some tool we already have slightly differently.
For one example, we started losing feedback and updates in email, because some person on the team would get left off the email (e.g. someone hit "reply" instead of "reply-all"), and we wouldn't realize it until some task went un-resolved for several days. We could have built or implemented some sort of support desk system and made it the clients' responsibility to make sure tickets are submitted and then integrated it with email. Or, we could just create a unique email alias for each client, which copies everyone involved. The latter took 2 minutes and improved communication threefold.
If you keep growing, you'll eventually reach a point where anything less than a full-blown software solution just isn't going to cut it. But by that time, you've seen how the team deals with the problem over time, and all the pitfalls of other smaller or less-custom solutions, and you'll be able to build the most awesome solution possible.
Tips and Advise for Startups
These posts almost always start as conversations with our startup clients or with other startups as conferences. When we find ourselves giving the same peice of advise twice, to different startups, that's when we decide to write it down. This is the new home for those posts. Unlike a blog, this handbook is a living document, which we can update as we refine our processes and advise with experience, making it easier to always refer new startups and clients to our thoughts on any given subject.