Notes on combining roles in development teams

Notes on combining roles in development teams

For more than 10 years, I have been observing the software development process both from the inside and from the side. During this time, I held various positions, from junior to tech lead, team lead and product manager. Now I combine everything a little at a time.
I was recently asked by management how to accelerate the delivery of value by the development team.

Basically, the problem voiced by the management was as follows: our analysts do not have time to write specs, and testers do not have time to test features. Let’s make programmers write specs and test features. Unfortunately, I encountered this approach in almost every place of my work, and not only there.

Now there will be a little offtop. I am actively engaged in sports tourism. When recruiting a group for a hike, the following situation often arises: a novice participant arrives, whose personal equipment weighs 20 kilograms. He also needs to carry 10-12 kilograms of public equipment and food. Together it turns out more than 30 kg.
Still comes the experienced competitor who spent a lot of time, effort and money to ensure that his set of personal equipment weighed 10-11 kilograms. His physical and technical training is also much better than that of our rookie.

What would a classic hike leader do in such a situation? It will remove the public burden from the novice and transfer it to the experienced one. As a result, we will get two units with a load of 25+ kilograms, neither of which can move with sufficient speed and autonomy.

What will an experienced manager do in this case? Even at the stage of the interview, the newcomer will indicate the requirements for the selection and replacement of equipment and tightening of physical form.

It is not necessary to weaken your strong members by shifting the load of weak ones. It is necessary to pull the weak to the level of the strong.

Today, it’s a very strange situation in general, which is that being a cool technical specialist is not profitable from the point of view of ROI.

A good senior backend developer gets 300-400 ACCOUNTS. per month. In order to achieve this, he has spent a lot of time on education, he understands the intricacies of data warehouses, networks, message brokers, algorithms, the fundamental principles of his programming language and other tools he uses, system design, analytics, testing and often product questions He makes decisions that affect the execution of tens of thousands of requests per second, is responsible for the product and, in general, for everything that happens to it. I’m not talking about senior Angular or React developers and other formoshleps (with all due respect), but I’m talking about software engineers who solve any number of large technical tasks.

A middle tester gets ~100 COUNTS. per month, at the same time, he knows how to send a request by postman (sometimes by Kurlom, but it is already 150 ACCOUNTS), how to write sql of the type select *, and that there are GET and POST requests. There is also some “testing theory” that is studied during the month. And for the rest, there are developers who will translate what goes beyond the scope.

Somehow it turns out that the cost of an IT technician depending on his skills is a logarithm, and from a certain point it becomes simply unprofitable to develop in the engineering direction.

Therefore, I would like to appeal to our dear managers: do not try to impose on programmers other people’s tasks that they cannot perform due to their own incompetence. Make them step up to the level of your programmers. Otherwise, you’ll be left with a bunch of expensive failures, with no one to pick up projects when their tasks go beyond POST requests.

Related posts