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 exists for sure, 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 spoke to Roman Mos Ivliev, technical director of the Mos.ru project, without unnecessary formalities .which is headed by the Saint Petersburg CommitteeLead Conf Program Committee 2018. In the conversation: who are the Timlides, how to prepare them correctly, who and what should they prepare for, what should be their responsibilities 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 at 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 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, consider that there is no significant difference. The system of problem statement 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 along the lines of integrating services, we are on a short foot: we 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 rules of the game and our 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 if there is an appropriate regulatory framework. Assume to equate 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 news editorial, 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 fresh - they made this for the Zaryadye Park.
We, relatively speaking, have a full-cycle team. Something we take from the side, although rarely. Other services that live in the domain www.mos.ru, but developed not 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 “ Gosuslug ” (they can be accessed through our website) is a separate team. Their services, in turn, are confined to industry-specific IT systems: healthcare, social, and so on.
- How large is the team engaged in the technical support 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 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 we have implemented the scheme "testing as a service." 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. We have dedicated special people to test mobile applications 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 the flow of 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 are 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 frontend and backend: 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 team lead?
- First of all, he is a strategist in his sector of the front - he is monitoring it for the observance of the rules of the game that we have established. On it - among other things - the decomposition of tasks, code review, the organization of retrospectives, the 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 those 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 with me. Experts with different competences, with different views on the technological landscape, with different positions, sit down in a circle. Discuss controversial issues, fix agreements, come up with an architecture or solution - and disagree.
Until recently, that in Banki.ru, that in Mos.ru, I was beaten out in the Timlids only "backs". As a rule, this role took on the senior back-end developer. But at the moment I already have two Timlids from the frontend.
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 someone, who is bad for someone, 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, and 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 the other group and to debug the interaction between the halves of our mini-team. Together we turned the herd-type collective into two effective combat units. They 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, at 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, who saved me from the torment associated with building a technological panorama in every detail. I interacted with them at the level of ideology and the overall coordination of processes. And building up the rules of the game - how to perform code review, whether to help the younger ones, to reprove the older ones, and so on - remained on their conscience.
And again about the same: with whom else timlidov compare, if not with sergeants? In the United 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 bear 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 bird leader is in principle and what its basic functions are. Everyone comes up with a configuration that he likes more. 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 were sufficiently “enlightened” to ask the right questions at the interview, not only to determine the qualifications of the candidate, but also to test his soft skills. Little by little the guys were pumping and turning 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 backfilling. 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. An office with 250 employees is different.
The same with the scrum master. No one bothers him to be a backender, 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 entropy as much as possible 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 focus points. The first is the very 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 seeks to ensure that in his clearing the rules of the game, adopted at the level of the company, division, group of employees, are observed. There are rules for making code, maintaining documentation, and holding general events - that means everyone should follow them.
Secondly, he exercises technical guidance: he is responsible for decomposing tasks, introducing them into development in order to make their implementation 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 has formulated 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 who are able to solve the problem. If the team fails to do 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 take its course.
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 if 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 not at all like 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, 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 the team leader 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 doesn’t help, he will come to me and say: “Something doesn’t 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 further developments within the division: we need the best techniques and techniques,
- How deep should a tmlid need to be immersed in the current technological stack in comparison with its “sponsored” ones, who work with their hands more than him?
- 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 have just appeared. Timlid, who communicates with the developers in his team and conducts 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. It seems to be not terrible questions, but in projects with a long support cycle, about five or six years, they are by no means idle and I begin to influence business as well.
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 to communicate with your team members on an equal footing in your new capacity, technological competence must be maintained at a high level.
You need no 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 advisable 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 nice 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 colleagues and lead them to victories, motivating them, raising their professional level, sometimes even entertaining.
- From which specialists - according to your experience, before your eyes - were the Tmlids 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 a person than on his position or specialization. In addition, depending on what company we are talking about. Somewhere, the most intelligent timlids best of all grow out of senior developers, in some - from architects. Architects, too, are different. Some program, others only draw, and others both program and draw, the fourth build super-fueled 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 have been 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 whether a senior developer or a system architect, but anyone has the potential to become a cool team leader?
- Potential feel rather subjective, based on personal characteristics. When you hire a person or increase it, you still risk to some extent. Interview is a lottery. There are people who are professionally interviewed. They manage to get into cool companies without the necessary skills.
I myself focus on human behavior, on how it is treated in the unit. Listen to it 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 tupit 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 things are going with him. 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 at 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 team lead 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 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 simply can not do otherwise.
And it happens that an excellent engineer with developed soft skills, who, among other things, is respected in the 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.
- “Timlidism” on the career path resembles a step before entering the category of “managers-managers”. If you develop your analogy, a person puts on sergeant's gables, but did not finish officer schools. What are the risks of timblid, which begins its journey in the new incarnation? Does he have any danger of slipping into micromanagement and hypercontrol?
- 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 made 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, it’s not possible to solve it either: I know a lot of cases of returning from the position of 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, such 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 external conjuncture.
Often, the Timlides stumble over 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 a bust if you want to be a senior engineer too (and the 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 the management, receive a product of good quality in a manageable time.
- Judging by the results of the previous conference, did Russian IT have a common understanding of who the 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 correct that there is no single standard definition: it means that this “teamwork” allows for a flexible approach.
We are not the least of all in order to conceive TeamLead Conf, so that those who enter this “state” meet with those who are just going to, and so that the latter see that this is a vast world and that this activity is striking - and not for the worse side, contrary to common fears - different from the net design.
Schemes of work in which the timlid may be involved are numerous. In the one that I built in Mos.ru today, the product actively communicates with the team leader. Even so: the product carries its grocery thought timlid. 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 infinity of 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 team leader - what and how to use it in order to effectively manage the team.
- Do foreign IT companies have cool practices that it would be wise to “peep” at Russian team leaders? Will they be on the agenda?
- Similarly, there is. 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 the 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 spoke to Roman Mos Ivliev, technical director of the Mos.ru project, without unnecessary formalities .which is headed by the Saint Petersburg CommitteeLead Conf Program Committee 2018. In the conversation: who are the Timlides, how to prepare them correctly, who and what should they prepare for, what should be their responsibilities 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 at 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 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, consider that there is no significant difference. The system of problem statement 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 along the lines of integrating services, we are on a short foot: we 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 rules of the game and our 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 if there is an appropriate regulatory framework. Assume to equate 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 news editorial, 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 fresh - they made this for the Zaryadye Park.
We, relatively speaking, have a full-cycle team. Something we take from the side, although rarely. Other services that live in the domain www.mos.ru, but developed not 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 “ Gosuslug ” (they can be accessed through our website) is a separate team. Their services, in turn, are confined to industry-specific IT systems: healthcare, social, and so on.
- How large is the team engaged in the technical support 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 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 we have implemented the scheme "testing as a service." 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. We have dedicated special people to test mobile applications 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 the flow of 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 are 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 frontend and backend: 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 team lead?
- First of all, he is a strategist in his sector of the front - he is monitoring it for the observance of the rules of the game that we have established. On it - among other things - the decomposition of tasks, code review, the organization of retrospectives, the 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 those 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 with me. Experts with different competences, with different views on the technological landscape, with different positions, sit down in a circle. Discuss controversial issues, fix agreements, come up with an architecture or solution - and disagree.
Until recently, that in Banki.ru, that in Mos.ru, I was beaten out in the Timlids only "backs". As a rule, this role took on the senior back-end developer. But at the moment I already have two Timlids from the frontend.
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 someone, who is bad for someone, 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, and 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 the other group and to debug the interaction between the halves of our mini-team. Together we turned the herd-type collective into two effective combat units. They 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, at 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, who saved me from the torment associated with building a technological panorama in every detail. I interacted with them at the level of ideology and the overall coordination of processes. And building up the rules of the game - how to perform code review, whether to help the younger ones, to reprove the older ones, and so on - remained on their conscience.
And again about the same: with whom else timlidov compare, if not with sergeants? In the United 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 bear 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 bird leader is in principle and what its basic functions are. Everyone comes up with a configuration that he likes more. 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 were sufficiently “enlightened” to ask the right questions at the interview, not only to determine the qualifications of the candidate, but also to test his soft skills. Little by little the guys were pumping and turning 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 backfilling. 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. An office with 250 employees is different.
The same with the scrum master. No one bothers him to be a backender, 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 entropy as much as possible 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 focus points. The first is the very 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 seeks to ensure that in his clearing the rules of the game, adopted at the level of the company, division, group of employees, are observed. There are rules for making code, maintaining documentation, and holding general events - that means everyone should follow them.
Secondly, he exercises technical guidance: he is responsible for decomposing tasks, introducing them into development in order to make their implementation 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 has formulated 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 who are able to solve the problem. If the team fails to do 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 take its course.
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 if 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 not at all like 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, 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 the team leader 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 doesn’t help, he will come to me and say: “Something doesn’t 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 further developments within the division: we need the best techniques and techniques,
- How deep should a tmlid need to be immersed in the current technological stack in comparison with its “sponsored” ones, who work with their hands more than him?
- 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 have just appeared. Timlid, who communicates with the developers in his team and conducts 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. It seems to be not terrible questions, but in projects with a long support cycle, about five or six years, they are by no means idle and I begin to influence business as well.
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 to communicate with your team members on an equal footing in your new capacity, technological competence must be maintained at a high level.
You need no 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 advisable 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 nice 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 colleagues and lead them to victories, motivating them, raising their professional level, sometimes even entertaining.
- From which specialists - according to your experience, before your eyes - were the Tmlids 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 a person than on his position or specialization. In addition, depending on what company we are talking about. Somewhere, the most intelligent timlids best of all grow out of senior developers, in some - from architects. Architects, too, are different. Some program, others only draw, and others both program and draw, the fourth build super-fueled 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 have been 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 whether a senior developer or a system architect, but anyone has the potential to become a cool team leader?
- Potential feel rather subjective, based on personal characteristics. When you hire a person or increase it, you still risk to some extent. Interview is a lottery. There are people who are professionally interviewed. They manage to get into cool companies without the necessary skills.
I myself focus on human behavior, on how it is treated in the unit. Listen to it 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 tupit 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 things are going with him. 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 at 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 team lead 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 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 simply can not do otherwise.
And it happens that an excellent engineer with developed soft skills, who, among other things, is respected in the 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.
- “Timlidism” on the career path resembles a step before entering the category of “managers-managers”. If you develop your analogy, a person puts on sergeant's gables, but did not finish officer schools. What are the risks of timblid, which begins its journey in the new incarnation? Does he have any danger of slipping into micromanagement and hypercontrol?
- 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 made 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, it’s not possible to solve it either: I know a lot of cases of returning from the position of 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, such 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 external conjuncture.
Often, the Timlides stumble over 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 a bust if you want to be a senior engineer too (and the 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 the management, receive a product of good quality in a manageable time.
- Judging by the results of the previous conference, did Russian IT have a common understanding of who the 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 correct that there is no single standard definition: it means that this “teamwork” allows for a flexible approach.
We are not the least of all in order to conceive TeamLead Conf, so that those who enter this “state” meet with those who are just going to, and so that the latter see that this is a vast world and that this activity is striking - and not for the worse side, contrary to common fears - different from the net design.
Schemes of work in which the timlid may be involved are numerous. In the one that I built in Mos.ru today, the product actively communicates with the team leader. Even so: the product carries its grocery thought timlid. 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 infinity of 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 team leader - what and how to use it in order to effectively manage the team.
- Do foreign IT companies have cool practices that it would be wise to “peep” at Russian team leaders? Will they be on the agenda?
- Similarly, there is. 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 the 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 .