Working With Your (Non) Technical Co-Founder
Whenever I give a presentation or sit on a panel I often introduce myself as a recovering English major. This serves two purposes: 1) as a new dad I have to get in as many lame jokes as possible and 2) it delays people from asking the inevitable question: are you technical?
I never know how to answer.
I began in startups as an unpaid marketing intern whose biggest value-add at the time was my side job as a bartender (they had a bar in their office). Servers and apps meant very different things to me back then.
When I first started working hand-in-hand with engineers it felt a bit like stepping through the brick archway to Diagon Alley — into a whole new world full of magic. They were wizards, and the things they can do and build never cease to amaze me. I doubt I’ll ever get to that level.
However in the past 3 years, I’ve learned enough front-end development to build a bootstrap site, I’m decent at debugging code given unlimited time and access to Stack Overflow, and even I can look like a wizard sometimes to my non-tech colleagues when I automate a task with IFTTT or Zapier.
When the question is asked, though, and I have to categorize myself to someone, I will always say “non-technical”. But that question really makes me feel like a TCK, stuck between these two groups. I don’t feel at home in either world (and believe me, people treat you differently depending on your answer).
Why Do We Categorize?
Businesses are complicated, and to get one off the ground you need both a broad and deep understanding of many different fields. For startups, many are building something that has never existed before, and the technical expertise required is immense. Naturally it’s difficult to be a deep expert in everything, which is why co-founding teams with complementary skill sets are so important. Each founder can be the “expert” in their area, and the skills of a technical vs. a non-technical cofounder are often very divergent, which leads to our quick classification of “technical” or “non-technical” founders.
The Dichotomy Leads to Silos
Here’s the thing, though: if you are co-founding a startup it’s imperative that you take the time to learn from your co-founders so you can gain a greater understanding and empathy for all sides of a problem.
I’m a firm believer that as a co-founder your job is to solve the biggest problem your company is facing that day. If that means closing a customer, as a CTO you have to be helping achieve that goal. If it’s shipping a product, as a CEO you better help get that thing launched.
It’s impossible to function this way if you don’t understand all aspects of your business. And oftentimes the attitude we have about “technical and “non-technical” co-founders (or even employees) contributes to forming silos at 10, 5, even 3 person companies.
Silos lead to frustration and failure. I spend a lot of my day as a liaison between technical and non-technical founders to help increase communication and improve workflow. Here are the top issues I see over and over.
Things Founders Do to Piss Each Other Off
Technical Founders:
Responding only with “It’s complicated” when asked why something won’t work.
It’s true, oftentimes the problems you’re facing are layered with complications. However, there may be other workarounds that you’re not thinking of, and if you shut down the conversation before you can even explore those problems you are not only putting off your co-founders by implying they aren’t smart enough to understand (even at a high level) the issue you’re solving, but you are also leaving out an opportunity for creative problem solving.
Asking “dumb” questions is one of the best ways to find innovative solutions to tough problems. And to quote Einstein — ”If you can’t explain it simply then you don’t understand it well enough.”
Saying: “We’ll just do marketing” when talking biz dev strategy
Mutual respect of each other’s abilities is important, especially for team dynamics. Because it’s harder to gain technical skills (or at least there are fewer technical people in the workforce) technical co-founders have a tendency to discount “soft-skills” as easy and not as important. I do believe it’s easier to take technical founders and teach them how to run a business than it is to take non-tech founders and teach them to be engineers (the accelerator model depends on this) but that doesn’t mean that one set of skills is more important than the other, and it doesn’t mean that business skills are easy to learn.
I can’t tell you how many times I’ve asked a technical founder, “How are you going to convince anyone that this is a problem that they should pay money right now to solve?” and gotten the response: “We’ll do social media marketing, SEO, viral growth hacking campaigns, yadda yadda yadda.”
What experience do you have doing those things? What makes you think that will work? That’s like asking a non-tech co-founder “How are you going to build this car that drives itself?” and them replying “We’ll just program it.”
“We’re not ready to ship yet.”
The eternal battle. Every cycle we spend dozens of hours arguing with every single team to get them to ship a prototype/beta/pilot product they are embarrassed of. Like Reid Hoffman says: “if you’re not embarrassed of your first product then you shipped too late.”
There’s something about the engineering mindset that doesn’t allow anything but perfection. The problem is, perfection is in your mind and it’s never what the end user/customer wants. You have to push yourself to get feedback as early as possible to prevent wasting time and money. The only exception to this is if you’re product has to potential to hurt someone (medical device, etc).
Non-Technical Founders:
“I scheduled 3 meetings today all 1 hour apart I hope that’s cool.”
Technical workers need large uninterrupted chunks of time to get work done. Interrupting them, even just for a quick question, can break their flow and it can take 30min+ to get back into the groove. There’s a pretty universal sign: if headphones are in don’t interrupt someone. When scheduling meetings, make sure you respect your technical founder’s schedule and only bring them in if it’s absolutely necessary.
“Sure, we can totally build that feature!”
Oftentimes non-tech founders talking with customers will promise features & services that they have no idea are even technically possible. The problem is, things that are very intuitive to humans can often be very hard to achieve technically. Without a background in the technology that runs your product you can get into some sticky situations.
“Sure, we can totally have that done by next week!”
Again, without an understanding of the technology and the challenges that come with it estimating ship dates and delivery to customers can be a dicey business. I’ve seen so many non-tech founder over-promise and under-deliver because they don’t understand the difficulty of the what they are proposing.
How to Collaborate
The most important part of building a successful company is building a successful team. That means setting a culture that respects everyone’s area of expertise, but still allows founders and employees to challenge each other’s ideas without fear of repercussion. It can be exhausting to explain technical details, or take the time to back up your course of action, but in doing so you will build trust, gain each other’s respect, and build the skill levels of your team to make everyone a more valuable team player.
— — —
Thanks to Nathan Speller, Chris Maury, and Andy C. Chan for reading drafts of this post.
