Must Read: Network Engineer Persona

David Gee (whom I finally met in person during recent Summit) published a fantastic series of articles on what someone bringing together networking, development and automation should know and do.

  • Part 1: Evolution of roles and the gaps
  • Part 2: You don’t have to be a developer
  • Part 3: Be agnostic, figure out the requirements, select the right tools
  • Part 4: Understand logging, embrace success and failure, understand the programmatic interfaces

Apart from being an awesome read, it was really nice to see how his conclusions match almost exactly what I’ve been telling attendees in the introductory sections of Building Network Automation Solutions online course.


  1. Hi Ivan,

    To me, this is nothing new. I have been involved in networking and IT long enough to spot re-circulating ideas and the latest fads. Fundamentally we are
    trying to describe a workflow, whether it be using JCL (remember those mainframes) or bash (early UNIX) or ansible/salt (the latest and greatest). It doesn't matter whether
    you come from a UNIX systems admin background or a networking one, you are trying to visualise a series of steps/commands/phases that will get you from start to finish
    for a particular requirement i.e. build me a 3-tier web-app.

    Back in the day (not too long ago) I used TCL and expect as the tools of choice to achieve my aim and they worked pretty well. Today, the choice is python and REST/APIs which you could say
    is a natural progression.

    My main issue is with applicability. Hyperscale companies such as Google and Facebook have significantly different issues to solve compared with your average small to medium
    enterprise, and yet the media dictate that automation is the path to follow in all cases.

    When it comes to development then I agree that advances in virtualisation have enabled development teams to provision target environments quick and on-demand
    and this assists in their efforts to be agile, however, once that application is released into production, the networking element becomes pretty much static
    and adopting an agile/automated approach to networking does not yield any particular benefits in my opinion.

    The main cause of delay to any application roll-out will always be the development effort. The reason networking always seems to be sited as a delay is due to time it takes to include
    the relevant resource in the overall project plan. In my experience, the networking guy is always included at the last minute and then introduces further delay by
    asking pertinent questions that should have been addressed much earlier in the process.

    It is all about communication.

    Is there a role for a network automation engineer in every company, I would say NO. Is there a role for a jack of all trades who understands the company and
    and will apply optimisations as required, I would say YES. What would they be called? Well an infrastructure engineer springs to mind.
    1. Thanks for an exhaustive comment - definitely plenty of interesting thoughts for another blog post or two ;) ... and BTW we're in violent agreement.

      As for "Is there a role for a network automation engineer in every company, I would say NO." I disagree (unless we're talking about really small companies). However, she doesn't have to focus exclusively on network automation, but on getting repetitive things (whatever they are) done consistently, reliably, and eventually faster. Agree? Disagree?

Add comment