The Path from Senior Engineer to CTO

Why CTO, biggest challenges faced and how Gregor overcame them

Intro

Today’s article is a guest post by Gregor Ojsterstek, CTO of Zorion and author of Engineering Leadership.

I’ve always wondered what the path to one is like, be it starting a company as a technical founder or growing from an engineer to CTO.

Gregor took the second path, and today, he is here to share more insights into a CTO role. He’ll share challenges he’s faced, skills he’s sharpened, and how he continues to stay technical despite being in a leadership position.

Without further ado, here’s the interview with Gregor.

---

You’re a CTO! What does your day-to-day role look like?

As a full-time CTO, I was leading a cross-functional team of 6-7 people and we were 15 altogether in the company. If I would pick my top 3 responsibilities, that would be:

• Making sure that the tech is aligned with the business.

• Making sure that we have a great process in place that we consistently deliver new increments.

• Making sure that we are building a stable, usable app that our users love to use.

My daily responsibilities were heavily aligned with making sure we are achieving these things.

I consider myself a good generalist that can if needed go into details of a certain part. Being a generalist, I am automatically looking to have experts on my team.

So what I did: I was a mix of being a manager and an engineer. I aligned everything that we were doing with the business, simplifying and aligning goals for us and managing expectations, facilitating and leading meetings, and had 1:1 meetings with my team.

At the same time, I was working on different projects, like building the administration application, improving the SEO of the website, doing technical specifications, doing performance optimizations, code reviews, building proof of concepts, etc.

What motivated you to transition from being a software engineer to taking on leadership roles, ultimately becoming a CTO?

I was always good at collaborating and communicating when it came to certain projects or functionalities. I wanted to always make sure we have the correct requirements and that we are building the right things.

I wanted to fully understand the needs and find the best solutions that would fit these needs.

I also understood the importance of managing expectations. You can do the best work in the world, but if the expectations are not met correctly, all the effort is wasted. So I wanted to always ensure that this was done correctly.

And that automatically brought me to the place where I wished to have a bigger impact on the projects and the team. Not only in details but also a lot more say in the direction and the overall team in general.

I was quite indecisive if the management path was right for me. That was slowing my growth, but once I got offered the Team Lead position and later after 6 months, I got promoted to the Engineering Manager role, that’s when I knew I made the right choice.

What were some of the biggest challenges you faced in moving from a technical role to a strategic leadership position, and how did you overcome them?

I made a lot of mistakes when I first started as a manager and the reason is that what made me a great engineer, didn’t make me a great manager.

Here are the 3 main challenges I faced:

1. Managing your time is really important

I’ve found myself in a position where a lot of people needed my help, advice or they would just like to chat about something. It’s hard to say no to these things. I needed to learn to say no to things that I believed were not so important, critical, or even needed.

As much as it’s important to help as many people as possible, there needs to be a correct balance between meetings and your contribution.

What I learned is that the best way to do this is to dedicate particular blocks to your own focus time and the rest to managerial time.

For example, you can block four hours, three days a week for your own focus time. And the rest is managerial time. I suggest blocking as many hours as needed.

Try to find the right balance for yourself at that particular time.

2. You can control what you can control

I often felt that there were many things that I would like to change, but I didn’t fully understand that I don’t make all the decisions across the business.

I can control the changes or responsibilities of my team, but for teams outside of my area, I wasn’t able to make decisions for them.

What I learned is that the best thing you can do is to establish great relationships across the organization and try to provide feedback or suggestions to people who are responsible for a particular part of the business.

3. Stay technical, but avoid going into too many details

I wanted to be too much in those fine details, as said above and this brought me close to burning out.

I’ve learned that It’s important to stay technical, no matter if you have a lot of managerial responsibilities. To help the team the most, you need to understand as well as have strong opinions about particular technical decisions or directions.

But don’t go into too many details - rather delegate the details to the team. You need to be involved in important decisions that are crucial for the business, but delegate the small details which are not so important.

You can get overwhelmed by too much information very quickly if you have too many things on your mind.

Found this helpful? Subscribe to make sure you don’t miss new articles and guest posts.

---

How did you balance maintaining technical expertise while developing leadership and strategic skills?

I strongly believe that you can help your team the most if you understand the problems they are facing, therefore staying good technically is very important for me.

No need to be the best coder, but being able to have fruitful discussions and having a wide range of experience really helps in order to align technical vision with the business goals.

Some of the things that help me to stay technical:

• Building Proof of Concepts

Whenever we are discussing a certain idea that we could potentially implement with the business and I’m not sure about the complexity behind it, I create a quick PoC to see what are all the complexities that we are dealing with, so we better know and understand the timelines and resources needed behind it.

• Writing and reviewing technical specifications

I review technical specifications from my team and also create some if needed. That is particularly the case if I build a PoC and it turns out that we want to go in this direction.

I share all of the context and details, share the business problems we are trying to solve and then the team takes it over.

• Making important business decisions like buy vs build, which technologies to go with and the overall architecture that we are going with

This is very important and can be the difference between a company thriving or being unsuccessful. These are the decisions that I put tons of research in and of course consult with the team and other experts across the industry.

• Owning particular projects

I like to create and own particular projects that help either the team or the organization/business. For example: I created an administration dashboard that helped the operational team with their daily tasks to be more efficient.

• Side projects

I like to work on some side projects in my spare time as well. For example, the last 2 things I built were a mobile application for tracking habits → I built it with React Native and I built my blog with React and Gatsby, which I later moved to my newsletter on Substack.

Can you share an example of a difficult decision you had to make as a CTO and what factors influenced your choice?

I’ve made a number of very important and also difficult decisions as a CTO. You can’t make all of them right, the key is to make most of them right and revert the wrong decisions as soon as you know.

An example of a difficult decision: Setting an optimistic deadline to launch the app into production.

We were blocked for quite some time to launch the application to production and when we finally acquired the license as a business, it was time to prepare everything for production.

I’ve set up a timeline that was quite optimistic for us to deliver the application to production. The reason for this is that launching it sooner is a lot better for the business than trying to perfect it for a longer time.

The team wasn’t too happy about it, but I’ve explained that we have the scope to be variable and the time to be fixed.

It doesn’t matter that we deliver all of the functionalities we have in mind. The important thing is that we make the functionalities we have work as it needs to and that the most important “happy path” works correctly.

That proved to be the correct decision, as we have removed a certain complex functionality, which turned out later that we don’t even need it.

Found this helpful? Subscribe to make sure you don’t miss new articles and guest posts.

---

What advice would you give to engineers who are interested in transitioning into leadership roles or pursuing a path similar to yours?

First, grow toward the Senior position and make sure you’ve built up a strong foundation of your skillset. After that, try to find out what career path is the right path for you.

No need to move to the management path in order to have a successful career. You can be the greatest IC and deliver a lot of value that way.

After you know which path you’d like to take, make sure to let your manager know ASAP. The reason is that if your manager doesn’t know about your goals and where you wish to grow, they won’t be able to put you in the position to showcase the skills needed to grow to that position.

Next, focus on credibility - build up your skills including product, business and especially communication (soft skills). And don’t neglect the second part → make sure that people perceive you to be a great person to work with (be reliable, be consistent, take ownership and responsibility, etc.)

And also prepare to make mistakes and be a fast learner when you start with your first lead role. Also, getting a mentor or a coach is always a great idea!

Do you ever wish you were an engineer again?

Even though I would be totally happy in the IC role and focusing on fine details, I am fortunate to have found the path that is right for me → the management path.

I really like making others around me better and focusing on creating a great environment where everyone can thrive.

I still consider myself an engineer though, I think my engineering chops will never go away, as I enjoy doing as well!

---

Takeaways

• After hearing from Gregor on his journey, I loved that he leveraged his soft skills (communication and managing expectations) to develop that into the CTO role.

• Time management is even more important in the CTO role – Gregor blocks off focus time for himself to balance out managerial time.

• “You can control what you can control”. I love this line by Gregor - there’s so much unnecessary pressure that we put on ourselves, especially in this day and age. What’s worked for Gregor here is to build relationships outside of his direct organization.

• His advice for engineers who are interested to grow to CTO: Know which path you want to take, inform your manager, and build credibility throughout your company!

Thank you

Gregor Ojstersek

for sharing your story today. Be sure to follow him on LinkedIn and subscribe to his newsletter Engineering Leadership, which he’s recently gone full-time on. I’ve learned a ton of important skills as a technical IC from him.