Hello, Habr! My name is Igor Desyatnikov, I am Chief Technical Officer at Neuro.net. Several times I met articles on Habré with an attempt to tell about the role of the service station, about the evolution of this position during the expansion of the company, etc. I agree with some things, but not with others.
Today I will tell you about my vision of the position of the SRT. If it works out, it would be great to raise a discussion in the comments. If you disagree with something, just want to add or share your own experience - let's discuss.
Who is a CTO?
There is a different understanding of the CTO's position, and it is quite natural that each company can have a completely different story. Here are some examples.
One company wants the candidate for this position to be, in fact, the team lead of the team: writing code, designing solutions and architecture, conducting code reviews, and performing other duties of the team leader. You need to build processes only within the framework of your small dedicated team and all that is expected of you is a working product. Most often, such a role of a service station is assigned to a company that is at the stage of a startup and creating an MVP product. In fact, they need to get started quickly, launch a minimal product, and test its viability.
Another company wants a CTO to handle development processes, infrastructure, tech management. This is a kind of development manager. In Western companies there is also such a position as VP of Engineering. This role is closest to me, although according to my duties now I have to do a lot of things from above.
In a third company, they may want the CTO to handle presales, company promotions and marketing.
And each company is right in its own way, there is no point in arguing here. I think that it is already good when the founders and shareholders, in principle, understand what the service station should do in the company. Understanding the problem is the first stage of its successful solution.
In my opinion, the service station has a “minimum program”: a person in this position must understand what the main opportunities and risks are for the business, focus on them and focus on the issue of business growth.
To summarize, in my understanding, the service station is responsible for the company's technological development strategy and manages the entire technical unit. In this sense, managerial skills are more important than technical ones. CTO is not someone who knows everything, but a person who has surrounded himself with specialists who know everything that is necessary for the development of the company, and he can manage it all.
How do I become a CTO?
Here I will briefly describe my path of growth, it is clear that it can be completely different for other colleagues.
The Beginning of the Path
My path to CTO was through development and management. I started my career as a test engineer, then moved on to developers and eventually grew up as a team lead of the development team. At some point I realized that I wanted to grow into management and management, so I moved to the position of Engineering manager. Then, for several years, he headed a large development department on Highload projects. Personally, I believe that the CTO needs to know all the technical processes from the inside, know the pains and potential bottlenecks. It was this path, from testing to development and department management, that I went through, but I emphasize once again that it can be completely different.
I am asked from time to time: "How do I grow up to the head of the development department or to the team lead." Of course, I help to figure it out, but often this is not a leadership story at all. More often than not, those who ask such questions grow worse in management than, so to speak, natural leaders. In my opinion, in order to achieve all of the above, you already need to be a leader, these are some kind of personal characteristics, soft skills, if you like. This is very difficult to teach, you either know and you can or you don’t.
Work at Neuro.net and the range of tasks that needed to be solved
When I joined the company, it happened at the end of 2019, the team was small - only 10 people. Neuro.net was a real startup at the very beginning of its journey: without processes and a clear organization, but with plans to take over the world. Fortunately, the latter is being implemented a little at a time. So, for a very difficult year for everyone in 2020, we managed to grow 10 times at once, so now there are about 110 people under my leadership. At the same time, we continue to grow aggressively. Of course, we
Now about the range of tasks. At the very beginning, I had goals for hiring people and building business processes. It is clear that with the rapid growth of the company, the processes have to be changed literally on the fly, somewhere with a file (or even a rasp) to grind them, somewhere to introduce something new. All this forces you to be resistant to stress and be able to quickly switch from one context to another. There was and remains a lot of work, even too much.
Perhaps, readers will be interested to hear about the nuances of interviewing for a CTO position. So, questions can be completely different, including a block about hiring a team, building business processes, solving complex conflict cases, development methodologies, etc. Otherwise, this is often a rather lengthy technical interview: databases, networks, architecture, etc.
The most appropriate question that I have met in an interview: "We have such and such a task to develop a product and build a team, how would you help in solving it?"
The nuances of the workshop
The duty of a leader, first of all, is to build a working mechanism. If you require frequent immersion in details, do something instead of specialists who did not cope or performed the task poorly - you have management problems or, perhaps, the wrong people are doing the work.
The real sign of an effective leader is that he practically does not have to do anything himself. The need to get involved in details should be a bad signal for the manager. There is a cool quote, I don't remember where I heard it, maybe it's from Habr: “If your CTO doesn't know how to write code, I have bad news for you. If your CTO writes the code, the news is even worse. "
Personal experience at Neuro.net
We usually hold weekly meetings with each development team, from operations to development and testing. Where the processes are not perfect or there are many new people, we meet more often: 2 or 3 times a week. At these meetings, we traditionally discuss what we have done, what we plan to do, and what problems there are. Such a structure of meetings allows you to always stay up-to-date, understand what is happening in the team and, if necessary, give someone feedback.
There are periodic meetings when employees can ask any question, ask about their pain, ask for help. Of course, individual meetings are also practiced. We try to hold them as often as possible, because at a distance, people lose touch with the team and the company faster.
Sometimes we have to gather working groups for some projects in development, which require efficiency or break our standard development process. I also have dashboards and notifications set up in JIRA, which allow me not to fall out of the workflow.
As for the problems, the biggest headache is where to find developers, what budget to allocate for them, and where to get it. In general, the history of money is very closely connected with the life of the service station. Considering the not always adequate IT market, this task greatly complicates everyday life.
Work and personal time
I consider it important to highlight this issue, since it is not touched upon so often. As for me, everything is complicated. This is not the same story when you leave work at 17.00 and completely switch to your personal affairs, it is simply impossible to do. There is no such state when you have no problems or no areas for improvement, you are constantly thinking about something.
Urgent calls, problems and so on occur from time to time. All this needs to be addressed and decisions taken very quickly. Considering the crazy growth of our company, decisions need to be made at lightning speed, and there can be many such decisions even in one day. I think that there are very few top managers who are able to “zero out” immediately after leaving the office. Why? Yes, simply because in most cases it is simply impossible.
Leadership Tips
From time to time I come across stories when a new leader comes to the company. His eyes are burning, he almost immediately wants to redo everything in his own way. This is a typical mistake - in no case is it worth it, without understanding what is, to break the existing structure and processes, building something of your own on the ruins. It is not a fact that the new will be better than the old. The situation is aggravated by the fact that the company spends a lot of time on restructuring and all these revolutions, losing valuable employees along the way, who could not or did not want to come to terms with the changes.
So the first piece of advice from me: first, carefully study how everything works. Change only what the soonest changes are objectively ripe for, and be sure to explain to the team why and why you are changing it. Support and develop further what is already producing good results. Don't break what works well, you will create a lot of negativity in the team. More details can be found here .
The second piece of advice that I want to give and which is relevant for me right now: protect the team of techies from business and their wants, become a buffer between the technical department and the salespeople. Otherwise, you will simply turn into a tool for realizing the desires of other departments, there will be no strategic development.
Well, and advice number three: regularly "check your watches" with every employee who is important to you and the company. Talk to your key employees and discuss with them anything that worries them. Perhaps you have no idea about these problems or the person who cares about them misunderstands the situation. In any case, it is important to discuss them openly.
Read specialized literature. At one time I was very impressed by the book "Principles" by Ray Dalio, I still consider it the best business literature on management, I reread it several times. Simpler books can be found at the link .