5 mistakes novice lead

Each team leader has his own graveyard of managerial mistakes. Every day new articles are published “5 mistakes of a novice developer”, “7 examples of how not to manage the processes”, “100 and 1 way to keep within the deadlines”. And this is awesome!

Other people's rakes save your time, make you bold, pat on the shoulder and visually make it clear that you are not the only one who “did so much for me,” and it all went through.

Ozhegov's mistake is incorrectness in thoughts or actions, and, possibly, at the same time. But how can a newcomer do without them with a new remit? Perhaps no way, but you can try to soften the blows. In my example, I will talk about the mistakes that I could not avoid in the process of becoming me as a lead. I hope every story will either smile at you, because you will remember yourself in childhood the beginning of his journey, or make you think about, and how not to step on such a rake yourself.

Prehistory

I have devoted the last 6 years to testing, having changed several companies and teams in order to get relevant and confident knowledge about how to create a high-quality product and what role testers-engineers can play in this process. Sometimes the reason for leaving was the lack of opportunity to learn from strong colleagues testers (and this is necessary at the very beginning of the path), because they simply did not exist. I tried my hand at both manual and automated testing. And it was after I was pumped into automation that I had the opportunity to try myself as a lead testers with experienced Agile-coach.

For me, the world turned over at that moment. The habit of offering solutions and independently implementing them has grown stronger and did not want to leave me. It turned out that the work style of the automation engineer does not fit in with the new role of the leader of a small group of people. Let's go to the details.

Errors

№1 Manager "here and now"

I was better able to solve point questions "here and now", but this does not always bring the team closer to the stated goal.

Consider an example. At the very beginning of the formation of the new QA format in Dodo, having become acquainted with the way testing was arranged and the desire of everyone to start automation yesterday, I decided that it should be started soon. (You can learn about how we changed processes in the “Alice in QA Country” report) We all really wanted to save the children from the daily routine of manual regression testing in 9 countries.

Following the principle of “solving problems here and now”, we organized a meeting with testers, made a map of actions, set priorities, gave each tester time to automate and started to implement tasks from the map. First of all, we decided on the tool and presented our plan to accelerate the regression at the general IT meeting. Testers rejoiced at appearing tests and believed in the speedy disposal of a hand-made routine.

However, it turned out that we covered with tests that which ate a lot of time for the tester, but at the same time almost never changed by the developers and had little effect on the business processes.

What to do? Cap tips

Deeper understand the problem, look for causes, not consequences. Chances are good that your expectations that testers are the main source of knowledge about the system from the user's point of view are greatly overestimated. It is worth calling to the first meetings of various representatives of the IT company, ask for help with facilitating the meeting with the scrum-master, having previously discussed with him what result you would like to get.

№2 Manager "Experienced Engineer"

My second file is a “cap” of an experienced engineer. All the most difficult tasks fell to me.

Creating a PageObject, implementing a basic set of methods for working with our system, launching scripts in CI / CD - I decided to take all this out of habit. I did not delegate and communication with product teams, infrastructure engineers, and interviews, and the texts of vacancies. According to the mentor, our QA team was “green” (beginners) in every sense. Of course, I decided to first teach the children what I know myself, watching their work in order to share their tasks over time.

The problem is that the number of meetings (general meetings, team meetings, internal training, 1 & 1, interviews, test days) that fell on my shoulders, I stopped to fit into working hours with my tasks. Eight hours a day was not enough, and I began to compensate for this with free time, which I spent on coding, texts, and preparation for interviews with candidates. I spent the rest of the precious watch with the guys in a pair with the purpose of training and the gradual development of the project with autotests. My context switching slowed us down every hour or two on all fronts: automation, QA communications with commands and so on. Low rates of development of steep QA-engineers and process automation led to the fact that I worked at the weekend to make a five-year plan in a couple of months.

What to do? Cap tips

Do not be afraid to delegate tasks. Everyone has a right to make a mistake and you shouldn’t take it away, no matter how you are hypnotized by the leads of other teams or a mentor. Your guys must themselves want to trust you and follow you, always experiment. Get together, determine which processes can be improved, which of the guys are ready to promote them, and maybe some of them can be transferred outside your team. An experienced facilitator will help to ensure that the solutions chosen jointly do not remain only on paper. An independent, effective team is what every leader should strive for.

№3 Manager "The reverse side of micromanagement"

Another one of the mistakes is often micromanagement. I had to face its reverse side - implicit tight control.

Trying to avoid spying on every step of the children and limiting the scope of work, I began to “impose” their “unlimited” possibilities on the children: development plans, research tasks, speeches, courses, organizing meetings, visiting other companies and other activities. Good intentions - learning, pumping and honing skills, expanding horizons, new acquaintances in the professional field. This is all that I missed when I started working as a tester. The problem is that the team wants the right to choose: to perform or not, to watch or not, and I have driven them into a rigid framework.

- Guys, we do mitap. We need the following roles, gifts, there will be such speakers. Without your help, we will not be able to make a memorable event.
- Guys, in December there will be Heisenbug. I have already ordered an online broadcast for us, booked a conversation, and on Saturday I broadcast from my home computer. All for?
- Guys, we are going to visit the Odnoklassniki company this week to get acquainted with how their automation is built.

These opportunities were perceived as a framework-constraints that everyone does not like so much. My initiative seemed to have no alternative, and most importantly it was not as effective as expected.

What to do? Cap tips

Excessive care for the child leads to the fact that he grows up infantile or begins to do everything the opposite in spite of the parents. It seems that the same can be said about the care of the leader about his team. Motivate, not force, gather an intercept on the topic “How do we expand our horizons in IT?” And listen attentively to your colleagues, do not start from the very threshold to call all the methods that you know. And most importantly, do not run after your colleagues with a proposal to speak at the conference and get to an interesting master class. Announce the opportunity - this will be enough.

№4 Manager "Everywhere did so"

Perhaps some of the solutions that have worked for you earlier in another team / company will not find support in the new conditions and the idea of ​​a colleague who is far from the field of software testing but tough in development will be implemented. The argument that your decision was supported and continues to be actively developed on a community basis is unlikely to convince anyone to do the same, but on a local technology stack.

What to do? Cap tips

The main thing is not to start oppressing yourself by the fact that your professional skills and knowledge are questioned and are not taken into account when making decisions. Either look for decent arguments that will find support from the team, or agree with the team.

№5 Manager "Tantrum"

An important role in the process of becoming you as a professional / master of your craft is played by a mentor. But there is one nuance, your perception of the help of a mentor. If you distrust each other, then the effect of joint activities is unlikely to please the team and everyone around.

Tips, recommendations, emphasizing the strengths and weaknesses of the decisions made are the main value of working with a teacher for me. However, coaches often use a different training format: without any warning, they will organize a difficult situation for you, for example, conflict in a team on the basis of technology choices, wash their hands and watch your actions. For me, everything ended with the fact that the project with autotests became the responsibility of development teams because of the high threshold of entry, which the coach insisted on. This alignment suits everyone, and it would be pointless to continue the battle for simplicity.

What to do? Cap tips

It will be important to learn this moment: shouting, throwing papers, deleting each other’s code, a presentation by you and a mentor of different visions of strategy and tactical steps, tears will not help. So you only delay the process of approaching the goal, and you will probably constantly roll back, because you will be afraid to deal with, sit on the same floor, doubt the soundness of your ideas. Try not to make quick decisions, figure out why the coach needed this conflict, what you are weak about and how to resolve the situation without exploding over trifles.

Let's sum up

Above, I described 5 points of weak management from an experienced automation engineer. The difficulties described above can also be faced by you, and it depends only on your preparedness, character, how successful your battle will be and how united and strong your team will become. My story ended with the achievement of the goal.

Testers are now part of the Dev-teams, the guys are very independent and able to make decisions on technical implementation, cooperation with other teams. They write scripts on their own, select new test guys, conduct meetings and much, much more. Yes, we went to this for more than a year, but no one promised that managing people is easy.