I’m the “nontechnical” co-founder, but I relearned how to code for Merge.
That wasn’t in the initial plan. My professional background is in finance and operations. Since I had partnered with a highly technical co-founder, it seemed natural to divide our responsibilities. I thought that there would be enough work with fundraising, user research, partnerships, recruiting, etc. in the early days to stay busy, and my co-founder Gil would oversee product and engineering.
But we’re ambitious and have a strong vision, so we wanted to build a high-quality, feature-rich product that would make a great first impression on the market. As a result, I quickly realized that the biggest impact I could have in the early days was building Merge as a software engineer alongside my co-founder.
My co-founder invested heavily in me in those early days and helped me relearn how to code (I studied computer science at Columbia). This was a big time investment on his end, but it was extremely valuable and has been consistently helpful throughout our journey. I thought re-learning to code would only matter as we were building the product, but it has actually shaped how I approach leadership as a CEO.
Do Startup Founders Need to Know How to Code?
Yes. Even if you’re not the one building a product, you still need to understand what goes into it so you can communicate with your engineers and your customers.
More Information Means Better Decisions
Andy Grove, the former chairman and CEO of Intel, wrote in High Output Management that managers have two responsibilities: gathering information and making decisions.
Throughout the past few years, I’ve focused on gathering information and making effective decisions by getting in the weeds, and knowing how to code has helped.
I’m more engaged in internal roadmap meetings because I can speak to feasibility, timelines and tradeoffs in a way that’s grounded in experience. For example, when we have to discuss timelines for certain tasks or larger projects, I’m able to gauge whether a timeline is conservative or aggressive and whether we should scope something down.
I’m able to support our go-to-market teams by participating in roadmap conversations with customers and prospects, where I can quickly visualize how we would implement their requests and estimate timelines.
In interviews with technical candidates, I’ve found it easier to share specific details on what we’re building and what kind of projects they could be working on. For example, if I’m speaking with a candidate for a partner engineering role, I can walk them through the integrations they’ll be working on and how they’d go about building and maintaining them.
Last but not least, I can get hands on and actually code, whether that’s addressing a ticket to resolve a customer request, contributing to a new product feature, building our design systems and more to keep our development process moving smoothly.
In short, my coding skills enable me to better support different teams. I can help recruiting fill important roles, enable sales to close key deals, empower the product team to prioritize the right set of features, and work with engineering to directly improve the product.
Building Credibility With Customers and Prospects
Merge sells to technical buyers, and technical buyers can immediately tell if a seller knows what they’re talking about.
Prospects want to understand how our Unified APIs are structured, how we handle scalability, edge cases, security and how our product is differentiated in the market. Being an engineer has helped me speak accurately on those topics, and that’s helped me build credibility. This, in turn, has made it much easier for me to close deals and renew customers.
If I couldn’t get into the technical weeds, I’d be stuck having surface-level conversations full of marketing speak. This would waste the prospect’s time and make our product seem no different — if not worse — than any other.
Working Alongside Engineering to Explore AI
Knowing how to code has made me even more bullish on the potential of AI coding assistants and other emerging AI tooling across go-to-market and design. There’s so much low-hanging fruit on our roadmap that AI can easily accelerate.
At Merge, we launched an internal initiative to give our engineers and managers the space — and the budget — to research these tools, test them, and share what’s working. For instance, during our R&D all hands meetings, several team members will share specific ways they use AI in their day to day work to help educate and inspire the rest of the team.
My engineering background also allows me to contribute. For example, based on my research on AI tools, I’ve recognized that reviewing code will be an increasingly important skill, so our team is focusing on becoming fluent in this area. We’re also building out a new product, and I feel confident in deciding when and how to use AI while developing it. For instance, it’s well-suited for tasks that are less likely to impact customers directly.
What I’d Tell Other Nontechnical Founders
I don’t think most companies need a technical founder, and the founder definitely doesn’t need to understand code. There are many companies that can succeed by focusing on operations.
I do think all founders need to be open to being deeply in the weeds to understand what’s going on at their companies, however. And if your company is launching a technical product, knowing how to code certainly helps.
