On taking shortcuts while building your startup

I’m a firm believer that a huge part of early-stage success comes from taking shortcuts.
Some obvious examples are using high-value people (like CEOs and co-founders) to learn & perform the work of two people, and running without any formal meetings because everyone is already spending 12 hours a day in a room together (and probably already knows more than they want to about the other person’s work).
Most of these patterns aren’t conscious decisions, because you’re spending very little of your time framing & deliberating over decisions. People just act, without asking for someone’s input, and things tend to get done. Eventually things have happened in a certain way so frequently that you have a habit, or a company culture.

Now as terrifying as the image on the right may be, in general I don’t think these shortcuts are a bad thing, or something to avoid. On the contrary I think they’re pretty necessary to your survival, especially if you have limited funds (most startups) or a short time window before something outside your control causes your product to be less appealing(also most startups).

But the costs of taking these shortcuts increase as they’re repeated, and over time the costs will tend to outweigh the benefits or savings (in cash, time, or otherwise) that they once provided. The lack of meetings becomes a problem at by the time employee #10 joins, especially if some folks are going home at 6pm to see their families, or are out of the office talking to customers while developers are at their desks, making product decisions on the fly. This becomes even harder if the shared judgement & values that the early team spent years & many long nights getting aligned on don’t translate as automatically to new hires (which isn’t necessarily a bad thing).

Some shortcuts manifest as a risk you choose (consciously or not) to take, and the costs are only made apparent if you ever suffer the bad consequences of taking that risk. Just ask anyone who’s had to debug 1000 lines of spaghetti code that they wrote 3 years ago, and didn’t feel the need to comment. This, like choosing to finish your 18th hole of golf as a thunderstorm is rolling in, might be a safe risk every once in a while, but do it often enough, and it becomes as rash & stupid as turning around to start another 18 holes during the same storm. The more time you’re exposing yourself to risk, the more likely it is you’ll get burned, often in a high-severity way.

So if shortcuts are generally really helpful in the early days of the company, but some of those shortcuts can wind up biting you as the company & product grow, which shortcuts do you keep, and which do you drop?

My thoughts for these situations are to keep doing things the way you’re doing them for now, and be honest with yourself (and your co-founders, your manager, or others who probably care about this) that what you’re doing now miiiiight not be the wisest way of doing things down the road. Talk to peers or advisors, especially those who are a few months down the road from your company, and see if they’re still taking similar shortcuts (and it still makes sense for them). One area that I’ve found I consistently keep holding on to things for too long are any tasks where I at first find myself thinking “This is neat! I’m learning this new system/process/task, and it gives me more versatility, and a better end-to-end view of {large, multi-person process}!” The value from learning feels great as you’re doing it, and it might feel wonderful to be such a jill-of-all-trades, but the chore-ish nature of these types of work quickly ramps up, especially when it’s 11:25pm and you still haven’t run that report for tomorrow morning. As soon as it makes sense, put these tasks onto someone who has the time to do them well, and not leave them to the last minute.

In a similar vein, use new hires as an opportunity to examine how you’re doing things, and how you should be doing things. Having their own sets of biases & values, new members of the team will probably have a different view of the costs and benefits of doing things a certain way than the founding team does (who, over time, tend to converge on their judgements, or at least to support each others’ choices). This is even more true of first-time founders, whose personalities tend much more toward learning how to do lots of things pretty well, but sometimes have difficulties getting to what specialists consider best practice (see also: any CEO who’s tried to manage their company’s accounting). The impatience & ease of getting to a ‘good-enough’ solution then moving on to the next thing are great for some roles, but in certain parts of the business this creates huge Organizational Debt.

My last thoughts about which shortcuts to drop: be especially watchful for shortcuts & patterns that stunt the growth of an individual or affect company culture. The more often you take these shortcuts, the more OK it feels to continue. In working with several companies (and discussing with others), the costs of these shortcuts are extremely subtle & delayed, and it takes a huge amount of energy to correct them.