I am often asked, “How do you manage a DevOps team?” This is an interesting question, as it is multifaceted. Are you talking about managing workflow and visibility? Are you talking about how your Project Management must change to take account of short sprints with no logical project endpoint? Reporting on progress to the Senior leadership team regarding work done, optimisation savings, etc? Optimising communication flow across disparately managed teams to lubricate the flow of work through the system? Or are you asking, “How do you start the process in the face of other vested interests vehemently against a change that will directly affect the status quo?” So, you see, it is not as simple a question as you may have thought initially, and the answer is that it all depends on where in your journey you are. Just like a company management style will be different at a start-up phase as opposed to a multi-billion revenue company, your approach to managing your DevOps practice will evolve. This is not even considering the conversation surrounding managing down as opposed to managing up, needs down, and expectations up.
In this article, we will investigate some of the techniques we introduced to ease and lubricate the process changes required to integrate DevOps into my company, together with keeping the flow of work through the system fluid.
Building Team Trust when remotely working
One of the most significant changes in work practices over the last three years was the rise of remote working during the Covid pandemic, followed by a reluctance of staff to return to the office. As somebody who has remotely worked for several years before the pandemic, I understand the hesitation, but for management, it can be tough to “see” work being done; there is a large number of managers that equate work with visibility or a bum on the seat where I can see it. This is especially true when undergoing a process change where workflow visibility is not as transparent. Remote working has indeed enhanced work flexibility “work is something I do, not a place I happen to be”; there now is little or no need to move halfway across a country or continent to carry out your tasks for a large contingent of staff nor the need to be visible in an office; it has also allowed firms to cut costs in terms of reducing office space, especially useful in these time of high energy costs.
Remote working is not going away; therefore, teams must work harder to build a culture between naturally dispersed teams.
Remote working seems counter-productive to DevOps
Remote working seems counter-productive to DevOps because one of the fundamental tenets is smoothing communication flow. Therefore, shouldn’t it be advantageous for a team to be co-located? Yes, however, this is not the reality we now live in. So the question is how to manage a dispersed team, sometimes across time-zones. Here is a five-step approach, that I have found to work.
Have a regular in-person huddle
What wait, I thought you were all for remote working! Why do you want people in the office? With the correct tooling (more on that later), why is this needed? Humans are social animals; often when working remotely and you main communication method is IM messaging, things can easily be taken out of context, this is, even more, risky when your team members are not native language speakers. a face-to-face meeting of the team helps to build relationships.
A team meeting once a month is an excellent method to disseminate information about key strategies, and formulate new pathways to delivering business requirements. But more importantly, it allows you to get to know your team members on a personal level around the water cooler or office kitchen whilst making a cup of tea or coffee. A shared lunch allows conversations to flow outside the boundaries of work into personal and this is where trust and relationships are built.
Invest in the correct tooling to support your team
It is a fact that when the world shut down due to covid, the vast majority of businesses were not ready for the logistical challenge that is remote working. We have been on a massively accelerated learning curve. Before I go into this, I would like to share a story. A team I am involved with has a 100% remote team. That is from the senior manager to the developers; I am not even working in the same country, but this team has, from a standing start, built up a significant pipeline and is delivering real value to the company. The first question is why?
It is all because our team is built on the principle of trust, and we have access to the correct tools to do our work. Our day starts with the huddle, here we outline our day, vocalise any blocker we may have, this allows the teams work to be visualized. We can see and understand what each of the team is doing and understand the flow of work through the system, from the pre-sales team into our TA’s through the build and coding teams and through to the operations team as BAU. As a team, we use mainly SaaS based tooling, M365 including teams, LucidCharts, Azure DevOps, Jira, Confluence, Trello; this reduces the need to be tethered to an office environment whilst being able to collaborate on documents.
Communication is the key.
With remote working, as with DevOps practices, communication is key. Work to flatten the communication path, encourage peer to peer communication across team and departments. Only require upward communication for major decisions or conflicts. Empower your team to make decisions. A common question that is asked in our team is “so what?” at first viewing, this seems a highly condescending question. However, the point is to hone the decision-making process, to make the people consider all options, including for technical people none technical considerations, and to help none technical participants understand the often negative sounding IT view points. “yee, canna break the laws of physics man”
You must have regular meetings, huddles, 1-2-1’s and even a water-cooler moment. These help to build trust and keep people informed and vested.
Make your meetings focused.
The other main point with regular meetings is to keep them focused and, more importantly, short. There is a reason that a stand-up was called a stand-up because originally, it was undertaken stood up. This forced people to focus, as nobody could return to their desks to sit down before the meeting ended. Another facet to this is that meetings require an agenda, and minutes need to be taken and distributed, actions assigned, and commitments documented and followed up. Too many meetings result in a talking shop that wastes time. Or, to coin another phrase, “don’t have meetings for meetings sake”. Finally keep the numbers in a meeting low, too many people in a meeting will result in people hiding, holding back from imputing, or the meeting becomes an exercise in work avoidance. If the core purpose of a meeting is to disperse information, then a large an audience as possible is recommended, but if the purpose of the meeting is to brainstorm. Then it is better to have several small meetings with a subset of the team. This will enable a better flow of ideas. One final piece of information that we learned is, on the rare occasions that you are having an in person meeting that has remote attendees. Do not forget that they are there. When doing round the room introductions get them to speak first; when asking for input, request their input first.
Always be improving
Just like with the DevOps infinity loop that we all know and love, you should always be improving your processes and exploring new and better ways of working, how to manage is also at part of those processes, and is a part becoming more efficient. This, as with everything discussed above, is still a work in progress. Yes there are still managers that want a return to the office, and I can understand that thought process, but remote working, when done correctly with the right amount of focused communication and the right support tooling can and does work.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
