This article is Part 6 in the 6-part series “The Bulletproof Maintenance Window”. For the rest of the story, see the links at the bottom of the page.
The process of building and executing a change to the network infrastructure, particularly a complex change, presents some excellent opportunities to practice technical leadership. These opportunities are available to all members of the team, regardless of their role. Since the work of networking requires highly specialized and highly perishable skills, the most junior person on a team can lead, if they want to. These opportunities to lead are hidden inside the work of the bulletproof maintenance window.
In this series, I have showcased 5 principles for executing a successful maintenance activity. Here they are again:
Let’s wrap up the series by reviewing these principles and using them to expose the technical leadership opportunities that are available to us.
Get and Communicate Context
The process of asking questions about the maintenance work to be done can bear fruit in some unexpected ways. The act of answering the question can cause someone who has a leadership title to consider the “why” of what they are doing. “Why” is critical to successful execution. If you help a leader to lead better, you are practicing leadership. Anybody can do this – whether they have a formal declared leadership role or not. Sometimes the consequences of a certain design decision will not be apparent until it’s time for execution. If you seek to obtain context before executing the changes, the chances are pretty good that you’ll catch these unintended consequences before they cause an outage. Preventing a train from derailing is surely an act of leadership.
If you are in a formal leadership role, you have to ascertain whether or not those executing the maintenance work understand the context in which it is occurring. Asking them these questions and hearing their answers will facilitate shared understanding. Different organizations and different change management cultures attempt to facilitate these conversations in different ways. But, in the end, if you aspire to provide technical leadership you have to take it upon yourself to make sure that shared understanding is achieved.
Communicating context gives you the chance to signal to your boss and the business “this is what I am doing, and why I am doing it”. In my experience, very few managers have actively obstructed somebody who is taking initiative in this manner. They simply don’t have the time to personally create all of the conversations that need to happen in a successful maintenance activity. Taking responsibility upon yourself for helping others to understand the “why” of your work is a great way to build your leadership muscle.
Plan the Work
While building a runbook, your primary focus should be on the stability of the infrastructure during and after the maintenance window. But there are also opportunities here to build up your peers. Consider building the procedures so that the most junior person on the team could execute them and be successful. Then, follow it up by asking them to do the work with you. People will surprise you with how often they want to be involved. Even if they turn you down, the act of building the procedures to their level of understanding will have raised the quality of those procedures.
The act of reviewing another person’s work puts you on sacred ground. You are tasked with evaluating the effectiveness and safety of the proposed procedures, which represent (hopefully) the best thinking of the person who wrote them. As a reviewer, it’s not your job to try to mold the procedures to your personal preferences, but sometimes the proposed actions will need adjustment. This is an opportunity to lead using persuasion, which is a much more effective tool than fear or force. Your task is to persuade (not command) your peer to consider an alternative approach or sequence of configuration. This act of persuading someone to improve, if done right, will help that person recognize that they are capable of doing better. It has the added benefit of protecting the business from service outages. All of the systems for peer review discussed in Part 3 – Peer Review should be centered around providing a constructive environment in which these peer review conversations can occur.
If you are executing a large and complex change that requires the real-time cooperation of multiple senior contributors, you must be able to plan the work so that a team can execute it. Leading the successful execution of complex changes with highly-qualified peers is, for me, the pinnacle of achievement in network operations.
The networking industry is coming to an inflection point. We are on the verge of having access to all of the tools for validation that our software developer colleagues have. This is going to require us to be far more rigorous than we have been in the past. Using CI/CD, Test-driven development, and other development-focused approaches to building networks and validating their operations feels like a thick brick wall to most of the people running networks right now. But being willing to be one of the first through that wall will put you in a position to lead – somebody has to go there first, and it might as well be you.
When I started this series I thought it would fit under a few headings in a single 1000-word blog post. I’m surprised that I had so much to say about it. As some have noted, this is not a sexy topic. Some of it is downright boring – the business process parts of this, ITIL, and all of that stuff, is about as interesting as reorganizing your sock drawer, at least to me. But there are also a lot of opportunities in the planning and execution of a maintenance window to distinguish yourself as an engineer, as a craftsman, and as a leader. I hope you’ll take those opportunities when you see them.
This article is Part 6 in the 6-part series “Bulletproof Maintenance Windows”. For the rest of the story, check out the following: