Interview – Interview with Packet Pushers Co-founder Ethan Banks

Posted by

Hi Ethan,

Welcome to Networkcareer!

Where do you work and what’s your role?

I am the co-founder of Packet Pushers Interactive. We’re a media company specializing in deep, technical content aimed at engineers. My business partner is the fabulous Greg Ferro. Many folks might know us because of the podcasts we co-host and writing we’ve been doing for over a decade about information technology, especially networking. My role is…complicated. In a small business, you do anything and everything that’s needed. Primarily, I read, research, and plan articles and podcasts about IT infrastructure technologies. You can find out anything else you want to know about me via ethancbanks.com.

What kind of roles and work did you do before arriving at Packet Pushers?

If I oversimplify my IT career, I can say that I spent twenty years building data centers for enterprises. That’s a bit of a generalization, as data centers weren’t really a thing for many enterprises back in the day. It would be more accurate to describe some of those early data centers as “the place where all the wires ended up, so that’s where we stuck the servers” or “the super dusty closet with no ventilation but it was the only space we could spare.” Somehow, that seemed to involve the entryway to the ladies’ room far more often than was comfortable. Ah, the good ol’ days…

But that’s what I did—build data centers. Sometimes that meant a couple of servers for a small company running a manufacturing operation, with a LAN gluing it all together. Sometimes that meant a huge facility with massive diesel generators for backup power and lots of racks spread over lots of square feet. It all depended on where I was in my career and who was employing me at the time.

Of course, there were also campuses and WANs to consider. I worked for different organizations where our network started with a LAN, but then we needed to connect remote offices to get at the systems located at HQ. Thus, I worked on a lot of fiber deployment projects to connect campuses together. I built a goodly share of WANs as well, some national, and some international.

My roles have included lots of things, up and down the ladder. Simple PC support. Highly billable consultant. Network engineer or architect. Technical team leader. Group manager. Server jockey. Security engineer. Data services engineer. Cisco, CheckPoint, Microsoft, Novell (remember them??), Linux, F5, HP, and so on.

I’ve been mostly hands on, where the critical value I brought to the organization was deep technical knowledge. I would train on a product such that I would know exactly what the product could or could not do. If I wasn’t sure, I knew how to find the answer.

Put another way, when problems came up that an organization needed to solve, my job was to bring technology to bear on the answer. Did we have the ability to solve X with technology we already owned? If not, what technology did we need to purchase to solve the problem? When technology decisions were made, I was often the team leader driving projects ahead to bring the new technology from proof-of-concept to production.

What have you learned in your career so far that you would like to tell the younger you?

  1. People matter. Make friends. Mentor. Learn. Tell people you appreciate them. Be thankful. Share what you know. Buy your boss lunch occasionally. You’ll never go wrong helping others, being patient, wording an e-mail kindly, and biting your tongue when you’re feeling nasty.

  2. Don’t be a martyr. Get help when you need it, once you’ve done what you can to figure it out for yourself. If you try to carry the world on your shoulders, your back will eventually break. Stop trying to do it all alone.

  3. Take time for yourself. Working hard can help you reach your goals, but make sure reaching your goals doesn’t come at the expense of your own well-being. For high performers, a career in tech is stressful, and some people eat, drink, or party hard to mitigate the stress. Don’t live in a world of extremes, i.e. working hard and playing hard. Live in a world of balance that allows you to maintain your mental and physical health. No cert, bonus, or promotion ends up being worth overextension.

  4. Match your job to your personality. If your only path to more money is to be a manager, but you’re not the managerial type, then don’t be a manager. The extra money will not be worth it.

  5. Learn fundamentals. Specific technology products come and go, but the fundamentals change far less often. If you get a handle on fundamentals, you can often apply them to any new technology and quickly make sense of it.

What are the most important skills you have picked up in your career so far?

By far, the most important skill I have picked up is the ability to listen. Listening in my context means that I’m quietly focused on what another is saying, and asking them clarifying questions when something they explain to me is unclear. In technology, you must listen in order to…

  1. Understand a problem someone is experiencing. They might not have the words you need to hear to immediately diagnose what’s happening. All they have is a user experience from their own point of view. But therein lies details that will help you get the root of the problem more quickly. Only if you listen do you get the nuance and find the details to zoom in on that can help bring a technical issue to a resolution.

  2. Understand a business challenge that technology might be able to solve. When in an architect or designer role, listening is the biggest part of a technology plan. Unless you clearly understand the problem that you’re trying to solve, it is not possible to present the best likely technology solution to that challenge.

  3. Understand what a new technology can actually do. Technologists hear podcasts, webinars, and sales engineers about what tech does. But unless you truly listen, you tend to hear what you want to hear, and miss the caveats and gotchas that might majorly impact your use case.

What’s your opinion on degrees? Are they useful for someone in the networking industry?

I have strongly mixed feelings about degrees. 1. College and university can be incredibly expensive in America, and I am highly skeptical of the dollar value conferred on a degree, broadly speaking. On the other hand, some companies require a college degree before considering a candidate for an open position. This is a frustrating dilemma for students. Undergraduate degrees are also stepping stones to master’s degrees. A master’s degree can be a major career stepping stone.

  1. A college with an excellent computer science program will teach the theory behind major concepts found in practical information technology. These fundamentals seem to be missing from many CS programs, as some of the grads coming from them don’t seem to grasp distributed computing theory, programming principles, and so on. In reviewing the required courses of a variety of compsci programs lately, they seem mostly geared towards teaching specific vendor product skills such as Cisco and Microsoft, programming languages, and hot job skills like web design. I don’t generally see programs teaching technology theory, so I am skeptical of the value these expensive degrees bring. A self-disciplined person can gain product and programming skills and go to market with them without enrolling in a degree program. Technology skills can monetized–don’t get me wrong–but I think a technology degree must bring more than just temporal technology skills to the table.

  2. Caveats I mention above aside, for networkers specifically, I think a broad information technology or computer science degree is useful. In life, understanding how businesses function and how applications work is critical to understand whether a network is doing its job or not. How is the business impacted when the networking is performing well? Or poorly? How is an application and user experience impacted when the network loses capacity due to a circuit outage and in what ways does this matter? A full degree can help gain the perspective required to accurately answer these sorts of questions.

What about certifications? Are they losing their value?

Certifications have lost their respect, but not their value. Cheating has ruining the credibility that certifications one had, which is a shame. On the other hand, when used as a structured learning tool, certification programs are incredibly valuable. Certification programs cause an individual to chase after knowledge they wouldn’t have otherwise forced themselves to learn.

That said, I am concerned that vendor certification programs are trending of late more towards driving sales and less towards architectural and operational knowledge. Then again, it’s always helpful to remember that from a vendor perspective, certifications are about creating soldiers to help them win the sales wars. Engineers tend to recommend products and solutions they are familiar with. So, none of us working through certs should be surprised when there’s a vendor bias.

Is the skillset of network engineers changing? What skills are important to have in the coming years?

No, not changing. Yes, changing. Both, I believe. Times are changing, yes. The skillset that’s changing is regarding device interaction. We’re being asked to move beyond the CLI and into systematic automation. This allows for rapid, low risk changes, with a reduced chance for human error. At the same time, networkers still must know routing protocols, hardware architectures, capacity planning, encryption, resiliency, troubleshooting, and so on. So no, the skillset isn’t changing, except where it is.

Another way to think about it is that network engineers need to know more technology than ever. We used to go through cycles of knowledge, where some tech would fade out once something new replaced it. Lately, it seems more like old technology never dies, while new technology gets added to the “need to know” list all the time.

The “important skills in the coming years” question is a hard one to answer. Everyone wants a unicorn from the future to deliver them a list of specific skills they are supposed to have so that they can make a pile of money, impress members of the opposite sex, amaze people reading their resumes, etc. The technology industry isn’t that way anymore. THERE ARE NO SURE BETS. There is no reliable certification ladder that you climb to get to a diamond swimming pool at the top.

I think rather than skills that are important, broaden the question. What are skills that are both important and personally interesting? Then push a little further–of those skills that are both important and interesting, which of them will improve your chances of having a job you think you want? When you’ve got your list, plan, and go after those skills.

For me personally, that list includes (in no particular order)…

  1. Public cloud.
  2. Practical automation.
  3. Using APIs.
  4. BGP-EVPN.
  5. Service function chaining.
  6. NFV.
  7. Distributed computing and scale-out architectures.
  8. The problem of data gravity.
  9. Security for ephemeral infrastructures.
  10. Telemetry and analytics.

If you look through that list, not all items are networking-specific skills. That’s an important idea to grasp, as the trend in IT is back towards the generalist. Know something about everything. Be expert in at least a few things. That’s the way it was years ago. When I walked in the door as the consultant, I didn’t just build a LAN. I also had to build the server, the storage, the backup system, the remote access, the Internet connection, the mail server, and so on. The industry is heading back that way, so go after some non-networking skills, too.

What skills are important for Network Architects?

Swagger. You want to walk in a room and have real presence. I mean, people should just KNOW you’ve arrived without even turning their heads. They’ll feel it in their guts. You. Are. HERE. Sunglasses and a leather jacket really do the trick, especially indoors where the florescent light can catch your features just so. Consider carrying around cigarettes, even if you don’t smoke. Just throw the pack on the table before you sit down at a meeting. It’s about authority, really. You gotta just own it, put it out there strong. Wear it proud! These people are about to be blessed with your wisdom, after all.

Wait…um…never mind that. I was thinking of something else…maybe being a pilot. Or cosplaying Bender.

The architect role, as I see it, is an important role as a bridge between business stakeholders and technology professionals. Therefore, they must learn to speak the language of business as effectively as they speak the language of technology.

Another skill for network architects is that of grasping application architecture. Since an enterprise network now encompasses mobile workers, public cloud, global business partners, as well as owned or co-located facilities, the details of an application architecture matter now more than ever to the network architect.

The network architect must understand not just where an app is housed, but also the answers to questions such as…

  1. How is authentication performed, and against which systems?
  2. How is the application data protected when in flight?
  3. If an application has been split into microservices, where are each of the services housed?
  4. When does a transaction time fall below acceptable levels, and how is that measured?
  5. How is the DNS portion of the architecture protected from a DDoS attack?
  6. How will this application be made available via IPv6 to APAC customers?
  7. How long will it take to prime the cloud storage volumes so the production app can be launched? Should we use the Internet, or make a copy and roll a truck?

The challenge of networking is exacerbated by the spread of applications, which in turns spreads the network. The hard perimeter is gone. A network architect must be able to think about these issues deeply, mapping a network architecture to fulfill a business’ performance expectation of an application.

Will the need for networking experts go away? Is it better to be a generalist than an expert?

In my opinion, the long-term requirement for networking expertise depends on the market. The mid-market and SMBs will see networking be automated by integrated IT stacks, like what hyperconvergence brings us. In those cases, an expert will be needed when the system breaks, although I tend to think of that expert as a generalist with some networking chops.

Other markets such as cloud providers, service providers, and hyperscale networks will never lose their need for networking experts. Their application delivery systems are so highly tuned and specialized that they can’t get by without deep networking technologists on staff.

Somewhere in the middle lie large enterprises with big campus LANs and global WANs. Even there, I see the networking expert being someone who has other expertise as well. I just don’t believe that it makes much sense for IT to continue operating in the “throw it over the wall, not my problem,” siloed mentality. The convergence of the IT silos is happening in the form of humans who are multidisciplinary, the so-called full-stack engineer.

What do you think of soft skills? Do we need them in the networking industry? If so, which ones are the most important?

I’ve talked about this earlier, but to reiterate, yes, soft skills matter. Learning to communicate with non-technologists about technology and business needs is the soft skill I believe is the most valuable at this time.

With SDN, orchestration etc. can we throw the “traditional” networking knowledge out the window? Why or why not?

No.

  1. Orchestration systems tend to take forwarding paradigms we’re already familiar with, and use automation to bring a scheme to life that meets an application deployment’s needs. The only thing that’s changed is the way the configuration gets done. When you look behind the curtain, it’s still a layer 3 network with OSPF. Or it’s VLANs. Or it’s ACLs. Etc.
  2. SDN has ended up in the realm of corner cases, or what I like to think of as exception programming. In other words, let the network function as it’s been functioning right along for years. But if you want do something weird with a few flows, let SDN tweak the forwarding tables to handle those weird exceptions. In my opinion, for all the hoopla about SDN and orchestration, it’s amazing just how much has stayed the same when you squint at it for a minute.

Should someone in the networking industry learn to code? Why or why not? What is your language of choice?

Ah, the “learn to code” question. Everyone loves to ask this question. I’ve even asked it myself. However, I now think it’s the wrong question. The root of that question is wondering what skills network engineers need to have if the CLI is no longer the tool of choice for configuration.

Now, one of those answers might be scripting or coding, sure. Certainly, writing your own code is the most versatile tool I can think of to assist with the repeated configuration tasks. But writing your own code is also like someone dumping a huge pile of Lego bricks on the ground and saying, “Take us to Mars!”

I don’t believe that network engineers will need to become full-time developers to accomplish their daily tasks. Writing and maintaining code will become a tool network engineers will likely be able to benefit from. Understanding how developers do their work, maintain code, version code, test code, re-use other people’s code, etc. are also likely to be beneficial. But again, in my view this is more about getting infrastructure configured rather than, “You’re a developer now.”

The function of making infrastructure do what it needs to do in order to meet a business need will still be at the core of what a network engineer does. Coding will just one of the tools that makes that happen.

My language of choice is python. Python has a huge community built around it, several free or cheap training courses available, reams of documentation, a plethora of pre-existing code, many excellent libraries to bolt on, and substantial vendor support.

What’s your best advice for staying updated in the networking industry? How do you stop the sipping from the firehose?

  1. Pick the topics you’re interested in, and focus on them. There is too much going on in technology to be able to keep up with it all, even if you narrow the focus to just networking.
  2. Reduce your social media consumption. Social media feeds will take you in all sorts of directions that might not serve you effectively. Why? Too much is competing for your attention. Yes, you’ll discover lots and lots of content to read about technology if you follow the right companies and accounts, but there will be more than you need, and it will be distracting.
  3. Use an RSS reader like Feedly to curate your own news. Add new feeds from either media organizations, companies, or individual blogs when the content is aimed squarely at your interests. Include a few “stretch” feeds to help you learn about technology you’re interested in, even if it’s not right in your wheelhouse now.
  4. Subscribe to sources that help condense news and technology for you. I recommend following TechFieldDay.com videos on YouTube, and subscribing to the free podcasts and newsletters at PacketPushers.net, of course!

Before we close out. What would you want to give as a final piece of advice to the NC readers?

I’ll offer two thoughts that didn’t fit in above.

1. Get out of the incumbent vendor mindset. Stop buying a bigger version of the thing you bought last time just because it’s easy and someone will sign off on the purchase order due to a familiar brand name.

Networking technology has a lot new to offer since your last refresh cycle if you haven’t had time to pay much attention. Pricing models are changing. Services available are changing. Integration with other parts of the IT stack is changing. Therefore, look hard when considering what to buy next, and then do the tough work of comparing technologies and doing proof of concept testing.

Shake things up, if you have the opportunity. I realize not everyone reading this will have the chance, but if you can, do it.

2. You must look out for you when it comes to your career. If you’re trying to negotiate a better salary or compensation, your best bet is probably going to be leaving the company you’re at. That’s a hard thing to do, but necessary if your goal is to grow in your responsibilities as well as your comp plan.

The organization you work for might love you to pieces and even bring in a sheet cake on your birthday, but if they can’t put their thanks in an envelope, then you have to do what you have to do. AND THAT’S OKAY.

Don’t get mired down by feelings of loyalty to the organization, as by and large, that organization has no loyalty to you. When the time comes for layoffs, they’ll lay you off if they have to. Of course, there are exceptions, and remember my point earlier about people.

Ultimately, you’ll set your own career trajectory by what you choose both to do and not to do. Inaction tends to lead to stagnation. You don’t move because you’re not moving. Only action can move you towards a goal, unless you’re already arrived.

One comment

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax