The role changed before my definition of it did

In an early reflection on building Throughout, I wrote that I had once spent almost every day coding. As the company developed, coding became a much smaller part of my work. That was an uncomfortable adjustment because I had associated my contribution with the code I personally shipped.

My calendar filled with architecture discussions, hiring, sales, client meetings, planning, and support for developers. Those tasks were part of building the company, but they did not feel like the engineering work I was used to counting.

A team needs decisions as well as implementation

As Co-Founder & CTO, I need to connect technology choices with the business and give engineers enough context to make good decisions. A difficult problem may need my technical input. Another may need a clearer priority, a conversation with a client, or someone to take responsibility for resolving ambiguity.

The useful question became where my involvement would help the team most. Sometimes that is code. Sometimes it is removing a dependency that keeps several people from finishing their work. Both are engineering contributions, even when only one produces a commit.

Hiring people also means building their environment

I learned that talented developers still need shared standards, documentation, review practices, and a reliable way to communicate. Bringing people into a company without those foundations creates more coordination work for everyone.

That is part of why Throughout’s direction evolved toward dedicated engineering teams. We want to support the capability around the software: onboarding, technical leadership, delivery, and continuity. It is an ongoing responsibility rather than something completed when the next person joins.

Learn the parts of the business that shape the product

Building a company introduced responsibilities I had not associated with software engineering: understanding sales conversations, discussing commercial needs, communicating with clients, and coordinating operations. I was still learning these skills when I wrote the original post, and that learning continues.

I do not need to do every job myself to understand how those jobs affect delivery. A product decision can change expectations elsewhere in the business. Knowing that context helps me explain technical tradeoffs in terms that other people can use.

Keep coding, but choose its purpose

I still enjoy writing software. The change is in how I decide when to do it. Coding is useful when it helps solve an important problem or supports the team; it is less useful when it becomes a way to avoid a leadership decision.

This is a personal lesson from our early journey, not a rule that every CTO should stop coding. Team size, product stage, and individual responsibilities differ. What changed for me was recognising that helping other people do their best work is itself a meaningful form of technical leadership.

What to take away

  • Evaluate your contribution through team progress, not only personal output.
  • Treat context and decisions as part of engineering work.
  • Let the company’s stage determine how hands-on the CTO role should be.