One of the best managers I ever worked under as a network engineer had a knack for helping me understand which projects and tasks were important to the business, and which were not. I was working for a medical manufacturing company, and during team meetings, we would hear, “Upper management is putting a focus on this project. Let’s talk about the rumors … now let’s talk about what’s real.”
Following those discussions, Richard would start divvying out project assignments to meet the business goals. This management method has some fantastic benefits for individual contributors:
- It points the team towards a common goal. Most network engineers want to be proud of the work they do and have it contribute to the business. When direct‑line managers can help separate the wheat from the chaff, work requirements become sharply focused and job satisfaction improves.
- It helps NetOps team members focus on the higher priorities. If your company is anything like most, your network engineers get a lot of “drive‑bys” from other departments – project managers, help desk technicians, and systems engineers stopping by their cubes with a “quick question.” If team members don’t fully understand what’s a priority for the business, they might be tempted to stop what they’re doing and help, not matter how busy they are. In other words, everyone else’s project gets completed on time, and your team has to work overtime to make sure their own projects aren’t late.
It’s this reality that drives home the importance of managing your most important asset – your people. Managers need to put bumpers around their staff to shield them from distractions that keep them from focusing on the most pressing needs of the business. IT professionals have a big set of responsibilities: day-to-day operational support, project work, on‑call duty, and professional development. If your team is consistently putting in 45–50 hours per week taking care of the business, they have no time for professional development. For a successful manager, it’s unacceptable to ask your staff to learn new technology on their own time.
Keeping Up with Technology
It should come as no surprise that all businesses, small and large, are becoming technology‑based organizations. The small restaurant that used to have a 150‑person occupancy is no longer able to operate at that level because of COVID‑19. “Curbside pick‑up” is now a popular option that requires new systems to take orders, collect the tab, get the order in front of the cooks, and send alerts when customers arrive to pick up their meals.
To be a good NetOps manager, you don’t need to be an expert in network technology, but you do need to understand the fundamentals. One of the toughest positions I’ve held was with a manager who knew systems but not network technologies. Most of my time was spent teaching him network basics before I could tell him how a design would meet business requirements.
As business rapidly evolves, technology needs to adapt to support the new needs. In the same way that technologists keep up with the bits and bytes, managers must understand the technical jargon and fundamentals of the new landscape.
Let’s circle back to the restaurant example.
If your team is assigned a project to develop the infrastructure giving the restaurant the ability to fulfill online orders, engineers will think in terms of APIs, authentication, analytics, and security. The manager’s concern is support, availability, ease of use, and cost. These are two sides of a coin in network and system design.
If you don’t know anything about software architectures or products like API gateways, controllers, and load balancers, you can’t keep your engineers focused on designing and building a quality product. You also can’t to translate the tech for the C‑suite so they can make informed decisions.
What To Do?
So there are two basic questions:
- How do you make sure your direct reports have time to do their high‑priority work?
- How do you stay abreast of the changing technological landscape?
Your mileage will vary, but there are things you can do.
Solving the first question is more problematic than it sounds. In many organizations, request for help via the “drive‑by” method rather than a service desk ticket is the norm rather than the exception. This is a cultural challenge you have to navigate.
One option is to empower your employees to say “no” but tell you about the requests. This gives you visibility into the demands on your team, enabling you to ask questions about business priorities, track the changing needs of other groups, and determine whether you’re understaffed. It also gives you an opportunity to discuss your peers’ technical needs with them, which helps you to prioritize project work. Enabling your employees to say no shows them you respect their judgment about which goals are important and want them to have a healthy work‑life balance.
Unfortunately, this type of organic change takes time. You need buy‑in from others in the organization to make major changes. It is still an important change to make if you find yourself in this type of environment.
The second issue demands your personal commitment. Just as technologists read whitepapers and pursue industry certificates, you must also commit yourself to learning. Remember that you don’t need to do an engineer’s job, but you do need to communicate effectively with them. Finding resources at the right level of detail can be tricky. Where can you find them? What do you look for?
If you’re in a web services quandary, there are some good resources to help you along. I suggest beginning with NGINX’s Learning pages about load balancing, service mesh, and API gateway. Each of these links has short videos and other resources to help you improve your understanding. Another good read is the Microservices Reference Architecture. It’s perhaps a bit technical deep from a manager’s point of view, but you can start to understand how all the pieces of the puzzle fit together. It is the insight you need to help your technical staff achieve business goals.
None of the ideas presented here are new, but many times we can get lost in the weeds and forget the basics. Managing is a difficult balance between knowing enough about what your reports do and staying out of the way to let them succeed. I hope this article has provided some resources to help you meet the challenges facing today’s network engineering manager.
