How to be a team leader - my version

I was absolutely moved on computers and gamers were godless. In my youth I wanted to go write toys and even wrote for a while. Grew, grew, grew. At various times he was a developer, team leader, project manager. It turned out that in the project it is necessary not only to code, but also to propose some solutions at once, justify them, negotiate, quickly switch between heterogeneous tasks. For me personally, this is a serious load on the brain. To go from the “cod” mode and “speak by mouth” mode takes a lot of energy.


A year and a half ago, I came to the project of the portal Cloud platform Technoserv Cloud . There was an opportunity to assemble a new team and no longer switch the roles of the PM and the developer.

In general, of course, when you work in a small project, you mix all the roles, even if you don’t want to. Nowhere to hide. If I had an honest resume, then the position of “chief accountant” would have got there, because that was also the case. But let's tell you how it works here, and how, from my point of view, to be a team leader. Perhaps you know how to do better, but what is, that is.
')
The most interesting thing is to assemble a team for yourself on a new project.

Roles

From my point of view, the distribution is:

• The developer writes the code, and such that it, if anything, can be edited and read by colleagues. In a small team of 5-6 people there is no one's individual code, there is only a common task. Someone went on vacation or fell ill - we can add a hotfix or implement a new feature, without waiting for it.
• Timlid gathers people, assigns tasks to them, makes assessments, turns requirements of an architect or analyst into a technical task for developers, leads a tracker and generally deals with everything related to the process of industrial production of a code from the brain. But at the same time team leader does not talk to people especially outside the team.
• The project manager is engaged in the interaction between those who need something from the developers and developers. If he has a dedicated role, the tracker is already on it, the priorities of the tasks, the ways to solve it - all this is discussed with him. The project manager receives the necessary resources, handles documents and solves organizational tasks, allocates work, breaks down tasks. The PM is responsible for the overdue project, and the tmlid is responsible for the quality of implementation.
• An architect or an analyst pierces with thought the layers of time and reads the customer’s thoughts about what is needed. We don’t have a dedicated architect; more precisely, the architect is one of the business customers. About this job my colleague architect, who has been dealing with large things, will tell you better; I haven’t had anything longer than 5 years.
• The productologist thinks about the development of the service from and to, and the programmer ensures the realization of the ideas of the productologist and in addition does everything so that the client can comfortably, safely, with all the necessary SLAs, without the risk of breakdown or “falling” from the load, order the service.

The key difference between a PM and a Timlid is not only in the social circle, but also in the fact that the PM doesn’t have to figure out how to do the work. He says what to do, timlid - how to do. I used to be a PM in a game dev, there was a great example - you need to set a task for the composer for a music level. And you have to say what kind of music you want. “More luxurious, your rhythm is too fast” - he seems to understand, but you feel that something is not right. Lucky if you find a common language. So with the designer and interface you need to negotiate. Tiring.

I did not consider such a confusion of roles as a career development path. In retrospect, this is a good experience in order to find a common language with another brain. But it is important then, already being on a big project, to stop “jumping” into different roles, otherwise the tasks will start to sag.

How is teamwork now?

The customer tells the analyst what he wants. The analyst goes to us, we discuss the problem and divide it into logical parts. More precisely, the analyst forms a backlog (a list of required changes), we issue time estimates, then the analyst together with the PM sets priorities - what we do at the beginning, at the end. The analyst’s profit is that the portal’s logic is stored entirely in his head, and he gives us tasks that fit this logic, and not so much that “they did, they asked, they looked, oh, they changed 8 times, until stopped oykat.

I disassemble the backlog and stuff the tasktracker. About 50% of the time is spent on working with the team and tasks: we discuss tasks, draw the shem on paper, manage the task tracker, do a review. Now I'm doing a review mainly by occasionally discarding other developers. I want to switch to a modern cross-review scheme, when everyone reviews everyone. About 40% of the time I write the code myself (it is reviewed within the team). About 10% of the time goes to the “conditional devops,” because we ourselves support our test environment.

Development of the portal architecture - on the development team - is one of our tasks. This is in such a discussion - “how do we make such a set of features here, so that later we cannot die on support”. We have some computationally or algorithmically complex problems. But there are a lot of tasks just about the architecture, flexibility of settings and multiple and rich integration. That is, hardcore is in another - in the architecture of the application.

We cover ourselves with tests, but testing the features of the type where and what in the interfaces we give out. Here I am very pleased that everything from the PM in the right thread comes to us - any resources.

Without tests, the code does not go into release. At review, we look first at the tests, only then at the code.

Our team has separate developers of the backend and the front. In principle, our backend developers can fix something and finish it in Angular, but this greatly slows down the work - unloading the python from the head, loading the angular - actually tiresome. And yes, I do not like Angular. The front-end user can read the parameters of API calls from the backend code, and we brazenly used it to not document the code. Then they started automatic generation of docks by API and stopped torturing him.

Start a new project

The most important thing in the lead is a team. If you have people you are not sure of or are not technically savvy about, this is a direct threat to the project. Therefore, at the moment when I was solemnly handed a project to Technoserv Cloud (we are doing billing, managing cloud resources, integration layer and a web storefront for consumers), I needed to recruit people who could work well with each other.

What I gave HR:

Stack: Good knowledge of javascript (vanillaJS) and HTML5 \ CSS3, understanding basic UX principles or a desire to learn them, ability to cross-browser solution, MobileFirst, Responsive design, experience using popular frameworks - React \ Angular \ Backbonejs \ Marionette, using build and testing infrastructure - Bower, Grunt, Gulp and so on. Understanding of modern approaches to client-server interaction (Restful, msgpack, graphql). Using distributed version control systems - Git \ Hg. It will be a plus code testing, work with test libraries. Experience in building large js applications, especially solutions using React \ graphql \ flux \ relay. Development experience for backend. Development experience for mobile devices. Experience with WebSocket. Design and development of frontend for the company's web services. Our specifics are the management of complex technological systems, various statistics with graphs, monitoring — many interesting tasks. Need quick prototyping of interfaces. There is reverse engineering and, if necessary, refinement of third-party solutions.

3 months before planned start.

He gave a job description to our HR, received in two weeks the first 20 meetings. In total, there were probably 50 interviews to select 4 people. I looked at about 100 questionnaires, we eliminated those who could not move, did not pass through a security audit, did not have enough experience in our technological stack.

With the interviews themselves it was not clear how to evaluate in 1 hour how a person would work. After 5-6 meetings, a general pattern appeared, and I stopped being shy.

At the interviews I was interested in what project the person worked in, how the process was organized there. This is to understand whether a candidate has mastered good engineering practices or picked up bad ones. For example, did the candidate exactly work in a team or just sit next to the guys and lonely sawed his plump module, and there was no one to tell him “your code is junk!”. Did his elder friends force him to write tests for the functional or would it do? That is, was there enough in the life of a developer cleansing suffering, useful for the soul, or so somehow slipped through.

We all like to say at the interview that in the previous project code-review was widely delivered. And now, sorry for the uneven handwriting (see above). In practice, it is interesting - what was meant by this. In projects with burning deadlines, developers should allocate time for this, and this is not always the case. There are such projects where it never comes to the review for “objective reasons”. Oh, as I recall the experience of the first works, that technical debt comes when you have 15 minutes before the planned release ... I hope that I reliably suppressed all this from memory. Repetition did not want at all.

I also asked what was the most difficult task, how I decided what I had to face. First of all, it’s interesting what kind of tasks a real professional has, and then it’s interesting to see whether the person himself is interested in something or somehow is not very good.

Then it was interesting to look at the actual code. If there are projects on GitHub - well, it's generally cool then, you can, firstly, swipe your finger across the code, ask questions like "why so, not syak", "how to improve it" and "what is the algorithmic complexity." Secondly, if someone has filed a project with his own - well, it means that he can still motivate himself, and this is a good, useful skill. But, naturally, not everyone had it. Then the test task came into play - very small, lines by 20.

In the task it was necessary to find out how systematically a person approaches a solution: owns the programming language itself, what it knows about algorithms, computational complexity, and what the computer has inside. This, in general, is not a control, it is rather necessary to talk about the code.

It is even easier to evaluate the experience if it is similar to my own: I consider the development of the gaming backend in the portfolio to be a “plus” - it is clear that the person had “schizo tasks” to reduce the timing of falling coins, or “remember the coordinates of the seals when moving to another location” - therefore, at least, a person has a strong psyche.

Approved by the person 17. The company is not a quick recruitment process. During this time, the candidate may receive more offers and stupidly not to wait. Security guards check all candidates. A couple of people just trained to go for interviews.

What do we need to know in principle? In addition to Python itself (standard library, memory management, algorithms in general) - in principle, web services architecture, databases (SQL, indices, transactions). It is advisable to imagine what will happen with the service under load, to have an idea about security and possible hacking vectors.

More moments

There are interesting stereotypes. For example, "programmers have a logical mindset." Most likely, this is the case, but this is not easier for anyone - even within the project team, each coder has a different project picture in his head, and each one is very logical, but all their pictures are mutually contradictory. You ask a simple question “can I make an icon purple?” - a person has flour on his face. In my opinion, from the side it should look inconsistent and strange.

Another "to cool code, you need a technical education" or "know well the math." While we all have not been replaced by neural networks, many developers are required, and not all of them must be hardcore. Technical education and mathematics, of course, pump over the cerebral muscle and system thinking, but it seems to me that it is no less effective to download it with specific for development areas of mathematics (logic, sets, graphs, algorithms) and code everything that comes to hand.

In my opinion, does not affect freelancing work or in the office. It seems to me that it is better to start in the office, in a team with a set development process - it is easier to pick up from more experienced cats. At freelance, this is more difficult because of the difficulties with communication - it just takes more time for it, it becomes expensive to ask questions, you get less feedback, you experience less pain, hence the illusion of your own greatness. Although, perhaps, I incorrectly prepared freelance.

This is the Temloserv Cloud material of Peter Matyukhov (he is in the photo of the team, as expected, with a beard and a sweater).