5 mistakes beginner lead
Each team leader has his own cemetery of management errors employees . Every day new articles are published: “5 mistakes of a novice developer”, “7 examples of how you do not need to manage processes”, “100 and 1 way to meet deadlines”. And this is awesome!
Someone else's rake saves you time, makes you bold, pats on the shoulder and makes it clear that you’re not the only one who “made me”, and all this passed.
An error according to Ozhegov is an incorrectness in thoughts or actions, and, possibly, at the same time. But how can a novice with a new range of responsibilities do without them? Perhaps nothing, but you can try to soften the blows. On my example, I will talk about those mistakes that I could not avoid in the process of becoming me as a lead. I hope every story either smiles at you, because you will remember yourself inchildhood the beginning of your journey, or it will make you think about how to avoid stepping on such a rake yourself.
Background
The last 6 years I have devoted testing, changing several companies and teams in order to get relevant and reliable knowledge on how to create a quality product, and what role testers and engineers can play in this process. Sometimes the reason for leaving was the lack of the opportunity to learn from strong colleagues of testers (and this is necessary at the very beginning of the path), because they simply did not exist. I tested my strength in both manual and automated testing. And it was precisely after I pumped in automation that I had the opportunity to try myself as a lead tester with an experienced Agile coach.
For me, it’s like the world turned upside down at that moment. The habit of proposing solutions and independently implementing them became 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 move on to the details.
Mistakes
No. 1 Manager "Here and Now"
I was better at resolving point issues “here and now”, but this does not always bring the team closer to their stated goal.
Consider an example. At the very beginning of the formation of the new QA format in Dodo, having got acquainted with how the testing works and the desire of everyone to start automation yesterday, I decided that it should be started in the near future. (How we changed the processes can be found in the report “Alice in the QA Country” ) We all really wanted to save the guys from the daily routine of manual regression testing in 9 countries.
Following the principle of "I solve problems here and now", we organized a meeting with testers, made a map of actions, set priorities, allocated time for each tester to automate, and set about implementing tasks from the map. First of all, we decided on the tool and presented our plan for accelerating the regression at the general meeting of IT. Testers rejoiced at the tests that appeared and believed in an early disposal of the manual routine.
However, it turned out that we covered with tests that which consumed a lot of time of the tester, but at the same time practically never changed by developers and had little effect on business processes.
What to do? Cap Tips
To understand the problem more deeply, to look for causes, not consequences. It is very likely that your expectations that testers are the main storehouse of knowledge about the system from the point of view of the user are greatly overstated. It is worth calling various representatives of the IT company to the first meetings, asking for help with facilitating the meeting with the scrum-master, having previously discussed with him what result you would like to receive.
No. 2 Manager "Experienced Engineer"
My second file is the "cap" of an experienced engineer. All the most difficult tasks came to me.
The formation of PageObject, the implementation of the basic set of methods for working with our system, the launch scripts in CI / CD - I decided to take it upon myself out of habit. I did not begin to delegate communication with product teams, infrastructure engineers, and interviews, and vacancy texts. According to the mentor, our QA team was “green” (newcomers) in every sense. Of course, I decided to first teach the guys what I know myself, observing their work in order to share my tasks over time.
The problem is that with the number of meetings (general meetings, team meetings, internal training, 1 & 1, interviews, test days) that fell on my shoulders, I stopped falling into working hours with my tasks. Eight hours a day was not enough, and I began to compensate for this with my free time, which I spent on coding, texts, preparation for interviews with candidates. The rest of the precious watch I spent with the guys in tandem with the aim of training and the gradual development of the project with auto tests. My context switching every hour or two slowed us down on all fronts: automation, QA communications with commands, and more. The low rate of formation of cool QA engineers and process automation led me to work on 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 the right to make a mistake and you should not take it away, no matter how you are hypnotized by the leads of other teams or the mentor. Your guys themselves should want to trust you and follow you, always experiment. Get together, determine which of the processes can be improved, which of the guys are ready to promote them, and maybe some of them can be transferred outside of your team. An experienced facilitator will help to ensure that solutions chosen together are not only on paper. An independent effective team is what every leader should strive for.
No. 3 Manager “The reverse side of micromanagement”
Another mistake is often micromanagement. I had to face its flip side - implicit tight control.
Trying to avoid monitoring the children’s every step and limiting the front of work, I began to “impose” the “unlimited” possibilities on the children: development plans, research tasks, speeches, courses, organization of meetings, visits to other companies and other activities. Good intentions - training, pumping and honing skills, broadening one's horizons, making new acquaintances in the professional sphere. This is all what I was so lacking when I started working as a tester. The problem is that the team wants the right to choose: to speak or not, to watch or not, but I drove them into a tight framework.
- Guys, we are doing a mitap. We need the following roles, gifts, there will be such speakers. Without your help, we cannot make a memorable event.
- Guys, in December there will be Heisenbug. I already ordered an online broadcast for us, booked a meeting room, and on Saturday I will broadcast from my home computer. All for?
- Guys, this week we are going to visit Odnoklassniki to get acquainted with how automation is built.
These opportunities were perceived as limitations, which everyone dislikes so much. My initiative looked uncontested, 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 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 on-topic on the topic “How can we expand our horizons in IT?” and listen carefully to colleagues, do not start from the threshold to name all the ways that you know. And most importantly, do not run after your colleagues with a proposal to speak at a conference and get to an interesting master class. Announce the opportunity - that will be enough.
No. 4 Manager “Everywhere they did it”
Perhaps some of the solutions that 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 cool in development, will be realized. The argument that your decision was supported and continues to be actively developed already on the basis of the community is unlikely to convince anyone to do the same, but on the local technology stack.
What to do? Cap Tips
The main thing is not to begin to oppress yourself by the fact that your professional skills and knowledge are being questioned and are not taken into account when making decisions. Either look for worthy arguments that will find support from the team, or agree with the team.
№5 Manager "Hysterical"
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 caveat, your perception of the help of a mentor. If between you distrust of each other, then the effect of joint activities is unlikely to please the team and everyone around.
Advice, recommendations, emphasizing the strengths and weaknesses of decisions made - this is the main value of working with a teacher for me. However, coaches often use a different training format: they organize a difficult situation for you without warning, for example, a conflict in a team due to the choice of technologies, wash their hands and watch your actions. For me, it all ended up with the fact that the project with auto-tests became the responsibility of the development teams because of the high entry threshold that 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 such a moment: screams, tossing papers, deleting each other's code, the presentation by you and the mentor of different visions of the strategy and tactical steps, tears will not help. So you only drag out the process of approaching the goal, and perhaps you will 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, why you are weak and how to resolve the situation without exploding for nothing.
To summarize
Above, I described 5 points of weak management from an experienced automation engineer. You may encounter the difficulties described above, and how successful your battle will be and how united and strong your team will depend on your preparedness and character. My story ended with the achievement of the goal.
Testers are now part of Dev-teams, the guys are very independent and are able to make decisions on technical implementation, cooperation with other teams. They write scripts on their own, select new testers, hold mitaps and much, much more. Yes, we went to this for more than a year, but no one promised that managing people is easy.