Early in my career I was working for a tech firm that had recently grown from a tiny startup to a company with a few hundred employees. One day the CEO gave a company-wide address in which he explained, “Startups produce code more efficiently than large companies — therefore we will continue to run this company like a startup!”
Unfortunately, in practice, this essentially amounted to free soft-drinks and everyone being expected to work unpaid overtime every day.
I remember at the time thinking, “That’s not how it works. There are reasons a big company can’t function like a startup.” And if you figure in all of startups that fail, it’s not even clear that startups produce more code-in-production per developer than larger companies.
In retrospect, I view that boss’s silly speech as a gift. It has inspired me, as I’ve worked at different companies over the years, to observe carefully the ways that “startup mode” differs from scalable practices — and to think about the best strategies for getting from one to the other.
The metaphor I like to use is the evolution of the eye.
Some animals have nothing more than a patch of light-sensitive cells. Some of their descendants developed a concave indentation for their light-sensors — giving the advantage of more information about the direction of the light and shadow.
Other descendants added further improvements, leading to our current version.
When you look at the steps sequentially, you might get the impression that each innovation was deliberately intended or designed to move the creature closer to having a complex, modern eye. But that’s not how evolution works. Each of these apparent “steps” is represented by an animal that is (or was) done — in the sense that it was fit to survive in its environment.
That is the type of path that you should follow when building your IT department from “startup mode” to “scaled-up mode” — every addition should be something that helps you build software more efficiently at your company’s current stage of development.
Unlike evolution, you have the advantage that you can look at the IT departments of successful larger companies — so you have an example that you can shoot for — and you can make changes intentionally. (It’s great to have some advantage since, also unlike evolution, you don’t have a hundred-million years to get it done.)
But having an example to shoot for has its pitfalls. It’s tempting to look at a big company and say, “Google is doing X, so my company should do X too.” Not necessarily. You might end up doing the equivalent of spending resources to make a lens before you have developed a retina to focus an image onto.
One of the main differences between “startup mode” and “scaled-up mode” is how much you can afford to invest up-front in any given project, in terms of time and resources.
In startup mode, it makes sense to use a “rapid-prototyping” strategy for code development. If you’re still in the stage where you have only a few clients (or none), your business plan will likely change and evolve — so a lot of standard best-practices are less important than getting examples of your ideas up-and-running immediately.
Often a startup will have one or two engineers who can churn out reams and reams of impressive code, and enjoy doing just that — unfettered by any kind of official process. That development strategy has some major drawbacks in terms of long-term code maintainability, so I wouldn’t recommend producing your product that way if you can afford not to. But when your company is a tiny startup, you’re probably on a pretty tight budget. And long-term code maintainability is kind of unhelpful if the up-front cost means your company fails tomorrow.
Scaled-up mode, by contrast, isn’t as fast, but can cost less in the long run. Writing properly-engineered specifications can save the time that would be wasted on misunderstandings. Maintaining extensive engineering-level documentation simplifies the process of onboarding and knowledge-transfer. And adding efficient and appropriate tests and monitoring during the development phase can help keep your developers from being constantly pulled off of their current tasks to “put out fires” — i.e. perform emergency fixes on problems that are in the production version.
But startup mode also has some advantages that aren’t just a question of throwing out long-term thinking in terms of short-term results. A larger company has more structured and costly processes and policies — not just because it can afford them, but — because it needs them more than startups do.
When you have less than ten people who are in the same room and constantly interacting with each other, you can afford to be flexible about who does what and in what way. The set of things to get done is small enough that everyone essentially has a handle on who’s doing what and what’s the status. This allows for an efficient and transparent distribution of tasks. If the company is composed of people who have a good rapport, whoever is good at a given task can step up and get it done. And the boss can oversee everything personally, so communication of goals and priorities is direct, instead of filtering through a chain of interaction.
With each new person you add, it becomes harder to make sure that everyone is on the same page. You need some sort of formal policies so that teams that rely on each other’s work (like dev & testing or client side & server side) know what to expect from each other — and to prevent misunderstanding about when and what to release or deliver.
When you go from a two-person dev team to a four-person dev team, it’s easy to have the problem where two engineers discuss ideas together informally — and then innocently think that “everybody knows” what we’re doing and who’s doing what. This kind of mistake can leave some other engineers feeling like they’re out-of-the-loop and don’t have any say in the decisions that affect their projects. This error can be solved by supplementing the “startup mode” flexible-and-efficient system of “engineers discuss their projects with whomever and whenever they feel like it,” with a more scalable system that involves some official-and-cumbersome planning meetings.
But meetings cost money. Specifications and formal requirements cost money. Tests and testers cost money. Managers cost money. So it’s important to distribute your resources wisely and add scalable components as you find you have need of them.
One of the most instructive managerial errors I’ve seen happened when I was working at a company that had just received a huge lump of venture capital money. The company had had some initial success with an innovative technology they’d brought to market a few years earlier. But technology marches on, and their flagship product was rapidly becoming obsolete. The company desperately needed to get back out in front at the leading edge of their tech market — when the godsend of new venture cash came flowing in to save the company.
But instead of using that money to revamp their business model and to figure out why their client-firms weren’t interested in their proposed new product line, the company spent it on an extensive (and expensive) restructuring of internal management — one that was rolled-out with much fanfare in a company-wide meeting. And their new product line was duly developed and implemented, and nobody bought it, the end. (For that company, at least.)
The lesson I drew from that experience is that you can’t get complacent when you’re living on investor money. You can’t buy “nice to have” process improvements when you don’t have a sufficient revenue stream flowing in.
The challenge is that from inside the company — especially if it’s your first startup — it’s hard to have a good perspective on what your company really needs most.
As as your company grows, you need to incrementally construct the policy structures of a larger company, and it’s important to add them in the right order so that each addition brings value to your company.
But what is that order?
Unfortunately, I don’t think there’s one simple set formula that every startup should follow. It would be easier if there were one path that always works. But startups vary widely. I’ve worked about seven or eight startups (depending on your definition of startup), and probably the most striking thing was how different they all were from each other.
Startups have a strong “founder effect” — the particular talents and interests of the handful of people on your initial team determine what your company will be like moving forward. And their strengths and weaknesses determine which holes you need to fill with formal policies first.
If you’re on your first startup, it helps if at least some of the people on your team have worked in a startup before, so they can give you some perspective on how the culture within your startup differs from others. If you have such team members, take the time to ask them for their impressions. And if you’ve just gotten some new investor money, it may even be worthwhile to ask an experienced outsider for advice on how to use it wisely.
Overall, I would recommend that you don’t blindly try to apply whatever ideas are hot right now. And don’t just assume that any set of management strategies, structures, or best practices are best for every company at every stage of development. Look for the places where your company is struggling, and start improvements there.