Are you a non-technical person working on an IT start-up idea, or other technical business ventures, with a bunch of software techies?
Best-case scenario, find a technical co-founder and you are good to go.
While some non-technical managers and founders are capable of working well with developers, there may be different problems that would jeopardize the growth of the business. I have outlined what some of those problems are when working with software engineers and how you can deal with them, in the video below:
You may have a hard time hiring the right technical talent. Developers program code that may be flawed, insecure, slow, unstable. Inexperienced ones may take forever to build simple features. Failing to design the right architecture from the start will lead to technical debt – a foundation that’s hard to maintain and grow over time.
Lacking business or management know-how (common for software developers who weren’t in a leadership role or lacking freelance/business expertise) may lead to decisions which are not necessarily in line with the long-term roadmap.
Sure, you can find the right talent from day one. It’s just a gamble – you need to rely on their self-assessment which is rarely objective.
But a purely technical founder may struggle with the business aspect of running a company. There’s a lot going on outside of IT – business and market research, sales, marketing, accounting, legal work, customer service.
Most traditional developers are used to working on predefined assignments (specifications). Or coming up with ideas that seem lucrative from a technical standpoint – not necessarily related with the actual business needs.
Which is why a non-technical founder may be instrumental – given the right.
My Experience As A Technical Co-Founder
Back in 2010–2011, I joined a former client of mine in a new startup. He tried three or four teams before partnering up with me.
I joined a project he won prior to that. His technical co-founder failed to align the time frames and we went past the deadline with 2–3 months of extra work to follow. The guy disappeared and stopped picking up his phone. He simply bailed as he had no experience working with customers in his previous roles.
I stepped in, met with the client a few times, dealt with frustrations and managed to negotiate another 3 months. The project was finally delivered and – surprisingly – everyone was happy in the end.
Plus, it was a wonderful project funded by UNICEF that I actually enjoyed.
So my client has offered me the CTO role in his new business. While I left a couple of years later, it’s still a successful business and most of my hires are still involved with the project. Our lead developer took my seat and he was absolutely the right fit for growing the business even further.
We still meet every now and then at Starbucks. My former co-founder is running business operations. His business and market research is absolutely crucial for new product launches.
The company is quite profitable (about 70% margins), the team is efficient and happy and works remotely. I am super happy for them and always love receiving their newsletters showcasing success stories and new product launches.
Are There Other Ways Besides Co-Founding?
Most people are intimidated by the “co-founder” label and try to dodge a bullet when they try to get some help without giving too much.
While finding a technical co-founder may help out a lot, it’s not the only way.
A fixed paycheck wouldn’t motivate most people to respond to an important email after hours or over the weekend. Or try to bring some clients during a conference. Some form of “ownership” may help out.
Contracting an entire agency may also be a viable option – although it may be a bit more expensive (given the management overhead). But you can tap into different skills and resources provided by the agency.
When Non-Technical Founders Have To Deal With Source Code
I see three major problems when non-technical founders have to deal with source code:
- Inability to understand the business problem in hand
- Poor code quality
- Lack of hitting certain KPIs
Tips On Fixing Source Code And The Business’ Other Technical Problems
1. Explaining The Business Goals
You have to be completely transparent and spend a lot of time with your technical staff discussing business. It’s important to discuss business problems and how your platform or software solution will solve them.
Share some business insights from your business plan. Discuss your competitors. Talk about your target audience and their demographics. Focus on the unique selling benefits and the most important features you want to incorporate.
Build use cases. Prepare flow charts. Design some scenarios resembling the usage of the product by your prospects.
The more your technical staff is acquainted with the customer needs, the easier would it be for them to build something that fits into your requirements.
2. Code Reviews and Analysis
A high-quality code is a vague metric. Sure, there are code conventions. There are “best practice” documents. But it’s unlikely that you will dig into this one yourself without learning a ton about programming on the way.
There are certain tools and systems that could automate that – Code linters, convention scanning tools, and the like. You can discuss that with your technical team and browse for some tools yourself that would reduce some of the basic mistakes.
They won’t catch everything. But, some automated testing tools will monitor for warnings and notices, intercept CPU spikes, or handle a subset of common problems that could be detected while parsing static code.
If you work with several different independent developers, you can assign them to perform code reviews across the entire code base. This could help to identify problems as well.
Signing a consulting agreement with an independent technical consultant or an agency will help you with objective assessments from a third party. There are plenty of senior engineers providing consulting on the side. They could review the latest commits every couple of weeks or run independent tests locally or on a staging environment.
3. Defining the Right KPIs
In addition to the functional requirements, you may set certain KPIs for the technical platform.
Identifying the right KPIs may still take some time (or require some help) and also depends on your business and the platform requirements. Solving more complex problems will also take more time and will cost more – but you don’t want your platform to crash once you start generating some traffic.
Some measurable ideas that don’t require programming understanding are:
- PageSpeed or YSlow scores that could be assessed with
- A certain number of concurrent users that the platform can handle (this also depends on your hosting)
- A seamless interactivity with a certain amount of volume (say, hundreds of thousands of records)
- 100% coverage and success rate when using some penetration test/security scanning tools and services
The more specific the list, the easier it would be to track success and ensure that the platform would solve the right problems without deviating too much or being unstable as it grows.
Overall, finding a co-founder will solve many of those problems. But creating a mix of experienced developers with a technical consultant spending 4–8 hours monthly on your project could also work out until you generate some revenue and scale your team.