Prescriptive Architecting

I'm reading a lot of opinions from fractional CTOs on LinkedIn about how CTOs shouldn't code. As a blank statement, I have to disagree, not because I'm at odds with the premise, I just disagree with applying that principle for every occasion.

The role of a CTO varies greatly with the size and stage of the organization. However some aspects remain invariant: always make sure that technological development is aligned with business needs, establish quality procedures and principles that propagate down, and keep an eye out on culture norms that permeate the organization, identify pitfalls the lay ahead, and so on.

As a few examples, technical co-founders at startups will be doing all of the coding, soldering or outright product building early on. This will continue until a cash influx can help the startup bring on senior engineering talent for completing an MVP (Pre-Seed) or rapidly scaling (for Seed or Series A), and so on.

Prescriptive Architecture

So this question of whether CTOs should be coding is relevant after those early stages when there are no longer a select few with product building capabilities and before the organization is complex enough that management and coordination tasks become too time consuming (though stay tuned for recommendations in those cases).

At this stage, though, I believe prescriptive architecting strikes a good balance between giving directions from a birds eye view and having to code features end to end.

Prescriptive Architecting is the practice of setting up functional scaffolding in code for major projects or features. By doing this, you remove any guess work from individual contributors as to how to set things up for success (since options are too many and decisions still need to be made at the top) and set them for success for building complete features.

This can also be boiled down to leading by example. Don't just tell subordinates what to do and expect the outcome to match your expectations, start building in the direction you expect things to go, and guide the rest of the team in this direction.

Let's analyze a few examples:

Early Stage

An early stage CTO or cofounder, even if when they have other individual code contributors should be doing much of the coding, and even developing prescriptive architecture for things they wouldn't be working on directly:

• Technology Choices.
• Repository and Project Setup.
• Code structure / libraries.
• CI/CD Pipelines.
• Tests.

Seed or Series A

By now you should have an engineering team and a rhythm for work, but even then if you completely delegate building a new major feature, or starting a refactor, too much will be lost in translation between any direction you provide and what's actually built so you can use prescriptive architecture for:

• Minimal prototypes of new products.
• Initial work on new features.
• Refactor direction, apply the refactor to a small subset of code.

Series B or Larger

At this point it should become obvious that hands-on work in code, DevOps or other technical tasks just doesn't have the return on time invested. However, I would encourage CTOs and organizations to ensure that architects or tech leaders continue this tradition of being prescriptive in their work as opposed to simply being enforcers of practices.

In the long run, it will make a world of difference to always lead by example as opposed to trying to lead by theory and expecting outcomes to match those theoretical expectations.