From founder-led engineering to a technology organisation that could run without the CTO

Situation

At the beginning of SmartFrame I was effectively the engineering team.

I had built the product, knew the infrastructure and knew most of the awkward corners of the codebase because I had probably created them.

That was useful early on.

It would have become a serious problem if the company had kept working that way.

As the team grew, more and more decisions naturally ended up with me. Architecture questions, implementation questions, releases, priorities, production problems, hiring.

For a while that can look like strong technical leadership.

Past a certain size it mostly means you've made yourself a bottleneck.

By its later stages the technology organisation had grown to 20 people across backend, frontend, QA, data and delivery responsibilities.

I wanted routine engineering to work whether I happened to be in the meeting or not.

What I did

I hired extensively over the years, interviewing more than 150 people and hiring around 45 as the team evolved.

But hiring more engineers wasn't enough.

At around a dozen people we needed proper ownership below CTO level, so I deliberately started building leadership inside the team.

At different points we had separate backend and frontend leadership, QA leadership and delivery/project-management responsibility. We had two backend leads and two frontend leads as the organisation changed.

The important bit was giving those people actual decisions to make.

I didn't want leads whose job was to collect questions and bring them to me.

There are Slack conversations where my response to a technical design question is basically: work it out between yourselves first and come back if you need us.

That was intentional.

We also built the boring operating machinery around it: code review, automated testing, CI/CD, release processes, clearer component ownership, documentation, monitoring and regular planning.

The leads group dealt with things like priorities, workload pressure, staging, handovers and making sure work actually got through review and into production.

There are plenty of examples of meetings and technical work carrying on when I couldn't attend. Kick-offs, pre-planning, handovers and vendor discussions didn't require me to be sitting there.

I still stayed close enough to the technology to help with architecture, difficult trade-offs and escalations. I just didn't want every normal decision to require CTO approval.

I applied the same idea outside engineering too.

I trained sales and other non-technical people so they could handle common technical conversations themselves. We built internal tooling so operational teams didn't need to ask developers every time something needed changing.

Over time that freed me up to spend more time on the work that actually needed CTO context: product direction, architecture, senior hiring, external partners, cost, risk and the connection between technology and the rest of the company.

Outcome

The engineering organisation grew from one person to 20 people.

More importantly, normal engineering didn't stop because I wasn't available.

Other people could run planning. Leads could resolve technical decisions. Teams could organise handovers and releases. Problems still came to me when they needed wider context, but that became the exception rather than the normal route through the organisation.

At least seven people stayed for five years or longer, and several people grew into substantial leadership responsibilities while working with me.

I wouldn't claim the company stopped needing a CTO.

It stopped needing the CTO to dispatch normal engineering work.

That's a much healthier place to be.

A few former colleagues have also since been willing to work with me again. I don't treat that as a hard metric, but I do think it says something useful about the kind of engineering environment we built.

What I took from it

A CTO becoming less involved in routine delivery is usually a sign of progress.

If every release, architecture question or planning decision still depends on the most senior technical person, adding more engineers won't fix the underlying problem.

People need enough context, authority and trust to make real decisions.

The test I use is fairly simple.

If the CTO disappears for a few days, does normal engineering keep moving?

And when something genuinely important happens, does it still find its way to them?

If both are true, the organisation is probably in decent shape.