I receive a good chunk of emails and messages from people in my network asking for general technical advice (infrastructure, architecture, picking the right platform or a vendor, etc.) And many of them openly disclose they have spoken with 5–10 people and brainstormed over the different answers they get.
Asking for a hundred different opinions may get confusing, though. I wouldn’t advise you to ask an open-ended question on Quora, Stack Overflow, social media, email blasts, personal network, friends, and recommendations.
Prepare that into multiple phases – half a dozen generic, high-end answers, sift through them, and narrow down your options, iterate with another group, expand upon or niche down even further.
Best-case scenario, you source advice from people who would potentially work in your team if you scale enough. This means that they would be willing to participate in a venture started in a certain way, what they advocate for.
Are You “Guesstimating” Your Tech Solutions?
The reason it’s so confusing is the variety of alternatives in the field and the lack of proper industry statistics or benchmarks.
Almost every problem in tech can be solved in a dozen ways or more. Some are more efficient than others, but most will work anyway.
The question is usually far more sophisticated as you need to project your business into multiple dimensions. What may work most effectively within the first 6 months may not scale past the 6th year, and the enterprise-grade solution will be overkill early on.
It also revolves around other aspects of the job — the type of community you want to engage with, the available workforce in your area, and future integrations with other tools or services.
The evolution of the business will start hitting different limits, but unless your business plan can reliably predict 10 years ahead, you’re guesstimating anyway.
How to Get Technical Insights
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, or 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 that 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, and 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 to the actual business needs.
This is why a non-technical founder may be instrumental given the right leadership on the technical end.
My advice would be to look for several trusted technical architects/team leads in your network with a decade of experience or more. Use other sources if you can, Quora being one option and technical consultants too. Ask for referrals and recommendations. Attend technical events and meet people there.
Tech people may be fairly open to sharing their 2 cents if approached the right way. Just don’t get overwhelmed with a hundred different options as you may give up too soon.
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.
You can hire a senior engineer and design a payment structure that doesn’t include equity. Best-case scenario, you’ll still give up some equity in order to keep your staff motivated.
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.
One really viable option is to designate a Chief Technical Officer (CTO).
Let’s debunk some myths as we review each part of the following questions separately.
1. Why Does a Company Need a CTO?
It probably doesn’t. But probably not for the reasons you’re thinking.
Roles, as such, are a formality. The CEO of the company may label themselves as the “Bearer of Good News”. The head tech person may be the “Cable-wrangling Soldier”.
Those roles could be misleading as well. A contract could be worded in a way that gives the full power to the CTO. Or an external owner of the company that’s not listed in the public records.
A contract is not necessary even in some instances where a couple co-founders simply decide on the chain of command which may not be obvious from their titles.
Businesses use the designated titles for brevity when looking for investors when talking to the press or in order to give a rough idea of hierarchy to the public (including when onboarding new employees).
2. Who Needs a CTO?
There’s usually a very good reason you are hiring a chief software architect.
The organization is large enough to need one for a massively complex platform. That assumes that a CTO is around, a bunch of tech leads/consultants, other software rockstars are employed.
Otherwise, it’s still a leading role but normally appointed through the CTO or a technical CEO.
Assessing tech skills isn’t easy for a senior role. It’s either an “emotional” decision or a purely data-driven one.
Emotional is a product of a veteran developer working on the team or hiring an old acquaintance that’s trustworthy (reliable, well-behaved, hard-working). Tech skills are obviously an important aspect but, more importantly, making sure that the lead will stick around for at least 5 years, without causing major cultural shock, is very important.
The data-driven decision combines experience, CV, portfolio, source code, references from tech leaders, industry talks, courses led or PhDs in the field, things like that. Some are more academic, others – more practical (experience in other large corporations or startups with a successful exit).
You rarely hire a chief architect out of nowhere. You either don’t need them or the CTO or some other devs are capable and trustworthy enough to assess the competency if that’s the path you want to take.
3. Who Can Work as a CTO?
Why hire a CTO if the VP of Engineering manages day-to-day operations?
There is no “legal” reason to do so. For instance, the VP of Engineering can act as a CTO.
As stated above, the reason for using designated titles is establishing a certain role in the company hierarchy.
Your head developer could act as a CTO. Often, the CTO is not the most “technical” personal on the team (the best developer and all). It’s much more about:
- Strategic vision.
- Understanding the broad spectrum of technical requirements.
- Defining the appropriate product/infrastructure roadmap.
- Ensuring that the hiring process is planned and executed properly (often through the VP of Eng when available).
Which is also why a VP of Engineering may be more suitable for day-to-day operations than a CTO.
Technical founders appointed as CTOs often bring a VP of Engineering in as soon as the overwhelming flow of questions and generic problems are too much to bear. Again, CTOs have a strategic role – research, architecture, platform design, picking the right technical layer for a new solution, etc. They don’t necessarily come with the “soft skills” package either.
The VP of Engineering is the technical manager on steroids. Understanding tech very well, but the focus is primarily on communication, building the right technical department (including hiring), ensuring that teams are structured effectively and operating efficiently.
4. Can Technical CEOs Cover the CTO’s Role?
It can be very hard – and hardly reasonable.
If a technical founder is completely focused on the technical end, they usually bring a CEO in.
The role of a CEO entails overseeing each and every high-end aspect of the company, building the vision of the organization, creating strategic partnerships, engaging in media activities (interviews, PR), and much more.
It’s a leadership role. It’s not limited to the tech department as a growing organization branch into a creative team, marketing department, sales team, finances, operations, hiring, revenue…
Working closely with the tech team (on behalf of a CTO) would drastically limit the attention of every other team in the company.
The Limitations of Technical Founders
As a technical founder myself, I had expertise in leading 10–15 people teams and teaching technical classes for up to 150 people in previous companies.
I couldn’t handle more than 6–7 tech people under me as a founder.
- I had regular meetings with clients.
- There was the marketing strategy whereas a CMO was (and still is) not available.
- I had to handle payroll and finances.
- There were interviews for all sorts of roles and I was heavily involved.
- Budget planning and investment decisions (staff vs. automation vs. increased ad spent).
The list is longer than I care to admit and I had dozens and dozens of varying activities to take care of on a weekly basis.
The larger the team, the more impractical it is for a CEO to cover for a CTO. Either everything will go south (all of the other departments), or you’ll try juggling between 5–7 teams weekly, paying limited attention to each.
This may lead to a decreased employee satisfaction (and layoffs), delayed milestones, chaos in the tech department.
A CTO is a CTO for a reason. A CEO should not step in as a CTO unless the startup has just been bootstrapped (< 5 people). VP of Engineering is a managerial role handling day-to-day operations while CTOs are in charge of research, architecture, design, and the technological vision of the company as a whole.
How Is a CTO Different From Project Managers and Lead Developers?
A project manager may deal with your offshore team and your client – or your management team if your products are internal. This may be handy in terms of keeping everything on track or reporting delays and possible problems early on.
Your project manager can also identify problems or help out with testing the separate iterations of the product, assist with documentation, and so on. If you implement an agile model and there are regular scope changes, someone should be in charge of communicating these to developers and updating the time frames accordingly.
The drawback would be the lack of programming know-how. Some delays may be caused by technical problems or architecture that hasn’t been planned for your use case.
Assessing delays would also be a problem as there would be no measurable way to identify the covered test/use cases, how long would it realistically take to finish the rest, and is the platform stable enough to get the project done without having to refactor most of it.
A lead developer would be technically experienced (ideally in the same programming stack) and could work closely with the other developers on requirements, estimates, and the proper implementation of features.
This may work out well from a technical standpoint – ensuring stability and reliability of the products and a local trusted member who can manage the code quality. Estimates should be more accurate, too.
The problem is that more agile projects (or rapidly evolving ones) would still require a lot of back-and-forth with non-technical team members (your management team or your client). Developers with no PM expertise can often postpone projects or implement features in a way that is not necessarily the best option for the specific business case (for instance, introducing additional layers for stability, performance, or something else for an MVP that wouldn’t need that over the next 3 years).
As some senior developers may disagree, I’d say that a technical project manager or a lead developer with outstanding soft skills and business experience would certainly be “the best of both words”. Definitely more expensive and harder to find, but both “edge” alternatives have some limitations that may eat up extra time each and every month.
Hiring CTOs Internally vs Externally
That depends on the size of the company, its long-term goals, and the different stakeholders involved in the process.
A fast-growing funded startup has different goals when compared to a small shop bootstrapped by a technical guy in charge of the business activities now.
Unless you’re a large organization that grew incredibly fast, looking for talent internally may be a good option. Identify leadership roles within your technical team who have already received a promotion or two (team leaders, senior technical managers).
Those people have already shown commitment and potential. They are aware of the business processes, the technical environment, and the dev team. A promotion would be somewhat seamless for someone deeply involved in the technical process over the past years.
Rapidly growing companies may require someone who can take the business to the next level. There are different steps in building and growing a business. Not everyone is prepared for (or capable of) making the jump and setting the foundations for the next iteration.
In that case, you are probably looking for a former CTO, a VP of engineering, or a technical manager who is aligned with your process, vision, and goals.
CTOs have different roles in different organizations – some are extremely technical, involved with R&D and actual hands-on while others primarily manage the process and evaluate software alternatives and high-end approaches.
A CTO is a “partner in crime” in the business. This could be a long conversation with someone you’ve known for a while. It requires serious commitment and understanding of the business goals, determination to grow with you and nurture the technical team (and the product development) over time. It shouldn’t be underestimated in any case.