Being an engineer working with a non-technical colleague, cofounder, or manager can be a challenging experience—they often don't understand the true complexity of what's being built. So too can being a non-technical business person working with engineers when they slough off deadlines or ignore nagging bugs. Far too often, the chasm of understanding between these two groups can create frustration—or worse. But it doesn't have to this be way.
Here's how to think about the relationship, no matter which side you're on. Hint: It's the non-technical folks who have to extend the olive branch.
"When I look at the balance in a startup, what I try to do is evaluate teams rather than individuals," says Bubba Murarka, a general partner at VC firm Draper Fisher Jurvetson, and a former business strategy guru for Facebook who helped broker key deals with the likes of Microsoft, Netflix, and Yahoo.
"When I look at a team of cofounders, I want to see a totality of skill sets realized—which does include technical skills, says Murarka. "But while sometimes that’s going to be one person with all the skills, sometimes it’s two—or even up to four, which is the largest number of cofounders I’ve seen."
To Murarka, it doesn’t so much matter that every member of the team is a master coder, as it does that all team members realize it's the programmers who actually bring the application to life. In this way, being a productive team member doesn’t have to mean technically being able to code, so much as it does being able to articulate your competitive advantage and your long-term mission statement in technical terms.
"In some ways, having a clear vision of the future that you can convey to the other people in your group is the most important technical skill you can have," he continues. "That might mean coding—or building software—but other times it means knowing enough about what you want to achieve to bring the right team of people together to execute your vision. The predominant technical skill you need as a founder is to know what it takes to solve problems, build a product, and bring it to market."
Since coders may spend more of their day writing in (say) Python than they do English, it is no exaggeration to say that business people and programmers speak different languages. This can be a cause of friction within working relationships, and is one reason why it is advisable for all team members—no matter how technical—to have a basic understanding of code.
"At Facebook, my technical background made me uniquely valuable in the role I was doing," says Murarka. While he wasn’t expected to be technical as part of his role, the fact that he was able to interface just as easily with people from all parts of the company made his job that much easier.
"If you’re a smart founder, I think you want to understand what it is that the people around you are doing," Murarka continues. "A struggle I see with non-technical founders is less to do with the fact that they don’t have a technical background, and more to do with a communication problem because they can’t work out how to get people who are highly technical to believe in what it is that they’re after."
Redpoint VC Ryan Sarver—formerly Twitter’s director of Platform—agrees with him. "I would recommend anyone who wants to work in tech to at least get some basic competency skills as a coder," he says. "You don’t have to be amazing at it, but at least have that baseline understanding of what it is that you’re working on. There’s a real advantage to be able to build and prototype something that you’re thinking about, which engineers uniquely have. Even if it’s not the version that ends up shipping, it’s a great way of getting people to rally around a product that you’re thinking about."
For Sarver, it goes deeper than being self-sufficient. It also fosters a type of professional empathy, which he views as key for business relationships.
"Speaking personally, I was never the best engineer, but I had enough competency in it that I was able to have empathy for the people I was managing, because I knew what I was asking for, and what this actually meant in terms of the amount of work I was asking them to do," Sarver says. "It matters both in having their respect, but also in terms of managing a team. You know the difference between a tough development or an easy development. Without that, I think a lot can be lost, and that can make your job much harder as a manager of people."
But while coders might therefore feel justified by demanding that their boss understands a bit about what it is that they do—just as a hotel owner should have an appreciation for what a hotel receptionist goes through—it is also important that they try and appreciate the importance of different skills.
"There needs to be an appreciation of what non-tech founders bring to the table," says Paul Biggar, founder of automated testing startup CircleCI, and a PhD in Computer Science. "Building relationships, and off-line traction and community—these are the kind of things that non-technical founders can be very good at. When I look at the skills that have served me best as a founder, the vast majority of them have been non-technical by nature. By that I mean the ability to talk to people, the ability to convey a vision, the ability to coalesce customer requirements into actual products."
Ryan Sarver also points out that the systematic approach of the coder can sometimes differ from the approach of the non-technical person. While this can result in contrasting—sometimes conflicting—viewpoints, it can also be invaluable in creating an effective solution.
"If your [company’s] only hammer is a technical one, then every nail looks like something that can be solved through technical solutions," Sarver says. "The best teams are the ones that are well-rounded, and can bring different points of view. Sometimes I worry that Silicon Valley over-rotates toward technology being the only available solution."
Sarver points to a company like online voucher service Groupon, which adopted an approach to business that could only possibly have come from a non-technical founder.
"The main question comes down to problem solving," he continues. "The successful entrepreneurs and founders are able to single out a problem in the world, and work out how best to solve it. There are certainly some problems that are best solved through technical solutions, but there are others that aren’t always about creating the most beautiful technical solution. Sometimes people without a technical background can have a different way of thinking about problems in a way that brings a fresh perspective that you might not get from a technical founder."
At the end of the day, technical and non-technical team members have different approaches to what they’re doing—but arranged correctly this can result in a more positive, inventive approach to business.
"My philosophical answer to the question is that people should focus on where they have passion and strength," says Bubba Murarka. "If they find themselves enjoying the process of software engineering and coding that’s great—it’s something I would recommend they take further. At the same time, limiting someone’s options in business because of something they don’t feel passionate about is only going to stifle untapped potential. My pragmatic answer, however, is that if you want to maximize your chances of successfully running your own tech company, being familiar with software engineering is a tremendous advantage."
By exposing themselves to different ways of thinking about work, both technical and non-technical individuals can benefit. Coders should expect everyone they work with to empathize with what it is that they’re doing—but should also be open to problem-solving approaches that are non-technical in nature.
And as for non-technical folks embracing coding?
"I liken [coding] to knowing the Matrix exists," Sarver says. "Suddenly you’re able to manipulate the world around you, and understand how everything fits together. When you’re thinking about problems you want to solve, it gives you a different skill set. You don’t have to be deeply technical [as a founder], but it’s incredibly useful to be able to understand how the machines you’re interfacing with function. You see a world that was there the whole time, but that you now have a more solid grasp of."
Ultimately, it’s all about balance. Get that right, and you’re onto a winner.