When talking about companies like Uber, Facebook or Amazon, people tend to excessively focus on their founding fathers – the famed and rich CEOs who reap all the splendor and get all the spotlight. But somewhere behind the scenes, whether it’s a startup or multinational behemoth like Amazon, there is an important person who rarely gets the credit they deserve – a CTO. Lurking in the shadows and doing their job unbeknownst to the public eye, CTOs are the unsung leaders who make critical decisions about the technology used at the company and have a significant impact on how the business grows – and ultimately succeeds.

The role of the CTO is pivotal for meeting each tech company’s business goals. The work of chief technology officers cannot be underestimated, but there is still a lot of controversy around what the job really is – and what it is not. In this article, we will attempt to dispel the confusion. We sat down with MasterBorn’s CTO Przemysław Królik for a quick talk about the common misconceptions and ideas about the role.

Without any further ado, let’s cut straight to it.

Q: Who is a CTO?

There is a lot of confusion regarding the definition of the CTO. Some people like to believe a CTO is some kind of mastermind who knows everything about the company’s technology stack. But most people have no idea about who a CTO really is. Let’s set the record straight.

Przemysław Królik: A CTO is a person working at the interface of business and technology. He or she must primarily focus on the company’s business vision – and be able to map out a way to reach it through specific tech. Therefore, my role as a CTO is to have a "helicopter view" of how the business is managed.

In smaller companies CTOs are typically expected to do a million things. In bigger companies, however, CTOs mainly take care of managing people and aligning the technology with the business plans of the company.

When I worked at Droplr a couple of years ago, the company’s then CTO Levi Nunnink worked alongside the developers. He was pretty much a part of the team. He supported what we did and helped us a lot, and back then I thought he knew almost everything about the technology at the company. But the more I worked, the more I realized that it was neither possible nor necessary. The company’s CTO doesn’t have to be a master programmer and know everything about the technology. Instead, a CTO is a person who uses different tools and methods to realize the goal of the company.

Q: Does a CTO need to know every programming language?

Another common misconception about CTOs is that they must know every programming language. This may be useful, but above all, a CTO must know the human language, and apply his or her creativity in solving problems at the company.

Przemysław Królik: Many people learn programming languages at university or by other means – but the data structures and semantics that are shared between them, helps you a lot at work. This gives you a solid base for learning other languages. At university I learned lots of programming languages myself: Java, C#, ASP.NET, JavaScript, Haskell, Ruby on Rails and Python and the list goes on and on. For example, while I am by no means a JavaScript master, I know just enough to be dangerous with the people I work with. I think I know the advantages and disadvantages of each programming language. I know where to apply a language, but again, would never consider myself a programming expert. And that’s ok.

Anyway, programming is a tough industry, and the pace at which the languages and frameworks evolve is relentless – if you're not up to date, you can't really tell you're an expert.

Q: Do CTOs need to know the frontend and backend?

Contrary to common belief, nobody expects a CTO to be a jack of all trades (and, effectively, master of none). Instead, as a CTO, you must accept there are people smarter than you. It’s your job to find people and know how to work with them. For example, do CTOs need to know the frontend and backend?

Przemysław Królik: No, they don’t. Actually, it would also be quite impossible to be proficient at both – and be a CTO on top of that. The thing is, being a CTO is about understanding technology more than it is about an in-depth knowledge of CSS, database engines, etc.

Of course, at some point in my life, I had to know it all – frontend and backend. I used to be a full stack developer at my second job, which allowed me to gain huge experience. But I know in the long run it doesn’t allow you to learn as much as when you’re focused on a single area and that’s why I focused mostly on the backend.

As a CTO, you do not need to know the backend and frontend. What you do need, however, is some knowledge about software architecture and possibly a bit of devops relations. It doesn’t hurt if a CTO comes from a backend or frontend background, but he or she doesn’t have to be up to speed with all the new technologies in expert capacity.

In other words, as a CTO, you have to trust people, and simply learn to leave things to their expertise. Of course, before this happens, you have to assemble the right team to work with. Ideally, you should find people who know better than you and from whom you can learn. The CTO’s job is not to do the things, but to be able to tell, more or less, if the thing is well done. This would, for example, apply to backend and frontend experts – you just have to trust they know their trade.

It’s an important thing in life to realize that you don’t really have to be the best at everything. Your experience and time is limited, and the world is an almost unlimited trove of knowledge. It would be silly to try to know everything. Find your niche and leverage your best skills instead.

Q: Do CTOs spend most of their time programming?

People tend to believe CTOs are just master programmers at the company. What’s your take on this? Do CTOs spend much of their time programming?

Przemysław Królik: No, they don’t. The bigger the company, the less time the CTO is expected to spend coding. What does gain importance, however, are all the non-programming or dev-ops responsibilities.

So what does a CTO do then?

Przemysław Królik: I can’t really speak for everyone in the industry, but if I wanted to break down how I spend my time on average, it would probably look something like this:

• 5-10% actual programming

• 20% doing opsing – depending on the specific project

• 30% as a software architect

• 40-45% recruitment, meetings, managing goals, organization.

When do you need to hire a systems architect?

Przemysław Królik: Usually when big players – companies with big systems and big projects – need architects who agree on how it should look, where it will work and how long this specific project will take with provided resources. So they usually have some pool of them going around depending on funds/project needs.

The second approach is more common in startups: a CTO is the orchestra man who just complements his skills with other people’s skills and utilises them for the best cause. I personally believe that every programmer is the architect of their own solution (i.e. a code level architect) and I love to find talented people inside of the company to grow (and become e.g. an application/solution level architect) due to our specific needs and stack rather than look outside. In this approach you need to know your capacity and how good you can pass the knowledge and predict it with projects to come. Usually if there is a need for such a person and we have a lack of such a skills, we tend to look for it two months before actually starting a project.

Q: Is the CTO just a tech guy?

We like to think about tech people as antisocial geeks, but real life is completely different. There are people all around you, and you just have to know how to talk to them to move towards your goals. You certainly can’t achieve much in isolation, even less so if you are a CTO. The common stereotypes about tech people stem from the fact that many of them are introverts.

Przemysław Królik: That’s true, but even introverts need people to some extent. I am no different – I need to be with other people and I’m fine with it, but it is exhausting in the long term. I just need to give the most of myself to show my best, but it ultimately kills my batteries. I relax best when there’s nobody around. However, I believe that as a CTO you are not the technology man, but a people man first.

You have to keep your people up to date with the tech goals of the company. You need to make sure they grow professionally while keeping their focus on the goals. To get the most out of the people you need to make them feel they’ve found their own spot and are understood. Make sure that their goals are met while you achieve the goals of the company.

Also, you have to explain to them why we do things one way and not another. Make it clear to them what is important. Use business terms, and make them understand the motivations of the people who pay for our services.

I often serve as an interface between technology and business people. When I speak to the business side I try to avoid the tech jargon. I just explain our technology choices and tell them how much they cost, and how they help us achieve our goals. Conversely, when I talk to the tech side, I explain why a specific functionality is important and why we made it a priority rather than refactoring the code and fixing our technological debt.

Q: CTOs and recruitment?

What is the role of the CTO in the recruitment process? Do CTOs need to get involved in hiring new staff?

Przemysław Królik: Yes, as a CTO you need to dip your toes in recruitment, there is no way around it. In a nutshell, if you get surrounded with people you are not happy with, you will never obtain the best results. I like to believe that every company strives to find people who share the same set of beliefs and work ethics. This is a fail-safe way to build a self-controlling system which is self propelling and strives for perfection all the time. I think this works equally well for the technology and business sides.

When I take part in backend recruitment processes, I always try to look at things from two perspectives. There are hard skills (technical knowledge) and the so-called soft skills – how the person communicates, how the person describes processes. If the person can make a complex technical issue easy to understand and implement, it is a testament to certain business sensibility, and also a strong technical background.

There could be a candidate with strong soft skills and the ability to understand things and explain them to non-technical people very easily. Although technologically this person may have problems or lack experience, I’d still prefer to go with such a person because I know it is hard to teach someone soft skills. It would be difficult to change the attitude, methods of communication and many other things. It’s much harder than showing a code and teaching the person step by step what to do with it.

I think we give people the opportunity to learn things and develop with us at the company. We see potential in you and your skills. We believe in you as a person. This is why I believe a programmer should not be assessed just from the perspective of technical skills.

Q: A CTO is for technology, and HR people are for relations

There is a reductive view that a CTO is a technology person, and human relations are a thing of the HR department. This is not necessarily true. There is a significant overlap between CTO and HR responsibilities. It makes the role of the CTO more difficult than it seems. CTOs often speak to the clients, their teams, and must be familiar with the tools of feedback and communication. Good listening skills, empathy, appreciative inquiry and learning goals are just some terms they need to be familiar with.

Przemysław Królik: I may not know all these terms, but in my role I definitely try to act by the tenet “give a man a fish and you feed him for a day, teach a man to fish and you feed him for a lifetime”. This approach works wonders for tech people.

Some CTOs do things intuitively, but don’t have the right vocabulary to call these things. For example, I may not be familiar with the terms “mirror” or “paraphrase”, but I can definitely apply these concepts in my everyday work. I think there is just one word that nicely covers it all for me: empathy.

I typically paraphrase. When I discuss things with my people, I may know the answer, but still encourage the other person to come up with the solution independently. I just tell them what I’d imagine the final result to be (although I have done it numerous times). I just give the general guidelines and wait for them to come up with a solution. This approach teaches me a lot about how other people think, and allows me to understand their points of view. It also teaches me a lot. And the person who is being assigned the task learns a lot too. This is pretty much the 7 levels of delegation. This is the fourth level – “we will agree together”. He agrees, I agree, and we’ve got a solution. This is important from the development point of view, and also to learn other people’s behavior. This builds great communication and allows everyone to feel comfortable in the team. At the same time, you get the confidence that when delegating, I know the assigned tasks will be well made. I will just check it later. Of course, when the person is new, you might want to assess it more carefully,

But there is not one size fits all, you need some nuanced actions. And use the right tools for the purpose.

So you’re basically trying to find common ground. I can see empathy and careful listening are some of your key tools at work.

Przemysław Królik: Yep. I guess the word empathy wraps it up perfectly.

I did the “16 personalities” test to learn more about why I do things the way I do – and found that I am the “advocate”. Advocates are among the rarest personality types. They have a deep sense of idealism and integrity, but they aren’t idle dreamers – they take concrete steps to realize their goals and make a lasting impact.

At work, I try not to draw hasty conclusions. I pay attention to my and other people’s development. So I guess it’s not about telling people what they should do, but making sure everyone is happy to some extent. Of course, there are some disadvantages here, but that’s a subject of a completely different discussion.

Q: Does a CTO need experience in programming?

Most CTOs working at big companies have strong programming backgrounds and many of them studied computer sciences at university. However, it seems you can still be a successful CTO knowing just the basics of the tech side.

Przemysław Królik: It really boils down to what is understood by “programming background”. Does it mean that this person used to be a programmer? Worked in IT?

Let’s say this person has working experience as a programmer – then my answer would be no, it’s not a requirement. CTOs at companies like Uber, Facebook, and probably 99% of other tech giants, probably have solid IT backgrounds. But there is a small present of people who do not have these strong programming skills. Instead, they have strong soft skills like understanding people and sticking to the company vision. Good budgeting skills come in handy too, as this can be one of the things the CTO does in some companies.

So, in a nutshell, you can be a good CTO without a solid programming background. But knowing a little bit of this and that helps to support your decisions. Keep in mind that there is also a CIO role that non-programmers people tend to occupy in place of CTO.

Q: Should a CTO always be involved wherever decisions about technology are made?

Delegating tasks, trusting other people and holding them accountable for their work is important. A good CTO should get involved wherever it helps the company, but also leave some autonomy to the people – support their development and independence.

Przemysław Królik: No. And this is actually one of my problems. I tend to want to be involved in everything and oversee every single process. But this approach is exhausting in the long run and spreads you thin. It may only be good when you are an early-stage startup – and there is just one product you’re working on. At MasterBorn, however, we don’t work on a single product. We have many projects.

So how many ongoing projects are there currently in development at MasterBorn? How many are you directly involved in?

Przemysław Królik: There are 10 projects in the company and I am personally involved in 4 of them, but I’m always open to support anyone in the company as needed.

But it’s not always like that. In general, it’s all about the current needs. For some of these projects I am just an important organizational and architectural foundation, because I started these projects. I also oversee situations when other people are learning. I try to oversee them. I just join most projects on a per-need basis. Even if I’m not directly involved, I am always ready to help in some capacity. I try to make the best use of my experience and knowledge.

Also, I can tell that asking others for help is a valuable skill that most people should learn in their lives. From my own perspective, however, I can tell that it is really hard to do. I know there is a limit to the knowledge you can gain on your own. So, I can read tons of stuff, but will not know the other person’s opinion about the technology before I actually ask this person.

Also, when I’ve come up with a solution, I will not know if the other person's solution is different. Maybe even better. For example, the schooling system doesn’t foster creativity, while this is a very coveted skill in many problem-solving industries like the IT industry.

Q: Does a CTO need to be technical or creative

In IT, you have to be this person who is able to imagine some solutions, and come up with different approaches to a problem. Do you think people can learn creativity? Do you use any tools that support it? Mind Maps, Ishikawa diagrams? Debono hats?

Przemysław Królik: I have no idea honestly. While I do know these tools, I wouldn’t say I use them on a daily basis. What I actually do a lot is discuss problems with other people. I listen carefully and let them voice their vision and express concerns. It fosters creativity and helps them develop professionally.

Q: Is the role of the CTO to drive the company’s tech revolution?

It is believed that it’s the CTO’s responsibility to drive the company’s tech revolution. Is this true?

Przemysław Królik: Not really. I may sound conservative here. I enjoy new things, but “revolution” at all cost may not necessarily be the best idea. Certain caution is needed when looking at new stuff. The tool must ultimately help you meet the business goals. As a small company, we can try different things, but it must conceptually align with our core tech (our case: JavaScript). It is the common denominator for us. It gives us a business advantage. It is more about aligning the technology you use for the goals of the company.

So, if we want to try something new at MasterBorn, we could probably go with Angular. Look for new devs. When something goes bad, we need another person to take care of stuff. But it takes away the possibility to move around our experts between projects, because this stuff takes some learning. We lose transferability of skills. This person would need a lot of time to become an expert.

You need specialists to maintain your projects, and it may quickly get out of hand business-wise if there are multiple projects developed in different technologies.

It takes a lot of time to recruit the right people, and they may still not be right for your specific project. Sometimes you have to continue recruiting for weeks or months. Is this something you can afford? You may also end up with a bunch of talented employees, but their skills are just not transferable between projects. So, the bottom line is: I really support trying new things, but certain caution is needed. It can get out of hand and become a liability business-wise.

How do you plan this? Do you set aside like 20% of the time during the month for testing new technologies?

Przemysław Królik: No. Having an actual RnD department at the company is actually one of my dreams. Technological revolution is a great thing in every company, but the definitions vary. It means something different each time it happens. For example, as a small agency you can test new frameworks and methodologies internally, but it is certainly not as affordable as trying things in bigger companies (e.g. >1,000 people).

Summary

CTO is a role which reflects the evolution of a programmer from a person with a vision and an ambitious programmer to a person who orchestrates staff at the company to work towards one goal, and under a single technological banner.

CTO is not a role for everyone. There is a certain amount of stress and responsibilities some people just don’t like. Chances are you may not have what it takes. But if you’re considering building your career towards becoming a CTO at some point, we hope this article is a good start.