When you have been involved in enough software projects, you build up a kind of mental muscle memory; a cheat book of what works well and what does not: X and Y save time, and Z will cause everything to catch on fire six months down the line.
But when you make certain career moves, you revert to a beginner’s mindset. As a software engineer, I knew what to do; as a manager of a small team, I knew what to do; and as a technical lead, I knew what to do. But when I became a startup CTO and all of those roles came crashing together, the old learned responses did not necessarily work—in fact, some of them directly contradicted one another.
Every beginner finds themselves in the trap of not knowing what they do not know. It is the classic Dunning-Kruger Effect. So you will often not realise the degree to which you need to upskill for a new role until it is too late.
Where a new role places you amongst experienced peers, you can (and should!) lean on them to point you in the right direction. But the real learning comes only from doing; from experiencing new things with enough regularity that you can build up a set of learned responses that help you consistently make the right choices.
But that takes time, so what can you do in the interim?
Write down your brilliant insights
In the course of your working life, situations arise where you realise you do not know where to begin. So you do some research and put whatever you learn into practice. When you look back at how it all went, you should be able to reflect on what worked and—perhaps more importantly—what did not.
There’s a valuable lesson hidden in most retrospectives. Especially when something did not go according to plan. You will uncover lessons that will serve you well and, if put into practice often enough, will become second nature.
So while I am in that discovery mode, before the moment of clarity fades forever, I write the lesson(s) down. I aim to keep my notes short and sweet; a few words are usually more than enough.
Remind yourself often, and seek out opportunities to practice
From doing this, I have managed to curate a short list of around 10 very important lessons specific to my quest to become a passable CTO. They are pieces of advice that I simply must seek out real-world opportunities to execute. Things to practice often enough that they become second nature.
A recurring calendar event reminds me to read the list every Friday. The few minutes I spend doing this are among the most important of my week.
When I read the list, my goal is to think hard about each lesson, and to ask myself two questions:
- When was the last time I put this into practice?
- Did I recently miss any opportunities to do so?
With enough prompts, I will create opportunities to practice. And from that practice, I will eventually require fewer prompts. Until I can eventually (and confidently) say that I have some idea what I am doing.