Thomas Goetz
How this newbie got an education in coding—and management
What you don’t know can help you
LIKE MANY WHO HAVE made the leap into Startupland, I guessed from the outset that I had a lot to learn. I was right. Indeed, I jumped into the wormhole of blind spots and unknown unknowns. This has been especially true on matters technological. At Iodine, my startup, I took the role of “nontechnical co-founder”—a Silicon Valley term I’ve always considered slightly pejorative, but whatever. I’m not completely analog. I’ve spent years around technology, helping run Wired and a couple of tech news websites over the years. But I’m no coder, and—even though I have a very astute technical co-founder—you can’t run a software startup without knowing something about software. So I’ve tried to catch up.
As a leader, you know you can’t know everything. The trick is to uncover the knowledge that is critical to both running the business and connecting with your team. Becoming conversant in code, it turns out, has been one of the best parts of the gig: working with engineers and web developers and seeing how good software happens. I still can’t code. But I’ve absorbed the rhythms of software development—sprints and huddles and standups—and, most important, I’ve learned how to communicate with our technical teams.
The minutiae of the tasks our engineering team is tackling remain lost on me. I might grasp the difference between, say, client-side and server-side rendering, but not what’s involved in building one versus the other. Still, it’s been unexpected fun to ponder the riddles of software development. In addition, participating has helped me comprehend how good code can become a great product. If you find yourself in this role, be prepared to publicly display your ignorance. I know I did. In our first several product cycles, I couldn’t understand why our time estimates were consistently so wrong. We’d make seemingly prudent estimates for releases, but inevitably we’d blow the deadlines. In my previous life in journalism, deadlines were sacrosanct. In software, time estimates are often approximations of approximations. I learned to double any estimate to allow for those unknown unknowns to settle out. Since then, we’re much more accurate—though hardly perfect—with our schedules.
Part of what keeps me engaged is realizing how exceptional this education has been. Consider that over the past 20 years, software development has been the discipline from which some of the most radical breakthroughs in business have emerged. Open-source software, after all, is the template for crowdsourcing and distributed collaboration. Agile software development gave rise to lean startups, which have led to startups of all stripes more effectively creating useful products. Likewise, bug-fixing has improved quality assurance, and software-as-a-service has influenced the models for service- driven businesses from truck leasing to office-space rental.
In short: Learning how to build software is a great way to learn how to build a business. Even better, this educational process is a two-way street. Our engineering team has gleaned that writing content (Iodine offers medical information written by experts for real people to understand) can be exceptionally challenging—full of the “edge cases” that easily trip up algorithms. And they better appreciate the role of good design, where aesthetics and architecture not only organize information but can also make it easier to understand.
This cross- disciplinary knowledge transfer has been one of the steady delights of my startup days. No doubt my engineering colleagues would remind me that I still have a lot to learn. They’re right. And that’s the joy of it.