Timlid is a sergeant in the IT department
Sometimes it seems that a timlid is someone or something like Snark from Lewis Carroll's poem: it definitely exists, is described in its everyday and business manifestations in a versatile and contradictory way, but with all that it is a mystery. Understand how significant this (Timlid, not Snark) role in engineering teams is, who is more correct to put on it and what pitfalls are hidden in “teambuilding” promises to help Saint TeamLead Conf 2018 , which will be held September 24-25 in St. Petersburg .
A month before the event, we talked without further ado with the technical director of the Mos.ru project, Roman Ivliev , who heads the Program Committee of Saint TeamLead Conf 2018. In the conversation: who are the team leaders, how to prepare them correctly, who and what should they be trained for, what should to be their duties and much more.
')
Roman Ivliev was born in 1982. In 2005 he graduated from the Faculty of Cybernetics MEPI. More than 15 years in IT. Specialization: high loads, management in technology teams, training.
Last jobs:
• In 2009–2013, first as a senior engineer, then as a project manager at Kaspersky Lab (responsible for supporting and developing corporate websites — both b2c and b2b).
• In 2014–2016 - Director of Information Technologies, Banki.ru
• He occupied the position of CTO in the Mos.ru project at the end of 2016.
- For nearly two years, you have been a CTO in the Mos.ru project, and before that, he worked for many years mainly in commercial organizations. What, in your experience, how does a technical director in a government structure differ from activity in the same position in business?
- From the point of view of production processes, there is no significant difference. The system of setting tasks is not much different from those adopted in commercial offices. The difference in scale: usually a state project is a huge mechanism. His work involves many people who have the right to make and make decisions. For comparison: if in Banki.ru we sculpted some internal project with five of us, then in Mos.ru about twenty people could be involved in it. In the state organization, the IT division is a bit more difficult in terms of building external communications: sometimes, you try to catch the right person for half a day - simply because the staff is very broad. But with those with whom it is necessary to interact regularly, including through the integration of services, we are on a short foot: we have got acquainted with everyone.
In every corner of the Department of Information Technology of the City of Moscow (DIT) and other structures with which we have to interact, our own rules of the game and our own problems, as in any huge organization, but at least in the same Sbertech. Our Mos.ru is not much different from b2c market services - except that we do not earn money.
Of course, we are also dependent on legislation. And if we translate a certain service into an electronic form or publish a new service, it is only in the presence of an appropriate regulatory framework. Assume to equalize the rights of those who are recorded to the dentist on the Internet and through the registry. Inside the department is not our area of ​​responsibility. Sometimes, we postponed the release due to similar circumstances, which we could not influence. Although the business is now the same leapfrog.
- What is behind the facade Mos.ru?
- Mos.ru is the gateway. A portal that brings together a whole scattering of services. When it operates a newsroom, which writes about the events in the city, is a poster. There are sections that we are obliged to have in accordance with the law, for example, containing information about regulatory legal acts and the structure of government. These parts of the resource are also filled by specially trained people. We are preparing them for the mechanics of content management, they use it.
Even in the area of ​​our responsibility digital-special projects. From the fresh - made such for the park "charge".
We, relatively speaking, have a full-cycle team. Something we take from the side, although rarely. Other services that live in the www.mos.ru domain, but are not developed by us, but by other units of the DIT, are available on the site due to internal integrations. We hide them from the user so that for him any transition within the portal is seamless. Sitting on Mos.ru, you can easily be in another system, however, if you don’t get into the page code, you won’t notice anything.
The same city “ Goslussugi ” (they can be accessed through our website) is engaged in a separate team. Their services, in turn, are confined to industry-specific IT systems: healthcare, social, and so on.
- How large is the team involved in the maintenance of the portal under your command?
- In the development of twenty people. With a dozen testing, including those involved in automation. Add the operation team and DevOps here. In total, up to fifty, the exact amount and composition depend on the current circumstances and load.
- How do you build a hierarchy of technical leadership? How are areas of responsibility divided?
- We have three main areas: development, testing, operation. Operation, in turn, is divided into clean operation and DevOps. And those who interact with data centers and those who are engaged in automation stand out, but they have a lot of common tasks, so I don’t spread them across different camps.
Testing is implemented under the “testing as a service” scheme. There is a group of testers and her boss. They are nominally tied to teams, but in fact are not their members. If necessary, we transfer testers from task to task: these guys are cross-functional with us. The exception is mobile. For testing mobile applications, we have detached special people and try not to twitch them for nothing: their work has a pronounced specificity.
We also have DevOps as a Service: tasks are set, prioritized, and flowed through devops, which are also not assigned to any teams tightly. Operation works in a similar way.
But the development is divided into teams in functional areas. We have teams of two types. The first - highly specialized. In particular, the one that does the search. It does not touch the front end and the GUI: only the backend. Sawing their algorithms, clinging to machine learning, doing wizard, hints, statistics, analyzers, correcting typos. They are sitting on their technological stack and are joined with Mos.ru through the API. The search service connects to any part of the portal. A separate team planted on the direction of mobile applications. She has her own backend.
Both of these teams interact with the “core development” of the DevOps lines, test and operate.
The second type of commands is those that create and support separate Mos.ru modules, including GUI. Each usually has five, maximum six employees depending on the direction. In such mini-groups, there is a clear separation between the front end and the back end: in our case, it proved to be effective. Most of my back-stackers are full stack developers, but I don’t force them to spin on two dance floors at once. Each such team has a timlid.
- That sounded the word. And what does such a tmlid do?
- First and foremost, he is a strategist in his sector of the front - he is following him to observe the rules of the game that we have established. On it - among other things - decomposition of tasks, code review, organization of retrospectives, education of newcomers.
Translated into military ranks, this is someone like a sergeant — the squad leader. He is empowered and has the right to make decisions within the framework of the technological decisions and standards that we have jointly adopted.
Plus, my teammates are part of an architectural team. This is not a formalized and not permanent structure: it arises when there is a need to invent something new in terms of technology. Then all the team leaders, the heads of the testing and operation departments, and all others who are vitally interested in changes are going to meet me. Experts with different competences, with different views on the technological landscape, with different positions, sit down in a circle. Discuss controversial issues, fix the agreement, come up with an architecture or solution - and disagree.
Until recently, that in Banki.ru, that in Mos.ru, I had only “Beks” in my teammates. As a rule, this role was assumed by the senior back-end developer. But at the moment I have two Timlids from the front end.
Everything is changing. We had to adapt to the current technological realities, and as a result we got what we called guilds.
The thing is: in 2018, the front-end is hard to keep track of what's going on in the backend world, and vice versa. We realized that people need to cooperate on a horizontal level, to stray into informal associations without direct subordination, but with statuses - like titles in secret societies, something like a “master of the order back-end”. The carriers of such “titles” are people who de facto make management decisions of an applied nature: will we move to PHP 7.2, will we develop Angular, or is it better to rely on React.
Guilds are regularly assembled - separate front-tenders, separate back-tenders. They gather and find out who is good for whom, who is bad for them, which is fashionable and cool now. They argue whether a Webpack is a dull hat that collects a lot of unnecessary things, or you just need to learn how to handle it. Just do not pour from empty to empty, and come as a result to a practical solution.
Ultimately, the architectural team replaces my system architect. Yes, I have no system architect.
- What place does team lead in your team? Does he report directly to the CTO or are there intermediate level managers?
- We do not have an intermediate level - it just happened. According to the logic of things between the team leaders and me there should be a development manager. In fact, in the testing and operation departments there are heads, but I personally lead the development. Therefore, the Timlides report directly to me.
Slightly more cunning scheme of submission in devops. Initially, I was also going to isolate them into a separate group with my boss, but the guys and I thought about it and decided that this was a superfluous management link. Brought to DevOps instead of the boss Kanban, and this is highly satisfied.
- When did you first encounter with an entity like a timlid in development? When on personal experience did you find out that this feature is useful?
- In 2008, my colleagues and I wrote cunning software at a defense plant. Once we buried our nose in the fact that it was offensively simple: a team of ten developers was not able to produce anything, but was only able to decorate and swear. Then, for the first time in my life, the phrase “group leader” arose - a kind of prototype team leader.
The group of engineers was divided in two, appointing each of the two groups in charge. I was one of them. We began to build internal development processes with the head of another group and to debug the interaction between the halves of our mini-team. Together we have turned the herd-type collective into two effective combat units. We began to distribute tasks between them and prioritize these very tasks, plan for longer periods, and, finally, synchronize the work of the teams in order to avoid downtime.
In Banki.ru, the structure of the technical department was also “cellular”: the teams in it were controlled by team leaders, and most of the time I was in direct contact with them - five, in the absence of the head of development. Just like now in Mos.ru.
Prior to that, in Kaspersky Lab, where I was responsible for the operation of corporate sites, I had several teams under my control — of different profiles, with different technological stacks. So I would have damaged my mind there without the Timlids - the leaders of the groups that saved me from the torment associated with building a technological panorama in all details. I interacted with them at the level of ideology and overall coordination of processes. And building the rules of the game - how to perform a code review, whether to help the younger ones, to reprove seniors, and so on - remained on their conscience.
And again about the same thing: with whom should the timlids be compared, if not with sergeants? In the States, the whole army rests on them. I can't do it without my “sergeants” either. Rather, I can, but with pain and through the stump-deck. They are my eyes, ears, hands. They are the first to carry my wishes, suggestions and instructions "to the masses" and make sure that all this is implemented.
- In your opinion, is a timblid more likely a profession or a situational role in an organization, by analogy with a scram master?
- I now have both in the team. It’s one thing when a team’s tasks are mostly of the same type, and people move in a single rhythm. Another is when a team performs parallel tasks on n tasks, where n can exceed the number of engineers in a team. In the second case, the team leader has every chance of becoming, albeit temporarily, a natural administrator who will “route” these tasks. As for me, this is both the role and the profession.
In addition, the market is still arguing about who the Timlid bird is in principle and what its basic functions are. Everyone comes up with a configuration, which one he likes. More often, they even proceed from what tasks it is necessary and appropriate to solve in a specific team. For example, in Banki.ru, I delegated staffing to my team-mates: they “enlightened” sufficiently to ask the right questions at the interview, not only to determine the candidate’s qualifications, but also to test his soft skills. Little by little, the guys were pumped and turned from ordinary technical managers of the initial rank into units of the following levels. In Mos.ru, we gradually came to the same system. The guys study resumes themselves, look at candidates, conduct technical interviews. I often attend this stage as a spectator.
Is there a team leader as a profession, a question about backfill. Is the team leader a profession? Absolutely right. Only in rocket production one, and in programming another - from the point of view of the functions performed by its representative and the spectrum of the tasks it performs. In the firm, where five people are sitting in the development, there is one. In the office for 250 employees is another.
The same with the scram master. No one bothers him to be a back-tender, a front-end, a tester, and at least a technical writer. The main thing is the ability to bring people together, adjust them to the desired mode and organize, reduce as much as possible entropy and encourage colleagues to move in a single rhythm and in one direction.
- Let's visit your ideal world. When the team includes a product manager (product owner), and a project manager, and all-all-all, where is the responsibility of the team leader? Timlid is more likely to "design" than "product"?
- He is closer to the "project", yes. But business is business, and internal engineering processes are internal engineering processes. The whole point is that its main area of ​​responsibility is the organization of labor in the “cell of society” that produces the final product.
More precisely, the team leader has two points of focus. The first is the organization of work in the micro-collective, from the collection of input data to the delivery of the result. The second is the provision of social interactions within the team and the establishment of its connection with the top IT management. If there is a clear bias in one direction or another, the matter is rubbish.
- What does a team leader have to control?
- First, he is trying to ensure that the rules of the game adopted at the level of the company, division, group of employees are observed in his clearing. There are rules for making code, maintaining documentation, and holding general events - that means everyone should follow them.
Secondly, he provides technical guidance: he is responsible for decomposing tasks, introducing them into development with the goal of making them as easy and understandable as possible, and monitoring their implementation. Adjacent to this is an underestimated and extremely important task of the team leader - to ensure the completeness of the input data for the team. For me, these guys are at the entrance to their mini-group as a filter: if a team is hit by a frank bullshit instead of TK, its team leader is pressing on a project or product until he formulates the right requirements.
When needed, a team leader extracts resources through exploitation, for example, network accesses. And of course, he understands how that part of the system, which his teammates are engaged in, is arranged, including how it is clear how the integration works. Otherwise, he will not be able to competently formulate tasks for testing and operation departments on behalf of his team.
Thirdly, such a manager, in the event of failures of any kind, with whom he is unable to cope, immediately signals them and brings them to the consideration of people capable of solving the problem. If the team fails to meet something on time, he barely finds it, walks to his boss, and without rassousolivanie admits: “We don’t have time, because we’ve missed,” and offers him solutions.
In Mos.ru of the 2018 sample, the tmlid is responsible for ensuring that incoming tasks to the team are closed on time, within the limits of a given budget, with the current composition of specialists. This is the ideal. Something fails - he immediately pulls into the world a problem with which he is not able to cope with available resources, and “squeezes” it until it is solved within the team or one or two levels higher. At least it does not leave the problematic process to drift.
Thus, the team leader is a full-fledged technical manager, not some sort of appendage from the category of "let it be."
- What other responsibilities can - or should - be given to the care of the team leader?
- Another part of the functions of the team runs very often, just depending on the circumstances, they give the organization more or less attention. For example, the adjustment of the development methodology: you, as a timlid in place, see best of all, whether the methodology chosen for all is appropriate for your particular site. Often it turns out that no. Imagine that everyone is sawing a GUI, and you are a service component. Obviously, your processes are quite different from those of your neighbors.
Moreover, there is a "humanitarian" mission: education, support, early detection of internal problems in the team a la "Something the engineer I have come to work dull." This direction intersects with the field of activity of the HR department. However, not all the companies where I worked, kept Eychara in the state. In some of them I was Haychar myself. In others, the HR department lacked contact with developers.
I still know in general what is happening with almost every one of my engineers. Let's say if one of them is approaching the burnout threshold. Often this information reaches me through the timlids.
The impact of team leads is not unlimited. If some developer constantly mows, then, obviously, it is necessary to expel or try to re-educate. Timlid can try to take action at his own level: gently shame or advise how to correct the situation. And if he does not help, he will come to me and say: “Something does not work, come on.”
By and large, filling the profession of a timlid - or a role, whatever you call it - functionality depends on the views and goals of management. And often it does differ from person to person. I do not insist that the duties of timlidov in Mos.ru were unified. People are different, the teams are different. Someone does not need to develop a stormy upbringing activity in his sector, so he focuses on engineering matters and on the synchronization of processes. At the same time, there is a team where we “subdivide” young guys, and in it the educational work, on the contrary, is very active: we need to embed a person in our paradigm and processes, which requires thoroughness. There, the guys are at the helm a little more experienced, and we will replicate their work in the future within the division: we need the best techniques and techniques,because we are going to work even more with young people, including through advanced training of newcomers.
— «», ?
- Deep, really deep. It is necessary that he distinguishes the husk from the advanced solution. He will have to do this often. After all, do not feed a good engineer with bread - let me try the newest technologies, and on the drum that they just appeared. Timlid, who communicates with the developers in his team and conducts the code review in it, can see some component that he had not previously encountered, which was not in the system. He will have to decide whether it requires the removal of the public (say, my architectural team). Let's say whether we will implement Vue.js, whether we want to switch to PostgreSQL 10 or “nine” is enough for our eyes. Like and not terrible questions, but in projects with a long cycle of support, about five or six years, they are by no means idle, and I begin to influence business.
Naturally, a team leader must understand the subject and be aware of current trends, at least in his professional field. He needs to be aware of how and by what reasons the technological stack in large companies of the industry is changing, as was the case with neighbors: for example, in what direction does the search on the Sphinx of Avito evolve. Otherwise, the authority of the team leader will be blown away in a moment.
On the one hand, the team leader becomes a manager, on the other - in a sense, remains the developer, and most often the senior developer. The position is twofold. But, from my point of view, if you want in your new capacity to communicate with members of your team on an equal footing, technological competence must be maintained at a high level.
You have no need to own product management to perfection to communicate with products. But if you manage developers, you should understand on the fly that you have just been called a new framework, and not sent you far and for a long time.
- What if you are a team leader in a cross-functional team? After all, we casually touched on the fact that the back-end and front-end diverged far from each other and it is very difficult to be megapros in both areas.
- It is desirable to still be savvy on both sides. Or, if you are a real backender and do not rush to dive headlong into the frontend, it would be good if a friendly “front” sat at the next table that will support you in terms of technology expertise. Well, you will continue to improve as a “back” and at the same time unite your colleagues and lead them to victories, motivating them, raising their professional level, and sometimes even entertaining them.
- From which specialists - according to your experience, before your eyes - were Timlides most often grown? Is there an optimal position to go into this state, say a senior developer or system architect? Who is best forged?
- It depends more on the person than on his position or specialization. In addition, depending on what company we are talking about. Somewhere, the most intelligent tmlids grow best of all from senior developers, some of them from architects. Architects, too, are different. Some program, others only draw, and others both program and draw, the fourth build super-heaped models. What is there, IT is often a non-standardized area, even at the protocol level. About people and say nothing. There is no such thing: since you are an architect, you are ordered to lead.
With the career path to the CTO point, everything is the same. Who is becoming the best tech-head - the one who was a team leader or an architect? Do you think that “an architect — a timlid — a technical director” —is a fork in the road to which a person necessarily falls, becoming a senior engineer, and is forced to choose? Solid questions.
- How to understand if a senior developer or systems architect has any potential to become a cool team leader?
- You feel the potential rather subjectively, relying on personal characteristics. When you hire a person or increase it, you still risk to some extent. The interview is a lottery. There are people who are professionally interviewed. They manage to get involved in cool companies without the necessary skills.
I myself focus on human behavior, on how it is treated in the division. Listen to him at general meetings or not. Does he speak at such events, does he take an active position: “I don’t want to code on your crappy PHP, let me write on Go, because here it will be good at this and that.” He sits down on the edge and goes into the tablet or listens vividly, waving his arms, reacting to the cues of others.
If I see that a person is “turned on”, it becomes calmer for me: I understand that he is less likely to give up at the first difficulties, and the others will listen to him in case of anything.
Further I arrange something like a trial period. First, I load a person with new duties for two or three weeks and see how he is doing. Something like learning the "Brazilian system." Of course, I help newly minted timlid, I answer his questions.
Timlid - a complex role. To hire or assign tmlida in principle difficult. So the selection of such a leader in the team - the whole art. He is devoted to a lot of reports on IT and HR conferences. How to hunt and motivate engineers, more or less figured out. And how can you hire someone who can manage a team and who its members will respect for their real technical knowledge and skills? Yes, there is always a bearded engineer in a sweater with deer, who in programming will shut up any timlid for a belt. But if you are in the subject line, if you are able to steer from delicate situations thanks to your diplomatic skills and to achieve results from colleagues without prejudice to your own positions in the team, then you are really valuable to the company.
How to pull out a team leader from the depths of the team is another discussion topic. No wonder many teams prefer to take Timblids from the street, rather than educating them inside. Prefer - or they just can not do otherwise.
And it happens that an excellent engineer with developed soft skills, who, among other things, is respected in a team, flatly refuses to become a team leader. Whether to try to appoint such an employee as a team leader despite his objections and doubts in the hope that during the trial period he will get a taste? Maybe it will. Well, I once, three months after such an appointment, left a great developer: he was not so nice with his new role.
— «» «-». , , . , ? ?
- Roll off, just go. And the task of the senior comrade - technical director or head of development - to pull a beginner team leader out of the swamp of excessive detail and excessive effort. Sometimes the team could not stand it and begged: “Take this leader away from us”. Especially often this happens when the team finds the lead inside. The man sat and programmed himself, and now he has a new front of work - everything is new. Not everyone gets a painless switch. On our September Saint TeamLead Conf , several applications were submitted on these topics: how to catch a person in the micromanagement phase, how to adapt it to “teambuilding”, what to do with its “tags”.
According to my observations, it correctly translates into the status of a timlid - without implanting aortic rupture and depression without failure - about half of the people. The other half, having hit the micromanagement, are confronted with a wild lack of time, and even in their head the usual thought is itching: “Why should I chew them, better I will do everything myself - I'm a senior developer.” We will also discuss this problem at the conference: there are different views on how to solve it.
Often, however, I often fail to solve it: I know a lot of cases of returning from the position of a team leader to the development under the motto: “Well, you have to go to the devil, I’d rather write code and get high, and you’ll manage it somehow without me.”
- What competences are most often lack of timlid in the Russian market? Where do they usually have spaces?
- In my experience, there are several such moments, but mostly there are difficulties with soft skills. In other words, with such non-technical skills as the ability to build communication in a team from top to bottom and from bottom to top, manage expectations both inside and outside the team, regulate internal processes depending on the external conjuncture.
Often, the Timlides stumble on questions of self-development, self-motivation, accumulation and transfer of knowledge, as well as the development of personnel and, in turn, its motivation. The range of problem points is very wide - it is better to look at specific companies, projects, teams.
- What, in your experience, is the maximum size of a team that a team leader can lead? What level leader does he actually become?
- Purely empirically, four or five people in a team are enough for comfortable work of a team leader. With this configuration, he has time for himself, for programming and self-development. In the literature, they write about 7 ± 2, the same numbers are called at conferences, but, in my experience, this is overkill if you want to be a senior engineer too (and cool developers love their job). In different companies in different ways, but on average in the industry a team leader is the level of operational management in terms of technical tasks and simple business tasks.
- How to understand if a team leads its tasks? What are the criteria for the quality of his work?
- In short: if everyone is happy, then everything is fine.
In other words:
• Team is vigorous. In it everyone understands who does what and why, what is it all for, where the team is going, what plans have been made within the division and the company.
• Management sees everything that happens in a team, understands the status of key operations and processes, sees prospects and problems, and most importantly, sees the manageability of the team and its ability to respond to external influences, no matter where they come from.
• Customers do not run in circles, do not complain to management, receive a product of good quality within a manageable time frame.
- Judging by the results of the previous conference, did Russian IT have a common understanding of who this team leader is in principle?
- Not!The question remained hanging in the air. It turned out that the breadth and variability of the notion of “tmlid” is commensurate with the size of the IT industry. Maybe it is right that there is no single standard definition: it means that this “teamwork” allows for a flexible approach.
Last but not least, we conceived TeamLead Conf, so that those who entered this “state” met with those who are only going to, and so that the latter could see that this is a wide world and that this activity is striking - and not for the worse side, contrary to common fears - different from the pure development.
Schemes of work in which the timlid may be involved are numerous. In the one that I have built in Mos.ru today, the product actively communicates with the team leader. Even so: the product carries its food thought timlidu. And in Banki.ru, on the contrary, the product took on itself the tasks of an analyst, and most often something that did not require detailed explanations was downloaded to the development; except on procedures like grooming backlog, sometimes it was necessary to shake the product and find out some details from it.
In some organizations, a team leader is a pure manager with a technical bias. He accepts a bunch of tasks at the entrance, distributes them among engineers, then controls their execution, accepts work, reviews them. And heychary and the head of development are engaged in educational activities.
One of the goals that we pursue in preparing Saint TeamLead Conf is to demonstrate to our colleagues this infinite possibilities. And clearly show that if you are a team leader in company A, this does not mean that by going to company B, you will receive exactly the same set of tasks with the same set of requirements for you.
- Were there any topics in the previous, first TeamLead Conf program that the organizing committee wanted, but could not dig deeply? How will audience requests be reflected in the next conference program?
- First of all, communication, the accumulation of knowledge and their management, work with the team, the adaptation of the team and yourself personally for the company's business processes. These topics were somehow affected in the winter, but this time we will give them more attention.
Also, we will not leave aside the toolkit of the timlid - what and how to use it in order to effectively manage the team.
- Do foreign IT companies have cool practices that it would be reasonable to “peep” at Russian team leaders? Will they be on the agenda?
- Exactly. We look at them and agitate foreign colleagues to share their experience. I think that by winter we will invite someone interesting with something interesting. In the meantime, we carefully refer to the experience of one, but very well-known foreign company. Wait a little before the publication of the program.
- What are the long-term goals of the conference? Create an “industry hub”, set professional standards, something else?
- Do not say that they are original. Moreover, it sounds pathetic to the utmost: to organize, support and develop a platform so that representatives of the Timid caste from both the IT industry and about the near markets communicate and exchange experience. As the practice of our other events shows, over time there will be an “industry hub” and everything else.
We learned to move the industry “from below” - through HighLoad ++ , through a series of RIT ++ application conferences, we adapted ourselves to invigorate the industry “from above” - through Whale Rider and Aletheia Business. The “middle time” has come: we gave a start to communication, showed that everyone has problems and that these problems have solutions, offered solutions to share and together move the industry forward.
A month before the event, we talked without further ado with the technical director of the Mos.ru project, Roman Ivliev , who heads the Program Committee of Saint TeamLead Conf 2018. In the conversation: who are the team leaders, how to prepare them correctly, who and what should they be trained for, what should to be their duties and much more.
')
reference
Roman Ivliev was born in 1982. In 2005 he graduated from the Faculty of Cybernetics MEPI. More than 15 years in IT. Specialization: high loads, management in technology teams, training.
Last jobs:
• In 2009–2013, first as a senior engineer, then as a project manager at Kaspersky Lab (responsible for supporting and developing corporate websites — both b2c and b2b).
• In 2014–2016 - Director of Information Technologies, Banki.ru
• He occupied the position of CTO in the Mos.ru project at the end of 2016.
- For nearly two years, you have been a CTO in the Mos.ru project, and before that, he worked for many years mainly in commercial organizations. What, in your experience, how does a technical director in a government structure differ from activity in the same position in business?
- From the point of view of production processes, there is no significant difference. The system of setting tasks is not much different from those adopted in commercial offices. The difference in scale: usually a state project is a huge mechanism. His work involves many people who have the right to make and make decisions. For comparison: if in Banki.ru we sculpted some internal project with five of us, then in Mos.ru about twenty people could be involved in it. In the state organization, the IT division is a bit more difficult in terms of building external communications: sometimes, you try to catch the right person for half a day - simply because the staff is very broad. But with those with whom it is necessary to interact regularly, including through the integration of services, we are on a short foot: we have got acquainted with everyone.
In every corner of the Department of Information Technology of the City of Moscow (DIT) and other structures with which we have to interact, our own rules of the game and our own problems, as in any huge organization, but at least in the same Sbertech. Our Mos.ru is not much different from b2c market services - except that we do not earn money.
Of course, we are also dependent on legislation. And if we translate a certain service into an electronic form or publish a new service, it is only in the presence of an appropriate regulatory framework. Assume to equalize the rights of those who are recorded to the dentist on the Internet and through the registry. Inside the department is not our area of ​​responsibility. Sometimes, we postponed the release due to similar circumstances, which we could not influence. Although the business is now the same leapfrog.
- What is behind the facade Mos.ru?
- Mos.ru is the gateway. A portal that brings together a whole scattering of services. When it operates a newsroom, which writes about the events in the city, is a poster. There are sections that we are obliged to have in accordance with the law, for example, containing information about regulatory legal acts and the structure of government. These parts of the resource are also filled by specially trained people. We are preparing them for the mechanics of content management, they use it.
Even in the area of ​​our responsibility digital-special projects. From the fresh - made such for the park "charge".
We, relatively speaking, have a full-cycle team. Something we take from the side, although rarely. Other services that live in the www.mos.ru domain, but are not developed by us, but by other units of the DIT, are available on the site due to internal integrations. We hide them from the user so that for him any transition within the portal is seamless. Sitting on Mos.ru, you can easily be in another system, however, if you don’t get into the page code, you won’t notice anything.
The same city “ Goslussugi ” (they can be accessed through our website) is engaged in a separate team. Their services, in turn, are confined to industry-specific IT systems: healthcare, social, and so on.
- How large is the team involved in the maintenance of the portal under your command?
- In the development of twenty people. With a dozen testing, including those involved in automation. Add the operation team and DevOps here. In total, up to fifty, the exact amount and composition depend on the current circumstances and load.
- How do you build a hierarchy of technical leadership? How are areas of responsibility divided?
- We have three main areas: development, testing, operation. Operation, in turn, is divided into clean operation and DevOps. And those who interact with data centers and those who are engaged in automation stand out, but they have a lot of common tasks, so I don’t spread them across different camps.
Testing is implemented under the “testing as a service” scheme. There is a group of testers and her boss. They are nominally tied to teams, but in fact are not their members. If necessary, we transfer testers from task to task: these guys are cross-functional with us. The exception is mobile. For testing mobile applications, we have detached special people and try not to twitch them for nothing: their work has a pronounced specificity.
We also have DevOps as a Service: tasks are set, prioritized, and flowed through devops, which are also not assigned to any teams tightly. Operation works in a similar way.
But the development is divided into teams in functional areas. We have teams of two types. The first - highly specialized. In particular, the one that does the search. It does not touch the front end and the GUI: only the backend. Sawing their algorithms, clinging to machine learning, doing wizard, hints, statistics, analyzers, correcting typos. They are sitting on their technological stack and are joined with Mos.ru through the API. The search service connects to any part of the portal. A separate team planted on the direction of mobile applications. She has her own backend.
Both of these teams interact with the “core development” of the DevOps lines, test and operate.
The second type of commands is those that create and support separate Mos.ru modules, including GUI. Each usually has five, maximum six employees depending on the direction. In such mini-groups, there is a clear separation between the front end and the back end: in our case, it proved to be effective. Most of my back-stackers are full stack developers, but I don’t force them to spin on two dance floors at once. Each such team has a timlid.
- That sounded the word. And what does such a tmlid do?
- First and foremost, he is a strategist in his sector of the front - he is following him to observe the rules of the game that we have established. On it - among other things - decomposition of tasks, code review, organization of retrospectives, education of newcomers.
Translated into military ranks, this is someone like a sergeant — the squad leader. He is empowered and has the right to make decisions within the framework of the technological decisions and standards that we have jointly adopted.
Plus, my teammates are part of an architectural team. This is not a formalized and not permanent structure: it arises when there is a need to invent something new in terms of technology. Then all the team leaders, the heads of the testing and operation departments, and all others who are vitally interested in changes are going to meet me. Experts with different competences, with different views on the technological landscape, with different positions, sit down in a circle. Discuss controversial issues, fix the agreement, come up with an architecture or solution - and disagree.
Until recently, that in Banki.ru, that in Mos.ru, I had only “Beks” in my teammates. As a rule, this role was assumed by the senior back-end developer. But at the moment I have two Timlids from the front end.
Everything is changing. We had to adapt to the current technological realities, and as a result we got what we called guilds.
The thing is: in 2018, the front-end is hard to keep track of what's going on in the backend world, and vice versa. We realized that people need to cooperate on a horizontal level, to stray into informal associations without direct subordination, but with statuses - like titles in secret societies, something like a “master of the order back-end”. The carriers of such “titles” are people who de facto make management decisions of an applied nature: will we move to PHP 7.2, will we develop Angular, or is it better to rely on React.
Guilds are regularly assembled - separate front-tenders, separate back-tenders. They gather and find out who is good for whom, who is bad for them, which is fashionable and cool now. They argue whether a Webpack is a dull hat that collects a lot of unnecessary things, or you just need to learn how to handle it. Just do not pour from empty to empty, and come as a result to a practical solution.
Ultimately, the architectural team replaces my system architect. Yes, I have no system architect.
- What place does team lead in your team? Does he report directly to the CTO or are there intermediate level managers?
- We do not have an intermediate level - it just happened. According to the logic of things between the team leaders and me there should be a development manager. In fact, in the testing and operation departments there are heads, but I personally lead the development. Therefore, the Timlides report directly to me.
Slightly more cunning scheme of submission in devops. Initially, I was also going to isolate them into a separate group with my boss, but the guys and I thought about it and decided that this was a superfluous management link. Brought to DevOps instead of the boss Kanban, and this is highly satisfied.
- When did you first encounter with an entity like a timlid in development? When on personal experience did you find out that this feature is useful?
- In 2008, my colleagues and I wrote cunning software at a defense plant. Once we buried our nose in the fact that it was offensively simple: a team of ten developers was not able to produce anything, but was only able to decorate and swear. Then, for the first time in my life, the phrase “group leader” arose - a kind of prototype team leader.
The group of engineers was divided in two, appointing each of the two groups in charge. I was one of them. We began to build internal development processes with the head of another group and to debug the interaction between the halves of our mini-team. Together we have turned the herd-type collective into two effective combat units. We began to distribute tasks between them and prioritize these very tasks, plan for longer periods, and, finally, synchronize the work of the teams in order to avoid downtime.
In Banki.ru, the structure of the technical department was also “cellular”: the teams in it were controlled by team leaders, and most of the time I was in direct contact with them - five, in the absence of the head of development. Just like now in Mos.ru.
Prior to that, in Kaspersky Lab, where I was responsible for the operation of corporate sites, I had several teams under my control — of different profiles, with different technological stacks. So I would have damaged my mind there without the Timlids - the leaders of the groups that saved me from the torment associated with building a technological panorama in all details. I interacted with them at the level of ideology and overall coordination of processes. And building the rules of the game - how to perform a code review, whether to help the younger ones, to reprove seniors, and so on - remained on their conscience.
And again about the same thing: with whom should the timlids be compared, if not with sergeants? In the States, the whole army rests on them. I can't do it without my “sergeants” either. Rather, I can, but with pain and through the stump-deck. They are my eyes, ears, hands. They are the first to carry my wishes, suggestions and instructions "to the masses" and make sure that all this is implemented.
- In your opinion, is a timblid more likely a profession or a situational role in an organization, by analogy with a scram master?
- I now have both in the team. It’s one thing when a team’s tasks are mostly of the same type, and people move in a single rhythm. Another is when a team performs parallel tasks on n tasks, where n can exceed the number of engineers in a team. In the second case, the team leader has every chance of becoming, albeit temporarily, a natural administrator who will “route” these tasks. As for me, this is both the role and the profession.
In addition, the market is still arguing about who the Timlid bird is in principle and what its basic functions are. Everyone comes up with a configuration, which one he likes. More often, they even proceed from what tasks it is necessary and appropriate to solve in a specific team. For example, in Banki.ru, I delegated staffing to my team-mates: they “enlightened” sufficiently to ask the right questions at the interview, not only to determine the candidate’s qualifications, but also to test his soft skills. Little by little, the guys were pumped and turned from ordinary technical managers of the initial rank into units of the following levels. In Mos.ru, we gradually came to the same system. The guys study resumes themselves, look at candidates, conduct technical interviews. I often attend this stage as a spectator.
Is there a team leader as a profession, a question about backfill. Is the team leader a profession? Absolutely right. Only in rocket production one, and in programming another - from the point of view of the functions performed by its representative and the spectrum of the tasks it performs. In the firm, where five people are sitting in the development, there is one. In the office for 250 employees is another.
The same with the scram master. No one bothers him to be a back-tender, a front-end, a tester, and at least a technical writer. The main thing is the ability to bring people together, adjust them to the desired mode and organize, reduce as much as possible entropy and encourage colleagues to move in a single rhythm and in one direction.
- Let's visit your ideal world. When the team includes a product manager (product owner), and a project manager, and all-all-all, where is the responsibility of the team leader? Timlid is more likely to "design" than "product"?
- He is closer to the "project", yes. But business is business, and internal engineering processes are internal engineering processes. The whole point is that its main area of ​​responsibility is the organization of labor in the “cell of society” that produces the final product.
More precisely, the team leader has two points of focus. The first is the organization of work in the micro-collective, from the collection of input data to the delivery of the result. The second is the provision of social interactions within the team and the establishment of its connection with the top IT management. If there is a clear bias in one direction or another, the matter is rubbish.
- What does a team leader have to control?
- First, he is trying to ensure that the rules of the game adopted at the level of the company, division, group of employees are observed in his clearing. There are rules for making code, maintaining documentation, and holding general events - that means everyone should follow them.
Secondly, he provides technical guidance: he is responsible for decomposing tasks, introducing them into development with the goal of making them as easy and understandable as possible, and monitoring their implementation. Adjacent to this is an underestimated and extremely important task of the team leader - to ensure the completeness of the input data for the team. For me, these guys are at the entrance to their mini-group as a filter: if a team is hit by a frank bullshit instead of TK, its team leader is pressing on a project or product until he formulates the right requirements.
When needed, a team leader extracts resources through exploitation, for example, network accesses. And of course, he understands how that part of the system, which his teammates are engaged in, is arranged, including how it is clear how the integration works. Otherwise, he will not be able to competently formulate tasks for testing and operation departments on behalf of his team.
Thirdly, such a manager, in the event of failures of any kind, with whom he is unable to cope, immediately signals them and brings them to the consideration of people capable of solving the problem. If the team fails to meet something on time, he barely finds it, walks to his boss, and without rassousolivanie admits: “We don’t have time, because we’ve missed,” and offers him solutions.
In Mos.ru of the 2018 sample, the tmlid is responsible for ensuring that incoming tasks to the team are closed on time, within the limits of a given budget, with the current composition of specialists. This is the ideal. Something fails - he immediately pulls into the world a problem with which he is not able to cope with available resources, and “squeezes” it until it is solved within the team or one or two levels higher. At least it does not leave the problematic process to drift.
Thus, the team leader is a full-fledged technical manager, not some sort of appendage from the category of "let it be."
- What other responsibilities can - or should - be given to the care of the team leader?
- Another part of the functions of the team runs very often, just depending on the circumstances, they give the organization more or less attention. For example, the adjustment of the development methodology: you, as a timlid in place, see best of all, whether the methodology chosen for all is appropriate for your particular site. Often it turns out that no. Imagine that everyone is sawing a GUI, and you are a service component. Obviously, your processes are quite different from those of your neighbors.
Moreover, there is a "humanitarian" mission: education, support, early detection of internal problems in the team a la "Something the engineer I have come to work dull." This direction intersects with the field of activity of the HR department. However, not all the companies where I worked, kept Eychara in the state. In some of them I was Haychar myself. In others, the HR department lacked contact with developers.
I still know in general what is happening with almost every one of my engineers. Let's say if one of them is approaching the burnout threshold. Often this information reaches me through the timlids.
The impact of team leads is not unlimited. If some developer constantly mows, then, obviously, it is necessary to expel or try to re-educate. Timlid can try to take action at his own level: gently shame or advise how to correct the situation. And if he does not help, he will come to me and say: “Something does not work, come on.”
By and large, filling the profession of a timlid - or a role, whatever you call it - functionality depends on the views and goals of management. And often it does differ from person to person. I do not insist that the duties of timlidov in Mos.ru were unified. People are different, the teams are different. Someone does not need to develop a stormy upbringing activity in his sector, so he focuses on engineering matters and on the synchronization of processes. At the same time, there is a team where we “subdivide” young guys, and in it the educational work, on the contrary, is very active: we need to embed a person in our paradigm and processes, which requires thoroughness. There, the guys are at the helm a little more experienced, and we will replicate their work in the future within the division: we need the best techniques and techniques,because we are going to work even more with young people, including through advanced training of newcomers.
— «», ?
- Deep, really deep. It is necessary that he distinguishes the husk from the advanced solution. He will have to do this often. After all, do not feed a good engineer with bread - let me try the newest technologies, and on the drum that they just appeared. Timlid, who communicates with the developers in his team and conducts the code review in it, can see some component that he had not previously encountered, which was not in the system. He will have to decide whether it requires the removal of the public (say, my architectural team). Let's say whether we will implement Vue.js, whether we want to switch to PostgreSQL 10 or “nine” is enough for our eyes. Like and not terrible questions, but in projects with a long cycle of support, about five or six years, they are by no means idle, and I begin to influence business.
Naturally, a team leader must understand the subject and be aware of current trends, at least in his professional field. He needs to be aware of how and by what reasons the technological stack in large companies of the industry is changing, as was the case with neighbors: for example, in what direction does the search on the Sphinx of Avito evolve. Otherwise, the authority of the team leader will be blown away in a moment.
On the one hand, the team leader becomes a manager, on the other - in a sense, remains the developer, and most often the senior developer. The position is twofold. But, from my point of view, if you want in your new capacity to communicate with members of your team on an equal footing, technological competence must be maintained at a high level.
You have no need to own product management to perfection to communicate with products. But if you manage developers, you should understand on the fly that you have just been called a new framework, and not sent you far and for a long time.
- What if you are a team leader in a cross-functional team? After all, we casually touched on the fact that the back-end and front-end diverged far from each other and it is very difficult to be megapros in both areas.
- It is desirable to still be savvy on both sides. Or, if you are a real backender and do not rush to dive headlong into the frontend, it would be good if a friendly “front” sat at the next table that will support you in terms of technology expertise. Well, you will continue to improve as a “back” and at the same time unite your colleagues and lead them to victories, motivating them, raising their professional level, and sometimes even entertaining them.
- From which specialists - according to your experience, before your eyes - were Timlides most often grown? Is there an optimal position to go into this state, say a senior developer or system architect? Who is best forged?
- It depends more on the person than on his position or specialization. In addition, depending on what company we are talking about. Somewhere, the most intelligent tmlids grow best of all from senior developers, some of them from architects. Architects, too, are different. Some program, others only draw, and others both program and draw, the fourth build super-heaped models. What is there, IT is often a non-standardized area, even at the protocol level. About people and say nothing. There is no such thing: since you are an architect, you are ordered to lead.
With the career path to the CTO point, everything is the same. Who is becoming the best tech-head - the one who was a team leader or an architect? Do you think that “an architect — a timlid — a technical director” —is a fork in the road to which a person necessarily falls, becoming a senior engineer, and is forced to choose? Solid questions.
- How to understand if a senior developer or systems architect has any potential to become a cool team leader?
- You feel the potential rather subjectively, relying on personal characteristics. When you hire a person or increase it, you still risk to some extent. The interview is a lottery. There are people who are professionally interviewed. They manage to get involved in cool companies without the necessary skills.
I myself focus on human behavior, on how it is treated in the division. Listen to him at general meetings or not. Does he speak at such events, does he take an active position: “I don’t want to code on your crappy PHP, let me write on Go, because here it will be good at this and that.” He sits down on the edge and goes into the tablet or listens vividly, waving his arms, reacting to the cues of others.
If I see that a person is “turned on”, it becomes calmer for me: I understand that he is less likely to give up at the first difficulties, and the others will listen to him in case of anything.
Further I arrange something like a trial period. First, I load a person with new duties for two or three weeks and see how he is doing. Something like learning the "Brazilian system." Of course, I help newly minted timlid, I answer his questions.
Timlid - a complex role. To hire or assign tmlida in principle difficult. So the selection of such a leader in the team - the whole art. He is devoted to a lot of reports on IT and HR conferences. How to hunt and motivate engineers, more or less figured out. And how can you hire someone who can manage a team and who its members will respect for their real technical knowledge and skills? Yes, there is always a bearded engineer in a sweater with deer, who in programming will shut up any timlid for a belt. But if you are in the subject line, if you are able to steer from delicate situations thanks to your diplomatic skills and to achieve results from colleagues without prejudice to your own positions in the team, then you are really valuable to the company.
How to pull out a team leader from the depths of the team is another discussion topic. No wonder many teams prefer to take Timblids from the street, rather than educating them inside. Prefer - or they just can not do otherwise.
And it happens that an excellent engineer with developed soft skills, who, among other things, is respected in a team, flatly refuses to become a team leader. Whether to try to appoint such an employee as a team leader despite his objections and doubts in the hope that during the trial period he will get a taste? Maybe it will. Well, I once, three months after such an appointment, left a great developer: he was not so nice with his new role.
— «» «-». , , . , ? ?
- Roll off, just go. And the task of the senior comrade - technical director or head of development - to pull a beginner team leader out of the swamp of excessive detail and excessive effort. Sometimes the team could not stand it and begged: “Take this leader away from us”. Especially often this happens when the team finds the lead inside. The man sat and programmed himself, and now he has a new front of work - everything is new. Not everyone gets a painless switch. On our September Saint TeamLead Conf , several applications were submitted on these topics: how to catch a person in the micromanagement phase, how to adapt it to “teambuilding”, what to do with its “tags”.
According to my observations, it correctly translates into the status of a timlid - without implanting aortic rupture and depression without failure - about half of the people. The other half, having hit the micromanagement, are confronted with a wild lack of time, and even in their head the usual thought is itching: “Why should I chew them, better I will do everything myself - I'm a senior developer.” We will also discuss this problem at the conference: there are different views on how to solve it.
Often, however, I often fail to solve it: I know a lot of cases of returning from the position of a team leader to the development under the motto: “Well, you have to go to the devil, I’d rather write code and get high, and you’ll manage it somehow without me.”
- What competences are most often lack of timlid in the Russian market? Where do they usually have spaces?
- In my experience, there are several such moments, but mostly there are difficulties with soft skills. In other words, with such non-technical skills as the ability to build communication in a team from top to bottom and from bottom to top, manage expectations both inside and outside the team, regulate internal processes depending on the external conjuncture.
Often, the Timlides stumble on questions of self-development, self-motivation, accumulation and transfer of knowledge, as well as the development of personnel and, in turn, its motivation. The range of problem points is very wide - it is better to look at specific companies, projects, teams.
- What, in your experience, is the maximum size of a team that a team leader can lead? What level leader does he actually become?
- Purely empirically, four or five people in a team are enough for comfortable work of a team leader. With this configuration, he has time for himself, for programming and self-development. In the literature, they write about 7 ± 2, the same numbers are called at conferences, but, in my experience, this is overkill if you want to be a senior engineer too (and cool developers love their job). In different companies in different ways, but on average in the industry a team leader is the level of operational management in terms of technical tasks and simple business tasks.
- How to understand if a team leads its tasks? What are the criteria for the quality of his work?
- In short: if everyone is happy, then everything is fine.
In other words:
• Team is vigorous. In it everyone understands who does what and why, what is it all for, where the team is going, what plans have been made within the division and the company.
• Management sees everything that happens in a team, understands the status of key operations and processes, sees prospects and problems, and most importantly, sees the manageability of the team and its ability to respond to external influences, no matter where they come from.
• Customers do not run in circles, do not complain to management, receive a product of good quality within a manageable time frame.
- Judging by the results of the previous conference, did Russian IT have a common understanding of who this team leader is in principle?
- Not!The question remained hanging in the air. It turned out that the breadth and variability of the notion of “tmlid” is commensurate with the size of the IT industry. Maybe it is right that there is no single standard definition: it means that this “teamwork” allows for a flexible approach.
Last but not least, we conceived TeamLead Conf, so that those who entered this “state” met with those who are only going to, and so that the latter could see that this is a wide world and that this activity is striking - and not for the worse side, contrary to common fears - different from the pure development.
Schemes of work in which the timlid may be involved are numerous. In the one that I have built in Mos.ru today, the product actively communicates with the team leader. Even so: the product carries its food thought timlidu. And in Banki.ru, on the contrary, the product took on itself the tasks of an analyst, and most often something that did not require detailed explanations was downloaded to the development; except on procedures like grooming backlog, sometimes it was necessary to shake the product and find out some details from it.
In some organizations, a team leader is a pure manager with a technical bias. He accepts a bunch of tasks at the entrance, distributes them among engineers, then controls their execution, accepts work, reviews them. And heychary and the head of development are engaged in educational activities.
One of the goals that we pursue in preparing Saint TeamLead Conf is to demonstrate to our colleagues this infinite possibilities. And clearly show that if you are a team leader in company A, this does not mean that by going to company B, you will receive exactly the same set of tasks with the same set of requirements for you.
- Were there any topics in the previous, first TeamLead Conf program that the organizing committee wanted, but could not dig deeply? How will audience requests be reflected in the next conference program?
- First of all, communication, the accumulation of knowledge and their management, work with the team, the adaptation of the team and yourself personally for the company's business processes. These topics were somehow affected in the winter, but this time we will give them more attention.
Also, we will not leave aside the toolkit of the timlid - what and how to use it in order to effectively manage the team.
- Do foreign IT companies have cool practices that it would be reasonable to “peep” at Russian team leaders? Will they be on the agenda?
- Exactly. We look at them and agitate foreign colleagues to share their experience. I think that by winter we will invite someone interesting with something interesting. In the meantime, we carefully refer to the experience of one, but very well-known foreign company. Wait a little before the publication of the program.
- What are the long-term goals of the conference? Create an “industry hub”, set professional standards, something else?
- Do not say that they are original. Moreover, it sounds pathetic to the utmost: to organize, support and develop a platform so that representatives of the Timid caste from both the IT industry and about the near markets communicate and exchange experience. As the practice of our other events shows, over time there will be an “industry hub” and everything else.
We learned to move the industry “from below” - through HighLoad ++ , through a series of RIT ++ application conferences, we adapted ourselves to invigorate the industry “from above” - through Whale Rider and Aletheia Business. The “middle time” has come: we gave a start to communication, showed that everyone has problems and that these problems have solutions, offered solutions to share and together move the industry forward.
The reports that Roman and colleagues selected for presentation at Saint TeamLead Conf are already noted in the Conference Program . Guess which foreign company was discussed?
The materials of the spring TeamLead Conf are fully posted on our YouTube channel . There will also be a video of the new conference, but in a few months. Subscribe if you don't want to miss.
All our news around management and entrepreneurship, we collect in thematic newsletter. It includes: the publication of articles and transcripts, open video, cool speakers and other usefulness. If interested - subscribe .
Source: https://habr.com/ru/post/421729/
All Articles