You can find a lot of information online about becoming a manager, a team leader and on how to organize the work of an IT department. There are books, articles, webinars, conference presentations and talks on that topic. Some resources cover general managerial practices, others talk about the intricacies of specific IT departments — primarily development. In this article, I will share my personal journey of transitioning into the team leader role and managing a DevOps department.

A quick self-introduction and a couple of words about our department and the company. I have been in the DevOps field since 2019. Started as an engineer at Loovatech, and by the end of 2021 I progressed into the role of a team leader. There are five people in our department, we work as a distributed team, all operating remotely. The company has just over 40 employees, primarily focusing on custom software development, mostly web and mobile applications, and separately — DevOps services. So our department not only provides in-house services but also collaborates on projects with customers that maintain their own development teams.

To start, I will discuss my adventure of learning management basics, and how the team and the department came to be. In the end I will share my thoughts on the pros and cons of this role.

I believe this article could be useful to a new team leader overseeing a small department. Feel free to join the conversation and share your insights in the comments after reading this.

The department creation and my transition into management 

In the early days of the company, like in many other areas, the company’s technical director handled the DevOps direction, hired engineers, coordinated their activities and task assignments. As the company grew, the need for delegating management and separating the team into departments became evident, including DevOps.

In early 2021, we worked on a major project for delivering DevOps services. At that time, I was the sole DevOps engineer in the company, and we established that we needed to scale up. For that we decided to bring in a junior specialist to help share the workload and free me up for the new project. I participated actively in the recruitment process, such as drafting requirements, reviewing responses, and conducting interviews. This experience proved invaluable when I later took the role of team lead and had to handle these tasks myself.

The company hired a junior engineer, and at that point my assumption was that I would become her mentor, training and delegating. But the bosses proposed that I become a full time manager, which meant overseeing all aspects of operation and communication, along with responsibility for the employee’s effectiveness and development. I distinctly recall that at the time I had no intention of venturing into this role. My primary focus was on developing my technical skills. After some consideration, I decided not to turn down the opportunity to test my abilities. I am aware that many engineers may not aspire to become team leads, saying that they either do not want that, or do not see themselves as managers. Nevertheless, it is always worth evaluating such a proposal. One can always return to one’s previous role, and the gained experience will be worthwhile.

So I started managing our new employee while learning through various resources and receiving feedback and guidance directly from my direct manager. I cannot say it was simple. It required new knowledge, developing new qualities, and a great deal of self-reflection. However, I felt excited and that I was progressing in the right direction.

By the end of 2021, our project workload doubled, and it became clear that we needed to hire additional DevOps engineers. The management decided to establish a dedicated DevOps department and appointed me as its head. I will share my experiences on how I structured the department’s operations, introduced best practices, and used various resources to enhance my management skills.

Management training

Right away, I realized that management was not just an additional responsibility but an entirely separate profession that I was unfamiliar with and that I needed to grasp at least its basics. Books became my primary source of knowledge. They gave me basic understanding of the role and taught me specific practices like one-on-one meetings, feedback, delegation, and such. I will not list all the books I read, but will mention the ones that were most helpful.

• The Effective Manager by Mark Horstman. Written by one of the creators of the Manager Tools podcast, the book provides a solid foundation in management concepts and offers practical guidance — i.e. tools — essential practices, from one-on-one meetings to coaching. This is the guide for mastering management from scratch.

• The Practice of System and Network Administration, 2nd Edition, T. Limoncelli. This book centers on practices and principles of system administration, with a chapter dedicated to management. This book specifically addresses management of a technical department and offers recommendations on department organization, hiring, and operation. While primarily focused on classical system administration much of the information remains relevant to any technical department. There is a newer book called “Practice of Cloud System Administration, The: DevOps and SRE Practices for Web Services” by Mr. Limoncelli, but the information in the original book is very solid, and it is considered by some to be “the first DevOps book”.

• On Writing Well, William Zinsser. The book may not be about management, but it addresses a crucial skill for any manager: writing. Managers often need to craft their messages swiftly and efficiently:announcements, letters, policies, various documents, memos. I turned to this book while working on my first article for Medium, and it improved my writing skills which were initially quite weak, and by a lot. It is worth noting that this book focuses on non-fiction writing and does not cover business correspondence.

Learning from my colleagues and their experiences was also very important. During the initial stages, I regularly talked about the process with my supervisor and asked for feedback and insights. When faced with challenging situations, I had the chance to seek guidance, get different views, and ask for recommendations for my next steps.

The team

Currently our team is made up of five members including myself. Three work full-time, and the other two work part-time. Here are some insights into our approach.

Right now we emphasize recruiting junior engineers, and invest in their development, their career within the department. We also hire seasoned professionals, mainly part-time or temporarily, both as engineers and consultants.

I am aware that people have different opinions in regard to hiring junior specialists. I will explain our rationale for this.

Hiring a junior not only holds promise but delivers tangible benefits right from the first months. A junior team member progressively lightens the workload for their colleagues by taking on responsibilities like requests and incidents, basic server configurations, internal infrastructure, releases, documentation, and more. Naturally, we consider project complexity and seek candidates with relevant backgrounds. In terms of technical skills, I look for candidates with at least a year of experience in Linux system administration, proven ability to automate tasks through scripting or Ansible, and a solid understanding of Docker basics.

Having a junior on the team contributes to its long-term strength. They grow steadily, gaining theoretical knowledge and practical skills while tackling progressively complex projects. I explain our employee development practices in the “Employee development plan and grading system” section of the article. This quickly produces a technically skilled engineer who knows our projects well and fits into our company culture and work principles. In a competitive engineering job market, growing our own specialists is an effective strategy for building a strong team.

However I should acknowledge that this approach requires a considerable commitment from both the manager and senior colleagues for training and mentorship. Also as the team’s workload increases, team expansion could not be rapid enough.

How do we compensate for potential expertise gaps? With our experienced engineers, typically hired on a part-time basis. They are often engaged in projects with lighter workloads or, in the case of major projects with resource shortages or specific tool and technology knowledge. They provide valuable support. On some occasions, we also enlist professionals as consultants. The experts help in solution design, guide the engineer's actions, and offer advice on potential challenges.

However, finding the right fit for part-time roles can, too, be a bit of a challenge. The perfect candidate manages time well, works independently, has strong skills in the necessary area, and is motivated to tackle new projects. However, it is important to consider potential risks: their primary job will come first, and during busy times, they may need to temporarily reduce their involvement in our projects.

To summarize, our current team building strategy revolves around recruiting and nurturing junior engineers, as well as bringing in experienced consultants and engineers in temporary or part-time roles. This approach has proven effective for us and delivers tangible results. However, I recognize that this strategy may not be a one-size-fits-all solution for every company. It should align with the company’s projects, its capabilities, and the unique aspects of its operations. As our project count continues to rise, we anticipate that we will be hiring more experienced professionals on a full-time basis.

Team communications 

We have established a fully remote team, scattered across different cities, with no physical in-person interactions. However, I have managed to incorporate some elements of traditional office work, such as meetings in a conference room, casual water cooler chats, and impromptu brainstorming sessions for new ideas. In a fully remote setup, communication among team members tends to suffer, which requires special attention.

I have regular weekly one-on-one meetings with each team member. These sessions last for half an hour and are aimed at building relationships and refining our work processes. I generally follow the O3 techniques mentioned in Horstman’s book, which involve dedicating 10 minutes to the employee, 10 minutes to the manager, and 10 minutes to discussing development and growth.

In the beginning, I conducted hour-long meetings instead of the recommended 30 minutes. This was because in a remote work setting we needed more communication. As a technical lead, these meetings involve discussing technical issues, providing assistance, and coaching, especially when meeting with junior team members. In this context, coaching — monitoring an employee’s technical skill development — sometimes transformed into direct training.

But over time, I found that that was not as effective as I initially thought. Trying to discuss everything during an hour-long meeting led to a lack of focus. So I made adjustments to the process and discovered that half an hour was indeed sufficient to cover what was necessary without getting into excessive details. If we needed to discuss specific tasks or related issues, we scheduled separate mini-calls or addressed them during our standing team meetings. These changes ended up saving time for both my directs and me.

We have weekly department-wide calls that last for an hour. The goal is to encourage communication among our engineers, helping them to learn more about each other, exchange experiences, and discuss new work ideas. At first, we held these meetings every two weeks, but we switched to a weekly schedule after updating the one-on-one calls.

Most of our work communication happens through messages in Slack. However, there are times when it is more efficient and appropriate to pause the chat and have a voice discussion. I do not hesitate to make quick calls, and Slack offers a handy feature for this called Huddle. Also, I encourage more screen sharing. In a remote setting, we cannot peer over each other’s shoulders to share advice like we would in an office. Observing how a colleague works leads to helpful comments or recommendations.

Processing requests and scheduling tasks

For a while, we did not have a formal resource planning system or clear rules for managing tasks and requests in the department. It was not a big deal right away, but as our projects and team size grew, we needed to make some changes.

My first goal was to streamline how we handle requests from colleagues. Our current method of using personal messages and threads was not allowing us to effectively plan and organize tasks and requests. So we increased our use of Jira for managing requests and shifted our day-to-day communications to a dedicated Slack channel called #infrastructure and project-specific channels. Tasks are assigned by either me or the project managers, and we use a kanban board for better task visualization and planning.

The company now has a regular resource planning meeting. Every Monday, project managers and department heads take part in a call where we plan workload and allocate team members to projects. We use the Runn.io service for this planning, and employees track their work hours with Hubstaff. This helps us compare actual project time with the planned allocation. Resource planning helps us assign team members, set task priorities, and meet project deadlines and budgets. It also allows us to anticipate potential staffing shortages, manage workloads, and account for employee vacations. Runn.io also provides visualizations for tracking vacation schedules.

Department 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 create internal policies for our department. We documented in our Confluence all the information and rules that were previously communicated verbally.

These policies cover various aspects, including how we handle incidents and requests, responsibilities, duties, payment for overtime, benefits programs, and other organizational details within the department and the company as a whole.

Our infrastructure policies outline what to do when deploying infrastructure and running applications, along with the underlying reasons and principles. They generally do not get into technical specifics. Instead, they encompass a range of practices, from naming resources to approaches to monitoring and documenting infrastructure.

These policies have streamlined the onboarding process for new team members and serve as a helpful reminder and checklist for the entire team. All the essential information is now consolidated in one place, which eliminates the need to start from scratch each time. It is essential to dedicate time to keeping these materials updated.

Employee development plan and grading system

Every employee has a personalized yearly development plan. The plan is collaboratively created by the manager and the employee. Generally, it consists of two milestones, one for the first half and another for the second half of the year. After each milestone, we hold a meeting to evaluate the results. My role is to design a plan that helps with the employee’s skill development and professional growth. Beyond creating the plan, I also support it by assigning relevant tasks and projects for the employee to work on.

The plan is a short document with specific goals and deadlines. For instance, it might include objectives like earning a particular certificate before 1st of October, or showcasing a skill on a project with positive feedback from both the project manager and myself. This way each goal in the plan is measurable and time-bound.

Our grading system outlines the skills and experience required for an engineer to advance within their role. And, of course, the development plan aligns with this grading system. Currently, our DevOps engineers are categorized into junior, pre-middle, middle, and senior grades.

At the middle-grade level, we have certification. Currently, engineers can choose from exams like AWS and Kubernetes (CKA). The specific certification direction is decided through a discussion with the employee based on the engineer’s projects or the expertise we want to create within the team. Certification is a valuable way to develop and validate skills in a specific area. The company covers the exam cost and provides resources for studying. For the company, having certified employees is beneficial during the presale stage of new projects.

Our planning and grading system facilitates the development of team members. However, plans may not always align with reality, and adjustments are sometimes necessary. For instance, if an employee was initially slated to develop AWS skills but did not gain the required practice because of a project with a different technical stack, it is essential to adapt and redefine goals rather than clinging to them.

Conclusion

At the time of writing this article, I have been a team leader for a year and a half, and my team has grown from one to four engineers. This article outlines my journey and experiences. So, what do I think now?

Initially, I did not aspire to be a manager, I saw myself purely as a technician. However,I am glad I took that career path. Managing the department, coordinating work, nurturing team growth, and handling various processes is very fulfilling. This experience has enriched my knowledge and provided a different perspective on work. It has strengthened me professionally and it will remain valuable, even if I decide to return to an engineering role. 

Transitioning into the role of a team leader has its downs. For example, my own technical development has slowed down as I now need to balance between management and working on project tasks. To address this I have designated 1-2 days a week without meetings to focus on technical assignments. Besides, the role comes with new responsibilities and difficulties. While I previously only had to concern myself with my own work, development, and results, I am now accountable for the entire team. This means addressing the problems that arise for the department as a whole or for individual team members.

I have shared with you my journey into the team leader role, where I learned a new profession, built a team, and introduced various departmental processes. I am dedicated to further skill development and plan to use the Manager Tools podcast, especially the Basic series, to develop the knowledge I got from the The Effective Manager book.