The Non-Technical Founder's Dilemma

To Partner with a Technical Co-Founder or Not to Partner?
March 18th, 2024

I’ve watched this play out painfully so many times in my career. Other technical founders will tell you the same thing. I heard it again from three different types of people just last week alone in mentoring sessions, external code reviews, and casual conversations with investors in my own startup ecosystem.

Last week’s conversations included:
  • First-time, non-technical founders in the US and UK with the potential to solve much-needed, real world problems with technology, but seeking orientation at the idea stage.
  • Seasoned, non-technical founders who have bootstrapped development externally, and are now taking stock of where they are, relative to where they want to go.
  • Burned investors reigning in much needed capital after having made too many early-stage investments in founders who ran out of runway in an outsourced, software development effort.

Don’t get me wrong. This isn’t to knock outsourced development. I use it and use it successfully, but I’m a technical founder. That’s the point. For those who are not and lack a technical co-founder, I can say that I’ve only seen it work at all when there is an existing, trusted relationship with the outsourced team, and excellent internal product management. That’s a rare scenario for non-technical founders - especially for first-time, non-technical founders.

What Makes a Great Technical Co-Founder?

A technical co-founder can come in different forms and be compensated in different ways, but must be qualified. I think that a good technical co-founder - or anyone satisfying the role of one, regardless of his or her time commitment or financial interest - is going to be one who understands the strange and perilous life cycle of a company - from idea to exit. It takes more than a software developer who can code. I think that a great technical co-founder for a startup should be very hands-on with the coding effort, but bring perspective and cohesion across multiple disciplines. I share those below, and am happy to provide a free mentoring session to anyone seeking more insight. I know lots of others in the tech founder community who would sincerly offer the same.

Some advice to First-Time, Non-Technical Founders...

If you’re a first-time, non-technical founder wondering if you should get a technical co-founder, then my answer is a resounding YES! Please, please, please do. I think you’ll find that most investors will tell you the same thing. The right technical co-founder can save you so much time and money. And please don’t overly concern yourself with equity dilution. You can own 100% of 0 and it’s still 0. There are ways to approach and align incentives properly, keep your cap table clean, and protect your founder investment.

Some advice to Seasoned, Non-Technical Founders...

If you are a seasoned, non-technical founder and concerned with the velocity of your project relative to your cash burn, then I highly recommend an external review. You need to understand what you have and how close or far away it might be from the light at the end of the tunnel. Perhaps you’re just looking for the right questions to pose back to your team. Again, I’m happy to chat.

Some advice for Investors in Technology Startups...

If you invest in technology startups, then - well - you already know the truth of all of this. But if you’re non-technical too, then perhaps you need someone with a technical co-founder history to help evaluate your investments. Maybe you’re a venture studio building an all-star team within a startup. I always learn things that are super-valuable to me as a founder by talking to investors.

Here's Why Technology Startups Need Experienced, Technical Leadership.

Regardless of your company type, stage, or business angle, a technical co-founder should be able to dive in and provide value in most, if not all, of the following areas:

  • Code Quality Assessment
    • Readability and Maintainability: Evaluation of how easy it is to read, understand, and modify the code. This includes adherence to coding standards and best practices.
    • Architecture and Design: Analysis of the software architecture and design patterns used, ensuring they are appropriate for your application's requirements.
    • Consistency: Checking for consistency in coding practices across different parts of the project.
  • Security Analysis
    • Vulnerability Assessment: Identification of potential security vulnerabilities within the code and the overall software infrastructure.
    • Compliance: Evaluation of the code's compliance with relevant security standards, data privacy requirements like GDPR, and best practices.
  • Performance Evaluation
    • Efficiency: Analysis of how efficiently the code performs its tasks, including resource usage (such as memory and CPU).
    • Scalability: Assessment of the code's ability to scale with increased load, which is critical for growing startups.
  • Quality of Documentation
    • Code Documentation: Review of the availability and quality of inline code documentation and external documentation (like API docs), which is crucial for future development and maintenance.
    • Technical Documentation: Evaluation of system architecture documents, setup guides, and any other technical documentation provided.
  • Testing and Reliability
    • Testing Strategies: Review of the testing methodologies used, including unit tests, integration tests, and system tests.
    • Test Coverage: Analysis of the extent of test coverage and identification of critical areas lacking tests.
    • Bug Reports: Examination of existing bug reports and how they are managed and resolved.
  • Compliance with Standards and Best Practices
    • Industry Standards: Assessment of how well the code adheres to industry standards and practices for coding, security, and performance.
    • Dependencies Management: Review of external libraries and dependencies used, ensuring they are up-to-date, securely integrated, and licensed in a manner consistent with your exit strategy.
  • Future-Proofing
    • Technology Stack Assessment: Evaluation of the technology stack used for its longevity, support, and suitability for the project's future needs.
    • Flexibility for Changes: Analysis of how easily the codebase can adapt to future requirements, feature additions, or changes in business direction.
  • Business Alignment
    • Alignment with Business Goals: Analysis of how well the software meets the current and projected business goals.
    • Recommendations for Improvement: Concrete suggestions for improving the code, architecture, and processes to better align with business objectives.
  • Cost Efficiency
    • Development Efficiency: Insights into whether the current development practices are cost-efficient considering the output quality.
    • Maintenance Costs: Analysis of potential long-term maintenance costs based on the current code quality and practices.
  • Product Management
    • Agile Practices Adoption: Evaluation of how well Agile methodologies are integrated into the development process, including the use of sprints, stand-ups, and retrospectives, to ensure a flexible, iterative approach to product development.
    • Product Backlog Health: Analysis of the product backlog for its organization, prioritization, and clarity. This includes assessing how well the backlog items are defined (with clear acceptance criteria) and whether they align with the product roadmap and business objectives.
    • Roadmap and Release Planning: Review of the product roadmap for its alignment with business goals, market needs, and the technical capabilities of the team. This should include an assessment of the planning process for releases, feature sets, and iterations, ensuring there is a balance between delivering value to users and managing technical debt.
    • Stakeholder Engagement: Examination of the mechanisms in place for gathering and incorporating feedback from all stakeholders (customers, business, and development team) into the product development process. This includes evaluating how feedback influences backlog prioritization and roadmap adjustments.
    • Risk Management and Adaptability: Assessment of the processes in place for identifying, monitoring, and mitigating risks throughout the development cycle. This also involves evaluating the team's ability to adapt to changes in the market, technology, and project scope.
    • Team Dynamics and Collaboration: Insight into how the development team collaborates and communicates, ensuring that Agile practices are fostering a productive, inclusive, and innovative team environment.
    • Continuous Improvement: Review of the practices in place for continuous improvement within the team and the development process, including regular retrospectives and the implementation of actions to address identified issues and opportunities.

Feel free to reach out if this struck a nerve. It is one of a few, common reasons why startups fail. Most fail for avoidable reasons. This is a big one.

Comments