Learning to Love
What I Don’t Know
How this newbie got an
education in coding—and
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
diference 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 fnd yourself in this role, be prepared
to publicly display your ignorance. I know I did.
In our frst 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 efectively creating useful
products. Likewise, bug-fxing has improved quality assurance, and software-as-a-service has
infuenced the models for service-driven businesses from truck leasing to ofce-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 ofers 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.
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
Thomas Goetz is a co-founder
of Iodine, a digital health startup
based in San Francisco. Follow him
on Twitter: @tgoetz.
LAUNCH 36 - INC. - NOVEMBER 2017