"Universal" in the development team: good or harm?

Hello! My name is Lyudmila Makarova, I am the development manager at UBRD, and a third of my team are “generalists”.

Acknowledge: each Tech Lead dreams of cross-functionality within their team. It's so cool when one person is able to replace three, and even do it qualitatively, without shifting the deadlines. And, not least, it saves resources!
It sounds very tempting, but is it really so? Let's try to figure it out.

Who is our anticipator of expectations?

The term "universal" is usually understood to mean team members who combine more than one role, for example, a developer analyst.
')
The interaction of the team and the result of its work depend on the professional and personal qualities of the participants.

On hard skills, everything is clear, but soft skills deserve special attention. They help to find the approach to the employee and direct him to exactly the task on which he will be most useful.

There are many articles about various types of personalities of representatives of the IT-industry. Based on my experience, I would divide IT-universals into four categories:

1. "Universal - Almighty"

These are everywhere. They always show great activity, they want to be in the center of attention, they are constantly interested in colleagues, whether their help is needed, and sometimes they can even be annoying. They are interested only in meaningful tasks, participation in which will give room for creativity and will be able to amuse self-esteem.

What are strong:

• able to solve complex problems;
• deeply immersed in the problem, "digging" and achieving results;
• have an inquiring mind.

But:

• emotionally labile;
• poorly managed;
• have their unshakable point of view, which is very difficult to change;
• difficult to make a simple matter. Easy tasks hurt the almighty's pride.

2. "Universal - I'll figure it out and do it."

Such people have enough manual and a little time - and they will solve the problem. Usually they have a big background behind them as DevOps. Such universals do not bother with design and prefer to use the development method only based solely on their experience. They can easily have a snack with tehlidom regarding the chosen variant of the task.

What are strong:

• independent;
• stress resistant;
• competent in many matters;
• erudite - there is always something to talk with them.

But:

• often violate obligations;
• they tend to complicate things: they decide the multiplication table by integration into parts;
• the quality of work is low, everything works 2-3 times;
• constantly shifting deadlines, because in reality everything turns out to be not so simple.

3. "Universal - okay, let me, since there is no one more"

The employee is well versed in several areas and has relevant experience. But he fails to become a professional in any of them, because he is often used as a lifeline, plugging holes for current tasks. Compliant, executive, considers himself in demand, but it is not.

Practical perfect employee. Most likely, he has a direction that he likes more, but because of the blurring of competencies, development does not occur. As a result, a person risks becoming unclaimed and emotionally burned out.

What are strong:

• responsible;
• aim at the result;
• calm;
• fully controlled.

But:

• show average results due to low level of competencies;
• can not solve complex and abstract problems.

4. "Universal - master of his craft"

A person with a serious developer background, has a systemic mindset. Pedantic, demanding of himself and the team. Any task with his participation can grow to infinity, if you do not mark the boundaries.

He is well acquainted with the architecture, chooses the method of technical implementation, carefully analyzing the influence of the chosen solution on the current architecture. Modest, not ambitious.

What are strong:

• show high quality of work;
• able to solve any problem;
• very workable.

But:

• intolerant to the opinions of others;
• maximalists. They try to do everything right, and this increases the development time.

What do we have in practice?

Let's see how roles and competences are most often combined. We take the standard development team as a starting point: PO, development manager (technical), analysts, programmers, testers. We will not consider the owner of the product and technical support. The first is due to the lack of technical competencies. Second, if there are problems in the team, you just have to be able to do everything.

The most common option for combining / merging / combining competences is a developer analyst. Also, the analyst-tester and “three in one” are very common.

Using the example of my team, I will show you the advantages and disadvantages of fellow station wagons. They are third in my team, and I love them very much.

PO has received the urgent task of introducing new tariffs into the existing product. My team has 4 analytics. At that time, one was on vacation, the other fell ill, and the rest were engaged in the implementation of strategic tasks. If I pulled them out, it would inevitably break the deadlines for implementation. The only way left is to use the “secret weapon” - a universal developer-analyst who owned the required subject area. Let's call him Anatoly.

His personality type - "wagon - I'll figure it out and do it . " Of course, he tried for a long time to explain that he had “the full backlog of his tasks,” but by my volitional decision he was sent to solve an urgent task. And Anatoly managed! He staged and completed the implementation on time, and the customers were satisfied.

At first glance, everything was a success. But after a few weeks, requirements for revision arose for this product. Now the “pure” analyst was engaged in the formulation of this problem. At the stage of testing a new development, we couldn’t understand for a long time why we have errors in linking new tariffs and only then, unwinding the whole bundle, got to the bottom of the truth. We spent a lot of time and thwarted deadlines.

The problem was that many hidden moments and pitfalls remained only in the head of our station wagon and were not transferred to paper. As Anatoly later explained, he was in too much of a hurry. But the most likely option is that he came across problems already in development and simply bypassed them, not reflecting it anywhere.

There was another situation. Now we have only one tester, so some tasks have to be tested by analysts, including universal. Therefore, I gave one task to the conditional Fedor, “a universal, alright, let me, since there is no one more” .
Fedor is “three in one”, but the developer has already been selected for this task. So, Fedya had to combine in himself only an analyst and a tester.

Requirements are collected, the specification is transferred to development, it's time to test. Fedor knows the system to be worked out “like the back of his hand” and thoroughly studied the current requirements. Therefore, he did not bother to write test scenarios, but conducted tests on “how the system should work,” and then transferred them to users.
The test ended, the revision went to prom. Later it turned out that the system not only suspends payments to certain balance sheet accounts, but also blocks payments from very rare internal accounts that should not have been involved in this.

This happened due to the fact that Fedor didn’t conduct a check on how “the system shouldn’t work”, didn’t draw up a test plan, checklists. He decided to save on time and relied on his own instincts.

How do we work with problems?

Such situations affect the team performance, release quality and customer satisfaction. Therefore, they can not be left without attention and analysis of the reasons.

1. For each task that caused the difficulty, I ask you to fill out a unified form: an error map, which allows you to identify the stage at which the “drawdown” occurred:



2. After identifying bottlenecks, with each employee who influenced the problem, a brainstorming “What to change?” (We do not consider special cases at retro) is conducted, following which specific actions are born (for each personality type) with timelines.

3. We have introduced interaction rules within the team. For example, we agreed to necessarily fix all the information about the progress of the task in the project management system. When changing / identifying artifacts in the development process, you need to display this in the knowledge base and the final version of the TOR.

4. Monitoring began at each stage (special attention is paid to problem stages in the past) and automatically based on the results of the next task.

5. If the result for the following task has not changed, then I don’t put the wagon in question into the role with which he does not cope well. I try to assess his ability and desire to develop competencies in this role. If I do not find a response, I leave it in the role that is closer to him.

What is the result?

The development process has become more transparent. Decreased BUS-factor. Team members, working on mistakes, become more motivated, improve their karma. We are gradually improving the quality of our releases.

findings

The station wagon staff has its pros and cons.

Advantages:

• You can close the hanging problem at any time or resolve an urgent bug in a short time;
• an integrated approach to solving the problem: the performer looks at it from all roles;
• generalists can do almost everything equally well.

Disadvantages:

• growing BUS factor;
• blurred core competencies inherent role. Because of this, the quality of work decreases;
• increases the likelihood of a shift in time, because there is no control at each stage. There are also risks of growing the “star”: the employee is confident that he knows better that he is a pro;
• the risk of burnout increases;
• A lot of important information about the project can remain only "in the head" of the employee.

As you can see, there are more disadvantages. Therefore, I use generalists only if there are not enough resources, and the task is rather urgent. Or a person has competencies that are not enough for others, and quality is at stake.

If in the joint work on a task, the rule of distribution of roles is observed, the quality of work increases. We look at problems from different angles, our eyes are not blurred, fresh thoughts always appear. In addition, each team member has all the opportunities for professional growth and expansion of their competencies.

I believe that the most important thing is to feel your involvement in the process, to do your work, gradually increasing the breadth of your competencies. Nevertheless, generalists in a team are useful: the main thing is to ensure that they effectively combine different roles.

I wish you all a self-organizing team of "universals – masters of their craft"!