Jumping from lead to CTO
Episode 2 of my CTO series, about the main differences between two jobs
Find episode 1 here.
I had been a tech lead of some sort or other for 5 years when I started nearly two months ago as a CTO in a new (smaller) company, leading 2 teams of about 5 developers each. Tag along as I explore the biggest differences that I can see at this point between the two roles.
Second-hand decision-making
First, the most blatant difference is that I now make more important decisions with far less information.
A lead developer, in my experience, is first and foremost a developer, with a bit more seniority, the capacity to ask the right questions and sometimes the last say in tech decisions. In that position, I had a first-hand view on what took too much time. I could look into less-tested areas of the code, CI optimisation, deployment tooling, etc. My role was to either solve these problems or bring them to the attention of the person responsible for planning.
Now, I am not supposed to code. I am not part of any of my two teams, I only follow the daily meetings now and then and attend the plannings. What I don’t have anymore is this very real experience of what needs to be tackled. I am the decision maker and I have never been so far removed from the code.
It is both a blessing and a curse: I can have a higher view on what is going on, I spend more time in various committees thinking up the future of the product, time that I could not use this way if I were to stay focused long enough to code something functional. On the other hand, I can only trust the developers to tell me how they work and where they spend their time.
High communication with the developers is the only way I have to feel legitimate when I talk to non-tech people and advocate for my team.
Low implementation power
As most of my day is spent protecting the team from interruptions and making their work smoother, after all these weeks I have checked out the code but have not run it yet. I have no time, no focus and barely any knowledge to implement the changes I want to see. If you are a developer, you can imagine the frustration. This is known to be the first reasons for devs to never become managers.
I spent my time so far observing and some of the changes were easy to identify: reduce the Single Points of Success*, release more often, improve platform observability. Lots of quick wins there, but nothing I can do myself: it is faster to ask somebody to make changes in the CI than to do it myself. Will that situation last? How much should I invest in knowing the code, what is the norm in small teams? Would it help at all? Time will tell (and I’ll tell you).
Managerial and admin work
Obviously, part of the new role implies some administrative and managerial work, some of which I was already doing as a developer.
Grasped — Protecting the team’s focus time
No need to wait for a managerial role to start protecting the rest of the team from non productive (yet useful) work, such as communicating with stakeholders the state of our work. Be it updating the ticketing tool, creating easy-to-understand roadmaps and updating the colour code, meeting with decision makers to stop them from bothering each person individually, this is the role of a lead as much as the role of a manager.
A bad reason to delegate is that I don’t want to do the work, too boring, too annoying. A good reason is that I don’t have the skills and somebody else does. This is a habit that any dev can pick up: if it needs to be done, do it, unless you have a very good reason to leave it to somebody else.
Grasped — Coaching and listening
In teams where the official manager is, for any reason, unreachable, any member can be an ear and a coach. In dev roles, I have dealt with team members who didn’t speak to each other, people whose private life was a mess and who needed some space, juniors with very low esteem of their work, juniors with high esteem of their work too, devs struggling with test strategies, with asking the right questions or meeting the right people, struggling with speaking up in meetings and sharing their expertise. Don’t wait for experience before acting like a human being.
In progress
New things, though, have been dumpled on my plate.
Security questions are the most blatant. Beyond securing my code and keeping enclosed files from weird stranges in the bin, I never really invested time in the security topics. User management in all the tools we use, penetration tests, priorising small vulnerabilities over a timely release, setting up phishing prevention campaigns, answering security investigations from future clients, there is a lot to learn.
Another thing is the upcoming end-of-year reviews, but that’s a future topic. I know I will have the full support of the HR team to explain the process, and I have a few ideas on how to make it clear for people.
Cultural compass
The most exciting part: I can directly influence the culture of the company with my personal values, which, I hope, were part of why I got the job in the first place. I can finally implement the things I loved from some of my previous managers, and the things I missed from others.
It includes a transparent feedback culture with psychological safety and no blaming. I know I’m an idealist. It includes values of care and work-life balance: e.g. when a team member had to run a migration at night, I made sure that he received some time off as compensation. It includes inclusive language (don’t use “guys” as gender-neutral when you address a group of devs), especially when we use French as the working language, which has a highly gendered grammar.
Some of these differences are easy to anticipate if your goal is to join the ranks of the CTOs of this world. I know that I will keep discovering other new functions in the next few weeks. Stay tuned.
*Single Point of Success is a cheesy rephrasing of the known term: one person is responsible for the success of the entire system and if that person is missing for any reason, well, we’re doomed.
