Article originally appeared in Forbes on Feb 13, 2019
During my senior year of college, my new lacrosse coach arrived with an approach he called “leadership from the front.” For one of his many lessons on the topic, he brought in a former Marine who spoke of the need to experience the roles of the people he was leading.
“If I’ve never shot a machine gun before, how in the world can I lead my gunners to success?” he asked. “If they go down, I need to be able to jump into their role.”
It took me three years to understand the value of this advice.
I had just hired a new CTO for my second startup and tasked him with taking over development from the offshore engineering team. He had an incredible work ethic, but it soon became clear that he was in over his head and that the one computer science course I had taken in college wasn't going to be enough to pull us out.
Although the offshore developers had delivered a well-crafted product, one that attracted thousands of users, their code was far from clean. As I now intimately know, transitioning ownership of an offshored codebase without any process or direction can be a daunting task for even the most senior of engineers.
I had set my CTO up to fail. We were unable to deploy even the smallest improvements, and meetings about the future of the product slipped from hourly to daily to weekly as he struggled with the technical complexity in front of him. I knew he was trying his best, but there was no way for me to help or truly monitor progress. I didn’t even know where, or whether, he was saving his work.
I knew things were bad when he stopped returning my phone calls and emails. I knew things were really bad when he unfriended me on Facebook. I don’t blame him. I was unable to lead from the front.
During this rocky period, I had the good fortune to land a lunch with the cofounder and CEO of a well-known software company. For some youthful and naive reason, I had visions of this lunch ending with an acquisition offer.
Instead, it ended with an admonition: “How many more times are you going to walk into the room and say, ‘I’m not the tech guy’?”
The CEO straightened me out on tech acquisitions really quickly. Successful software companies don’t usually buy users — even hundreds of thousands of them — and a 12-month-old codebase. They usually buy technical teams and leaders, who, when brought into the mothership, can increase product velocity.
I’m paraphrasing his advice, as it has been six years since our lunch, but he then said something like this: "The world is programmed, and if you want to change the world, you need to know how the world works. But most importantly, if you want to run a billion-dollar company someday, culture and hiring are all that matter. And if you want to stay in technology, which it sounds like you do, in order to attract and lead the best technical people, it’s not enough to have taken a computer science class and ‘kinda’ read code. You need to be able to argue with them about their refactoring philosophy.”
In other words, if your CTO unfriends you and the servers go down, you need to be able to jump in and turn them back on.
So I spent the next three years of my life studying code, developing systems and ultimately paying it forward by teaching students to write code and, of course, lead from the front. And as the CEO I had lunch with suggested, the greatest benefit of leading from the front isn’t the skill itself, but the relationships that can emerge from the technical knowledge.
One day I was coding in a bagel shop when I spotted someone else hacking away. I walked over and struck up a conversation with “Hey, are you a JavaScript guy?” Four years later, that JavaScript guy is now the cofounder and CTO of my third startup.
Leading from the front is about more than surface familiarity with your team’s responsibilities — it’s about an authentic understanding of the role that you're asking them to perform. If you're managing a sales team and have never closed a deal, get out there and keep failing until you do. If you run a logistics company and have never seen a warehouse, go schlep some boxes. And if you run a tech company but have never fixed a software bug before, then I hope my experiences and failures can point you in the right direction.