One Obvious Startup Lesson It Took Me Way Too Long To Learn

Len Epp
5 min readFeb 29, 2020


There are some small things I wish I’d known from the start of my adult life, that would have made some things way easier.

A few of them are kind of analog and outdated nowadays, but most of those have digital equivalents, because the benefit is a matter of principle, not any specific technology.

Anyway, here are some of the small things that I most regret not figuring out early on, in my personal and professional life:

  • Have one box where you keep all your receipts and the instructions for things you’ve bought
  • Have one binder where you keep all your official documentation in separate sections: banking statements, insurance records, utility bills, rental and ownership agreements, tax information, etc. Keep them in temporal order, with the most recent document on top of each section
  • Have a document where you write down all your addresses, and the dates you lived there (seriously, you never know when you might need a security clearance of some kind, or need to provide your former addresses, when you’re trying to get some kind of approval)
  • Don’t battle your chronotype in the long term. If you’re a night person, find a way to live like a night person, most of the time
  • Learn how to use spreadsheets
  • Write everything in plain text, not Word
  • Work out every day, and keep the long term in mind, unless you’re training for something specific

Just like you do in your day-to-day life, you also learn small lessons like this over time, when you get into the world of tech startups.

Before I get to the big one, here are some of the small, but still important, lessons I’ve learned myself over the years:

  • It’s normal to cold-email potential investors (but you should always write a unique, personalized email, that shows you’ve done your research, and you understand how your interests are in alignment with those of the person you’re emailing)
  • It’s normal to email journalists too (but, see above: make sure you’re actually letting the journalist know about some real news, and that it’s the kind of thing they write about)
  • Always be nice to everyone and never send an email etc. when you’re angry, and mute the exceptions (e.g. racists). This sounds easy but (at least for me) it can take enormous discipline
  • Always have the best equipment you can afford, not only for your team, but also for yourself
  • If you’re a small team, make the most of the benefits unique to this situation, like being able to tailor your interactions to the particular nature of each individual on your team

But the biggest lesson of all for me, took me the longest to learn, because, like many of these lessons, it seems kind of mundane.

I know I am far from being the first person to say this, but here it is:

Write shit down.

This is a simple thing to say but like all powerful lessons, it has many dimensions to it.

Let me start with a section from an interview I did for a podcast with Ian Miell, who at the time was a leading software architect at a giant bank:

You have to be in the team, with the team — coaching them through the difficult mentality of investment — of not just fixing the problem right in front of you, but actually thinking about what investment are you putting in, so that next time, you spend less time on this. Next time you’ll have a bit more time to do the more interesting work.

Writing things down at the process level seems like a waste of time, and without the right culture it both feels like, and is, a waste of time.

But if you get your culture right, it lets you focus on the hard and interesting problems.

Not only that, it is actually a necessary condition for focusing on the truly hard problems, because without it, you can’t scale, unless you have enormous resources at your disposal, in which case, your business might not be properly understood as a startup.

The really important thing to internalize here is that if your team is reinventing wheels all the time, you will find it much harder to make forward progress.

Writing things down also helps in times of crisis. When everybody’s freaking out, having a process for dealing with the problem already spelled out in detail, means you’ll solve the problem faster, and you’re less likely to make a mistake.

This is especially the case when you get to a point where you need to delegate important tasks to new people, which partly goes to the point about scale.

Writing things down is also of enormous benefit to your users’ time, which means it’s also of enormous benefit to your team’s time, as well as your own.

If you write things down, you can treat every contact you have with a user like the expression of a systemic issue that also has a systemic solution.

Here’s a practical example, one I really wish I’d internalized a lot earlier: set up a Help Center so you never have to write the same support email twice.

Every time you are contacted by a user about a new issue, turn your response into an article in your searchable Help Center. If a user contacts you about an issue that’s already been addressed, you can just point them to the Help Center (and, of course, this process can be automated).

Eventually, users will learn that they don’t need to wait for a human to solve their problem, or answer their question. (Just to be clear though, having human support always available is a huge advantage. Customer service is one of the biggest things companies of all kinds are competing on right now. Writing things down, and writing them well, is a key feature of competing in this area.)

The same goes for internal issues. Every time someone on the team creates a new process, they should write it down in a company wiki. And anyone who comes across it, when they need to do the same process themselves, should update it, if anything about the process has changed.

One of the deeper issues here concerns the importance of communication. It sounds simple, but it’s not. Running a successful startup and getting to the point where very few people can handle very many users, means that the tools and processes you set up for communication need to work very well, and eventually seem like second nature to your team.

I know that to a lot of people all of this will seem obvious, but I thought I’d add my small piece to the literature on this subject, for the benefit of anyone else out there who hasn’t yet learned the “Write shit down” principle, and why it matters. It sure took me too long to really understand it.



Len Epp

Startup cofounder. I like to write about tech, publishing, the interwebs, politics, and such.