An important role was played by the opportunity to learn from my colleagues and adopt their experience. At first, I shared the details of the process with my supervisor in detail, receiving a lot of feedback and food for thought. In difficult moments, I had the opportunity to consult and get an alternative view and recommendations for action.
Now there are 4 people in the team besides me. Two work full-time and two part-time, combining with the main job. I’ll tell you about the current approach that is currently being used in the formation of the team.
At the moment, much attention is paid to the hiring of junior engineers, their development and further career growth within the department. We also employ experienced professionals, mostly part-time or temporary, both as engineers and consultants.
I know that there are different opinions about the advisability of hiring beginners. I’ll tell you why we are betting on it.
Firstly, hiring a junior gives not only a perspective, but also real benefits from the first months of work. June gradually unloads colleagues from tasks like parsing calls and incidents, administering simple stands, internal infrastructure, release support, documentation, and more. Of course, you need to build on the complexity of projects and look for an engineer with the necessary background. If we talk about technical skills, then I hire candidates with at least a year of experience in the field of Linux administration, who can automate their work (scripts, Ansible) and know the basics of Docker.
Jun also strengthens the team in the future. The employee gradually grows, developing in theory and practice, moving from simple projects to more complex ones. I talk about our practices for the consistent and controlled development of employees in the part “Employee development plan and grading system”. We quickly get an engineer who is technically advanced, knows the company’s projects well, has a similar culture and work principles. In an environment where there is a huge demand for engineers and it is difficult to compete with large companies for experienced ones, growing your own specialists is a great way to build a team. Of course, this approach has nuances. Training and working with such an employee will require a lot of time on the part of the manager and senior colleagues. And with an increase in the load on the team, such hiring will not allow you to quickly scale the team.
How is a possible lack of expertise made up for this? An important role in the team is played by experienced engineers who are hired on a part-time basis. Most often, they are involved in projects with a small load, or in the main ones, if there is a shortage of hands and knowledge of certain tools and technologies is needed that are not in the team. Sometimes we also involve experienced specialists on projects as consultants. Such an expert helps in the design of the solution, coordinates the actions of the engineer and advises him on possible questions and problems.
Given the limited hours and the nuances of combining work, it is not always easy to find the right person for part time. Here, the ideal candidate is someone who knows how to plan their time, is independent and has experience in combining several jobs. Strong skills for the required stack and motivation to dive into new projects and tasks are important. Companies, on the other hand, need to take into account the risks: the main work will always have a higher priority for the employee, and with a high load and urgent tasks on it, he may temporarily drop out of our projects.
In total, the current team building strategy consists of hiring and developing junior engineers, as well as attracting experienced consultants and engineers on a temporary or part-time basis. This approach is now effective for us and gives results, but certainly not for all companies. It is necessary to build on the projects of the company, its capabilities and the specifics of work. And with the growth in the number of projects, we ourselves will need to refocus on hiring more experienced people on a full-time basis.
Communication with the team
We have formed a completely remote team, we work from different cities and do not see each other in person. Nevertheless, I also managed to catch the classic format of work: meetings with employees in a meeting room, conversations at the cooler, spontaneous discussion of new ideas, and other attributes of office work. Of course, with the format of complete remoteness, communications between employees noticeably sag and special attention should be paid to this.
With each employee, I hold regular weekly one-on-one meetings – weekly half-hour meetings between an employee and a manager. The purpose of these meetings is to build relationships with colleagues and improve work processes. For the most part, I try to stick to the O3 techniques outlined in Horstman’s book I mentioned earlier: 10 minutes as an employee, 10 minutes as a manager, 10 minutes for a development and growth discussion.
True, initially I held meetings for an hour instead of the 30 minutes suggested in the book. This seemed necessary to me, because due to the remote work format, we need more communications and this time is not enough. Plus, as a tech lead, I have to take the time to discuss tasks from a technical point of view, help and coach, especially at meetings with juniors. In this format, coaching – monitoring how an employee develops technical skills – often turned into training, that is, direct training of an employee.
Over time, I realized that this format of meetings is not effective enough, both in terms of time spent and results. O3 meetings between a manager and an employee have a specific purpose and trying to discuss anything and everything in them often means not focusing on anything. I made adjustments to the process and in practice made sure that often half an hour is enough to say everything necessary, without unnecessary immersion in details, and give feedback. If there is a need to discuss a specific task and problems on it, then in this case we are going to a separate mini-call on this topic, or we discuss it at a regular team call. These changes freed up both staff time and mine.
Regular calls of the department, where all employees participate, take place once a week and last one hour. The purpose of the calls is to improve communication between engineers: to allow them to get to know each other better, share experiences and discuss new ideas for work. Initially, the meetings were biweekly, but after reducing the time of One-on-One calls, they became weekly.
Most of our work communication takes place by text, for this we use Slack. But sometimes it is much easier and more correct to stop the correspondence and discuss something in a voice. I try not to disdain quick calls, Slack has a handy feature for this – Huddle. Also, if necessary, I try to share the screen more often or ask colleagues about it. In a remote environment, we do not have the opportunity to look at each other’s monitor and share advice and wisdom. After all, after looking at how a colleague works, you can notice something useful for yourself, or give a recommendation on how to do something more optimally and more conveniently.
Handling requests and scheduling tasks
For a long time we lived without the practice of resource planning and any rules in terms of processing tasks and requests by the department. At first, this was not a big problem, but as the projects and the number of people grew, changes in the process were required.
First of all, I wanted to deal with requests from colleagues and systematize them. The total use of personal messages and threads that we have developed did not allow us to effectively plan and organize work on tasks and requests. As a result, we switched to a more active use of Jira for working with requests, and operational communications were transferred to a special Slack channel #infrastructure or project channels. I deal with the distribution of tasks, or project managers immediately assign them to the engineer responsible for the project. Using a kanban board helps with visualization and task planning.
As for resource planning, here the company has a common regular practice. On Mondays, we have meetings where all project managers and department heads participate, and work is planned with the distribution of people across projects. For planning, we use the Runn service, and the time spent on work is tracked by employees through Hubstaff. This is how the analysis of the real time spent on projects and the difference with planning is carried out. The very practice of resource planning helps to allocate people and prioritize to meet the deadlines and budget of projects. It allows you to see in advance the possible shortage of personnel for the project, employee overload and take into account people’s vacations when planning, which are also visualized in Runn.
Department work policies
“Your team needs a wiki. On it you can document all your policies (what should be done) and procedures (how it is done)” (с) OpsReportCard.
The next step was to draw up internal regulations and policies for the work of the department. Information and rules that were not clearly defined and passed down orally have now been described and enshrined in our Confluence.
The department’s work policy contains information about the principles of working with incidents and requests, about areas of responsibility, duty, etc. It contains information about payment for processing, social. program and other organizational nuances in the department and the company as a whole.
Infrastructure building policies contain information about what should be done when deploying the infrastructure and launching applications, why and on what principles. As a rule, there are no technical details here, it is a set of practices, ranging from the principles of resource naming, and ending with the approach to monitoring and documenting the infrastructure.
Politicians have improved the process of onboarding new people to the team and have become a reminder and checklist for the entire team. The necessary information is collected in one place and there is no need to pronounce it all from scratch. The main thing is to periodically take the time to update the materials.
Employee development plan and grading system
For each employee of the department there is an individual development plan for the year. The plan is drawn up jointly by the manager and the employee himself. As a rule, the plan contains two milestones, for the first and second half of the year, after each there is a meeting to discuss the results. My task is to draw up a plan that will allow the employee to develop the necessary skills and improve their qualifications. Of course, in addition to putting together this plan, I need to help develop skills and communicate appropriate tasks and projects that the employee can work on.
The plan itself is a short text document that contains goals with deadlines: for example, getting such and such a certificate before the fall, or a skill demonstrated on a project with positive feedback from the project manager and from me. This makes each goal in the plan measurable and time bound.
We have a grading system that shows what specific skills and experience an engineer needs to advance in the position. The development plan, of course, is drawn up taking into account the grading system. At the moment, we have the following grades of DevOps engineers: junior, pre-middle, middle, senior.
At the middle grade, we get certification. Currently, the list to choose from includes AWS and Kubernetes (CKA) exams. The specific direction is discussed with the employee, and depends on what project we are preparing the engineer for or what kind of expertise we want to increase in the team. Certification is a great way to develop and validate skills in the required area. The company pays for the exam and preparation materials. For the company itself, in addition to developing the skills of employees, the availability of certificates can be beneficial at the pre-sale stage of new projects.
Having this kind of planning and grading system helps the process of developing people in the team. True, here we must remember that the plan does not always coincide with the fact and sometimes you need to make adjustments in the process. If an employee was planned to develop according to AWS, but in fact he did not receive the necessary practice due to the need to work on a project with a different technical stack, then you need to redefine the goals, and not cling to them.
At the time of this writing, I have been working as a team leader for a year and a half, and the number of people in my team has grown from 1 to 4. In the article, I described my experience and the path I have traveled. What are my impressions of working in this role?
In the introduction, I wrote that initially I had no aspirations for management, seeing myself exclusively as a techie. Now I am happy with this career development. It turned out to be interesting for me to organize the work of the department, coordinate, develop people and other management processes. I got interesting experience and knowledge, and the opportunity to see a lot of work from a different angle. All this greatly strengthened me as a specialist and will not lose relevance, even if I decide to leave management for engineers.
There are nuances to which you need to be prepared. Firstly, the team leader slows down his own technical development, you need to balance between management and completing tasks on projects. I try to give myself 1-2 days a week without meetings to focus on technical tasks. Secondly, the transition to this role means new responsibilities, complexities and challenges. If earlier I was worried only about my work, development and results, now I am responsible for the whole team. You need to pass through yourself the problems that arise in the department as a whole or in a particular employee and deal with them.
So, I told my story of transition to the role of a team leader, shared my experience of learning a new profession, building a team and implementing various processes in a new department. I plan to further develop my skills. As a source of information, I will use the Manager Tools podcast from the authors of The Effective Manager book, which I mentioned earlier. I have already started my acquaintance with the Basic series of podcasts, which allow you to consolidate and slightly deepen the information from the book, and then move on to the main podcast.