I often get calls from founders who feel that they’ve been at it long enough and that the time has come for them to hire, promote or invite a CTO into their startup.

The challenge

When starting out, the founder is faced with one problem, will they be able to build a product that solves a pain for somebody, hopefully many, people in this world.  Although this might be a daunting thought for many of us, the founder, a visionary, is most likely at the easiest part of their startup journey, and that is, to find a means by which to build a product.  They need to define their feature set and match that with an engineer, a dev shop, a cloud tool, or whatever to get that first solution in the hands of a human.

But what happens when that cycle turns into a happy outcome that now increases it’s appetite for faster technical development?  Two things:

  • the founder feels overwhelmed because their startup went from an MVP side project, to now also having to develop customer, build the business and possibly start wooing investors
  • the founder is being bombarded with technical decisions that need to be made that they don’t feel equipped to handle
  • the product market fit starts suffering because their customers love the product, but would love it even more if they saw a few additional features that weren’t really on the roadmap

The misconception

This initial success, especially for the first time founder, drives the urgency for technical leadership and technical leaders are called Chief Technology Officers no?  Well yes, but technical leadership comes in many forms and hiring a CTO is an involved process that I’ll write about in the near future.  I am huge fan of incremental changes where possible and bringing in a CTO is not an incremental change.  In fact, you might be focusing on one aspect of your business that needs the least amount of change or attention at this stage.  Hear me out.

Zig-Zag your way to a CTO

In the video above I explain the Zig-Zag method towards hiring a CTO and I’ll list the zigs and the zags here:

1. Find your Fit

Find your fit by any means possible.  I tell founders that there are plenty of ways to figure out if someone is going to pick up what you put down without breaking the bank.  Here are a few ways:

  • The No Code route: Build your concept using existing tools and then use zapier to integrate those tools.  This doesn’t require coding and there are plenty of resources that aim to solve this problem.  The upside is that you get to spend endless hours converting your ideas into reality which will often lead to you rethinking some of your assumptions.  The downside is that these solutions are harder to customize or build upon.  The main idea here is to see if you can help a prospective customer understand the solution you’re presenting for their pain.
  • The Dev Shop route: You’d be surprised at what you can build for $20k or less.  I’ll let you in on a secret.  Dev shops aren’t enticed by lump sums, they are enticed by retainers.  When they have retainers, your project is more predictable from their business standpoint and it’s easier for them to ramp up developers and keep them.  Great ways to get started is to ask, “can we get started with $3k or $5k/month?”.  This is a solid route if you’re totally clear on what features you want built and have wire frames accordingly.  This is definitely not the way to do things if you only have a vague idea of what you want built.
  • The Friend route: You can always tap into friendships or family to get your product build started.  I’ll just add that whatever is said about business ruining friendships is mostly true but your mileage may vary.  I may write something about how to go about this at some point.  A tip for how to do this would be to keep the business and equity and future conversations out of this and try make it a fun experience, eg. spend a day together in a fun location and grind something out.  Keep it to exactly what it is, friends who like to hang out.

2. Find an (active) Advisor

When founders reach this stage they have proven product market fit and can show revenues, usually less than $20k/m.  When you see money coming in, my suggestion is to not see this as a means to bringing in your first CTO.  I would much rather see you bring in an advisor.  Here are my requirements for what type of advisor you should look at:

  • Someone who is gainfully, and happily employed in the role of CTO and wants to help out some startups, otherwise known as help solve other people’s problems.  CTOs get bored.  We are also problem solvers, of the technical and the business kind.  There are many of them out there who simply want to help startups out.
  • Someone who is well connected is someone who can introduce you to future engineering or product resources you may need.  They could hopefully also introduce you to your future CTO.
  • Someone who is willing to spend 3-5 hours a week on your startup.
  • Someone who isn’t talking to you about advisor shares or equity.  This doesn’t mean that you don’t offer them a little something, but it’s not the main topic of conversation.

Your advisor is not writing code!  But if they want to that’s ok but be careful, you’re not looking for another developer, you’re looking for the leader of developers and process.  Their time is best spent on the following:

  • Meeting with you for an hour or two a week discussing your own business goals and customer challenges
  • Reviewing developer contracts, scopes of work and any documentation that you’ve generated
  • Checking with your dev team/technology resources for 15-30 minutes a day
  • Possibly joining your team collaboration tools like Slack or Teams

3. Find a Product Lead

This is the step that might be the least intuitive, but I would prioritize a product lead over a technical lead at this stage.  Once again, the assumption is that with the help of you technical advisor from step 2, you’ve increased revenues, or perhaps you’ve secured a cash infusion.  Don’t go running to a CTO but rather look at your CPO/Product VP/etc. options.  Here are my top reasons for going this route:

  • If you as the founder have been playing the product role up until now, you are undoubtedly distracted by what the business needs in order to operationalize it’s revenue.  This is a very nice way of saying that you’re probably not that great at this job anymore.  I know, I know, it’s like telling a coder that they’re better at managing now than coding.  It stings.  But truth is, as CEO/founder you need to focus on bringing in the people that will build your products while you make sure that the company rocks it on the culture front without running out of money.
  • I really love classically trained product managers.  They will fight for engineering empathy and more customer advocacy as they seek to focus the attention of the company on exactly what needs to be built.  A word of caution here, I think that there are many engineers turned product people that aren’t really suited for the role I am speaking of here.
  • Since you’re probably emotionally tied to the product up until now, you need someone that will be a strong counter to your ideas in the C-Suite.  I like the idea of hiring a CPO and not just a product manager.  This is literally a person who is going to say “No!” to many of your pet projects, are you ready? :)

For the longest time I thought that good CTOs would also be good product people but I am no longer in that camp as a rule.  Yes, obviously there are the exceptions, but I like to think that separating the “what” from the “how” to be really important.  If the CEO is a strong product person, I would recommend that the product lead report into the CEO even if there is a CTO onboard.

4. Find a CTO

And finally, we are in the quadrant where we have a very solid product market fit with revenues to show for it.  The need for technical leadership is probably felt by everyone and this is a great time to bring in a CTO.  When you’re in this quadrant you’ll probably feel the following burn:

  • deliverables lack in the quality they used to have, i.e. it seems like with every release you have more bugs
  • delivery has slowed down, also known as velocity
  • your development expenses seem to have gone up

These are just a few canaries in the coal mine indicating that there is a consumer mentality towards implementation and this ends here.  Find a person to occupy the CTO role, report directly to the CEO and help firm up the product engineering in order to satisfy your customer’s needs for high quality products.  What would the CTO focus on, you ask?  Let me highlight a few aspects that I consider to be important out the gate:

  • Team: your CTO needs to earn the trust of the existing leadership team (think emotional intelligence) and start focusing on bringing your technical competence in house.  As mentioned before you’re probably paying too much for the dev shop and quite frankly, the dev shop needs to know that there’s a new sheriff in town.  If the dev shop is still working for you, then the CTO will help stabilize cost and delivery estimates.
  • Tools: your CTO will help with the overall tooling in your company from sales and marketing tools all the way down to the financials integrations and the stuff that makes engineers happy.  These can be technology tools but also just best practices aimed at increasing the productivity and effectiveness of your people.
  • Scale: this could be another reason your costs are growing since you’re having to work with more customers and team members.  The CTO helps you scale your organization’s technical team and product availability so that customers never complain about downtime and your team never complains about the size of your backlog.
  • Strategy:  if you have your business and product voices in the C-Suite, it’s important to have that technical voice to round things out.  I think a lot of innovation relies on knowing what can and can’t be done and I love CTOs who are able to fly with the ideas and vision of their C-Suite to see how they can make things happen.  It’s also important to know when to hit the breaks and this requires a ton of communication that a good CTO is all too willing to do.

There are plenty more aspects to the CTOs role that I won’t cover in this article but hopefully this gives you a sense of what is important for you to focus on.

Conclusion

The days of viewing your CTO as the “IT guy” are over.  You can’t afford to think that all you need is someone who knows how to code and understands which tools are out there.  Your CTO is not your “first engineer” hire.

Let me know how this all works out for you and always open to your feedback.

Etienne