Why a good CTO is great at PoCs

Doing PoCs is a great way for a CTO to flex their skills and help their teams

In my last article, I discussed why a CTO needs to spend a lot of their time doing planning, requirements, and proof of concepts.

A CTO can’t write all the code. They can’t be the hero every week. They have to build and support their development team. The CTO doesn’t scale, so their work has to scale everyone else!

When they aren’t busy keeping their development team running smoothly and going to endless meetings, they can help by doing proof of concepts and other special projects.

If they strike the right balance, it allows them to flex their technical skills and provide major contributions to the team.

I’ve been known to hack a few things together.

What is a Proof of Concept?

At a startup, even the business itself is a proof of concept! You have to rapidly try new things and figure out what works and what doesn’t work.

Software development projects can be complicated and take forever.

The goal of a proof of concept is to validate an idea quickly. It is done by hacking a few lines of code together over a few hours. (It’s amazing what you can do in an afternoon if you know what you are doing!)

Here is an example:

At my current company, we are integrating our digital marketing software with a job tracking system.

I am doing a PoC by evaluating how their APIs work and validating if we can do an integration that will meet the needs of our users.

If it works, I can hand the findings over to my team, and they can complete the full integration work. I will then move on to the next PoC.

Benefits of Proof of Concepts

Most development teams are bogged down with day to day work. There is a considerable backlog, and it is hard to get stuff done. It is just reality.

Over my career, I have continuously moved the product forward by doing prototypes or proof of concepts. Part of my job was to innovate new things while the team was keeping up with the day to day.

While a CTO should avoid writing code for production systems, they can be extremely valuable when it comes to doing proof of concepts.

Here are some benefits:

  1. Validate product-market fit: A CTO can help write the code of the first version of new products to get it to market quickly and iterate based on market feedback. The CTO should also be talking to customers to get feedback firsthand.

  2. Identify technical challenges: Reduce development time by solving key architecture issues, building prototypes, and validating assumptions. Many teams struggle with how to do big new projects. A simple PoC can help flush out key requirements and remove ambiguity.

  3. Build credibility: By quickly prototyping new features, your company can build credibility with potential investors, partners, and customers. Even if the new product is only 80% complete, moving fast is huge for PR.

  4. Innovation: Most engineering teams get lost in the weeds. A good CTO thinks outside the box and can help prototype new product features or products.

Tailor made for the visionary CTO

There are many different types of CTOs, and they bring different things to a company. It varies wildly by company size, industry, etc.

Every tech startup needs a visionary CTO. They are equal parts CTO and product visionary. That describes me and is why I have been a successful tech entrepreneur for 20+ years.

The combination of their product vision and technical skills means they are probably a 10X developer (Don’t tell them that because it might get to their head).

They understand the WHAT, WHY, and HOW. That makes them the perfect person to do proof of concepts and prototypes.

All the special projects

There are many types of tasks that a CTO can do that can be very helpful for the engineering team. It isn’t always about writing code. It could also be other special projects.

Here are some examples of other special projects or tasks they could do:

  • Vendor selection

  • UI mockups

  • Planning, roadmaps, requirements

  • Reviewing technical specs for future projects

  • Evaluating new hosting or infrastructure options

  • Improving project management or DevOps tools

  • Internal reporting or projects

  • Production performance optimizations

While the CTO may not be head down writing production code every day, they can do many other things to help make the team more productive.

One of my favorite things to do has always been to put my DBA hat on and help do some database tuning.

The creative outlet

As CTO, we get caught up in the day to day of running an engineering team, business needs, and the occasional client issue or production fire.

Working a few hours a week on PoCs and special projects is a great creative outlet. In addition, it helps break up the daily grind of management work and meetings.

It enables you to flex your technical skills, experiment with new technologies, and push the boundaries of what’s possible.

I have spent many evenings at home after the kids go to bed tinkering with code for fun. As a busy entrepreneur and CTO, sometimes that was the only time I had to work on the things I actually wanted to work on.

My code sucks, and that’s OK

I’ve been a software developer for over 20 years. I’ll be the first to admit I am not an expert on all the latest and greatest frameworks, especially front-end JavaScript frameworks.

I don’t write perfect code. My code is beautifully hacked together for a prototype. I cut every corner and didn’t follow any standards. It uses bubble gum and duck tape.

My code sucks. The good news is that my code is not going to production!

My goal was to validate an idea, and now another developer can adapt or rewrite my code. It might not even be in the same programming language.

In many cases, my prototype was done to prove that we can do something and how we would do it. 

Finding a balance

The hardest thing for me over my career has been how much time I should spend writing code versus how much time I should spend doing management work.

Many people struggle with this balance.

From experience, it is a terrible idea as a CTO to be responsible for critical projects that could delay a release or block the team. Therefore, I should not be a major contributor.

It is also important that the CTO still focuses on the engineering team being a well oiled machine. The CTO should not lock themselves in a room and throw pet projects over the wall all day.

However, I can be an excellent part time contributor by doing special projects and proof of concepts. It is highly rewarding and helps move the team forward.

Like everything in life, the key is balance.


or to participate.