Not so long ago, I was a developer. I worked for various companies as an employee, and more recently as an independent programmer. In one of my contracts, I found the stack very scattered, reflecting long months and even years of tech inconsistency, yet on solid technological choices. I shared this observation with my client, and suggested him to hire a CTO. He or she would refactor the current architecture and avoid the same mistake to happen again.

He asked me to jump in that role.

I said "yes".

My career slightly started to shift. Here are some important take-aways I wish I had known before.

It's hard work

Taking the ownership of a full tech stack is tough. I means reading a lot of technical documentation code, go through a lot of configuration files, git history, API calls, unused code (which I didn't know it was unused), environment creation, testing, backup-ing, playing with prod (which I didn't know was prod)... That means a lot of different technologies, in different contexts. I was happy to have 12 years of experience and being able to fluently read most of the files in there.

In the meanwhile, new code has to be released, and bugs have to be fixed. It's not like the company is stopping its activity because the CTO has to understand it all.

This amount of work was quite impressive at first, and scared me in some situations.

1. It's interesting work

I found very interesting to dive into entire projects. Mistakes were made, most of them understandable given the context (of a small startup) and good decisions were made as well. I learned from all of these situations. I started to be able to understand decisions not only from a technical perspective, but also from a business one. Bad technical decisions can be good business ones (and vice-versa?). In other terms, creating tech debt is not necessary a bad thing for the business, as long as the debt is known, documented, and at some point reimbursed!

Another interesting part is to be close to the strategic orientation of the business. In my case, the product is very tech-centered. This creates a strong dependency between business and tech. The business will go were the tech can bring it. The strategic discussions resulting from this fact are very interesting, and I was missing them while a developer. The perspective it brings is enlightening.

2. It's a lot of non-tech work

I was very frustrated at the beginning of anything that would not be related to coding. I really thought I was loosing precious time to achieve more. To a dev, meetings, HR, debates, documentation is a waste of time. For a CTO, it's the regular job. For a dev to be efficient, some people around him or her must make it possible and the CTO is one of them. Being able to estimate (roughly) and take a decision means discussions, meetings and a lot of information. I slowly accepted that and reduced dramatically the amount of code I was able to deliver, unfortunately. I don't find it a waste of time any more.

The frustrating part is to be able to know and decide without understanding the full stack perfectly.

3. The "how long will it take" question

This is always a difficult question to ask an engineer, because it depends too much on too many parameters. And this is not an practical answer to any decision-maker. To answer this question means to start building a solution, or to be more accurate to architecture it. That is when business meets tech: the way to build it depends on the business orientation, and vice-versa. Still, this question is crucial to any CEO, and answering it means to me:

1. knowing the current stack perfectly
2. creating a couple of realistic architectures (sometimes in seconds during a meeting)
3. saying: "it depends" 😂 And detailing the one or two good options.

The CEO knows enough of the history of the stack, the people involved and the tone of my voice to take action. At early stages, "long and difficult" or "short and easy" are good enough answers. The "quick and dirty" can occasionally be a good one, although never the one I prefer...

4. There is a lot of HR

When a developer or a contractor says he/she is leaving, that means to me: "I must find about 20 hours in the next months to handle this situation". Indeed, preparing the leave, looking for someone, checking the skills, onboarding, checking the skills again... takes a lot of my time. And this time is very fragmented. I find interesting to dig in profiles, meet new people and build a team, but the amount of work related to it is almost prohibitive.

When people are not leaving (most of the time!) I take a little time frequently to address 1-to-1 chats. It helps create a stronger relationship, especially in a full remote team like ours. At first I looked at it as a waste of time, but I now see the value and enjoy it. I am never busy enough to skip 1-to-1s with my devs.

HR includes also career consideration. Developers are not here just to execute work written on Trello cards. Their experience, personality and goals in professional life are always important. Knowing them one by one is a long process, but a necessary one. I must find the win-win situation that empowers both each individual and the company. Accurately knowing one team's skills at one time is also a precious information for business orientation.

Having such responsibility of team is something I did not expect this way.

5. Every day is very different

I really miss my long hours of development and building of a cool feature, or even refactoring! On the other hand, my days are very different from one to the other. Having to interact with the CEO, the Product Owner, the Project Manager, the testers and the developers during a single week is enriching. They all have skills that nurture me. It also requires very strong organizational skills.

Considering the relatively small size of my team, I must perform additional tech tasks that nobody else would do. Not because they lack the skills, but because we pay them for something else. For instance, I am the main DevOps and the one who pushes to prod every week, and I am the one architecturing new product-wide features.

6. This is a humble journey

I think that any of the devs in our team could do my job. I can barely do theirs now. Gathering information and talking to people did not seem like a real skill to me... It is. There are many situations where I just "don't know". I say it humbly when it happens, and I understand my job is often to "know" in a reasonable time (ASAP). This instability is very scary at first, and more than once I trembled to estimate, push to prod, or meet with an important person. Confidence is growing in me.

I really enjoy the journey so far, and I really think it was a good time for me to embark. Joining a "small project getting bigger" was a relevant situation for me to become a CTO.