In April 2021, I left my job at Akvo as CTO, after about two years in the position.

Today, six seven eight nine ten months later, it seems like about time to stop procrastinating and write something about it.

Leaving

I realised that I needed to leave when Sunday evenings became the worst part of the week when I felt exactly the same as in my old school days: anxious and unhappy.

But it was not only Sunday evenings. I have never minded some work problem popping in my head out of working hours -- I love solving problems -- but now it will just suck all the joy of whatever I was doing.

And of course, the sleeping troubles that came with all of this.

True happiness occurs only when you find the problems you enjoy having and enjoy solving.
Mark Manson, The Subtle Art of Not Giving a F*ck.

Root Cause Analysis

No need to go through the 5 whys to see what the cause was: the compounded effect of the company’s financial situation, the impact of the decisions I was involved with, and the feeling of being completely unprepared.

As an example, my translation of the new business strategy: stop product development.

Who I was to push for halting the development of what has been the company’s flagship product since its inception, twelve years ago? Would a more experienced CTO see otherwise? Would a more experienced CTO change the business strategy? Changed how product development was financed? How contracts were negotiated? Find external investment?

And the impact on the development team …

This was the last decision that I helped make.

Mistakes and lessons learned

Mandatory “lessons learned” section:

1. Bye-bye coding.
2. Complaints are good.
3. Clarity is hard work.
4. Business first, tech second.
5. Conflicts: avoid being a broken telephone.
6. Difficult conversations (with data).
7. It is always a system problem.
8. Self-blaming is pointless.
9. It is all about teams.
10. Don't make changes, run experiments.
11. Feedback loops are loooong.
12. Ring-fencing is a necessary evil.
13. Lonely.
14. I don’t dislike people management!

Bye-bye coding

As much as it hurts, there will be always something more important than coding.

Complaints are good

Not all complains and not all the time, but some level of complaining means that people trust you enough and that they care enough about the job.

Complains are an opportunity to either:

1. Make an improvement.
2. Provide clarity.

Best outcome is delegating the improvement in the complainer after giving some additional clarity.

Clarity is hard work

Not only communication is messy and you will need to repeat yourself ten times, finding the clarity yourself in the first place requires a lot of work.

Business first, tech second

I understood that my main responsibility as CTO was to improve how we delivered software. Major mistake.

I should have dug deeper from the very beginning on how the business works and how software supported and enabled it.

Conflicts: avoid being a broken telephone

Foo complains about Bar because of Buzz. You talk with Bar about Buzz but Bar says Quux, which you have no clue about. So you go back to Foo to clarify Bar's Buzz's Quux and Foo replies Flob.

What a waste of time, energy, and a source of confusion.

The underlying issue is that Foo does not want to have a difficult conversation with Bar, which, as much I can empathise with, it needs to happen.

So either, depending on circumstances:

1. Ask Foo to have a difficult conversation with Bar.
2. Sit with Foo and Bar to have a difficult conversation.

Difficult conversations (with data)

Two ingredients that made difficult conversations less difficult to have:

1. Following the respectful confrontation script, which has a wonderful mix of hard-core objective real data and fluffy feelings.
2. Internalizing that all problems are system problems.

It is always a system problem

Everybody is doing their best, under the current circumstances.
Gerald M. Weinberg, Becoming a Technical Leader

With this in mind, it is amazing how much more productive conversations are once you move from blaming people to understanding, inspecting, and changing the system.

The steps:

1. State that we are trying to understand how the system leads to the outcome.
2. Repeat point 1.
3. Agree that the outcome was undesirable.
4. Collect the timeline/facts about the system behavior, to understand "the circumstances".
5. Agree on what was the desirable outcome.
6. Agree on what system change is needed to avoid (1) and promote (2).

Note that "circumstances" can be a lack of knowledge or competency by the person doing the work. This is something that can be fixed.

Change the system and people will follow.

Self-blaming is pointless

I always thought that acknowledging that "It is my fault!" was a brave thing to do, but if you really believe that something is your fault, then you are ready to believe that others can be at fault.

Blaming and self-blaming are counterproductive. It is always a system problem.

It is all about teams

What teams, composition, responsibilities, the internal and external dynamics, ... this is going to be your main leverage point for system change.

Don't make changes, run experiments

Change is scary and comes with a lot of resistance, but running an experiment sends a different completely different signal: it is a temporal thing aimed to learn.

Experiments are expected to "fail", which brings the psychological safety required for honest feedback and increases the willingness to participate.

Feedback is high quality as it comes from empirical evidence, not theoretical "this will never work here".

And the most important reason:

Change culture by first changing what people do, not how people think.
John Shook, How to Change a Culture: Lessons from NUMMI

Feedback loops are loooong

You will miss those 72 hours test suites.

Ring-fencing is a necessary evil

I made several times the mistake of asking people for important-but-not-urgent work and expecting them to find the time for it. It rarely worked.

As much as it pains me, the workaround is to explicitly ring-fence people's time, so that if other conflicting priority arises, they can rely on your authority to push back, or escalate the conflict to you.

Lonely

I have never talked so much and been in so many meetings, but nobody in your company will be in your same position, so I actually felt quite lonely at times.

I ended up reaching out to random CTOs on LinkedIn, which was surprisingly useful.

I don’t dislike people management!

You probably do not care but it was a big surprise for me.

Even if the 1-2-1 days were really really draining, I actually enjoyed the time spent with other human resources.

What is next?

The experience was like my first beer, first blog post or first conference talk.

Trying once is not enough to make up my mind.

But before starting a new job, the original plan was to take the rest of 2021 off, get a respite from work and COVID, and take care of my family while my wife went through some nasty surgery.

But life had other plans ...