Work as teamlide in 2018

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 to the lord. 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 “they took middl / senor / elder, they became middl / senor / elder”. When I began to look for a job, the position of the lord (and I was looking for it) would be enough for me, but the offer of the lead bought me out and was a bit flattering.

Actually, on the very search for vacancies, on the second day I was lured to a capital company that develops websites on Bitrix (so that further everything happens against the background of developing websites 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 did not leave me a 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 couldn’t in any case refuse Beatrix if the client insists on it.

In a new place

At the new place there was a very good technical manager, a bad manager, June, Middle, and several really big projects on Bitrix. Quite a 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 works, 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, there was a lot of govnokod everywhere. 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 to some extent pleased me, 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 moved 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 didn’t know anything about projects or clients, and this information was not stored
~~anywhere~~ in text form. Therefore, the first thing I began to pull information from the heads of colleagues in the texts.

In fact, the company engaged in the development, there are 2 large subsets of important and / or useful texts:

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

At first, I just 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 is not to cut features. 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, thereby 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, only 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 here 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 current status of tasks at an arbitrary point in time, we decided to bypass, through coordination calls and plans for the day.

Recharge 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 of vue and reactor also 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 authorities, saw hr-awards).

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

Total in the development of the following situation:

one “old man”
I
three absolute beginners
work is not yet established
some knowledge already lost

It is natural that dozens of questions from newcomers immediately fell on me as a 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 take 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 independently. 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 (calls the singer himself) 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, then the addresses of all 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 system common to 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
in order to upload the code to the common area, 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 began a pilot transition to it on one project, where the newly acquired seigneur was just 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 sites 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 a 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, to 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 clients, 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 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 interviewed 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 to 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 well 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 responsibilities, 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 mid-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 a whole week every day in an attempt to create a new functional 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 (I, 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 repeating “I will 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 rather quickly found a problematic 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 necessity of 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 it 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 them about it in a row. Such direct training, of course, was more useful.

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

In total, we didn’t spend a lot of lectures, somewhere around 5. First of all, none of the other programmers 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: merdzs led to code loss, conflict resolution sometimes 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 in between cases, 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, finally moved, getting rid of questions on the gita, improving 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 I am 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 negative 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, how 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 passed and then reworked
lost time searching for some accesses
...

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 programmers level itself, because of which “black holes” tasks are formed and the correction of bugs is delayed by the clock. 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 assessed 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

On the basis of all this knowledge, we have come up with countermeasures:

I personally check every day all the assessments and the formulation of all new tasks, of course, I pay special attention to small tasks. So we struggle with the inadequacy of the assessment and the incompleteness of the statement
translate all the guys in the storm so that they at least stop messing with the merges in the console
in all tasks we put time for testing, communication and delivery to the client
We conduct weekly calls with a narrow programmer circle, where we program together, share knowledge, tricks, learn how to resolve conflicts and refactor code in between cases

This all began to bear fruit pretty quickly, especially programmer calls. For example, after the second phone call, the problems with git were gone.
The efficiency began to improve, although not very quickly. At the moment we are still putting a lot of effort and do not stop studying this issue.

What I learned in the new post

Frames - the most important

You can buy all the products of Atlassian and Jetbroins, tell smart things, introduce a bunch of regulations, agree with customers about the task setting schemes, but if your colleagues sabotage the regulations, work “out of habit” and do not use new tools, then there is no sense in innovations.

Also, a proactive person always favorably differs from just a good worker, even if it can get out of its “legal” area of responsibility and prevent the task from stalling or can offer some kind of general improvement without asking from above.

Personal qualities are more important than professional ones.

For example, you can have a cool specialist who always meets the deadlines, can solve any problem, writes the ideal code, but he appears in touch God forbid 2 hours a day or suddenly takes a day off in the middle of the week. This brings incomparably more problems than good, especially when detecting bugs in its tasks.

Or you can imagine a situation where there are two identical employees, but one of them reads professional literature and / or leads personal projects, and the second is not. Initially, they are the same in salary and skills, but after a while, the second one starts to pull the company down and pack, and the first one continues to fulfill its tasks or even overtake more experienced colleagues.

The moments when people refuse to take responsibility are also very harmful. This results in the sabotage of instructions or the dead stopping of tasks, if there is no connection with the original performer, and / or if you need to do something potentially dangerous, for example, to resolve a conflict or perform some action on the combat website.

Emotions from colleagues influence a lot (more than I previously thought)

Many do not like their job because of stress. Stress can be caused, for example, by the level of salary, the toxicity of colleagues, the stupidity of clients, expensive to work, work duties, a million other reasons.

New stress on the work can bring customers, unforeseen circumstances, colleagues. But from the first one can abstract, the second one can solve, but you will see forever whining and depressed colleagues every day.

Generally, so that we do not do it: write code, design, work with accounting, we still work with people anyway, and it is they who most influence our mood. And it is possible that it is the communication with the team that determines whether a person is delayed in the company or not.

Do not sit on two chairs

The first time I had to write the code all day, because of what I thought I didn’t have time to do my purely Timlide duties, I just helped the team as a whole more or less meet deadlines. But this is how to roll a square wheel when you were asked to grind it.

More popular harmful examples of mixing duties:

programmers communicate with clients for a long time and do not fit into the deadlines after that
managers are engaged in the distribution of all tasks among the performers, which eats up all their time
content managers try to edit the code and break the site
the manager is trying to convey a complaint to the programmer by code to another programmer
~~1s try to come up with a good solution~~

Of course, there are no postulates about the importance of self-development or, for example, occupational health, but only because it is not a new experience that I discovered.

Plans

Initially, when I was just starting to think about changing jobs, I wanted to go to Cyprus because I was expecting the sun from him (stereotypes about Peter are not stereotypes at all), peace of mind, good salary, interesting challenges and lack of stress.

But Moscow offered me conditions that I could not refuse (career growth, zp 2 times the current one, a platform for experiments and almost complete freedom of action).

On the other hand, if you think about it, we are also Europe. Therefore, I want to “bring Cyprus here”, that is, to command:

less stressed at work
stopped wildly tired
got rid of the negative outgoing from colleagues and customers
I had the opportunity to be proud of my work, that is, to stop correcting bugs and raking fakapy, and saw something cool
~~ever got away from bitrix~~ used new technology.
Well, of course, increased profits

Well, that is all that we expect from the beautiful far.

Part 2

This article covered about six months of my work in a new position. In the second part I would like to talk about how we are moving towards our goals with the help of:

Autotesting, which we are just starting to implement. Strange, but for some reason there are no decent examples on Beatrix
getting rid of legacy code
further accelerate and simplify development
the fact that I draw from the comments
many other secret things so far (all of a sudden my guys are reading me)

Thank you all for reading. I would be very happy to comment, especially if you know more optimal ways to solve the problems we encountered.

Good luck and joy in work and life!

Tags: