An Audacious Mindset
On delusion and progress
You have to be a little bit unhinged to build a company.
Whether you’re truly at the ground floor as a founder or assume slightly less risk as an early employee, if you step back and really examine what you’re signing up for, it’s a pretty bad deal.
Most startups fail. And on that journey, you’re taking a substantial pay cut, working in a chaotic environment where you’re persistently starved of resources. If you’re expecting a marketing department to put together a one-page sell sheet for the product when you’re the first salesperson to join the team, you’re not going to last very long.
And yet, people do it. Some over and over again. I love it, and I really enjoy helping others take this leap into the unknown.
There are a lot of potential reasons for people to take that leap. The potential of a huge payday. The ability to have more direct impact. Or a chance to learn a ton.
I think another motivation is a certain audacity — bordering on delusion — that you can do things better, and you want the space and opportunity to prove it. Among the best startup people I know, I think that attitude runs deep.
And I think it’s this audacity that both draws people to the adventure, but is also instrumental in giving a new venture its best chances to succeed.
This thought was inspired by an experience a few months ago exploring a role that I ultimately lost. While the rejection was predictably vague, reading between the lines, I got the sense they saw me as too much of an agitator. Someone with strong opinions and who’s used to having the influence to make them a reality.
Which, for better or worse, is completely accurate. This newsletter is a case in point.
And while this organization is of course allowed to own its role definition, I couldn’t help thinking it’s a counterproductive strategy given what they’re trying to do. They’re trying to build new ventures. If that’s your goal, I’m not sure you want to screen for compliance, docility, and conformity, as I get the sense this organization was.
(I’m keeping this vague on purpose. They’re entitled to their strategy, and I see no reason to point fingers excessively.)
The best entrepreneurs and startup people I know are constantly looking to push boundaries or blow away old ideas.
Obviously, this is most evident in the venture’s mission writ large. If you’re Instagram, it’s a new way to share photos with friends and family. If you’re Deliveroo, it’s a new way to deliver food and other sundries.
If you’re not building something distinct, that pushes a boundary at least somewhere, odds are you’re on a path to failure.
But I think this audacity also shows up in less obvious places, like the way the company operates internally to deliver its product. It’s an attitude and worldview, not a skill.
Talking to a senior engineering leader at Spotify a few years ago for advice, she explained that change is very much baked into the company culture. You might think that a company that’s grown to 1,000 employees probably has most pieces figured out. But as this person saw Spotify grow from that 1,000 people to 5,000 employees and beyond, change was unending. Today, no one is surprised when there’s another reorganization, as the company constantly tries out new ways to get people working together effectively.
Even if you’re not in the proverbial room where it happens, being willing to engage with that chaos and “figure out” spirit is what keeps a company like Spotify nimble and competitive.
This doesn’t necessarily mean being original in a sui generis sense either. Often, this boundary pushing is more seizing the opportunity to adopt best practices.
With my engineering hat on, everything DevOps springs to mind.
For example: while containerization is pretty universally seen as the gold standard for building and deploying code today, if you’re a large, legacy business you probably haven’t moved everything over to, say, nice Docker containers being deployed and controlled with, say, Kubernetes. And these kinds of deep optimizations are difficult to get to the top of the list of priorities.
If you’re working at an early-stage company, there isn’t a giant committee of people you need to get approval from to set up Kubernetes. If you can squeeze it in while you polish up another piece of the system, it will happen. No one is going to make you write a five-page memo. Or run it by the “process improvement team” for approval, and for them to implement when they get around to it.
At one company, I more or less woke up on a random Tuesday, decided we should set up container orchestration to solve an acute issue — we couldn’t deploy our code at all in the previous system — and within about three days we had migrated our entire stack with no real issues.
This can also be critical in giving a new venture the edge and ability to cope with limited resources and a need for agility. You can get away with legacy deployment patterns if you have a team of 30 people who can take a week to roll out changes. That’s not going to work if everyone’s deploying their own code and you want to ship something within hours, not weeks.
On the product side, it takes audacity to dream up features that have enough differentiation anyone is going to care. Good product managers listen. Great product managers synthesize.
If you have to tell your team to push boundaries, that’s a problem.
When I’m hiring, candidates often asked what the best part of working at a startup is. I usually tell them that the best part is also the worst part. There’s an unending stream of unsolved problems and novel challenges. From the product itself to internal processes. If you don’t have the audacity to think you can take those on, I’m not sure it’s the journey for you.