Life as a CTO – Part 1
(and everything they never tell you)
This is the first entry in a longer series I want to write over time about the real, messy, human side of being a CTO.
Not the polished version you read in books or in LinkedIn posts, but the day-to-day reality that sits behind the role.
A sort of long-running diary, written whenever something is worth remembering.
The Myth vs The Actual Job
When you become a CTO, you convince yourself that the hard part will be the technology.
Architectures, standards, planning, roadmaps.
All that wonderful mental Lego that gives you the illusion of controlling chaos.
Then you discover the real chaos isn’t in the code.
It’s in people.
No book warns you about that. No course prepares you for it.
You just get dropped into situations no diagram can save.
Learning the Human Side Late
I thought I had everything figured out.
Then I realised I didn’t.
Psychology and communication are things I’m learning now, slowly, piece by piece.
Often by messing up.
Isendu played a big part in this. It forced me to understand that strong technical skills are not enough.
If you can’t read people, you’re only half a CTO.
Technology doesn’t live in a sterile environment.
It lives inside a group of humans with fears, doubts, frustrations, and days when everything goes wrong.
Developers and Awareness
Here’s another truth many won’t like.
The truly aware developers, the ones who understand the bigger picture, you can count on one hand.
Not because the others lack skills.
But because most people naturally focus on their editor, their ticket, their task.
Seeing the whole system is rare.
With everyone else, you have to adapt.
Mediate. Translate. Anticipate.
Pull them out of the tunnel when they get stuck.
These are muscles you develop only when you’re thrown into the deep end.
Stuck Between Two Worlds
No one prepares you for being the filter between management and the team.
You end up carrying tensions that are not yours.
You try to turn top-down decisions into something that doesn’t feel like punishment.
You try to protect the team from impulse-driven requests.
You try to keep things clear when everything slides into fog.
It’s not glamorous.
But it’s the glue that keeps a company from cracking.
When Things Start Flowing
The funny thing is that once you stop resisting this part of the job, things improve.
Proposing solutions instead of reacting to chaos changes the outcome dramatically.
People don’t need you to be their friend.
They need to trust that you’re not acting randomly.
And when a conflict dissolves, when a process finally flows, when the team breathes again, you realize something obvious:
Technology was always the easy part.
Software can be fixed.
People need attention, context, patience, and space to grow.
A Note to My Future Self
I’m writing this because I’ll probably need to read it again someday.
To remind myself that the job isn’t just choosing a tech stack or writing code.
It’s understanding the humanity inside the software.
And accepting that the most complicated and the most rewarding part is keeping the whole system from crashing when life gets noisy.