Interview with Dmitry Simonov, creator of the CTORECORDS channel: “The main quality of techdir is the habit of winning”

Late in the evening, the general calls and demands that the release be rolled out after six hours - in the morning he has a meeting with investors in China. Developers - in order of importance for the project - prune, vacation, professional burnout, macramé and picket "green" to protect the rights of guinea pigs. Testers have already gone home. Timlid weeps like a “girl in an automatic machine” - her affairs are heartfelt. An office cat knocked over a vase of water onto documents with wet seals. The release needs to be rolled out with Chinese and Korean localization. And the closest specialists in Asian languages ​​are Tajiks in a hostel across the road.







You sigh and get to work. After six hours, everything works. Released. General satisfied. The developers are cheerful, cheerful and happy to try.







The usual everyday life of tehdir.







A lot of technical directors have gathered at the SlOorm DevOps. After the intensive, I talked with Eduard Medvedev about IT ethics , with Artem Galonsky about endangered professions and DevOps . And I was lucky to get acquainted with a unique tech-director-extrovert, who can organize anything and find a common language with anyone.







Dmitry Simonov ctorecords , founder of the Tehdir club and creator of the Tehdir Zapiski channel, https://t.me/ctorecords , told how to become a technical director, a kind of Jack of all trades in the IT field.









Dmitry Simonov and the blue llama or alpaca from eLama.







Techdir Career



You’re leading the Techdir Notes. How do you find time for this in the cycle of technical issues? What is it for you: hobby, self-realization, IT evangelism?







Tehdir Chatik and the channel are my own trend monitoring tools. In them, of course, I write my thoughts, but the most important thing for me is there to be people with whom you can chat and learn new trends. I’m quite actively digging the topic of joining business and technical teams, and this requires a wide coverage of opinions. Therefore, for the most part, I not only write opinions, but also test ideas.







Professionally, I still work as a technical director, I deal with both the managerial part and coding.







Just returned from Slurm DevOps, where he raised his skills. As for the managerial part, I am actively taking paid courses - and some of the thoughts from these courses fall into the channel.







Such an example was “Management Tasks”, https://t.me/ctorecords/1126 . This is a description of complex situations that often arise in work. It is important to understand that in real life, the technical director can be on any of the roles described. His task is to be able to get out of the current situation with the maximum gain and the least losses. The criterion for the correct decision is the disappearance of the conflict. The trick here is that almost always any role is not ethically flawless: either the CEO wants to save money on someone, or the employee wants to sell the company’s resources, or something else is going on.







Over time, my tools become more useful to participants. So, for example, the closed techdir club has recently opened, in which people of very high qualification have gathered. They are interested in communicating with each other on very specific topics, so as not to be distracted by the "ships plowing outer space", about which novice talkers love to talk. This is a very quiet chatik. Everything about the case.







How did you become CTO yourself, which way did you go? What are the most important milestones along the way? What did you understand important in the process of this way?







In 1995, while still at university, I went to work “on the Internet” - and since then 25 years I have always worked in the same profession. Step by step, I went through the stages of all variations of programmers, team leaders, and, finally, grew to techdir. He moved to Moscow and went all the same way anew a second time - he confirmed his skills in Rambler, Yandex and Mail. And only then he began to build his own technical solutions and teams.







An important point - I always loved the business I was doing. And he got real drive from success in the profession.







The most important thing in the profession, I think, is the ability to stop and think carefully about the future - to see victory in it. Only after you see her, as you yourself believe in her, can you lead people along as Moses led his people.







NB: The main task of the tehdir is to find a common language with everyone, remove the contradictions, clearly indicate the conditions of victory and the path to it. Motivate your team with your example. Tehdir is the captain of the ship.


IT community and tech club



Do you plan to somehow develop the channel “Notes of tehdir”. Other platforms? Or write a book? You have real stories there, instructive and funny, for a whole book.







Yes, a lot of funny stories have accumulated. For example:







     . ,   API     21:00.   ,   ,          ,     21:00. .    .
      
      





         2014    .      ,  .   2            (  18:00 ): - !     ? -  ,   . -  ...     ,     7:00     ! ? OMG...  -  .  -   ?     ?     ,     -     .    .    ... ,  ... -  , - , - ... , .    .     -   4   .          .   .   : -    ! -    .      ! - ....    ?  ?         ? -  .       ... !  .    : -   -   ? - ! !   - 00:30 .  -?  .  .   , ,     ,     ,    4  . -   e-mail,  ,  !  2      .
      
      





I systematically develop techdir activities and develop the community. Some of the topics raised cause such a stormy response that you have to adjust your own approaches to work on the fly. Thus, for example, I adjusted the approaches to the technology developed by me for external team audits and technologies for assisting in hiring technical experts.







I will not hide, I have very clear intentions and goals for the techdir community that I am moving towards. In many ways, I focus on requests from community members themselves, but there is also a global movement vector that gives meaning to everything I do.







I thought about the book and maybe even that makes sense, but I'll wait until there is a clear need for it. I would like this desire to arise "organically", and not through some kind of PR.













How do you assess the development of the IT community in Russia? In which cities is it most developed? What do you consider the criteria for development and formation?







IT in Russia (and not only in Russia) has become a social elevator that has raised talented young people to the level of not only world experts, but simply well-off people. The elevator is so effective that some flaunt not so much with their successes as with successes achieved thanks to a common hype.







It is believed that every kind of clever IT person is able to form his own team, find funding for it and create at least something that can be sold. Not everything is right, but this example is not very far from the truth.







Why are these successful community people? Why should they consult with people like them? They themselves do an excellent job! Each one is a super-mega unique, capable of building VKontakte, Odnoklassniki or even Facebook in one person. Such experts do not need anyone - they themselves with a mustache.







What do they need? What do these specialists need when they fall into the consumer society described by Jean Baudrillard?







NB: Hype is corrupting. Absolute hype corrupts absolutely. It is important to clearly understand where your achievements are personally, and where are the consequences of explosive market growth and a shortage of IT specialists. Self-criticism and self-reflection within certain limits is an important quality for a professional.

Tell us about the closed channel for techdirs. How he appeared, what tasks he solves, what kind of people are present there.







The Closed Techdir Club was a response to the request of a group of highly professional IT specialists to retire to a place where they can discuss the most sensitive issues, while not being distracted by the opinions of the June / Pioneers. The fact is that the real “chess players” are simply tired of the numerous Bender Ostapes, who instead of real discussions constantly self-promote and push thoughts in the style of “ Chess thought that turned the county town [New Vasyuki] into the capital of the globe will turn into applied science and invent interplanetary communication methods . " Obviously, the pros from the category of authors of Kotlin, Tarantula or Postgres are interested in things quite specific and clear. These guys focused all their aspirations and goals in life on a professional orientation.







The club exists only a few months, and the audience is only getting to know each other so far. All these people are accustomed to power, accustomed that their words are perceived without criticism and as a law. Here everyone knows who is who, and very carefully communicate with each other. The result is a really interesting construct.







The topics so far are raised rather narrowly - I occasionally make quotes samples. One of the articles published on the public channel is questions on the technical processing of logs.







In the near future, as far as I know, you plan to speak at the meeting. Tell me more about what you will talk about, what problems to deal with.







Yes On October 9, at 19.00, the Team Lead Meetup will be in the SkyEng office to manage the team and knowledge from team leaders. Broadcast at this link: https://youtu.be/Y9Sxg14pads







This will be a review report before the Timlids on the essence of the work of the techdir. From company to company, the role of techdir is completely different, but in the big picture it is always working in three teams: a top team (developing infrastructure), a product team (developing business solutions) and a technical team (implementing infrastructure and business solutions).







The product team will always be drowned for crutch-oriented solutions that accumulate technical debt.







The technical team will be drowned for the work in the right way, for the use of hype technologies that are expensive to implement, for the work on detailed technical specifications that someone else should write for them.







The top team requires precise timelines and resource estimates with a minimum of precise wording for the technical team.







At its core, the work of the techdir is to daily resolve the conflict between money, users and development.







NB: Techdir in almost any company is an arbiter who smooths out the contradictions between the product, technical and management teams. And each participant in the process finds a construct that will benefit the project.







The Tehdir Day in St. Petersburg on September 3 was a success. Planning to develop this event? And why on September 3, when "everyone flips calendars"?







Tehdir’s day was very shocking - more than a hundred people registered, among whom were general and technical directors, team leaders, architects, products and projects. It is amazing that from the prepared stock of beer and lemonade, lemonade just sold very well, and more than half of the beer remained. Another stereotype can be thrown away.







The holiday was held synchronously in St. Petersburg in Selectel and in Moscow in Skyeng. We arranged a full-fledged video bridge between the capitals and congratulated each other.







According to the results, we agreed not only to annually celebrate Tehdir Day in the capitals, but also to extend the holiday to all cities with millionaires by the type of franchise. Now we are collecting applications for participation (write to dsimonov@gmail.com!)







What is techdir?



HR, who spoke at Tehdir’s Day, have repeatedly said that it’s very difficult to formulate who CTO is, what kind of animal it is, what it is eaten with, and how to hunt and headhunt it. How do you determine what techdir is? And how did this profession develop?







Techdir - it sounds proud! From my point of view, techdir is a synonym for the word “winner”, who believes in himself, believes in his team, believes in victory! And he wins. It cannot but win - otherwise it’s not a tech editor, but just a developer who imagines himself. This is his main task - to overcome difficulties, convince colleagues, implement plans. But the most important thing is to see your victory and understand in detail in the details how it will be achieved. What are the little things? These are details whose values ​​the techdir does not understand. What is Tehdir then?







In this case, no matter how professional he is, he will lose any battle, merge and tell the shareholders in detail why it didn’t work out. With a presentation, excellently delivered speech and justification. And then he will go to conferences for a long time and talk not about how to build projects, but about how not to build them. This will be a professional of why the project will not work. I periodically meet such people in peach clubs. Their words always begin with “Now I’ll tell you why you won’t succeed!”







NB: The most important quality of tehdir is the habit of winning, seeing victory in difficulties and problems, and never giving up. You can always find a solution in any situation - you just need to look at the problem from a different angle and expand the tunnel of reality.

If you were to select techdir for a parallel project, by what criteria would you select?







At HH, upon request from CTO / CIO in Moscow, there are many hundreds of resumes. If you look closely at the profiles, then in fact this is a wanna be CTO / CIO resume. Former executives and managers who want to try in Chief positions. That is, those who consider themselves CTO or want to become one. How among these many candidates to figure out who is worth what? What to ask them about?







  1. Recommendations from business owners are very important. And if you broke up with someone not very friendly, ask immediately to comment. These people are your colleagues who already know how to work with the candidate and from them the list of rakes is important for you, which is better not to step on.







  2. It will also require recommendations from subordinates. These people have experience subordinating to the candidate and experience trusting him as a leader. In the final analysis, a lot depends on such trust of the team. Look at what he really knows how to do with his own hands and how it relates to your project. Here it is important not so much that he himself build everything with his hands, but, in principle, his willingness to delve into what is happening in the code. Clarify the stack of technologies with which the candidate has experience interacting with specialists.







  3. The list of independently launched projects with urls and a description of the role on the project. There must be some kind of reinforced concrete evidence of the reality of this role, and not just “stood by”. This paragraph is about the fact that the candidate is used to bringing his projects to mind. If he doesn’t have such a skill, he can very well learn it - at your expense.







  4. A description of the principles by which the candidate will compile a table ph with a cut in the specialties with fixed payment per month and / or hourly pay. FOT always torpedo, and if the candidate has habits for its formation, it means he knows which sides to cover when torpedoing.







  5. If possible, examples of self-written documents. For example, a strategy session, a painted feature with technical decomposition, pieces of technical specifications, test documents, a schedule, detailed schedules, and that’s all. All of these documents, of course, are trade secrets or chipboards. Nobody will give them to you.









It is important to make sure that the candidate is used to working with such documents, has the knack and is not the first time for him. All this must be settled in his head. If he thinks how to build these documents, and not builds - this is an indicator of lack of experience. Habits fixed at the level of the machine say sooooo much.







These are difficult questions - and not everyone will be able to answer completely. Even if the answers to these questions are very modest, it is much more important that they are honest. Preliminarily discuss with the candidate what you expect from him, first of all, trust and honesty, and secondly, about a grand experience.







The most important thing is to be able to understand for each candidate how he is used to working, what he does “automatically”. It is these skills that he will use in any difficult situations.













Are there technical manuals, parameters and criteria for Tehdir or is it the mythical Jack of all trades?







A quarter of a century ago, webmasters were boys. Then came the web programmer boys. Then came the fullstock boys. In general, the boys were required to come and do everything. (laughs) Now these boys are called technical directors!







True, in order to become full-fledged techdirs, the boys had to upgrade significantly. A team of up to 5 people can still be controlled manually - in fact, this is a dumb “hardcode”, as programmers put it. For large teams, the hardcode no longer works - you need to introduce fully-fledged complex and flexible frameworks, develop the basic processes in them. Techdir is a person who programs not only in programming languages, but also in document language: he plans budgets ph, writes test programs, develops policies for hiring, onboarding, and layoffs. Now he operates not with variables, but with teams, data centers, infrastructure. He is more concerned about business issues - and often they are more important than beautiful local technical solutions.







Work begins with a balance between budget, timelines and technical solutions. In addition to these voluminous tasks, in which a significant part is occupied with working with people, there must also be something that distinguishes this particular techdir from others: his own personality. In many ways, everything is determined precisely by this personality - and technical solutions in the first place.







For example, if we are talking about a technical maintenance engineer, then he focuses on a whole bunch of system-tuned monitoring systems that monitor the targets. The order of work is very important for technical experts, and for such operators the most stringent compliance with regulations is in the first place. These are still general trends for all techdirs.







But a person is determined by the fact that she is able to set trends herself. For example, release your own plugins and tweaks for well-known monitoring systems - tailored to his own needs.







Why is personality so important? In its absence, there will be nothing in development, and the techdir itself is easy to replace - there is no difference who works as a techdir. And there will be no traces from the previous incumbent techdir. He will be forgotten the next day.







NB: Techdir - should be not only a good specialist, but also a person. With a unique approach, with high initiative. This is indeed the captain of the ship - if he is not an example for everyone and does not cause respect, the team will ramble around pears and scatter in each port. In a sense, the technical expert is not programming the code, but the people and the team.

Since people started talking about professions, there is an opinion, for example, I was told by Artyom Galonsky from the Bureau-Bureau that the DevOps engineer does not exist in nature, that this new profession was invented. And most often this self-name serves to request a higher salary in the labor market, but in fact, the DevOps engineer is just an admin with excellent knowledge of Kubernetes. How would you define what a DevOps engineer is? Have you ever hired such an employee?







The development world is rapidly accelerating at the “last mile”, when the implementation is underway at the sprint level, but the previously existing technical and organizational tools for system administration could not cope with this and became a narrow neck.







Developers (Dev) and admins (Ops) have always arranged mutual battles with each other. If there was a problem, then Ops said that the code is a problem, and Dev - that the server settings.







Then they came up with a methodology for which it is necessary to build a team in such a way that Dev and Ops regularly exchange experience in developing and maintaining the project. It provides a team solution to the problems of supporting and developing software development and delivery using numerous tools that provide work with code, assemblies, testing, assembly artifact management, release management, configuration, monitoring and logging.







In my opinion, for devops one k8s is not enough, you need to understand in architecture and development, to be able to build reliable systems and deploy where you need to, write code and understand it, at least a little. I look with interest at the Slurm training courses that teach DevOps and SRE engineers, but for now I prefer to use not the services of singles, but the work of teams. This is due to the fact that teams from competence centers give a guarantee of the stability of my infrastructure at the price of one or two engineers.







Sometimes “fashionable”, “hype” professions, which exist for one or two years, appear on the it market and disappear. Once, about five years ago, all companies rushed to look for Jira setup specialists, then, about three years ago, everyone decided that it was impossible to work if the team did not have scrum master. How do these professions feel now? And won't the same DevOps engineers be expected in a couple of years?







Specialists in Jira and Scrum have formed their small community and, by the way, I regularly order some services from them. Depending on the depth of study, they earn more or less money.







Devops - .







?



, , . ?







, , , , .







, . , — , sre . — , , , -, - . ? — , , .







, , . , 10-30 , . , , , — , — . . . , .







« 10 .», . , , . , , , , .







, , , . , . , , , . , , , , , , , - . — , .







NB: . , , , , . , . .



All Articles