There’s loads of advice out there for aspiring founders, with much of it repeated ad nauseum. Don’t get distracted. Ship early and often. Read the Hard Thing About Hard Things. You know, the standard stuff.
The problem is that reading this advice rarely causes it to truly sink in. There’s a big difference between knowing you shouldn’t get distracted, and actually turning away the one person who is eager for your product when they come knocking on the door. (Not to mention the questions this would raise about your product-market-fit.)
So rather than reiterating the old clichés, I’ve spent some time thinking about some concrete activities aspiring founders should undertake which will allow them to hone the skills which will eventually be necessary for them.
In school or as an individual contributor, most of your work is defined ahead of time – all you have to do is fill in the blanks. But when you’re a founder, you have to deal with constant uncertainty. You’ll need to answer questions like “do I have enough information to make a decision yet?”, “Is it worth increasing my burn to hire more people onto the team,” and “is this customer worth the effort?”
There’s no rulebook for how to answer these questions, and there’s rarely if ever a best answer to take. So in order to have any hope of making good decisions, you’ll need to get comfortable with that uncertainty, and learn to distinguish between different shades of grey. The best way to do this is to actually get used to probabilistic reasoning, by making real, testable predictions and grading yourself on them regularly.
The predictions can be about anything – maybe they relate to the industry you’re interested in, but they could just as well have to do with your personal life and that of your friends and family. The point here isn’t to prove you’re an expert – you’re not. Rather, the goal is to start to get a sense for which classes of questions you can reliably trust your gut on, and which situations you’ll tend to need help navigating, at least at the start.
There’s been a lot written about direct market research (i.e. “go talk to 100 potential customers.”) It’s good advice, but limited in a sense – no matter how many data points you collect, you also need to have the skill to notice the overarching patterns. Is this new product a random deviation, or emblematic of a shift in the industry’s focus? Did this new demographic take interest because of a coincidental event, or are they here to stay? Where are investment dollars going, not just this year but over the next five to ten? These aren’t questions any single expert can tell you – you need to paint the picture yourself by combining everything that you’ve learned.
The quintessential “combine lots of data to predict patterns in industry dynamics” activity is the stock market, but I don’t recommend trying the stock market if you’re a beginner. It’s too noisy – you’ll never know whether you succeeded because you were actually right, or if it was just good luck. For those who have already trained their pattern-matching skills, the stock market can be a good way to test if your theories survive the messiness of the real world…but for those just starting out, I recommend solving puzzles.
No, I don’t mean Sudoku or crossword puzzles. I’m talking about the kind of puzzle where you don’t know the rules of the game, but you do know that everything is obeying some rule, and it’s up to you to figure out what. High-level puzzle hunts, like the MIT Mystery Hunt, are great resources for puzzles like this – or you can generate them yourself with friends via games like Zendo. The aim is to hone your ability to pick up on subtle cues that indicate broader trends, and to know where to focus your attention to learn more. These puzzles are the purest version of training materials for this skill, and I strongly recommend starting there before trying to break down messier real-world systems.
There are many facets to management, but the most essential skill in my mind is the ability to actually identify what drives your team. Once you know this, you can provide the best and fairest incentives, motivate the team, and organize folks for a balance of growth and getting sh*t done…but if you don’t actually understand why they do the things they do, none of your brilliant plans or noble speeches will ultimately have any effect.
So how do you develop this insight? Simple – you start talking to people today. Specifically, start conducting 1:1s with your own friends, colleagues, and anyone else who is game to try it. Obviously you’re not their manager today, so the point of these 1:1s isn’t to tell them what to do (not that real 1:1s should be about that either!) The point of a 1:1 is for you to shut down your own ego and focus entirely on trying to understand their own perspective. If they hint that they’re feeling bored, try to understand what could change that would excite them. If they mention they’re having trouble navigating an obstacle at work, restrain your urge to offer your own solution, and instead ask further questions to uncover more details of the situation and help them build their own ideas about what happens next. And, possibly the hardest of them all – if someone says something that appears hateful, ignorant, or even just annoying, rather than reprimanding them or shutting them down, genuinely try to understand where they are coming from, and how it is they came to utter those words. Nobody is the villain in their own story, so if you really want to be able to put yourselves in the shoes of your team and connect with them, you need to become truly skilled at putting your ego on hold and allowing yourself to see someone else as the hero.
The hardest part of writing code is getting past the first gate – the belief that code is ‘magic’ and insurmountable. Once you’ve seen behind the curtain, most of programming actually becomes…well, not easy, but predictable in a sense. Learn one programming language, and you’ve learned them all, as long as you have access to StackOverflow to figure out the different syntax or slightly reorganized primitives.
Lots has been written to try to encourage more folks to code, and I’m not certain I can add much to that discussion here. But once you do become comfortable with programming, there are still real challenges. Specifically, if you understand the basics of code, then you can, in principle, write pretty much anything you need given enough time. But to be successful in the real world, you need speed – both in terms of your speed to develop the code, as well as making sure your code is actually performant. And you also need to be able to understand leaky abstractions, because no matter how sophisticated the tools you use, and no matter what they promise about writing code once and then running it on every browser, every OS, every console, etc, there will always be things that are different when you try to deploy to different systems.
So, what coding project should you choose, that will teach you about the importance and difficulty of writing truly performant code, and force you to confront the challenges around shipping a program to a variety of platforms? I recommend writing a video game. Aside from just being fun, most people who start working on games can’t help but have their own ideas about improvements; nor can they help their desire to share what they’ve made with friends. So, rather than simply building “my first website” or yet another hello world program, I always suggest building even a super-simple video game as an exercise that will force you to actually gain a real understanding of the challenges real developers face. Even if you’ll never write a line of code again, you’d be shellshocked to realize how much more effectively you can interact with your development team once you have this kind of intuition for what their work really is.
Of course, there are many more Arts you’ll need to cultivate to become a successful founder, but these four are perhaps among the most crucial right from the getgo. And of course, they all stem from the same core insight – that if you truly want to be a founder, then you’re aiming to be someone who breaks the mold. That means nobody can tell you the right answers – you’re going to need to get used to trusting yourself, and that means getting started now at recognizing your strengths and weaknesses, developing well-calibrated humility, and learning what it really means to listen and to motivate someone. None of these are easy, but if you want to succeed without pushing yourself, startups probably aren’t the place for you.