This past week, I was interviewing a candidate for a VP role along with two of our engineering leads. Everyone in the room excluding myself was classically “technical” – they could write code, had experience solving hard software problems and a background in computer science. I wrote my last line of PHP in 2004, and it had to be rewritten by a real programmer within 6 months.
During the interview, we had the following exchange (due to an imperfect memory, I’ll paraphrase):
Thomas, one of the engineering leads: How would we design an efficient system to help scale (some new data we’re collecting), get it into the app for users in a performant way, and what would be the challenges we’d encounter?
VP Candidate: Storing the data won’t be a big problem – Amazon S3 can take care of that. Processing might be a bit expensive, but also not huge. You will need to think about how you serve the data to the app; pre-computing every view and transform might suck, but having serious slowness for customers when they want to reverse ordering in a table probably sucks more. You could use (three letter acronym) to do some of the data transforms in memory.
Me: (nodding)
VP Candidate: Then you’d need to make sure…
Me: No, wait. I’m sorry; I shouldn’t have nodded. I have no idea what (three letter acronym) is. Can you explain that?
Everyone smiled and laughed a little (in a jovial way), the candidate explained the terminology and we moved on.
Here’s the rub. A few years ago, I would have been scared shitless to ask for an explanation in front of team members I supposedly manage. And my experiences at other companies (visiting, consulting, helping informally, etc) suggest that this is a very common fear among managers and CEOs of all stripes. When you manage people, you’re expected to have all the answers, or at least knowledge of the subject matter, right?
Well, it depends. In some organizations, there’s a highly politicized, high power-distance culture that relies on managers showing no weakness. I haven’t personally worked in a place like that, but I’ve observed them, and I know that to folks there, saving face and showing strength matters. But in the startup and entrepreneurial world, I think it’s a relic we can do without.
Non-technical folks like me often have an inferiority complex about their lack of skill in the field, and much of what we read in industry media, blogs and forums suggests that true engineers hate working for/with non-technical managers, founders and CEOs. Just have a look at some well-trafficked posts on the topic:
• Founders who can’t code (on Hacker News)
• Please stop asking how to find a technical co-founder (Jason Freedman)
• The non-technical founder’s nightmare (Mike Dorsey)
• Every startup CEO should learn to write code (David Cummings)
• Business people and the ability to code (fellow Mozzer Andrew Dumont)
• Stop looking for a technical co-founder, learn to code yourself (YC)
• Successful startup founders who can’t code (via Quora. Notably, there’s only one example listed, Marc Benioff)
It’s enough to make a guy like me run screaming to Sal Khan and Codecademy for a fortnight, hanging my head in shame until I can show off my first hackday MVP. An eon ago in Internet years, I made crappy web designs, muddled together some PHP using Dreamweaver and whatever bits of code I could steal from web forums, Google searches, and sites I visited and put the crap stew I’d collected onto the web. That’s probably still the most technical work I’ve done, personally.
Unlike many of the writers above, I’ve never spent a few weeks teaching myself Ruby, learning the Rails framework and coding up a basic app. I’ve neglected the few dozen-hundred hours it would take to achieve minor proficiency in computer science basics in favor of working on hiring, reviewing/creating wireframes + specs, getting closer to inbox 0, building that presentation I have to give next week or, yes, blogging.
And yet, somehow, Moz has become a relatively successful technology organization. We’ve got some of the best and brightest engineers in Seattle taking on some of the most challenging software engineering problems and, in many cases, conquering them.
A popular Quora thread asked “What are some popular myths in software development?” I think the idea that only technical leaders can manage or lead software-engineering heavy teams deserves a place in the answer list. There are those who’ll proclaim that a great software company can’t be built or run by non-technical people. But I’d counter that numerous founders, leaders and managers with virtually no knowledge of essential parts of their business have achieved great things.
Tiny teams have built companies with exceptional marketing and had success spreading their message despite no formal knowledge. CEOs devoid of sales experience or formal training engage in the practice all the time. Others boldly flaunt their lack of an MBA (which includes knowledge of formal accounting, finance, management, economic theory, etc), yet have raised money, engineered complex financial transactions, hired great managers and taken companies from birth to IPO. Amateurs in spaces like travel, media, mobile, gaming, real estate and dozens more build category leaders by learning on the fly, hiring well and leaving the technical decisions to trusted specialists. Rarely do I see pundits from the startup world encouraging founders to personally engage in these specifics rather than hiring outside expertise.
Is coding unique?
Maybe.
Does having the ability to call variables via programmatic statements or store values in a SQL database inherently improve a founder’s chance for success in the startup field?
Probably.
But I’d put money that there’s plenty of other unique skills that can have a strong positive impact on that chance for success, and many of them don’t get nearly the attention or ink that programming does.
I’m still incredibly self-conscious about my lack of knowledge across the business. The key, at least for me, is to admit I’m an idiot and free myself of the stigma and fear. Not just to those around me, and not as a form of self-deprecating theatre, either. But because in order to make good decisions I have to understand the issues, the problems and the potential solutions. That doesn’t always require deep technical chops, but it does mean asking a lot questions, some of them potentially dumb, embarassing ones.
This method functions in diametric opposition to many of the power-based relationships I’ve seen in other organizations, and even at times here at Moz. But as I’ve gotten more comfortable in my skin, I’ve found value in specialized knowledge of all kinds. And as we’ve hired talent and grown more mature as a company, one of my favorite responses to hard questions (both to give and receive) is “I don’t know. But I’ll find out.”
No matter your position in startup world, I think appearing ignorant beats remaining ignorant, even for those who are supposed to “have all the answers.” And discounting a person’s ability to contribute because they can’t write code feels like a fad. Facebook’s doing it; Google sort of did it; the tech press and VCs are obsessed with it, so it must be right. I’m not convinced.
That said, I’m still planning to watch some of those Khan Academy computer science lectures. : – )
p.s. It goes (almost) without saying that the only reason I can afford to be non-technical is because I’m surrounded by a bunch of geniuses. This post is in no way to meant to detract from the remarkable work or critical function provided by engineers and developers in startups the world over, but merely to highlight how I’ve come to deal with my own inadequacies in the field.