Why you probably don't need a CTO

The CTO and fCTO market is completely saturated. Everyone is elbowing for a C-level role, fractional or otherwise. But what does this actually mean?

The role of a CTO is to develop, implement, and pivot as necessary through a long-term tech strategy. Most companies already have an app or software running and a short—and long-term vision.

However, the role is often Project or Product Management, possibly coding. None of these are the roles of a CTO; they are aspects of the long-term strategy and execution for successful software.

Reasons why CTO may be the wrong choice

• You need the CTO to write code as a primary duty.
  • You may instead want an architect or dedicated senior developer. An experienced CTO should not write code daily unless the team is small. Remember that a CTO with one developer is hardly a CTO.

• Most dev teams are less than 10 people, or the organization has less than 20 people.
  • Small team CTOs are not CTOs; they are coding managers, occasionally creating a vision; the title is often a resume hit for the developer until the company grows and needs a true CTO or realizes that the role serves no one.

• Established companies need continuity and accuracy, not vision.
  • A CTO will not differ from a technical PM if you have technology running and a long-term plan. A CTO is not a requirement. Instead, it is wise to invest in knowledgeable people and solid planning.

• Do you need someone to create a long-term technical vision or execute it?
  • Whoever said strategy must come from a CTO? Seriously! Technical project managers in agencies work successfully to create long-term strategies; I know because that was my role in agencies for years. Often, the results are better because delivery is the focus, and there is no time woodshedding for the perfect plan. Instead, execute, pivot as needed, and repeat.

• Pressure from investors to find a CTO or to get funding is a poor excuse.
  • Ask yourself why? A CTO takes a long time to hire and vett while your features, bug fixes, and growth are put on hold. Add in the long ramp-up time for a C-level position, all the due diligence, and training, and that position can consume 6 months or more and cost a lot more than a fractional approach. Don't be unagile; find professionals to deliver, not just for a title.

The CTO and fCTO market is full, if not overflowing.

My experience as a CTO and fCTO, combined with over 20 years of experience in software, informs my opinion that I recommend against CTOs (most of the time).

Many organizations' expectations actually align with those of Technical Project Managers or senior developers.

Companies need action, not vision. The vision part is easy; sticking to that plan is the domain of professional managers.

Statistically, companies are small (95%+ are 20 people or less in the USA). Companies need people who wear many different hats. One of those hats can be CTO, but is that really a CTO?

Many companies [think they] want CTOs who code, which is antithetical to the role. Occasionally writing code is development done poorly. Full-time coding is not a CTO. Code reviews, work allocation, and feature delivery are not the domain of the CTO but are required more than "vision and strategy." Consider a good senior developer instead.

A true CTO position depends on a large management structure of VPs, directors, and other managers. Each subordinate role commands many people, with the CTO at the top of the technology hierarchy. Few companies are in that position or ever will be. America is the land of entrepreneurs, and because of that, action and experience speak louder than the title.

True CTOs deliver a vision for technology that spans years and guides the software to fruition. And then we rebuild. Skilled consultants, architects, or managers cost less, bring a well-rounded experience, and set up systems that scale and allow for the addition/removal of team members.

Then again, what if I am wrong?

What if a "CTO" is actually a Technical PM with a different title? What if the CTO is slowly being absorbed by the mediocracy of taking a once strategic role and watering it down to "lead" for small teams?

CTO as a title is the trend. Unfortunately, this trend costs companies in important areas and underscores my message.

The first is Cost.

CTO roles demand more money, but most candidates rarely deliver on that extra expense.

The hunt is hard work!

The hunt for the right fit and person often becomes all-consuming. You are punishing your users, codebase, and dev team. I will remind you that poor management generally makes the dev team ready to jump ship. I know this because I have had many software roles. I often left because of poor leadership or a lack of opportunity.

Don't be short-sighted.

There are too many one-person companies with a CEO. Don't play that game. Single-person companies are freelancers or solopreneurs, not CEOs. The same is true for many CTOs.

Mediocracy brings all of us down.

As a former CTO and occasional fCTO, I can testify to the fact that many CTOs prioritize titles over actual experience. I have held these roles repeatedly but consistently outperformed in roles such as Technical Project Manager, which also cost less.

I deliver value for companies as a Project Manager, Product Owner/Manager, and Scrum Master supported by millions of lines of code. I have managed DevOps/Infra/SRE teams and been a sole practitioner in this craft as well; I get the job done and do it right. In my experience, organizations that had no CTO were much more successful. A solid senior developer often accomplishes much more than a CTO and out-codes most CTOs.

I consider CTO-less companies often superior. Usually, a small handful of established employees out-skill, out-code, and have a larger technological footprint than the CTO could ever possess. These craftsmen excel because they don't want the role of CTO and instead focus on software, coding, and making the best application possible. These are skills that few CTOs actually bring to the table.

You have been warned.

Don't believe me? Let's talk. I know some of the best fCTOs out there. I have also been an fCTO and CTO many times. My performance was exceptional, but the work taught me the above-mentioned lessons.

You probably need solid technical leadership and not a CTO.