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

Hi all! My name is Lyudmila Makarova, I'm a development manager at UBRD, and a third of my team are all-rounders.

Admit it: every Tech Lead dreams of cross-functionality within their team. After all, it's so cool when one person is able to replace three, and even do it with high quality, without shifting the deadlines. And, importantly, it saves resources!
Sounds very tempting, but is it really? Let's try to figure it out.

Who is he, our anticipator of expectations?

The term “generalist” is usually understood as 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.

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

There are many articles about all sorts of personality types in the IT industry. Based on my experience, I would divide IT generalists into four categories:

1. "Universal - omnipotent"

These are everywhere. They are always very active, they want to be in the spotlight, they are constantly asking colleagues if they need help, sometimes they can even annoy. They are only interested in meaningful tasks, participation in which will give room for creativity and be able to amuse their pride.

What are they strong in:

• able to solve complex problems;
• dive deep into the problem, “dig” and achieve results;
• have an inquisitive mind.

But:

• emotionally labile;
• poorly managed;
• have their own unshakable point of view, which is very difficult to change;
• it's hard to make something simple. Easy tasks hurt the vanity of the almighty.

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

For such people, a manual and a little time are enough - and they will solve the problem. They usually have a big background as DevOps behind them. These generalists do not bother designing and prefer to use the development method based solely on their experience. They can easily have a snack with the tech lead about the chosen option for implementing the task.

What are they strong in:

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

But:

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

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

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

Practical ideal employee. Most likely, he has a direction that he likes better, but due to the blurring of competencies, development does not occur. As a result, a person runs the risk of becoming unclaimed and emotionally burnt out.

What are they strong in:

• are responsible;
• result oriented;
• calm;
• completely controllable.

But:

• show an average result due to a low level of competencies;
• unable to solve complex and abstract problems.

4. "Universal - a 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 the boundaries are not marked.

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

What are they strong in:

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

But:

• intolerant of 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 competencies are most often combined. Let's take a standard development team as a starting point: PO, development manager (tech lead), analysts, programmers, testers. We will not count the product owner and technical lead. The first is due to the lack of technical competencies. The second, if there are problems in the team, just needs to be able to do everything.

The most common option for combining / merging / combining competencies is a developer-analyst. Analyst-tester and "three in one" are also very common.

Using the example of my team, I will show the pros and cons of my fellow all-rounders. There are a third of them in my team, and I love them very much.

An urgent task was received from PO to introduce new tariffs into an existing product. There are 4 analysts in my team. 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 disrupt the implementation deadlines. There was only one way out: to use the "secret weapon" - the universal developer-analyst who owned the required subject area. Let's call him Anatoly.

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

At first glance, everything worked out. But after a few weeks, this product again had requirements for improvement. Now the "pure" analyst was engaged in the formulation of this problem. At the stage of testing a new development, for a long time we could not understand why we had errors in binding new tariffs, and only then, having unwound the whole tangle, did we get to the bottom of the truth. We spent a lot of time and missed 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 stumbled upon problems already during development and simply bypassed them, without reflecting this anywhere.

There was also another situation. Now we have only one tester, so some tasks have to be tested by analysts, including generalists. Therefore, I gave one task to the conditional Fedor - “to the station wagon - okay, let me, since there is no one else”.
Fedor is “three in one”, but a developer has already been allocated for this task. So, Feda had to combine only an analyst and a tester.

The requirements are collected, the specification is transferred to development, it's time to test. Fedor knows the system being finalized "like the back of his hand" and thoroughly worked out the current requirements. Therefore, he did not bother writing test scenarios, but tested “how the system should work”, then handed it over to users.
The test is over, the revision went to prom. Later it turned out that the system not only suspends payments to certain balance accounts, but also blocks payments from very rare internal accounts that should not have participated in this.

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

How do we deal with problems?

Situations like these affect team performance, release quality, and customer satisfaction. Therefore, they cannot be left without attention and analysis of the reasons.

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

2. After identifying bottlenecks, each employee who influenced the problem is brainstormed “What to change?” (we do not consider special cases in retrospect), as a result of which specific actions are born (for each type of personality their own) with deadlines.

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

4. Control began to be carried out at each stage (special attention is paid to problematic stages in the past) and automatically based on the results of the next task.

5. If the result for the next problem has not changed, then I do not put the generalist in question in 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 him in the role that is closer to him.

What happened in the end?

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.

Conclusions

Generalist employees have their pros and cons.

Advantages:

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

Disadvantages:

• the BUS factor grows;
• the core competencies inherent in the role are blurred. Because of this, the quality of work is reduced;
• the likelihood of a shift in terms increases, because there is no control at each stage. There are also risks of growing a “star”: the employee is sure that he knows better that he is a pro;
• the risk of professional burnout increases;
• a lot of important information about the project can only remain “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 quite urgent. Or a person has competencies that others lack, and quality is at stake.

If the rule of distribution of roles is observed in joint work on a task, then the quality of work increases. We look at problems from different angles, the view is not blurred, fresh thoughts always appear. At the same time, each team member has every opportunity 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 job, gradually increasing the breadth of your competencies. Nevertheless, generalists in a team are beneficial: the main thing is to make sure that they effectively combine different roles.

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

Source: habr.com