Bootstrapping Network Automation: The Talent Equation
The following blog post summarizes insights from a recent discussion among Network Automation Forum (NAF) community members about the challenges organizations face when building effective network automation capabilities. These perspectives represent the opinions and experiences of community members rather than industry-wide consensus.
The Gap Between Technical Skills and Architecture
A central theme in the conversation was the distinction between technical troubleshooting skills and architectural thinking. As one community member noted, organizations often promote individuals who excel at specific technologies (BGP, EIGRP, EVPN) to architectural roles without considering whether they possess the broader systems thinking required for success.
This creates a fundamental challenge: technical depth (the long part of the "T") doesn't necessarily translate to the breadth of knowledge (the wide part) needed for effective architecture.
The Chicken and Egg Problem
Organizations starting their automation journey face a difficult question: where to begin? Community members identified several common approaches, each with limitations:
Rely on network engineers with some coding knowledge to "figure it out"
Hire dedicated software developers and hope they can understand networking problems
Engage professional services for implementation (often expensive and requires internal oversight)
As one participant put it, finding "this true Network Automation Architect off the street" who can handle both technical implementation and organizational influence is extremely difficult.
The Team Composition Dilemma
The conversation highlighted two primary workforce models:
"Coders who network" - Software developers who need to learn networking concepts
"Networkers who code" - Network engineers who develop software skills
Both approaches present challenges. Software developers may lack deep networking domain knowledge, while network engineers might struggle with software design principles if not given adequate time and resources to develop those skills.
Organizational Commitment
A recurring theme was the need for dedicated resources. As one community member stated: "my impression is a lot of orgs aren't even dedicating at least one engineer to automation, I see so many NetEng roles where automation has just become an expectation."
This lack of dedicated focus often results in sub-optimal implementation. As another participant observed: "the worst automation comes from engineers whose primary responsibilities in their roles is not automation" - not due to capability issues but because of competing priorities.
Professional Services Considerations
The group discussed the pros and cons of using professional services versus developing internal capabilities:
Cons:
Higher costs compared to internal development
Requires internal time to oversee implementation and provide feedback
Pros:
Can help implement change when internal resistance exists
Provides specialized expertise for specific projects
A key insight from the discussion was that many engineers struggle to effectively communicate the business case for internal development versus external services, allowing professional services firms to better position their offerings to leadership.
The Path Forward
The discussion concluded with a focus on better communication with leadership. As one member summarized: "the bit we need to figure out is asking the uppers 'what are the levers that need to get pulled to do something here?'"
Successful network automation appears to require:
Dedicated resources (ideally multiple roles)
Recognition that specialized skills require time to develop
Collaboration between networking and software expertise
Clear business cases that articulate value beyond technical implementation
Conclusion
Building effective network automation capabilities remains challenging for many organizations. The conversation highlights the importance of investment in both people and processes, rather than expecting existing network teams to simply "add automation" to their current responsibilities without adequate support.
These insights from NAF community members provide valuable perspectives for organizations considering how to approach their network automation journey. Specific contributions to the conversation behind this article came from Mark Prosser, John Howard, Ryan Shaw, and Dan Peachy.
Join us on Slack and jump into the conversation!
