Wrong CTO Profiles for a Scale-Up: Part 2

In the first post in this mini-series about wrong CTO profiles for a scale-up, I talked about why a too technical CTO often fails. Funnily enough, the other CTO profile who often fails does this because the CTO is not not technical enough.

The story I often hear goes like this: As a reaction to having had a too technical CTO, a SaaS hired a non-technical CTO who can communicate with non-technical stakeholders, enjoys project management, and knows how to deal with people. These are all good things! But their new CTO didn’t really know technical stuff and didn’t come from a developer background — but was a project manager or some sort of business consultant — and due to this lack of technical insights, the CTO has made some terrible technical decisions and/or hires, and the company is now in deep troubles.

The lack of technical insights means that the CTO cannot make informed technical decisions. Even people who are smart, rational, and math-savvy — but not software engineers — often fail when it comes to this. Paul Graham (co-founder of Y Combinator) once gave this advice to non-technical technical leaders: Give up! His reason was simply that a non-technical manager cannot recognize great engineers or great technical work, and that is why they fail.

Having smart engineers who can advice the non-technical CTO about technical decisions also never really works in practice… As Joel Spolsky (co-founder of Stack Overflow) once wrote, it reminded him of someone who doesn’t know how to surf, try to surf, with advisors standing on the beach shouting to the poor surfer what to do, while the surfer falls into the water again and again.

A CTO who is not coming from a developer background is almost always a problem, but in mature, established software houses, it is less of a short-term problem, because the CTO can cruise on for years on the existing architecture and tech stack — and just focus on pumping out new features and not shaking the boat — before it turns into a serious problem (but when it becomes a problem, it does so with a vengeance and needs a a big, nasty, re-platforming project, but that’s a story for another blog post).

In most SaaS scale-ups, even those without complex tech, making the right technical decisions and the right technical hires is critical to the survival of the company. While the company is scaling up, its CTO needs to decide what components from its original startup codebase (which almost always have a fair bit of duct tape and hacks) to keep, what parts to replace, and what to replace them with.

I’ve see at least four developer archetypes who want to influence those decisions, and not necessarily in a way that’s right for the company, and the CTO needs to be able to challenge them:

• Not-Invented-Here (NIH) Engineer: Sometimes as part of the scale-up journey, a company hires a new engineer who concludes that everything that was written before they joined the company is hopeless and beyond repair, so all code needs to be rewritten from scratch. Given that reading code is much more difficult than writing code, this is a common conclusion. For example, I know one company where a senior developer had started a naive project of rewriting the whole codebase from scratch, without really understanding the existing codebase or the size of such a project. Another typical not-invented-here example is an ecommerce scale-up that I talked with who had decided, in 2021, that they needed to write their own web shop software from scratch, because they didn’t think any of the existing solutions fitted with their pretty common needs (!) and now their web shop was missing essential features, like a mobile app, because they were too busy developing and maintaining other features that are available in most standard ecommerce solutions.
• Cloud-Vendor Salesperson: Smooth-talking salesperson from vendors such as AWS or Google Cloud who is trying to push more of their services into the scale-up’s tech stack, and offer all kinds of temptings-sounding offers, like you get Google’s own engineers to work on your product for free, if you just migrate to them. Of course, their aim is to create vendor lock-in so you stay with their services for good.
• New-Tech Engineer: Working with new technologies is super fun, so often there is at least one software engineer in the company who thinks it could be really awesome to use some new, uncommon technology. One example I recall from some years ago is a SaaS where one of the developers was really passionate about Rust (which I totally get!), but Rust didn’t really have any benefits that were business critical to the SaaS, the developer simply thought it would be a cool language to learn and do something in. The problem was that it was almost impossible for the SaaS to hire experienced Rust developers, which made scaling up their company much slower than it needed to be.
• Opposite-Tech Engineer: An engineer who always wants to use the opposite tech of the ones the company is using. If the company uses AWS, they want to use Google Cloud (and if you had used Google Cloud, they wanted to use AWS). If you use Angular, they want to use React; and so on. In most cases, if techs are more or less comparable, then switching tech is just an expensive project that adds little value to the customers while draining the time of the company’s most senior engineers, so there needs to be a pretty good reason to start such a tech migration.

In my experience, then scale-ups need to make so many important technical hires and decisions — where a wrong choice can put the company’s health at risk as neither funding nor time is unlimited — that they need a CTO who can listen to and challenge all of the persons above, and separate signals from noise, and at the end of the day be able to confidently make the right technical decision for their company.

That’s it! Hope you enjoyed this little series on the wrong CTO profiles for a scale-up🚀