Why a good CTO is great at PoCs
Matt Watson
Founder/CTO for 20 years, Bootstrapped a SaaS company to a 9 figure exit, CEO of Full Scale, Teaching People to Scale Engineering 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:
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:
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.
Building bridges between business leaders and IT innovation
1 年“Cause every once in a while, the lion has to show the jackals, who he is.” - Christopher Walken in Poolhall Junkies.
I rescue Golang projects | Sign up to learn about Go every day boldlygo.tech/daily
1 年Do you live in Kansas?
I cannot agree more with your comments about quickly throwing something together to demonstrate proof of concept. I can recall one instance where there was a lot of push back on an idea that I had with the argument that it could not be done and if done it would not be fast or useful and a lot of other negative comments. Well, I did exactly what you indicated, wrote a prototype that showed the idea and that would also address much of the negative feedback. Everyone was a little surprised at how quickly it was implemented and how useful and flexible it was. Next of course was to incorporate it into the product. I can distinctly remember the software engineer coming to me and trying to be as diplomatic as possible, asking if the internals of the code could be redesigned to improve speed, integrity, and help with future modifications. I told him that it was prototype code, and everything could be changed and that he should take ownership of it. He did a fantastic job, and it became a major component of the application.
Director BPMO at Forrest T Jones
1 年Like the tag
CTO @ Licenseware
1 年Great post Matt Watson. I'd love to read one about writing specifications and requirements.