There’s a paradox that I’ve noticed in myself that I like to call the “Emma Woodhouse phenomenon.”
Namely, that I often feel like I’m great at giving advice to other people and helping get their lives in order, while I’m hopeless at doing the same for myself.1
The more I’ve thought about this, the more I’ve come to see that the disconnect comes about because there’s such a difference in knowing what to do and actually doing it. It’s so much easier to see that something is right with distance. It’s different when you’re in the situation with all its concomitant pressures and commitments, and when you’ve never had to do something before. I can analyze my own situations with the same clarity I look at others’, but because I’m actually wrapped up in it, I often fail to act, especially when it’s going to be painful.
Put simply, doing is the hard part.
This popped into my mind in the company building context thinking about why some companies survive and others fail.
For all the guides and advice floating around to optimize or strategize at the margin, when I look at the companies that thrive, the difference is that they actually did the work and followed the advice on what to do.
The most obvious example in my mind is focus. It matters a lot what you choose not to do, however lucrative or appealing some rabbit holes or shiny objects may be. When you have laser focus and get everyone lined up behind it, magic happens.
That’s what I saw getting to know the team at SecurityPal, for example. Their core offering could not be more focused: they help you fill out enterprise security questionnaires. That’s it. You send them a blank questionnaire. They send back a completed one.
It might sound easy to maintain this focus. Especially since the company has some market validation and is doing well. In the compliance space they’re working in, though, maintaining this focus requires a ton of discipline. There are innumerable problems you could solve in that general direction. It takes real guts to tell a customer you don’t want more of their money when they explicitly tell you they’d give you more to build out, say, a solution to track data leaks or security vulnerabilities.2
The difference at companies like SecurityPal isn’t that they’ve got special insight about the company building process. If you’ve ever watched an Apple product announcement, you’ve probably been exposed to the idea that focus is important. The difference is that successful companies actually do it. At SecurityPal, for example, they’re able to do an exceptional job helping people get through the questionnaire step because they put all their weight behind it, from what they build, to the customers they look for, to how they support people who buy.
Or consider endowment effects.
Figuring out what works in a given market is really difficult. Most companies never make it to product-market fit. And along the way, it’s almost inevitable you’ll wind up with some customers who really shouldn’t be your customers.
My friend Diana Hsieh — a much better product strategist than me — wrote about the importance and difficulty of figuring out who your ideal customer is a few months ago.
Once those customers are in the door — and contributing to your revenue numbers — it can be difficult to give them up, even once you realize (perhaps only subconsciously) they’re dragging you down. The hard part isn’t knowing that you should let them go, it’s accepting the pain and actually letting it happen so you reap the longer-run benefits.
I’m increasingly convinced it’s these choices, not the ones at the margin — like how you set sales quotas or track engineering productivity — that really make the difference.
Another company I’ve gotten to know (that I shouldn’t mention by name) got to pretty serious revenue with what they thought was their ideal customer base. Into the millions of dollars a year.
Then the CEO realized it wasn’t taking off, and their growth was stalling.
After some experimentation, they realized a completely different segment had much better fit. A different segment that had virtually no overlap with their existing customers, and that was different enough again that their product didn’t translate exactly. To the extent they had to rebuild many pieces from scratch to meet the new customers.
It would’ve been very tempting for them to try and spin both plates at the same time. To keep the existing customers happy enough not to abandon the product and renew once their contracts were up while building toward the more promising customer base.
But that’s not what focus looks like. If you’re going to commit, you have to actually do the work and commit, accepting the hard parts. Which is exactly what this company did. They told their existing customers they’d be phasing out the product in their industry and let them all walk away. If you visit their website today, you’d never know they served the initial segment they went after.
Which made the difference. Instead of slowly inching forward, their growth took off after they made the switch. It was the difference between them hovering at $5 million of annual revenue and getting into the tens and hundreds of millions. They were able to focus on a market where they were beloved rather than merely tolerated, and are being rewarded accordingly.
Is it possible they could have failed by taking this gambit? Absolutely. I might argue that the sooner and more definitively you know something doesn’t work, the better. It’s not failure that kills you, it’s not knowing and not following through when you see it.
On a smaller scale, I’ve seen similar dynamics at work with technical projects, too. For example, embracing infrastructure as code, and deploying with automated, repeatable systems like Docker containers and Kubernetes.
It’s easy to find articles or evangelists extolling the amazingness of modern DevSecOps techniques. And having built an infrastructure organization that puts these ideas at the center, I speak from experience when I say it’s amazing when you commit and get it right. There’s so much less work involved keeping systems live and working. It’s night-and-day easier to scale up or down, or even just get data on where costs or problems lie.
But getting to a strong infrastructure-as-code posture encompasses so much. Until you’ve got good patterns and systems in place, it’s frankly a lot more work upfront to deploy your dinky backend system with a Kubernetes manifest than SSH-ing into a sever and booting up your code by hand. From a personnel perspective, it requires everyone — even people allergic to and unfamiliar with writing Docker files and configuring a CI pipeline — to embrace a different way of working. It’s easy to give up before you get where you know you need to go.
In the same way that losing revenue from bad customers is hard, actually committing to good DevSecOps requires a lot of commitment and work. The hard part isn’t knowing that it’s a good idea. The hard part is actually doing it.
There’s an aphorism that floats around in the world of politics. I’d pin its popularity to Aaron Sorkin and The West Wing. It goes something like “history is made by those who show up.” In a similar vein, it’s often the case that people who succeed aren’t necessarily the ones who have the most novel advice or insight, but those who are able to commit and actually follow formulae for success. Knowing is one thing. Doing is quite another.
Bonus: A Podcast Recommendation
I’m a big fan of David Runciman in general, and his podcast Past, Present, Future. The most recent episode, on what he calls the “Leviacene,” was especially great. I can’t recommend it highly enough. In my read, it’s a great philosophical basis for the need to rethink the way that we govern and lead organizations.
Enjoy this? Have an idea for something you’d like a perspective on? Drop me a line: I’d love to hear from you.
This was famously Emma’s dilemma in Jane Austen’s novel of the same name.
To be clear, these two examples are entirely made up and hypothetical! If you’re a SecurityPal competitor, don’t blame me for giving you bad inside information.