- Leadership doesn’t understand your jargon and they don’t need to. I’ve heard many network engineers decry the intelligence of their leadership because management doesn't know the difference between an ARP table and a MAC address table. This line of thinking is silly. Management’s role is to understand the business, build a healthy organization, manage teams effectively, and provide resources to accomplish business goals. Some degree of technical knowledge is helpful for front-line management, but the higher in the organization an individual is, the less detail they will need know about each technical arena. This is as it should be. It’s your job to know the difference between an ARP table and a MAC address table and to summarize technical detail into actionable information.
- Management doesn’t always know the exact right question to ask. I once had a manager describe a colleague as an individual who would provide only data, never analysis. My boss felt as though he had to ask 30 questions to get a handle on the technical situation. My colleague thought his sole responsibility was to answer the question precisely as asked — regardless of the value of that answer. Don’t be that guy or gal. Listen carefully and try to understand what you manager wants to know instead of parsing their words precisely. Answer their question, then offer insight that you believe will help them do their job better. Be brief, summarize, don’t include so much technical detail that they check out before you get to the punchline.
- Effective communication is an art, more than a science. At the end of the day, great communication happens in the context of strong professional relationships. You don’t have to be best friends with your manager and you don’t need to spend time with them outside of the office. However, you should work hard — as much as it depends on you — to build trust and direct, respectful communication channels with your leadership. Don’t dig in your heels unnecessarily. Give when you can and hold firm when you must. If you develop a reputation as a team player, your objections will be taken more seriously when you must voice them.
Communication: The Network Engineer's Secret Weapon
February 16, 2018
Networks
Most network engineers enter the profession because we enjoy fixing things. We like to understand how technology works. We thrive when digging into a subject matter with focus and intensity. We love protocols, acronyms, features, and esoteric details that make sense only to a small group of peers. Within the ranks of fellow geeks, our technical vernacular becomes badge of honor. However, outside of our technical peers, we struggle to communicate effectively.
Our organizations rely on technology to make the business run. But the deeper we get technically, the wider the communication gap between IT and business leadership becomes. We must learn to bridge the gap between technology and business to deliver the right solutions.
I was reminded of this communication disparity when working on a circuit outage recently. While combing through logs and reviewing interface statics, a senior director asked for a status update. I told him, “We lost BGP on our internet circuits." He responded with a blank stare. I had failed to shift my communication style and provided zero helpful information to my leadership. I changed my approach and summarized that we lost the logical peering with our provider. Although the physical circuit appeared to be up, we could not send internet traffic because we were no longer receiving routing information from them. My second response, though less precise, provided an understandable picture to my senior leadership and satisfied his question. He had more confidence that I knew where the problem was and it helped him understand what the escalation point should be.
When communicating with leadership about technical projects and problems remember these things.
