What I Learned in My First Year as CTO: 13 Hard‑Earned Lessons

I have been the Chief Technology Officer (CTO) of my current IT services company for a little over a year and think it is a good time to review the lessons learned during this first year.

My software engineering journey

2005‑2008: Software Engineer

2008‑2012: Senior Software Engineer

2013‑2014: Chief Technology Evangelist

2014‑2019: Lead Engineer/Architect (also acted as Director while staying hands‑on)

2020‑present: Chief Technology Officer (first leadership/management role)

CTO role definition

When I was told I would become the next CTO I immediately looked for a handbook that described best practices. I discovered there is no script.

The most important thing is to learn on the job and avoid repeating the same mistakes.

The first thing I read was how people usually define the CTO role, which is one of the most confusing C‑level positions because each CTO’s responsibilities differ.

Matt Tucker’s article provides a useful framework that splits the role into five styles. The image below shows Tucker’s CTO role framework.

I think this framework offers a solid mental model for thinking about the CTO role, especially for product‑focused companies. In my IT services company the role is diluted, distributed, and challenging for three reasons:

People are the most important asset, and growth in an IT services organization is proportional to headcount.

Large enterprises need to adopt modern technologies (React, Golang, Flutter, cloud, Kubernetes, micro‑services, event‑driven, serverless) but often lack the foundational work to do so.

Skilled engineers with experience in these modern stacks are scarce and expensive, and their motivations align more with product companies than with IT services firms.

There are few articles about CTOs in IT‑service organizations, so I adopted Matt’s framework and re‑defined it for my context. Below is the modified CTO framework with rough time allocations for each activity.

Modified CTO Framework

As shown in the table, I keep my context‑switching overhead low by ensuring I am involved in no more than two tasks at a time. In my first year I built a modest delegation hierarchy and plan to focus more on certain areas in the second year.

First‑year lessons

Lesson 0: Believe in yourself and own the role

Most software engineers dream of becoming CTO, but the title does not automatically follow technical competence.

You need a strong hunger; it took me almost three years to feel ready for the role.

The Peter Principle observes that employees rise to their level of incompetence.

If you don’t take the role, someone else will. Knowing my own leadership style, I decided to try.

Lesson 1: Schedule time for yourself

When overwhelmed with meetings, I began allocating several hours each day to deep work, refusing non‑essential meetings, and ensuring I was the decision‑maker for critical discussions.

Lesson 2: Don’t do it yourself, get it done

Doing everything yourself creates a bottleneck. Effective delegation involves deciding what to delegate and at which level.

Jenny Blake’s “6 Ts” categorise tasks as Tiny, Tedious, Time‑consuming, Trainable, Terrible, and Time‑sensitive.

Tiny: Small but cumulatively important.

Tedious: Simple tasks that waste time.

Time‑consuming: Important but lengthy tasks that don’t need my direct involvement.

Trainable: Complex tasks that can be systematised and reviewed.

Terrible: Tasks outside my strengths.

Time‑sensitive: Urgent tasks that must be delegated quickly.

I delegate internal tech talks, infrastructure ops, code reviews, junior hiring, etc.

There are seven delegation levels:

Tell – I tell them what to do.

Sell – I try to sell the idea.

Consult – I consult and decide.

Agree – We agree together.

Suggest – I suggest, they decide.

Ask – They decide, I ask again.

Represent – I fully delegate.

Lesson 3: Reduce chaos

Leaders must bring clarity to chaotic situations such as delivery failures or performance incidents. I use a simple checklist: ask probing questions, create a clear to‑do list, assign owners, and document knowledge.

Lesson 4: React wisely and express dissatisfaction

While most of the time you should stay calm, sometimes you must react and set clear expectations when a serious issue occurs, such as a broken API call caused by mismatched JSON fields.

Lesson 5: Learn from others’ mistakes

Observing others’ failures helps you avoid the same pitfalls and accelerates your own progress.

Lesson 6: You won’t have all the answers – and that’s okay

People expect complete answers, but the goal is to help them find solutions themselves. I now require a Google Doc template that defines the problem before I engage.

Lesson 7: You’ll develop talent, and they’ll leave

Even when you mentor promising engineers, many will move to product‑focused companies for better growth and compensation.

Lesson 8: Coding is great, but don’t over‑commit

Most advice suggests CTOs should not code because it competes with higher‑priority responsibilities and can lead to bias toward flashy tech.

In my first year I still contributed code, but I made it clear I was not the owner of tasks and paired with a teammate to ensure continuity.

Lesson 9: Only a few customers truly value quality

Clients usually want high‑quality products, agile requirements, and delivery within fixed cost and time. Balancing these constraints is difficult; quality often loses to speed.

Lesson 10: Speak the language, but don’t lose yourself

As you rise, you become more isolated; maintaining personal and professional relationships is challenging.

Lesson 11: Choose your battles wisely

Only a minority of problems are worth solving. Camille Fournier’s decision‑making flowchart helps decide which battles to fight.

Lesson 12: Keep adjusting continuously

Don’t become the system’s bottleneck. Make incremental, tactical changes while keeping the strategic goal in mind, and recognise reversible versus irreversible decisions.

Lesson 13: Your words matter and you’ll be held accountable

Never let others force you into decisions you don’t believe in; you are responsible for the outcomes.