The Path to Great Relationships Part #2. DevOps Engineer and Project Manager

Insights of collaboration with DevOps engineers on the project

This is the second article in the Path to Great Relationships of Project Manager series, where I interview top notch PMs to get their secrets of searching for perfect team members.

This time we will cover collaboration with DevOps engineers.

My interviewee is Kateryna Lysak, who has been working in IT for 6 years, including 2 years at SoftServe. She has a Ph.D. in Psychology and pays a lot of attention to support mental wellbeing at the company by running together with HR BPs the talk show “Wanna Talk About It”, as well as groups for managers dedicated to this topic.

During Kateryna’s career at SoftServe, she had a chance to work with 4 accounts of DevOps projects with different specifications — support, base migration, infrastructure migration from on-prem to cloud, and development of new infrastructure elements in the cloud. She had worked with teams of 1 to 8 engineers.

In this article I will guide you through the insights Kateryna shared with me during our captivating talk.

The main thing to pay attention to while looking for DevOps engineer

From my standpoint, the project type is more crucial than required technologies, clouds, and automation tools. There are three main project types. Let’s go through peculiarities of each of them:

Support projects. It implies working with existing infrastructure — minor migration, development inside the system, or support only.

While looking for the team players, I focus on the following points:

• Experience with the required tools and stack is a must. However, I don’t demand 100% knowledge of exact instruments, since instruments of different clouds can be similar. Sometimes, a person with considerable GCP experience can quickly learn a specific AWS tool. That is not always the case though, and there might be significant differences between specific tools.
• Communication skills. Often, customers need our engineers to become part of their internal team. Therefore, the success depends on the team integration. That’s why I am looking for team members who can establish effective communication with the client. It is fairly common that we don’t have clear requirements from the start, that’s why the team should be proactive here. In case the team already exists on the client side, knowledge sharing is a matter that requires a lot of effort and should be done properly. One could also come across a stereotype about DevOps being “unfriendly bearded men”. Can’t say that I totally support it, but majority of those guys are really introverted, so it is important to understand if they are willing to communicate a lot.

Currently, I’m managing the following project type. One DevOps from my team is integrated into the client team. He had a goal to learn the system that existed for years, which demands learning and finding out a great deal of information. It was possible to achieve that goal only with proactiveness in communicating with the developers on the client side.

That is the reason why I ask during the interview if the candidate had such experience previously or how he will behave in such an environment.

Infrastructure solution from scratch. Within this type of project the client wants us to build infrastructure from scratch or to migrate between clouds or from on-premises to cloud. I wouldn’t say that this type of project is harder to tackle, it is just different. While staffing I pay attention to the following:

• Ability to anticipate the best solution. Our goal is to show expertise and propose the right solution. That’s why my team members should be able to see the big picture and analyze what works best for the client business.
• Willingness to build trusted relationships with the client. Communication is important here too, but with a particular goal. Imagine the client has the existing system, everything works, business is going on. Of course, it is scary to make changes. Everything can happen along the way. That’s why our experts should be able to explain the anticipated plan in simple words and provide the necessary support.
• Purposefulness. Basic advice, but it means that person can set up certain goal for our project and make everything possible to achieve it.

Development team. The client wants us to develop a system or an app. In this case I am looking for a person with the following skills:

• Ability to cover the manager role from a tech perspective. I think, in this case, DevOps Engineers acts as the orchestrator of the teams. Release Schedule, backup plan to avoid system crashes — these are two of the big list of activities DevOps covers. Role in such a team is a fine line between leading and providing support to development teams.
• Willingness to find the team needs. And again, communication, now with the teammates — managers, BAs, QAs, developers, etc. DevOps should understand the requirements and problems the teams with different functions might come across to offer the best service from their side.

In general, during an interview, I find out about how the particular candidate can communicate the specific need and the ability to learn new technologies. The list of skills for DevOps is comprehensive, with lots of postscripts, like the Mendeleev table. One is not supposed to know everything but should be able to learn and be motivated to do it.

Experience with Junior staff or Why people skills matter

Let me share one case that occurred with a novice engineer and describes how crucial soft skills for DevOps are (actually, for all the software engineers, not just DevOps).

Around two years ago, there was a need to extend the existing team, so I conducted few interviews. The candidate I chose had hands-on experience with similar tasks, so I was sure he would perform fine. But what came as a surprise was his communication skills to become a key to the project success.

With a positive and calm attitude, he managed to explain everything to the client in simple words, repeating the same info several times if needed. The client was satisfied with such performance and even prolonged the contract for several months to keep this Junior DevOps (alone!) for further support.

Based on my experience, I can highlight the next great soft skills, that, of course, apply not only to DevOps guys:

• Curiosity. It guarantees that developers will effectively deal with tasks and obstacles on their way. Sometimes the solution does not lie the surface, so DevOps engineers should look through a substantial amount of data to find the needed answers.
• Desire to try something new. First, this helps the developer to adjust career path. Experiments with different stacks could help to find the right direction for future development. Second, this shows if the engineer is open to self-education. It is a proper approach before becoming an expert in the specific stack, for example, with one cloud. DevOps knowledge area is constantly developing; therefore, engineers should never stop learning to keep up with progress.
• Communication. I would say, with all stakeholders — team members, managers, and clients.

Novice engineers should never be afraid to ask senior colleagues for help.

What about motivation?

Most of DevOps Engineers prefer to minimize activities. Therefore, their target is to do less with more significant impact.

So how to motivate them to develop professionally? My option is to suggest learning new technologies to help optimize some work on the project. If it doesn’t work, I would set up goals with milestones in any area that engineers would like to dive into. By keeping people interested in what they do managers can effectively work with their motivation.

Quite popular are the projects facing a challenge to build infrastructure from scratch. Not every DevOps wants to be a part of it, but often, are looking for such a big challenge.

When offering the project or even on later stages it is important to show that the person not only performs various tasks, but also is the part of a bigger goal. PM should be able to describe the business of the client and the impact of the i.e., migration in relation to client business, what issues it can solve or opportunities it may open.

Fighting burnout effectively

A big amount of infrastructure projects I worked on did not last for a long time. However, the reason for that most of the time wasn’t the burnout of engineers. We had work to do, we did a release, and were open to new assignments. It doesn’t mean that the longer the project lasts, the bigger risk for team burnout is. I think it is about changes that help fighting the routine. The DevOps position is quite dynamic — they often move through the projects, learn new technologies, etc. Even if we are talking about project with long-term assignment, additional requirements and tasks could save the situation. Needless to say, it depends on the particular person, since some people are, on the contrary, into doing stable work.

My latest project lasted for a year and based on that experience I would like to share my thoughts on the best approaches to fighting burnout:

• To talk. Yes, quite simple, but I always start to there.
• To offer new responsibilities or task ownership. If your engineer wants to develop as a leader, this will be a right step to start with.
• To show the meaning of the work. I always try to communicate to people that they don’t only perform tasks but are a part of a bigger picture. I usually go with describing the business of the customer or, depending on situation, we can dig into the impact of our work together with DevOps — what issues it can solve or opportunities it may open, or what parts of the client business we affect.
• To support career development. Certifications, courses, books — anything I can be of help with.
• To offer an extension of DevOps career or a career change. Sometimes, we decide with guys that they are eager to change the clouds they work with or change the project type. In this case, we plan together the rotation that will make the person happier.

I don’t think that DevOps engineers are more prone to burnout than other developers. As I mentioned above, the DevOps area is relevant to modern needs and is permanently developing. Such conditions help managers to motivate employees by creating an area for the professional development of engineers.

We will continue talking about cooperation of PM with colleagues in our next articles. Here you can check the previous post about relationships with Technical Leads.