Being on the sales side of the business here at Network to Code puts me in a unique space when it comes to understanding why customers initially begin to think about moving forward with network automation and, ultimately, what has kept them (in their minds) from making the jump.
This post will discuss some of the most common thoughts that I’ve come across.

The Top Ten Things Customers Think About When Considering Network Automation

Of the hundreds of clients I have spoken to regarding starting their network automation journey, here are the top ten topics (in no particular order) that seem to be a high priority:

• My network engineers are not programmers
• We have too much work to do to start yet another project
• We do everything internally, and we don’t need assistance
• The knowledge of what has been built will leave with your team
• It is too hard to work across silos in our organization
• I am not interested in eliminating jobs by creating automation
• We cannot afford the tools needed to move forward with automation
• Our environment and workflows are too complex to automate
• There are security and outage risks
• I am in! . . . But I am struggling to get buy-in from my leadership team

I am not here to say that all the above are not valid points when considering changing how your organization deploys, manages, and consumes the network, because they are indeed valid. I am here to have an open discussion about reframing the thoughts around these “blockers.” Stay with me now! I know blockers is a traditionally sales-y word, but in this context and list, I am truly talking about mental blockers that I see leaders struggle to wrap their minds around.

Let’s begin the conversation:

My network engineers are not programmers

You know your team’s current skill set better than anyone else. You also know what you hired your team to do, and my guess is that it was not to perform high-volume/low-value tasks all day. You hire your engineers to do high-level technical work, and your engineers likely came to work for your organization with the promise of opportunities for skill and knowledge advancement. Am I getting warmer?

While your network engineers are not programmers today, what if you opened the door for them to grow their skill set with automation? With the right training courses and partners, your engineers will be able to practice what they have learned in real-time and become network automation engineers before your eyes. Allowing your team to use their knowledge and experience as traditional network engineers paired with new automation skills delivers value back to the business.

We have too much work to do to start yet another project

Starting down the network automation journey should not be considered just another project to accomplish in the year. For example, this journey differs from just a hardware refresh because it shifts how the organization consumes and supports the network. It is important to understand that fact when considering “when is a good time.”

While this shift will not happen overnight, when done with intent, an automated environment will cut down the time to deliver on those traditional annual projects. When you think about the time cost to start this journey and compare it to the time cost of not starting, the decision is simple: starting somewhere is always better than not starting at all.

We do everything internally and do not need assistance

Doing work internally is great if you have the time and resources to do so. However, many clients come to me with a similar mentality and ultimately choose Network to Code as their partner due to resource constraints. I don’t need to tell you that the business is often asking IT teams to do more with less in today’s world.

The knowledge of what has been built will leave with your team

Our work is not done here at Network to Code until a full knowledge transfer of what has been built is complete. On top of this, our goal is never to develop anything in a black box. Instead, we maintain full transparency and work alongside your team to deliver workflow automation to your environment. For example, we often offer “office hours” with our network automation experts where your team can jump on a call and work through questions or gaps in understanding as we progress through the project. This is just one way we prove that we are here to truly be a partner in the automation journey and not just a vendor.

It is too hard to work across silos in our organization

You do not necessarily need to work across the silos of your organizations to start your network automation journey. Starting small with the tools and workflows your team is responsible for is a great way to show value to the other silos of your organization. As they see the good work you are able to do, the walls between the silos will begin to come down, and you will be tackling automating workflows across silos in no time!

I am not interested in eliminating jobs by creating automation

Automation is not here to take jobs away from your team. On the contrary, you will likely see employee satisfaction and retention increase when introducing automation into the environment! How? you may ask. What if your employees could apply high-level thinking to engineering work that challenges them? On top of being challenged in their role, what if they no longer needed to do middle-of-the-night maintenance work because the automation is programmed to handle this? They may never leave!

While developing an automated infrastructure will not replace your employees’ jobs, it will change the way they do their jobs. Therefore, it will be important that they receive the proper training to perform their new tasks. For example, rather than managing the network from the CLI, it will now be from the automation environment.

We cannot afford the tools needed to move forward with automation

When building an automation platform, certain components are essential, including a well-understood source of truth and orchestration tools. But that does not mean you need to go back to leadership and ask for budget dollars for yet another tool! The open-source community has come a long way in making these enterprise-grade tools available to anyone, anywhere, for free. Besides avoiding additional costs, open-source tools often allow for more flexibility in building a solution fit for your organization’s unique needs. Additionally, any good workflow automation should lean into the existing tools in your environment and only augment where absolutely necessary. This practice allows for less technical debt and lets you use tools that your engineers and internal customers are already comfortable with.

Our environment and workflows are too complex to automate – it’s too big of an undertaking

Network automation is a journey (I think I have mentioned this a time or two), and it’s important to not try to “boil the ocean”. Start small! Just as you would with any significant effort in your life, you make a plan and start with small pieces until you are where you want to be. With automation, let’s make a flexible roadmap and then start with the low-hanging fruit to deliver those quick wins back to the business. Once the company and engineers reap the benefits of automation, they will be hungry to keep going!

There are security and outage risks

Security and uptime are of the utmost importance to just about every organization. I am here to tell you that automation is not the enemy of security or uptime! Rather, automation can improve upon both.

When you automate specific workflows, you can often pull out the human error margin that exists in any work we do as humans, especially when maintenance is scheduled in the early morning hours. Machines do not skip steps when tired and do precisely as they are programmed. This means pre and post checks, as one example, happen exactly as intended, every single time. This is music to the security team’s ears!

I am in! . . . But I am struggling to get buy-in from my leadership team

Let us help! Let’s present the network automation journey in a way that will resonate most with your leadership team. Do they care about lowering operational expenses, increasing security posture, time to delivery, or response time to incidents? Network automation has benefits in each of these spaces that can be highlighted clearly using real-world examples from our experience with other customers in this space.