Should CTOs Write Code?

In the world of technology, the question of whether a CTO should write code or not has been a topic of discussion for many years. Some argue that a CTO should focus solely on strategic planning and management, while others believe that a CTO who doesn’t write code loses touch with the technical aspects of the job.

However, the answer to this question is not a simple one. In my opinion, it depends on the environment in which the CTO is operating. Let’s take a closer look at these environments one by one.

Situation in Startups

Let’s leave software development or writing code aside and give an example from another area. Suppose we’re opening a hamburger or fish restaurant. We’ve chosen the shop, bought the tables, made the decorations, and now it’s time for the menu. At this stage, imagine saying, “I can’t eat my food because I’m a vegetarian.” How ridiculous does that sound? It makes no sense for any professional not to be a consumer of the service they provide. You should be in a position where you taste what you produce or serve, know its deficiencies, and inspire the people working with you.

For software development, the situation is no different.

“Startup” is a general definition given to companies searching for the most suitable business model for the dynamics of the market. In this context, a company must constantly be searching, which means regularly doing A/B tests. It means continuously writing new code and examining the results, making decisions regarding the changing situation. Or maybe, if the startup is at a much earlier stage, you may be preparing the first product. It is unthinkable that the CTO, the most senior technical person, would not write code in such a situation.

During a company’s startup stage, the number of employees is low. For example, in a company with only four or five software developers, the team does not respect a CTO sitting on the sidelines and saying, “I do not write code.” Software developers want to see the leading profiles of the company they work for. Their motivation to work is money as well as learning something new -- that is, professional satisfaction. This satisfaction can only be provided by the CTO in a company of this size.

A startup CTO may not always have the most up-to-date technology; however, they still have the expertise to speak at a conference or meetup on specific topics still in use. If necessary, they should have the knowledge to finish any job that any team member started and code the missing lines.

For some reason, CTOs are usually back-end developers. These people rarely have full command of front-end or mobile technologies. Unfortunately, a startup CTO does not have the luxury of saying, “I don’t know web or mobile.” At the very least, they should have enough experience to chat with a Swift or Kotlin developer.

It is generally not enough for a startup CTO to be just a software developer. You will also need to have some understanding of system and network technologies. You’re expected to have first-hand knowledge of the meaning of NAT or DMZ, how the SMTP protocol works, how to configure DNS, how to get SSL certificates, etc. Furthermore, if you are a CTO in a startup that uses modern technologies and you are using a container technology such as Docker or RKT -- or if you intend to use an orchestration environment such as Kubernetes -- you will need more advanced operating system, hardware, and network knowledge.

A startup CTO is also expected to have experience in security. You must be familiar with the security of the software you write and have basic system and network security skills. As a startup CTO, above all, you must be able to debug and code, along with having skills in system, security, network, databases, and other areas. Of course, there are exceptional startups with CTOs who are not software developers, but I don’t anticipate that this model will work in the long run.

Situation in Enterprises

Answering the question of a CTO’s duties in corporate companies is not as straightforward as it is for startups, as these tasks can vary greatly depending on the company’s orientation towards product, project, or system management. Additionally, CTOs with backgrounds in business intelligence or database management are also common. As a result, it is difficult to make a final judgment as to their uniform duties. Instead, we can make a few assumptions and generalizations.

In general, a CTO’s duty in corporate companies is to represent their team in front of the executive board or board of directors and ensure that decisions are implemented within the specified budget. In some companies, the majority of a CTO’s day is spent in high-level meetings, and they delegate operational duties to qualified individuals. They then communicate these decisions to their team through these individuals and monitor and control their implementation. In such companies, it is not typical for the CTO to write code.

If a company has an established range of products and services, a CTO’s main duty may be support functions or maintaining a ready-made software package. In both of these cases, it is unlikely that the CTO will write code in their daily life.

While it is possible to write code as a CTO in a corporate company, it can be challenging due to potential pitfalls.

Slowing Down the Team

Sometimes a CTO’s day in a corporate company cannot be fully planned. Dealing with unexpected meetings or crises is an essential part of our job. In such situations, your team may have to wait until the Jira task is complete before continuing their work. This could result in the entire team being unable to close the sprint for a simple two-hour job. This not only embarrassed me but also slowed the team down and made them feel victimized.

Losing Street Credit

Your team members, especially recent graduates, may see you as an idol and forget that someone in their twentieth year of a profession can still make mistakes. It can be disconcerting for the team when an engineer with only two years of experience finds your error.

To be honest, this is a minor concern, but I must admit: “I have been writing code for almost thirty years, and I have not written a single program without any errors. Those who claim otherwise probably have mistakes that have yet to be discovered.” While it’s fun to joke around and criticize each other, it’s frustrating to have to constantly remind newcomers that the CTO is human and can make mistakes.

The Team Doesn’t Want to Overwrite Your Code

You worked hard to maintain your reputation by writing code and submitting it to the central code repository. However, months later during a code review event, you noticed that a similar code was present in a completely different location within the same application. When you asked why the code was repeated, no one could provide a logical explanation.

The truth is that they know the reason, but they are afraid to change the front-end code. Despite your efforts, you were unable to break this prejudice. You tried to explain that you can make mistakes too and that you may have written the code in a hurry or simply to serve the purpose. You encouraged them to do better. This is a problem encountered in some cultures, such as Turkey, where such a mentality is still dominant. Out of respect for their elders, they perceive making changes to your code as disrespectful. However, this mindset can be changed, but it requires effort.

Risk of Neglecting Your Other Duties

One of the CTO’s most important duties in a corporate company is to promote and market their technical team within the company. Though it may seem unpleasant, it is essential to present the team’s work and accomplishments to the executive board and board of directors. As one of the company’s most budget-consuming teams, who else will tell them that the money spent makes great contributions to the company if not you? Neglecting these marketing activities and coding all day will only increase the pressure on your team. In corporate companies, departments with technology teams that have customer relationships are highly demanding. If they go too long without updates on the team’s progress, they will worry and may reflect on those worries without hesitation.

Summary

In short, I no longer write code for corporate companies with the same dynamics as before. However, to earn the respect of the team, I am not hesitant to demonstrate that I can still write code as well as they can. To achieve this, I occasionally open IDEs and write code during technical sessions. I also impress them with examples during code review meetings. Additionally, I keep up-to-date with technologies in my open-source projects and proudly display them on Github. My friends on the team are more satisfied knowing that a coding CTO is doing marketing for them.

I understand that nurturing the company’s vision is a crucial part of my job. To accomplish this, I require time to “dream” and get away from daily operational activities. As long as I can create these opportunities, I will be much more successful.