Chief Technology Officer, a 5-Year retrospective

My vision of the role

Dodging the Peter Principle

Every employee tends to rise to his level of incompetence. And with time, every position will be filled by an incompetent unable to assume its responsibilities.

The Peter Principle and its corollary have been longstanding concepts I grew up with. When I started in development in 2014, I remember my response to “where do you see yourself in five years?”. Five years from then, I didn’t picture myself managing anyone, let alone being a CTO. Five years from then, I saw myself as a developer, only more skilled.

But my first job as a developer had me founding the front-end team within months, and I was promoted co-CTO at my agency after three years.

I believe that in small to medium-sized companies, this principle is not necessarily a foregone conclusion. So before I took on the role, I made a promise to myself that I wouldn’t stop growing as a developer. So, I set my own goals and kept at it.

During the initial years, it was by remaining a developer to stay relevant with the technological advancements in my industry and to stay connected to the reality of the agency’s projects in my analyses.

After a few years, our agency underwent restructuring with an executive committee, and later with the arrival of a COO. I always advocated that a CTO could truly fulfill their strategic role only if they had a counterpart in tactics on the organizational chart. The arrival of Cynthia at this role allowed me to gain a lot of perspective on technology, detach myself from the daily production routine, and embark on a new phase in my career, that of a CTO-solopreneur.

CTO is a job, not just a hat

This lesson is somewhat the opposite of the previous one and only applies to companies with more than ≈4 developers. While it’s challenging to be both a tactician and a strategist, it’s even more challenging to be a developer wearing the CTO hat. Being involved in production biases the vision and puts blinders on the questions that a Chief Technology Officer, I believe, should be focused on. Being billable always puts the long-term interests of the company in conflict with the immediate interests of projects.

I’ve experienced both cases, and I believe I’ve been much more effective as a CTO when I wasn’t directly involved in billable work but rather focused on consultancy, analysis, and guidance. By following this approach, I could find long-term answers, regularly transmit my thoughts to the team, and involve them in decisions and the implementation of those choices.

Some call this position the “magic eight ball” to illustrate the hypothesis-test-conclusion loop. I believe that CTO, standing for Chief Technology Officer rather than Chief Technical Officer, better reflects my day-to-day work. In french, it translates to “directeur de la technologie”, which comes from the latin dirigere, “to steer”. It is all about setting a heading for how tech should shape our company.

Solopreneurship as Product Engineer, the best of both worlds

How can one excel in development while no longer being involved in sold projects? How to stay connected to developers if I must focus on the big picture? What seemed like a riddle to me was rooted deep within. The solution? Building internal tools that add value without being tied to client projects. This brings me to a quote I once read, which made me laugh, and that I rewrote based on the Peter Principle (again):

With time, every agency develops its own internal production management tool.

On my own, then with our COO upon her return from maternity leave, we took this adage to heart by rebuilding our aging scheduling management tool from scratch, then enriching it with everything we identified as needed to track projects and the team, trying as much as possible not to lock ourselves into an all-in-one tool. (e.g., not venturing into tools we already used like Linear or Notion, but optimizing their integration into our processes.) This is how I became once again a full-stack developer, designer, project manager, and client. In short, I became a solopreneur, then half of two duopreneurs product engineers.

Regularly showing the team the progress of the tool kept me connected with the dev team. It made it easier to advocate for the right tools and good practices.

My tech vision

In a nutshell: it depends. I have my personal preferences, but I will never (again) take part in Ruby vs. Node vs. PHP, React vs. Svelte, Next vs. Remix, or TypeScript vs. JSdoc wars. Unless, of course, the whole project depends on this choice. Been there, done that.

Where I stand firm is on building value from tech right from the start. I’m all about delaying fancy tech stacks until they are really needed and focusing on simplicity and maintainability.

• I believe in delaying the implementation of engineer silos. I advocate for full-stack technologies and full-stack engineers, and hosting on PaaS (Platform as a Service) or serverless, as long as hosting prices are not truly detrimental to the product’s survival.
• Regarding hosting, I believe in doing everything possible to avoid over-engineering unless specificity is at the heart of the project. In the long run, PaaS and serverless hosting may be more expensive than more advanced solutions (Kubernetes, Terraform, OpenTofu...), but for a startup product, the proliferation of individual expertise, its impact on dependency on certain individuals for certain tasks, and on the payroll burden are real burdens.
• On the coding style I advocate, I have often cited the phrase DRY, but AHA (Don’t Repeat Yourself, but Avoid Hasty Abstractions). Inmaintainable digital projects are often prisoners of good intentions, Separation of Concerns principles, and good practices applied without understanding the why and how. For me, it’s during the second writing of the code that these questions of reuse, separation, and abstraction should arise. WET (Write Everything Twice). And it’s often — but not always — during the second writing of the code that issues of test coverage and code and query optimization should emerge.

My goal as a developer is to deliver simple, clever but not “smart” code, easy to understand and take ownership of by any new developer, with constant questioning of objectives.

My goal as a CTO is to create or improve a team, to rally them around these principles of simplicity and maintainability, to provide a long-term technological vision (strategy), keep track and support stakeholders in the short-term planning details (tactics), and to ensure that the team is at the right level to launch the project.