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:
- Bye-bye coding.
- Complaints are good.
- Clarity is hard work.
- Business first, tech second.
- Conflicts: avoid being a broken telephone.
- Difficult conversations (with data).
- It is always a system problem.
- Self-blaming is pointless.
- It is all about teams.
- Don't make changes, run experiments.
- Feedback loops are loooong.
- Ring-fencing is a necessary evil.
- Lonely.
- 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:
- Make an improvement.
- 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:
- Ask Foo to have a difficult conversation with Bar.
- Sit with Foo and Bar to have a difficult conversation.
Difficult conversations (with data)
Two ingredients that made difficult conversations less difficult to have:
- Following the respectful confrontation script, which has a wonderful mix of hard-core objective real data and fluffy feelings.
- 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:
- State that we are trying to understand how the system leads to the outcome.
- Repeat point 1.
- Agree that the outcome was undesirable.
- Collect the timeline/facts about the system behavior, to understand "the circumstances".
- Agree on what was the desirable outcome.
- 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 ...
Top comments (7)
I'm the primary software/data engineer on a small team of data scientists at a startup (~5 employees) and the idea of "Business first, tech second" resonates a loooot with my experience and it was a hard but important pill to swallow
I spent a lot of time in the early days going through analysis paralysis with each nuance in our tech stack but once I realized the stack is just a tool the business uses to support its mission I was able to engineer much stronger solutions geared towards our bigger picture
Absolutely fantastic post - definitely going to be checking out the rest of the series, thank you Dan!
Thanks for sharing Chris!
This is quite a journey you've had, Dan. I totally agree that as a CTO you should focus a lot on the business, enable the teams to make experiments and shorten those feedback loops to actually learn something!
I think it was Seth Godin that said:
“The best way to change long term behavior is with short term feedback”
Wow, this turns into a really great series.
Thanks for sharing
Great series Dan, and I'm figuring this one was hard to write, but certainly useful for me in reading. I've recently decided to take a new CTO role and also left my last one last September and I totally get the "space then reflect" thing.
I learned from this article, but there is one place I'd seek to disagree - though it might be semantics.
For me, there are definitely faults and people definitely make them, myself definitely included! For me blame is not shame though. I find that if you say "it's all the systems fault" then you have no personal responsibility, and if a person is afraid of faults they try to cover them up, or seek face saving through uncovering people's faults.
"Perfect is the enemy of Good" is my motto and so I expect things to get better but not be perfect, in my own work and in others. This set of principles leads me to look for opportunities to find faults quickly and to expect them, roll with it, and make things better as a result - both for the output, but also for the people involved.
Does this resonate with you or have you had experiences that have had bad outcomes due to "faults" and "blame" becoming toxic?
Thanks for the comment Mike.
My experience is that "It is your fault" makes people defensive straight away, and assigning blame is what triggers people to hide and cover up errors. I have seen more than once finger-pointing destroying the relationship between people and teams, killing any future collaboration.
I find "it is a system issue" a constructive way of people being more honest as they can safely say "I made a mistake", and then discuss how that mistake can be avoided in the future. Looking at the problem from a system's point of view, it means that a solution that blame the person like "I promise I will never do it again" or "I will remember harder next time" are of little value. You are encouraged to dig deeper on the underlying issue and find a way that not just the person that made the mistake, but also any future person, will naturally not make the same mistake. This means changing the system, not the person.
But part of the system is people, and people's behaviour is shaped by the system.
It is the manager's job to ensure that people have the competency and clarity to do their job. I like dev.to/danlebrero/book-notes-turn-... model. Obviously, some people will not have the capability or potential capability, so it is that person to be blame to get a job that they cannot do? I don't think so, but the consequence is obvious: increase competency or find another person.
But you are right, where does personal responsibility starts? I think this comes from clear expectations. What does the manager expect from a person, is that person aware, and those that person agrees on the expectations?
Complex subject!