Work as a team leader in the 2018th year

In the article I will talk about my experience working as a team leader in a website development company. To make it more useful and easier for everyone to read, the article is divided into chapters, each of which talks about one particular problem and its solution. Although, if possible, the chronology of events will be preserved.

I hope that the experience described below will become someone else's rake, and in the comments I myself will get something from more experienced colleagues.

But no names, companies, customers, names of colleagues. Non-disclosure agreement, all affairs.

Prehistory How and where have I become team leader

This is the first company where I went immediately to the team leader. For me it was a qualitative leap in terms of career growth. At the last job (1.5 years), I came in the middle and grew up there before the senor. But the gradations of developers are too subjective and often depend only on the company where they work. For a while I studied a lot the issue of evaluating programmers and in fact it all boiled down to the fact that if you “took middl / seigneur / elder, you became middl / seigneur / elder”. When I began to look for a job, the position of the lord (and I was looking for it) would have been enough for me, but the offer of leadership has outbid me and was a bit flattering.

Actually, on the very search for vacancies, on the second day I was lured to a capital firm that develops sites on Bitrix (so that further everything happens against the background of developing sites on Bitrix). I, on the contrary, have long dreamed of leaving Beatrix, but the opportunity to realize myself in a new capacity and a good salary left me no chance to refuse.

A funny fact: the only condition for accepting me at work was that I could choose the technological stack myself, but I could not in any case refuse Bitrix if the client insists on it.

In a new place

At the new site, there was a very good technical manager, a bad manager, June, Middle, and several really big projects on Bitrix. A rather strange situation and I still do not understand how it was formed and did not collapse immediately. But maybe they invited me just to fix everything.

In the very first days, many “childish” problems caught my eye:

• information on projects was stored in the heads of one or two people and nowhere else. There were no instructions and documentation either, and in order to find out how this or that functionality worked, it was necessary to torture the person who did it, if at all we created it.
• There were no established systems and processes, everything was done “somehow”, “according to habit”. Hence, respectively, vanity, confusion, disruption of terms, tension
• Tasks were counted in words. There were only task names in the trackers, just to be able to log in time somewhere (you had to dial 40 hours a week)
• development itself was also not so hot:
  
  • somewhere, something was developed even outside the gita
  • somewhere programmers took turns ruled files on one server
  • somewhere there were test sites, but somewhere they were not (but in any case, they did not help much)
  • In addition, everywhere there was a very, very much govnokod. Anticipating comments, Bitrix himself, unfortunately, has nothing to do with
  
  
• All communication took place in Skype. But to him, I just have a personal dislike

In general, everything is obviously bad, improvements can be started immediately, without conducting preliminary research. This even pleased me to some extent, since it is possible to influence the indicators from the very first months. They really have not been considered, but because of Pareto, it is not important yet.

To my dismay, the processes of the first months were moving rather slowly. First, I myself had to work on client tasks for 8 hours a day, as a programmer, because I simply didn’t have enough hands. Secondly, in conditions of such time pressure, it was quite dangerous to make big changes that could lead to confusion and loss of code or time.

Now we come directly to the article and problem solving. First of all, the new company had to somehow navigate.

Retrieving information from employee heads

When I arrived, I knew absolutely nothing about the projects, or about the clients, and this information was not stored
anywhere in text form. Therefore, first of all, I began to pull information from the heads of colleagues in the texts.

In fact, a development company has 2 large subsets of important and / or useful texts:

1. instructions, regulations, articles, functional descriptions, user stories, ...
2. Tasks with their name, description, comments, time logs, captions for commits, comments in the code, autotests, ...

At first, I simply asked new colleagues to paint for me some specific things from the first paragraph, but of course they were too lazy, especially since the instruction to write it was not features to cut. But since at first I still had a completely unfazed look and I had to study the projects, seeing them for the first time, I just started translating my research into text, thus creating instructions and descriptions of the functional.

It was also fortunate that at the same time the company began to actively move to scrum (just a coincidence), the working software changed (also a coincidence), and business processes were created from scratch. And for some reason, I initially had great authority in the eyes of my colleagues. Therefore, I simply began to write the regulations independently (within the framework of my competence) and rebuild children to them, that is, in essence, simply dictate the rules and be an example of their execution.

The solution of the problem with the formulation and management of tasks was delayed for more than one month. This turned out to be a bottleneck, and in subsequent chapters I will raise this topic more than once.

At the time of the beginning of my work, the manager set the tasks terribly. Example: the name of the task is “Fix a bug on the site” and that’s all: no description, no screenshots, just the name and reference to the project. There were of course attempts to convey the principles of SMART and the importance of describing the tasks to the manager, but all the undertakings were divided into “I don’t have time to paint the tasks”.

At one time I tried to take over some of the responsibility for setting the tasks, but it was ironic that I didn’t have enough time for this either, since I wrote code almost all the time.

But the adjacent problem of obtaining the actual status of tasks at an arbitrary point in time, we decided to bypass, through coordination calls and plans for the day.

Recruiting staff, team integration

Almost from the very beginning it was clear that there was a catastrophic shortage of people (I myself wrote the code full-time, but we still did not have time).

We decided to take the front first, since both the progers in the company were Beks (and I also identified myself more with the backend), and there were enough tasks, especially in layout, and on the horizon, the tasks on the reactor and vue began to loom.

It was very fortunate that I had (and have) a friend front, who at the same time began to think about leaving freelancing, so we were able to quickly plug the vacancy, and I won an award for bringing an employee (one more plus to the bosses, saw hr-awards).

Almost immediately after the front, there were 2 Beks. And somewhere at the same time, June was gone (whose code left me several months after he left).

Total in the development of the following situation:

• one "old man"
• I
• three absolute beginners
• work not yet established
• some knowledge already lost

It is natural that dozens of questions from newcomers immediately fell down on me as on the Tam-Leopard. These were mainly questions about the life cycle of the code (where to write code, how to show where to send it later, how to collect the release), how to manage tasks (how to get tasks into work, how to show status, how to determine priorities) and how to work with git . Plus, the guys were still trying to ask questions “How does A work?”, “Do we have B on our site?”, But at that moment almost everything was reduced to the need to study the code.

First of all, it was important to give the programmers the opportunity in principle to work and write code on their own. I conducted introductory conversations with them, answering their questions, and then of course I decided to put all the questions and schemes into an article, which then turned into a lecture, and then generally into a completely new scheme of work in the company, which I will discuss in the next chapter.

Here it is worth saying a few words about the hiring process in our company, which is still working.

Recruitment process

First, we have a bonus for hiring an employee, which is pretty good practice.

Secondly, we decided not to arrange an examination at the interview, but to give a very voluminous task, close to our everyday ones. This is convenient in that the time spent on hiring is reduced only before searching for suitable resumes and easy interviews with applicants to check for adequacy and talk about the test task, and, of course, directly check the task.

The problem can actually be solved by June in a couple of evenings, while its volume is made greater by the freedom to implement, improve, and ask for chips. It is this flexibility of implementation that helps us assess the level of the applicant. We immediately say that the most important thing for us is only to meet the deadlines for solving the problem (he calls the singer) and at the end show the working code in the repository. We do not stipulate the use of any approaches and technologies, the performer chooses them, but to go to the meeting and give hints, we listed possible improvements in the list, such as tasks with an asterisk, for example, working through Ajax, ext. validation on the back, spam protection, design in the form of a module, the use of D7, ...

Total:

• on resumes and interviews we can judge the character of a person
• according to the deadline for the execution of the task, the fact that the code is working and the use of the gita, we make our own decision about hiring
• the quality of performance, we determine the level and, accordingly, the salary that we can offer
• plus already on the test task we show what tasks will have to be solved in a new place

Establishing a code development and delivery system

At that time we had several projects that were developed rather chaotically:

• somewhere in the battle was a master, somewhere in another branch
• somewhere there were test sites, somewhere not
• and if there were any, then the addresses are different
• git was in principle used poorly and with difficulty
• database changes were made manually
• ...

At first, I tried to correct the situation in small portions, so that programmers had to retrain less and get confused accordingly. For example, I took out the bitrix folder from under the git, renamed the main branch back to master.

But when a large replenishment came to us, the situation became critical. We had to explain a lot, remind and write illogical instructions, since the current structure of the development was not at all intuitive.

I am not a fan of instructions as such; I believe that their presence is in itself an indicator of a problem, so it was decided to create a common system for all projects that needs to be understood once and which by its structure removes many problems and questions.

The system is as follows:

• each developer has a remote personal work platform where he works
• There is a platform where the functionality is accumulated for the next release.
• if necessary, there is a demonstration platform for the demonstration of all the rudiments of the functional
• all code for one task is kept in one separate branch, where the name of the branch is equal to the name of the task in the tracker
• To upload the code to the common site, you just need to branch the branch somewhere and start
• Changes in databases are stored as migration files in the task branch.

I gave a big lecture on this system, and we started a pilot transition to it on one project, where the newly acquired senor had just been thrown.

The process of transferring all projects to this system, of course, was delayed (for example, on one project we mysteriously could not move to the master the first time), and it still continues, but at the end we got at least:

• the ability to release only the necessary tasks, and not to release with the useful code the unfinished functionality
• release the task without the author of the code
• parallel the work on the project between the performers
• do not lose code
• test the functionality isolated from the other and do not stop while the prog

All this before just was not. Plus, it is not necessary now to explain the extra subtleties of working with git or test pads to new progers, since everything is universal and intuitive.

Scrum, communications, regulations

Of course, in the article I intended to talk about how I helped in the development of the company, being a team leader, but we cannot talk about the development of our company without mentioning our boss and his initiative, otherwise it will not be entirely fair.

Firstly, he implemented scrum and at the time of my arrival the processes in the company began to be very actively redone. It was also at that moment that she transferred her from Bitrix24 to Djira.

Scrum, of course, brought more rhythm to the company and reduced chaos. During the retraining of managers, their execution of coordination calls, the opening / closing / planning of sprints, the head himself watched as the senior in this link.

He also worked a lot on the managers themselves, in particular on how they communicate with clients and programmers, since a large part of their work (but, of course, not limited to) is to communicate: to isolate programmers from clients, broadcast the wishes of clients in tasks in backlog and sprints, find and retell user stories. All this resulted in many regulations: on communication with customers, on setting goals, on working with backlog, on accepting bugs. Strong emphasis was placed on communication, and the governing body really showed progress.

The transition to scrum itself, of course, is very difficult and at the time of writing this article, we have not yet become its professionals, although this is all about. And I am very glad that I have received a lot of new knowledge on flexible methodologies and products of the Atlassian.

New manager. Texts, setting tasks, backlog

At some point, another person came who was supposed to help us make a qualitative leap - a new manager (before that, we had one).

I didn’t expect this moment, as there were not so many projects and programmers, and in theory there should have been only one manager. This link was a weak point in the company, but we tried to solve this problem by developing existing personnel. It just so coincided that one excellent manager, whom I know well, decided to change jobs, my boss found out about this, as she suddenly spoke to our contractors and I spoke about this funny incident, and we called her to us. Another bonus)

At the beginning, the new manager repeated part of my path, as she faced the same problems (she knows nothing and has no place to read) and started everything in a new way, but with the difference that she did not touch the code, the development infrastructure and the skills of the progers, but worked with setting tasks, communicating with clients, cleaning backlog, and also diligently pulled information from the head of the old manager. In particular, the first thing pulled out a list of contacts of customers and contractors.

The team was already familiar with it, since we once invited her as a lecturer to tell us about the time control. Plus, the tasks of steel are put in more detail, it did not add negative and did not transfer it from the client, the status of the tasks became more relevant at any given time. Therefore, we immediately placed great hopes on it.

For the first weeks, he and his boss put things in order in backlog on one project, in particular, they found an epic that was overdue by 2 months and not yet started. In addition, in principle, many tasks emerged that needed to be done a month ago. Well of course, the backlog was cleaned, but it was done too late.

She herself really "hung up" from the mess and not just rushed to leave, but the managerial link, we somehow greatly improved. Tasks are less likely to get lost in backlog, programmers are less likely to ask again.

The moral of the story will be at the end.

A crisis

Almost six months after starting work, I had to go on vacation. By the way, I agreed about the holidays even when I came to work, as it was planned as a honeymoon trip, so the period of my absence was known much in advance. But I still, of course, was nervous to the last, because we only recently stopped working “for wear”.

A week before the holidays, I completed the delegation of duties, taught selected people to perform specific tasks outside the code, assigned responsibility for a specific project to each programmer, finished or transferred all my current tasks (I was still programming most of the day). Nothing foreshadowed trouble in the middle of July.

And in the first days of vacation, too, nothing foreshadowed trouble.

And then there was a crisis.

On one project, the client was out of patience due to the fact that his expectations of completing tasks (deadlines, list, priorities) did not fit the cause. We ourselves noticed this not so long ago with the complete processing of the backlog and active communication with the client (the chapter about the new manager), but it was too late.

And on the second project, we finally accepted a very big and long-awaited task, finished testing and released it. But the new functionality suddenly brought down the combat site under heavy load, and the middle front with the week could not do anything about it. Naturally, this client also began to use foul language and think about abandoning our services.

The first problem was not directly related to the development, so I actively participated in correcting the situation on the second project. Although I could not significantly help, as I was in another country without the Internet and a laptop. The maximum of my help was in consulting progers, especially when I already bought the Internet.

The back-up responsible for the project reworked for a whole week every day trying to create a new functionality in the combat environment and, together with the front, dealt with the code base vue, where most of them were not written by two of them (by the way, by the way).

The colleague got into a terrible situation - he worked until one o'clock the whole week, he was very stressed, but all the bumps hung on him as a result, especially due to the fact that he kept saying “I'll fix it for dinner” by the end of the day / Nights / morning. ”
The situation could be rectified, but all this resulted in the fact that while we were deciding his fate, he himself wrote a letter of resignation, as he was tired of such stress.

The strangest thing was that judging by the communication with the guys, all this time, they really worked, and even quickly found a problem place, but the solution took dozens of hours and as much later to fix the breakdowns of the secondary functionality.

We thought a lot about why this situation developed and how to prevent them in the future. Obviously, the lack of professional skills and skill in assessing tasks was revealed, therefore, for prevention, we decided to introduce voluntary-compulsory pull-up of programmers inside the company. The need for this was also hinted at by the observation that progers with side projects did not have similar problems.

Programmers development

Critically important was to improve the skills of programmers. Stagnation is basically a small death (and already one real precedent for dismissal), moreover, problems have already begun to manifest themselves due to the lack of knowledge or skills:

• technical debt accumulated
• guys often complained about git problems
• fixing unforeseen bugs took a lot of time
• new technologies were introduced very hard
• meeting with someone else's code was a real obstacle

Someone developed independently, someone did not, and someone even went wrong into those wilds, although this may be useful. Therefore, it was necessary to develop programmers centrally by the company.

Codream

I tried to revise the code more often, but the exhaust from this was not enough. The guys, of course, read my comments, but the comments were repeated time after time.

Lectures

Another idea was to conduct lectures. For example, once I collected all the examples of govnokod that I found during a coding test into one large file with explanations of each case and told about them in a row. Such direct training, of course, was more useful.

By the way, it was in the format of the lecture that I taught the guys how to work with vue, which we later used a lot.

In total, we didn’t have many lectures, somewhere around 5. First of all, none of the other programmers have prepared their lecture. And it didn’t solve the problems with govnokod and exceeding the ratings, but they were the most important.

Joint sessions

I was especially upset with the problem with git, I had never seen such a number of them before: merdzhe led to the loss of code, sometimes resolving conflicts put the site, files in commits sometimes came marked as completely rewritten, and in principle commits and messages were completely uninformative .

I thought it was because the guys were working with git through the console or something else in their own way. This led to the idea not just to call up and give lectures, but to call up and write together code, show how to work in Storm, how to make commits, how to resolve conflicts through a convenient interface, how to refactor code between tasks and just discuss every programmer.

And this format is shot.

We try to get together every Friday. We show each other all sorts of chips in Storm, where the whole team, thanks to the phoning, has finally moved, we get rid of the questions on the gita, we improve the very quality of the development.

Plus, I believe that such weekly programmers call up the spirit of programmers, since we do not just understand why the wrong price came from 1c or add another section with shares to the site, but somehow we develop, closely communicate without managers and clients nearby. He shares a little bit of experience and that he is interested in, we analyze the technical problems that have arisen, we pull up the laggards. And not only am I leading them, on the contrary, quite often I give the initiative and the guys themselves start broadcasting useful things.

Team effectiveness, task evaluation

One of the biggest problems in the company was the constant timeliness of the tasks. Sometimes the average excess by hours per month reached two times.

The problem arose particularly acute during my vacation, when for a whole week the task was postponed for another several hours ahead from the very beginning, that is, every 3-4 hours it was said “you need another 3 hours”, and as a result it took almost 40.

Again, thanks to the leadership, we were not in the red and did not dismiss anyone, but stretching the tasks took away at least the bonuses from us, and at the maximum could lead to losses.

We called the fact / assessment of the performance of work in hours - the efficiency (well, as they called it). The efficiency of the whole team became my KPI, as the main task of the team leader. I was glad that I had a numerical KPI. And my joy was intensified by the fact that at the same time I finally stopped programming for 8 hours every day and now I could fully engage in Timlide affairs.

We soooo much thought about the problem of efficiency. There were no obvious leaks:

• programmers rated the tasks fairly healthily
• really worked on them, and not just set the timer
• there were no problems with communications

But then something always went wrong and each time was different:

• there was a pitfall
• the final decision did not suit the client
• some related functionality fell off
• when testing something missed and then reworked
• lost time searching for some access
• ...

I decided (not without an interview with each programmer separately) that the problems are rooted in:

• quality assessment tasks that guys still often miscalculated
• in the very level of programmers, because of what problems are formed- “black holes” and fixing bugs is delayed for hours. It could also cause stupor when meeting with unknown technologies.
• govnokode, code connectivity. Although this problem indirectly overlaps with the previous
• in the formulation of tasks, as I often heard complaints about the incompleteness of the information in the description, plus this very moment could lead to unnecessary alterations

Then I decided to conduct a study - I checked all the time logs in all tasks with an excess of the recent rating. And it brought several new discoveries:

• tasks initially estimated at exactly 1 o'clock were almost always exceeded
• Testing the task was almost never included in the assessment, and often it was it that exceeded
• unexpectedly and unpleasantly, but problems with git were often mentioned in the logs of time. And big logs, sometimes for an hour and a half

Based on all this knowledge, we have come up with countermeasures:

• , , , .
• ,
• ,
• , , , ,

, . , .
, . .

—

, , , , , “ ” , .

, , “” - .

, , , , , 2 . , , .

, , / , . , , .

, . , , / - , , - .

(, )

- . , , , , , , , .

, , . , , .

: , , , , . , .

, - , . , .

:

• ,
• -
• 1

, , , .

Plans

, , , ( ), , , .

, ( , 2 , ).

, , . “ ”, :

• , , -
• - .

, .

Part 2

. , :

• , . , -
• ( )

. , , , .

!