I was not ready to become a consultant

Throughout my IT career, I’ve been through many roles, the majority of which were leadership positions such as Lead Developer, Team Leader, Architect, Platform Owner, and Chief Technical Officer. None of them were my first choice. I’m passionate about developing software myself. I prefer to code. And just a tiny bit of hardware tinkering.

When I was first offered a CTO role, I refused. I was more excited by a Pencil (a soldering iron by Pine64 with support for Power Delivery, RISC-V Processor, and open-source firmware) than by the idea of leading an IT department.

I refused

This was my first “No” in taking more responsibility! I should be proud of myself!

At that time, I was leading a Platform Team and held the title of a Platform Owner. It meant that I was in charge of infrastructure and developer experience. I was not communicating much with the current CTO which was fine since I was busy solving “my” problems. There were many moving pieces reaching out far from the Platform Team to the IT department and the company in general. My team was mastering Pulumi for Infrastructure as actual Code and Kubernetes management while making it easy for developers. Developers were getting familiar with new responsibilities like managing their infrastructure, pipelines, and documentation right in their repository. Observability was getting to a point where it was actually usable by every developer. The software development life cycle was changing to accommodate trunk-based development. I was not just in the middle of it. I was actively steering the whole project in those directions. Bringing practices and tools to support them, organizing processes, and advocating change. Sitting down with every team to figure out ways to thrive together.

Doesn’t sound like a lot of coding, right? Yeah, you’re right! Accepting the CTO position, then, shouldn’t have been a big leap. The only thing I had to sacrifice was just a little bit of coding I had left. Two days and one difficult conversation later, I accepted the new role.

But why?

I have to accept that I love solving problems. Software-related ones in particular. However, software challenges don’t exist in isolation. So I would like to go back to the beginning of my IT career.

I began as a developer. First working with C++ for a sophisticated machine that detects problems in huuuuuuge transformers via oil quality monitoring. Then it was signal processing, also with C++. After that, I got involved in creating a social network with Liferay, so Java it was. These were my first experiences as a developer and in each of these roles, I did more than just code. I was trying to bring git to the first place to replace sharing files and archives. Acted a as scrum master and was responsible for bringing Doxygen, automation (mostly makefiles), and Jenkins at the second one. At the third one, I became responsible for our infrastructure. All of it while still being a developer and not being asked to do any of it.

These were issues that bothered me as a developer, so I went on an adventure to solve them before returning to pure coding—or so I thought.

Turns out I have little tolerance for unnecessary inconveniences. Norman doors are a wonderful example. While it’s difficult to change doors in a building you don’t own, it’s possible to change things in a company you’re working at or at least in a project. This is what I’ve been doing for the past 10 years. Changing things. Not just code or even architecture. Things that may be way out of my original scope. The product itself, processes, and communications internal or external.

For me, it boils down to key points:

• I care
• I strive to see the bigger picture

So, what’s wrong with being a consultant?

I thought I had enough experience in “seeing the whole picture” to get into a company, get familiar with how it works, and after taking a deep look give useful pieces of advice. Not just a summary of problems but also instructions on how to solve them in this particular case. That part turned out to be relatively easy. I’ve been there before.

The “I care” part got me in trouble. In all of my experience, I had at least some authority to enforce changes. I always was there with the rest of the team to lead the change and support them. But as a consultant, I’m just an outsider that has something to say. There is no way to act on my own. No way to lead the way. All I can do is to show the way. It might be enough in case change is awaited and welcomed. I had wonderful experiences consulting individuals. Not so much with a company. Individuals had particular problems while the company was not even sure they had one. Maybe consulting a company requires better persuasive skills. For the first three months, I was stuck in a situation where many improvements could be made but there was no movement towards them. I felt helpless.

I came to a company to help, not to get some money for talking. The hard truth is that a consultant just offers a solution it’s on the company to act on it. My problem-solving skills are stopped right before jumping into action. The spring is already loaded, ready to catapult me into making changes. Instead, I’m left with my hands tied to watch. It hurts when nothing happens. I care.

I consider my first experience as a consultant a failure. After a lot of difficult discussions with CTO & CEO, I agreed to become CTO myself. Which I still am at the time of writing this post. Actively changing things.