How to fire yourself: A founder's dilemma
"Grant, would you rather see your ideas implemented, or be the one who tries to implement them—but who never has time to finish even one of them, much less the majority of them?" Those cogent words, paraphrased from ex-Entagen and current Systemhouse CEO Chris Bouton, a long-time friend, really struck a nerve.
At the time, I was struggling to "do it all" and frustrated with a lack of progress on so many fronts, and his words started a cascading effect over the past two years that have caused me to "fire myself" multiple times and really hone in on what I'm good at as we've gotten bigger as a company. It was—and still is—one of the hardest things I've had to do as a company founder. After all, this company is my baby (even though it actually isn't—because we have other founders and investors—but it's still good to feel like it is). And from the earliest days, I've been involved in pretty much all aspects of the business—from writing code to marketing and selling.
In the beginning days of any company, a founder pretty much has no choice but to do everything, even if you aren't trained in it, and even if you have venture backing. Stuff needs to get done, so you get it done, and because you're the founding judge and jury, it's always right—right? Need some code for some new feature? Sure, I can do that. Need someone to troubleshoot at 4am? Sure, I can do that. Jump on a plane and be in NYC for a customer meeting tomorrow? Sure, I can do that.
I learned more about business, software, and, most importantly, people, in the first two years of Lucidworks than I did in the previous 10-15 years of school and work combined. Being a founder was (and is) a thrilling ride and one that expands your brain in ways you never knew it could expand. It's also an addictive ride, as your brain starts to crave the novelty of newness that comes from context switching between a dozen different things, seemingly all at once, as well as the satisfaction that comes from being "the one who gets it done." Not that you ever really are that person, but more on that in a moment.
As you can no doubt guess, being all things to everyone is not a sustainable approach for a founder or for the business, but often the problem is not something blatantly obvious. Instead, the problem creeps in subtly every time a team member says, "Let me check with [insert founder name] first," or a customer emails in the middle of the night with a problem and you're the person who did the technical sale on the account, and so you feel you have a particular obligation to resolve it. Other times, it comes from knowing you made a bad hire and you haven’t quite made up your mind to let that person go and so you go the extra mile to see if you can “save” them when in reality, you just need to move on. Your coworkers and employees will naturally pick up on all of these things and slowly but surely, you have become the bottleneck to growth.
Stopping yourself from being that bottleneck requires:
- a bit of education,
- trusting your team,
- and a good dose of honesty.
None of these pieces are easy and all require more work from a founder in the short term, but in the long run, they are difference makers in growing the business.
From an education perspective, the situation is like the proverbial tale of teaching someone to fish. On the business side, this also means setting proper expectations and making sure you've put in place opportunities to succeed with the right amount of process. Expectation-setting can be the most difficult, especially for technical people who are moving into management. Most computer science curricula don't have courses on management theory, nor are all of us "computer nerds" people-persons by nature. Several things have helped me on this front, such as:
reading and learning from other managers, working with several mentors and an executive coach, realizing that the investment will pay dividends down the road, and learning to give and take open, honest feedback. The last item is the most difficult because most people are naturally inclined to avoid conflict, or simply don't know how to have critical conversations in a constructive manner. I know I still have a long way to go.
As for the "trusting your team" factor, this comes from hiring well and creating a culture of winning as a team. It also comes from realizing that often the key to success isn't having the idea, rather, as my friend Chris so bluntly put to me, seeing the idea through. The only way that is going to happen is if someone who is good at implementing the idea focuses on it. And the only way that is going to happen is if you stop thinking you are the only person who can do it just because you are the only person who has been doing it. Ultimately, building trust means finding, nurturing, and recognizing other people's talents, especially ones that are complementary to your own.
Finally, the hardest part of stopping yourself from being a bottleneck is having an honest assessment of where you are most valuable in the company. If you're lucky, you are incredibly self-aware and do it automatically. In all likelihood, you'll have a CEO, board, or mentor who will gladly show you the way. The process won't always be easy, as these are often difficult conversations about what feels like a shortcoming, but you will thank them later.
If you are unlucky, you'll burn yourself out and only realize it after a meltdown. This most recently hit home when I transitioned from being both the CTO and VP of engineering to "just" being the CTO. During my time in the dual role, we completely re-architected and re-launched our flagship product, took on significant new contributions to Apache Solr (our open source core), and quadrupled the size of our product and engineering team, all while still doing conferences and customer events.
Although I consider most things we did in the time as a success—or at least a good start— that I needed to "fire myself" became increasingly obvious because I wasn't able to give both roles their due, especially on the engineering side, which requires a lot more attention to details. (Thankfully, I had some really good managers/leads who filled most of the gaps.) Also, my engineering role isn't conducive to the customer-facing role I increasingly find myself in.
I miss the day-to-day interactions with the team, but the benefits of the change are already obvious, both for the company and for me personally. The engineering team has a dedicated leader to take them to the next level of growth, and I have more time to focus on CTO responsibilities, such as meeting with customers or working on what's next in search and machine learning.
Are you ready to be fired?
The author has licensed this article under CC BY-SA