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

2020 was a challenging year marked by COVID‑19 and the shift to remote work, giving many of us extra time for reflection.

Having served as Chief Technology Officer for over a year, I review my software engineering career: 2005‑2008 Software Engineer, 2008‑2012 Senior Engineer, 2013‑2014 Chief Technical Expert, 2014‑2019 Chief Engineer/Architect, and 2020‑present CTO.

What is a CTO?

When I learned I would become the next CTO, I searched for a guide on the role but found none, so I turned to online articles and discovered Matt Tucker’s five‑characteristic CTO framework, illustrated below.

Modified CTO Framework for an IT Services Company

Based on my experience, I adapted Tucker’s model to better fit an IT services organization, as shown in the following diagram.

First‑Year Lessons

Believe in yourself and actively pursue the role – Promotion does not happen automatically; you must seek the position and overcome the Peter Principle.

Plan your time wisely – Separate “maker” and “manager” schedules, protect focused work blocks, and decline unnecessary meetings.

Don’t try to do everything yourself – Empower the team through delegation.

Define what to delegate – Use Jenny Blake’s 6T taxonomy (Tiny, Tedious, Time‑consuming, Teachable, Terrible‑at, Time‑Sensitive) to categorize tasks.

Choose delegation levels – Apply the 7‑level delegation model (Tell, Sell, Consult, Agree, Advise, Inquire, Delegate).

Reduce chaos – Clarify issues with probing questions and maintain a concise todo list for incidents.

Show dissatisfaction when necessary – Voice concerns to set expectations without being overly emotional.

Learn from others’ mistakes – Observe failures around you to avoid repeating them.

Accept that you won’t have all answers – Use structured templates (problem definition, attempts, outcomes) to guide collaborators.

Understand that talent may leave – Recognize that top engineers often aim for product‑focused companies.

Code when needed but don’t over‑commit – Balance coding with higher‑level responsibilities and pair‑program when possible.

Quality is often sacrificed – Clients prioritize speed and cost; maintaining high quality requires deliberate effort.

Speak truthfully, even to allies – Maintain integrity while managing relationships.

Choose battles wisely – Use Camille Fournier’s decision‑making flowchart to focus on high‑impact problems.

Drive continuous progress – Avoid being a bottleneck; make small, reversible decisions and iterate.

Own the impact of your words – Take responsibility for decisions and their consequences.

The Peter Principle suggests people are promoted until they reach a level where they are no longer competent.