We continue to share excerpts from the survival guide for beginner techlides from J.H. Rainwater. In the first series, we talked about which breeds of developers the manager usually has to work with; Now let's try to understand what to do with all this zoo. Organizational activities in a technical team can be divided into two parts - more or less native things (like code reviews and architecture management) and all that a programmer’s life did not prepare for — that is, managing people and processes. Let's deal with a stranger first.
Prioritization
The first thing that usually knocks down a freshly baked leader is an avalanche of the most diverse information. This state of affairs is quite logical: the one who is at the head of the team is less closed within its framework and is involved in more processes, but it does not get any easier. As a result, the technical leader often begins to disperse - considering his duty to respond to every signal, he grabs hold of everything at once, jumps from one task to another and misses out on what most needs attention.
There is only one way out - to filter this stream of information, separating what is directly related to the main task (release a code that meets commercial requirements, with an agreed deadline), and sending the main one to the backlog. But at first, the criteria for such sorting may not be obvious. For beginners, absolutely everything seems important.
Complicating matters is the fact that many stimuli excite emotions that interfere with sensibly assessing the importance and urgency of a problem. The incoming signals can cause interest (a curious anomaly was found in the code), guilt (the designer recalls that he has already requested many times to implement the function he wants to implement), apprehension (the user complains about the update).
In order to more successfully systematize all requests and information, the author suggests using the following matrix for processing them:
- How do the new data affect the project scope, the design decision, and the project deadline?
- Is the source of information reliable? If not, can it be ignored?
- Should I react to the receipt of information immediately or can I wait a little?
- Where and how to save information so that if necessary it could be quickly addressed?
- What is the validity period of the information? When does it become irrelevant?
- How does this information compare with what is already known about the project?
As you can see, this matrix helps to separate the grains from the chaff in several respects: get rid of frankly useless or unreliable information, push back what else can be moved, and evaluate the importance of the information strictly for the current project. However, questions about the timing and storage methods hint at the fact that information that is not relevant at the moment should not be dismissed as irrelevant in principle - this is another extreme that will lead the team to stagnation in the long run. We will talk more about this a bit later, when discussing the concepts of “leadership” and “leadership”.
Sprawling projects
The next pain point is the assessment of volumes and terms of work. Again, for some time, “swimming” in this area is almost inevitable for a beginner techlide - experience is needed to be able to review all the components of the project at once, not missing anything, and from the first attempt to set for each type of work, including unfamiliar, adequate terms. But even the experience gained does not save from a certain error, and it is not possible to reduce it to zero. Extreme accuracy in the planning of work is hindered by two laws that Humphrey aptly formulated:
Any process will last longer than you expect. Something always appears that you haven’t thought of.
Based on all this, the author calls to treat the problem philosophically. Most likely, as a first approximation, you will not be able to take into account any less obvious functions or unpredictable complications, and they will require an additional resource that you did not mortgage. For such surprises you need to be prepared and prepare a team - to teach people to quickly rebuild in order to "patch up holes", to leave them a little time in reserve for unforeseen circumstances. What can not be done in any case is to consider natural growth as an emergency and look for the guilty, especially in other departments (and this always looks especially tempting). So you only sow enmity between the teams and do nothing to solve the problem.
Nevertheless, one should not fall into complete fatalism: the growth of the project is nevertheless the result of flaws in planning. It will not be possible to completely get rid of them, but it is possible and necessary to reduce the concentration.
If we transfer Humphrey's laws to programmatic realities, it becomes clear that planning sags for two reasons: insufficient analysis of details and overly optimistic estimates of the duration of software product design. Optimism among managers usually wanders off in a natural way: several times breaking deadlines, you will perforce begin to play it safe. As for the detail, this skill also comes with experience, but it’s worthwhile from the very beginning to get a general idea of what the roadmap should look like.
For example, if you embark on a project armed with such a document, there will be many natural disasters and hassles ahead of you:
If the roadmap is more similar to the sample below, the chances of a happy outcome are significantly increased:
In addition to these two reasons, Rainwater lists a few additional risk factors that Robert Glass, the author of a sad book about disaster projects in the IT field, highlighted:
- Inadequate specification of project objectives
- Application of technology new for this company
- Annual / Missing Project Management Methodology
- Lack of leading experts in the group
- Disruption of agreements by hardware / software manufacturers
Common language search
You might think that we are talking about communication skills of communicative talents - but no, the meaning of the title is much more literal. In different companies, teams of programmers are formed on different grounds. If you're lucky, you might be in charge of people working with your native technology stack. But very often mixed teams come across, where different employees speak different languages. Such confusion at times makes life difficult for the leader.
One of the responsibilities of the lead is to oversee all the activities of the team, to ensure that all the code that goes into the world is working, high-quality and without excessive complexity. If you are not familiar with the tools that your subordinates use when developing, then your hands are tied. You cannot conduct code reviews on your own, you will only learn about serious errors at the testing stage, which disrupts the whole rhythm of work, and, roughly speaking, it’s much easier to drive you by the nose.
What to do in this situation? In general, there are two ways. If the set of languages and technologies is not too large and changeable, you can spare no time and try to master them at least at a basic level. This is perhaps the best way out - so you don’t have to depend on anyone, you will receive information directly, which means you can avoid the “dead phone” when discussing functionality, requirements and deadlines.
If it is not possible to learn the necessary languages yourself, then you will have to look for ways to delegate this responsibility. Form the core of assistants who can provide you with objective and honest feedback on each unfamiliar technology (if only one employee owns it, this method will naturally not work).
Deepening your knowledge in issues related to technology and tools is also useful for another reason - the only way to become a technical leader in the full sense of the word. In his terminological system, the author breeds the concepts of “manager” and “leader”. A manager is one who organizes work, solves everyday problems and makes sure that current tasks are completed on time and properly. The leader is a strategist who thinks outside the control deadlines, sets the general direction of movement for his team, raises the bar, rethinks and optimizes processes. Of course, in the development team, such visionary work requires a good acquaintance with the technology market. In the background, the technical leader constantly estimates that the current toolkit is outdated and needs to be replaced, monitors new products and at the same time has a broad enough outlook to evaluate their real merits (and not fall into the Stunt syndrome).
In the first part of the article, we talked about the fact that the leader does not need to worry that he will drop out of working with technology - and for those who aim at leaders, this is indeed so. But here it makes sense to repeat the warning from the same place: do not hope to evade the responsibilities of the manager. Management involves balancing between these two roles, which sometimes come into conflict, but remain almost equally (management is somewhat inferior) necessary for the survival of the team. Hone organizational skills to your advantage - the less time a routine eats, the faster you will grow as a technical expert. If daily tasks are left to chance, chaos will reign in which there will no longer be any strategy.
Flock picking
Now we turn to the second block of problems - the notorious work with people. Let's start from the very beginning: before talking about how to manage a human resource, you need to figure out where to get it. Even if you got the established team, sooner or later the question will arise about recruiting employees. Previously, we analyzed the types of programmers and pointed to those who should be chased in the first place. Now you need to understand how to act in order to identify the necessary qualities in the candidates and not be disappointed in their choice.
The author offers the following recommendations for interviews:
- Give the candidate a test task. Set a potential employee a task that he will either have to solve immediately, or take it to his house and solve it by the due date.
- Be sure to conduct an oral test of the candidate's skills - so you can evaluate both his knowledge and the ability to think clearly in a stressful situation.
- As much as possible, write down the duties of the desired employee, all the tasks that he has to carry out, and give this list to the candidate for review. So the conversation will immediately become more objective and, as a rule, more frank.
- Do not limit yourself to one meeting. It will be very good if the candidate communicates not only with you, but also with the aforementioned “core” - your assistants, deputies, leading developers in the team. But arranging a show with the whole team is not worth it, this is already too much.
- Verification of personal qualities, typological tests and the like are a possible, but optional step. Only resort to it if the candidate is not opposed and you have reliable assessment tools.
Speaking of hiring, one cannot but mention the flip side - the dismissal of workers who pull the team down. Here Rainwater takes a rather tough position and advises without hesitation to get rid of those who have shown themselves incompetent or problematic. The best position is the policy of one warning: it gives a person the opportunity to improve, but does not allow abuse of this right. If an employee is on the “black list” and you had a conversation with him, you need to supervise his further success with great care. This requires additional effort, so giving a third chance is already unjustified wastefulness.
In addition, not only the abstract “common cause” usually suffers from negligence of a team member, but also very specific people who have to correct his mistakes or put up with the fact that he spoils the results of their work. Excessive indulgence, therefore, is paid at their expense and is unlikely to strengthen your leadership position.
Organization of work of employees
Comfortable living environment
The book pays a lot of attention to this aspect. To achieve maximum productivity from your employees is a direct responsibility of the leader, but high productivity requires high concentration, and concentration is impossible if the programmer is surrounded by irritants on all sides. Therefore, the leader must do everything in his power to provide the team with good working conditions.
The specific recommendations for designing an office that Rainwater gives in places sound somewhat idyllic (for example, in a separate office for a brother), and in some places they are like echoes of a distant and difficult past (each developer must have his own computer). But the general principle still remains reasonable and applicable: in order for programmers to achieve success in their activities, they must have the opportunity, on the one hand, to work in a team for some time, and on the other, to brainwash alone. For the first you need training venues that are suitably equipped: meeting rooms with projectors, leisure teams (ideally) with the notorious tennis tables or game consoles. For the second, it is necessary to organize the available space so that people have to be distracted as little as possible by noise, flickering, smells and other distracting factors. If conditions are poor, let employees, especially those who are valuable and reliable, work from home.
An obligatory minimum of amenities also includes modern, high-quality equipment, which the developer can, within reason, configure at his own discretion. If the cars are weak and outdated, there’s no need to talk about technological breakthroughs, and you just don’t need calm, uninterrupted operation. For testing programs, special devices should be allocated that reproduce standard user characteristics.
Working hours
The heap of duties of the technical expert, which we outlined, suggests that the duration of his working day should almost double. But here you must be careful. The problem is that, with his working regime, the manager himself, unwillingly, sets the tone for the entire department. If you sit late, workers will assume that something similar is expected of them too. As a result, processing can enter the flesh and blood of your local culture - and this is fraught with trouble.
Firstly, not everyone will be happy with this state of affairs. First of all, processing will hit those who are burdened with additional obligations, for example, family ones. If there are many such people, the situation in the team will be tense. But secondly, the author, like many after him, points out that extra working hours are more likely to harm productivity - both because of fatigue and because of a decrease in motivation. It is wiser to demand effective work from school in lesson time than to instill habits that will lead to burnout.
Task distribution and supervision
Let's be honest: even ideal conditions and a gentle schedule in themselves will not encourage people to self-organize and diligent work. Among other things, a boss is needed to distribute the work and to ensure that it is carried out. Some part of your time should be occupied by control - by the way, this also contributes to concentration.
The author advises not to split up the “reporting periods” too much for subordinates, not to stifle them with constant observation with a daily request for results. It is wiser to determine a list of tasks for each weekly and evaluate the amount of work done for the same period. In particularly hot periods, the lists will have to be adjusted even at this small interval due to urgent matters arising and changes in priorities. The leader must keep all these changes in mind (and in modern realities - and make them in the appropriate accounting system).
If a leader comes to a “foreign” team with an already established working rhythm, it is worth asking each employee to paint his usual tasks in the same way. Such documentation can reveal a lot of interesting things - not only who and what is involved and how the management was carried out before, but also what people generally think about their responsibilities.
As for the content of these lists, of course, in many respects it will be determined by the skills of the employees and the requirements of the company. But with all this, the book advances the idea that it is necessary to rotate tasks as far as possible - the developer should not do the same thing from week to week. There are several reasons for this. Firstly, it helps to maintain a healthy climate in the team: no offense due to the fact that someone constantly gets the most unpleasant or, conversely, the most interesting things, less sensation of routine and monotony in work. Secondly, programmers need to stay in good intellectual shape - a variety of tasks will contribute to this. Finally, with such alternation, a minimum of effort will be required to form a bench.
The Reinwater attaches great importance to the bench. The main idea here is that in the event of illness, vacation, dismissal, untimely death of any of the developers, the team should include people who will be able to fulfill its functions - at least for that period, until they hire a replacement. This not only ensures the smooth operation of the department, but also avoids some other problems (for example, the company's acute dependence on Wizards). Accordingly, it is necessary to maintain the interest of employees in relevant technologies, in every possible way to encourage cooperation and participation in "other people's" projects.
By the way, the boss himself is not protected from the factor of falling bricks. Therefore, as soon as you get used to it a bit, start to think about who you would make your successor. This is not only reinsurance, but also a good exercise for delegating tasks - when preparing a successor, you unwittingly have to think about which work is the easiest and safest to entrust to others. During rummages this knowledge will be very useful.
And the last: until now, it was mainly about the interests of the team and superiors, but do not lose sight of the fact that we still work with people. Personal preferences and characteristics of employees should be taken into account whenever possible. You should not expect special mobility from someone who can hardly switch from one to the other, you should not, for reasons of justice, send the Brakes to a task that he is afraid to not cope with and so on. Here we again rest against the thesis that we need to carefully monitor our employees and know them well.
Motivation and encouragement
But enough about the whips, let's talk about the more pleasant - those gingerbread cookies that programmers should get from work. Rainwater names the following types of gingerbread (in order of priority): salary, career advancement, kind word and, finally, abstract corporate regalia.
In terms of remuneration, managers who have left the development are not too prone to pickiness, but often fall into the opposite extreme and overestimate the expectations of employees. When deciding on rates, keep in mind the following factors: productivity, experience, effectiveness, timeliness of tasks, current average rate, market conditions and corporate standards. A common mistake is to raise salaries in advance, hoping that this encourages workers to give their all. In fact, people treat upgrades differently - as the norm that they have already earned.
If the company has a premium system, make sure that real achievable indicators are established, based on which employees can be rewarded objectively. Otherwise, the prize will turn in their eyes either into a certain fiction, which exists only in theory, or into a fixed allowance.
Employee promotion is a complex topic. The difficulty lies, first of all, in the fact that in many companies promotion is inextricably linked with managing people (perhaps you yourself got into a leadership position because you ran into a “ceiling”). Not everyone needs it and is suitable. Ideal conditions for growth are a developed hierarchy of purely technical workers, which allows to differentiate between different levels of responsibility and competence and pay for them accordingly. If this is not the case, you will have to look closely at the employees especially to see if they can handle the new set of responsibilities.
The praise of the previous two paragraphs does not replace, but remains an important tool for motivation. Developers are mostly exhibitionist cats, they like to see that their contribution, whatever it may be in reality, is noticed and appreciated. But one should not go too far: praise should be timely, sincere and substantive. The banalities in the spirit of “We all worked well on this project” will be perceived as corporate idle talk and are more likely to be repelled than inspired. It is better to praise in public (and criticize face-to-face) - this has a good effect on the general atmosphere.