Human Change

Many books have already been written on changing employees or teams, changing your own behavior (self-help books), and the psychology of the human being. This background information is not in any way intended to be complete; rather, it provides a brief description of two concepts related to human change.

It is important to know that the human brain essentially works in two modes: a very fast mode and a very slow and considerate mode. The slow mode takes all the things that it perceives in more detail and balances out before making a decision, while the other mode of the brain works so fast it can feel like nearly instant action. The latter one is defined as the limbic system but is more commonly known as our lizard brain.¹

¹ The limbic system is often referred to as the lizard brain because the limbic system is all a lizard has for a brain function. It is in charge of fight, flight, feeding, fear, freezing up, and fornication.

An example of the lizard brain is when you are walking in the park. We do not need to think about which signal is sent to which muscle at which moment in order to walk. But just try to take that same walk while trying to continually add up nonsequential numbers. For example, start with one and add three at each step. Eventually your pace will slow down because your slow and considering brain is taking over from the lizard brain as the task at hand becomes more complex.

As you can imagine, that slow and considerate mode of the brain consumes much more energy to undertake an action than the fast mode. To make the most efficient use of our energy, our brain is “programmed” to use the lizard brain as much as possible and will attempt to take shortcuts, which are known as human biases.

Our slower considered mode of the brain is used for learning new skills and making difficult decisions. But once something is learned, neurological paths in our brain are created, or programmed, so that our lizard brain can take over after we have learned a new technique or trick.

This background information is important to know when a change in human behavior is required, for example, in troubleshooting a network incident. If a major network incident occurs, a typical network engineer will ask for some context and start logging in to switches and analyze the network. The lizard brain is taking over, and the skills the network engineer has learned are being applied to solve the problem at hand.

It is possible to change these automatic pathways and behaviors, but it will take time and effort. It is a complete separate field of expertise to change human behavior, but for this paragraph, it is sufficient to know that there are several fields within human psychology that cover this topic.

To facilitate change it is necessary to be aware that automatic pathways are used for skills that someone has learned. Figure 14-1 displays a model commonly used to represent the stages somebody follows when learning and applying a new skill.

The first stage is that you are unaware of a specific skill at all, so you are also unaware that you can possibly learn that unknown skill. The second stage is that you are consciously aware that you do not have that skill (yet), and you start to learn that new skill. Once you learn that skill, you will be consciously aware of that skill. You now know that you can apply that skill, and you set your mind to perform that specific skill. The skill is there, but you need to put your mind to it.

The last stage in learning a new skill is that you are not consciously aware of applying that new skill at all; you can now perform that specific skill without much thought. Your lizard brain now can jump into action and execute that skill automatically.

This information can be leveraged to support change in behavior. For example, somebody can be made aware that he or she automatically logs in to a switch when an incident is reported, while Cisco DNA Center assurance might already provide information without even touching the CLI.

Once somebody is made consciously aware that he or she followed an automatic pathway, it is possible to suggest alternative paths and allow the person to learn a new skill and thus adopt new (automatic) pathways.

It is important to support and guide the changes and learn new required skills.

And because learning new skills is performed by the slower brain, this change will take a lot of energy and concentration. That works great when there is no pressure, but as soon as pressure is applied almost everybody will revert to their old automatic patterns. This is perfectly normal human behavior; essentially the lizard brain kicks in and uses the automatic pathways and familiar behavioral patterns.

So even when training and coaching are being executed during the transformation to IBN, once a major disruption occurs, or some other external pressure is applied, engineers (and designers) will fall back on their good old behavioral patterns. And it will appear as if all was done for nothing. This situation will occur and should be allowed to happen. Ensure that there is room to make the “relapse” aware to the team and allow the team to learn and change again.

Fear

Another human aspect to change is fear. It is, again, part of our brain to react to a situation in either the “fight” or “flight” mode. Fear can be a difficult obstacle to overcome when not handled correctly. Fear can make somebody (or a whole team) go into a defensive mode, and they will do everything possible to keep things the same and might even sabotage changes to prove they are right.

Although many engineers are enthusiastic about any new technology or tool and their “engineer heart” wants to dive in immediately, the most common show of fear is with the introduction of automation into the network.

When automation is introduced into any environment, staff will almost instantly fear losing their jobs.

And although examples can be identified, in most situations where automation is deployed, old jobs will be lost, but new jobs will emerge as well. In other words, if you are able to change and adapt, you might find yourself in a new role with a different job description.

In summary, fear is a true risk to any change and is specific and real in the case of automation. To be able to cope with this risk, it is important to have both support and good understanding from upper management. IBN is not about how to do as much work as possible while reducing the operations team; it is to prepare the enterprise (and the network) for the upcoming changes with an already overloaded and understaffed operations team. It is important that upper management understands this and that IBN is an enabler for digitalization. Once that commitment is established, it is important to keep communicating and repeating that statement, specifically when introducing the automation component.

Quid Pro Quo and Incentives

A successful driver for change is the combination of quid pro quo and incentives. Quid pro quo is a Latin proverb that translates to “something for something.” It is much easier to make a change successful if there is a beneficial element. That element could be something directly related to a person, or the removal of a boring part of the job that needs to be executed. Using benefits or incentives to drive a change is a common practice. The mechanism itself is very common, used throughout marketing and communications.

Although this use case is not directly related to IBN, it displays how quid pro quo can be used to drive change when resistance or fear is a major factor. The transportation market is competitive, and cargo information is sensitive. But in this situation both parties benefited from a shared change.

Quid pro quo is a form of incentive where both parties benefit from a change. It can perfectly be combined with enticing a user or a team into change as well. The combination can be used to overcome tangible risks of fear and resistance in a team. It is used to reduce the level of fear and aims to provide a direct benefit to the team.

A good example where this can be applied is the introduction of automation. As automation is almost synonymous with the fear of losing a job, this mechanism can be used to encourage the team to use automation to get rid of boring tasks such as manually changing a Syslog server or updating 100+ switches manually.

Although this mechanism should not be overused (because of the risk of losing credibility), it provides a great method of gaining trust and introducing change.

Challenge

Another method or aspect to change is using challenges. Challenge a team or person on why a choice was made in the past. By challenging a design choice, or process, the person is triggered to think about that choice.

The challenge will trigger the brain to use the considerate mode and will likely use experiences related to that choice to determine whether that choice is still valid. Answers like “we have always done it this way” are not acceptable. Ask why that choice was made.

To keep the discussion open and alive, it is important to ask these questions and challenges in a noncondescending way. As soon as the challenge is perceived as condescending, people will go into a defensive mode and will not be able to approach the initial challenge differently.

Challenges can be executed by using the why question or by asking whether a different solution can be used to achieve the same situation. Different thinking can trigger changes as well.

Challenges (or disruptions) should also be just large enough to put somebody off-balance to trigger thinking differently. Change, though challenging, is a process that will take time, but it will provide the benefit that the support for doing things differently is greater than simply enforcing a change. Change should be intrinsic to the team, and challenging can help in adopting change. Also, do not create challenges too frequently, as people might completely go off-balance and then revert to old behavior.

Because this kind of change will take a longer period of time, it is possible that external factors will put pressure on the process of change. For example, a strong budgetary cut can easily put strain on the process, and a reversion to all methods will occur.

This situation typically describes an external factor that can put pressure and strain on any project and change. It is important in these types of situations to keep focus, consistent communication, and commitment to the changes already in progress. Some changes might take longer, but the commitment in combination with perseverance will eventually result in the desired change.

And as change is usually realized slowly, periodically try to step back and see the progress. Changes occur in small steps, and sometimes are even invisible.

Failure

It might be a platitude, but everybody learns the most from his or her own mistakes and experiences. The ability to recognize your own mistakes and learn from them is a separate skillset, and the most interesting stories are often from senior staff members who share war stories that also contain their own failures. Showing your own failures and mistakes is essentially a show of strength and not weakness.

A successful transformation to IBN is not complete without some type of failure and the experiences learned from them. This aspect is applicable to all facets of the transformation to IBN, from learning new technologies and new troubleshooting skills to changing teams and operations. If failures are not allowed during the journey, the chance of reverting to old behavior and patterns is very high. It is thus recommended to create an environment where failures in each aspect of the transformation are allowed. Inform stakeholders that mistakes and failures are an essential part of the process and need to be accepted without repercussions.

Forward Thinking

Forward thinking is a mechanism where a team is learning new skills or applying changes by guiding them through a number of smaller controlled steps rather than providing one big step. This principle is common in learning a new language. Instead of providing all grammar rules and vocabulary at once, smaller controllable steps are used to introduce new words and grammar rules to the student.

A similar approach can be taken for change. By continuously forward-thinking a number of steps toward an implementation, the team can take smaller, manageable steps toward that goal. By taking the team only on the first step (while keeping the second and third in the back of your mind), the team can take one small step at a time, making it easier while still being able to learn a bigger new skill.

The risk of not forward-thinking a number of steps is that after the first step a new path is taken to a completely different solution than originally intended and anticipated. By continuously predefining the next three to five steps, the path being taken becomes more controllable and manageable. Small diversions are allowed, as the second or third step will then be used to revert to the original strategy or implementation.

Although the steps are defined, it can be overwhelming to a team to know all the steps toward implementation. Sometimes it is better to not share all the steps, but allow the team to take one step at a time. This is specifically important if a large change in operation or design is to be implemented. Big changes tend to be more difficult than a sequence of small changes. And although the end result is the same, the risk of losing the team during the change is much lower with small steps than larger steps.

The process of defining the next three to five steps is rather difficult and requires some experience and knowledge. To prevent too small steps or taking a wrong path, it is recommended to periodically reflect the steps toward the intended change or implementation with peers using peer review and open discussion. These peer reviews could be with senior members of the team who are open to change or, in a more generic way, with persons who perform similar tasks.

It is important to periodically validate the end implementation with the stakeholders (and management) as they might have had a change of insight too.

Forward thinking can be seen as a key concept for the transformation to Intent-Based Networking. The end goal is an Intent-enabled network, which is a great change. By dividing it into smaller, manageable steps, it allows the team to take that journey and change more easily.

Ownership

Traditionally in larger enterprises, projects are used to drive change in an organization. Projects are used to deploy a new software solution, execute a large software upgrade, or select a new coffee vending machine. One of the reasons for this strategy is to keep operations running the business while a change is being executed in a controlled manner using project management frameworks. Although this strategy helps keeping a controlled scope and deliverables, this strategically will most likely fail for the projects related to the transformation to IBN.

Often these projects are defined with a specific demand. A project manager and project team are established to execute that task. It is common to hire external resources to execute the project to keep the operations running and not have the operations team worry about project-related tasks and project stress.

These project teams often have to make decisions during design or implementation that have consequences when the project is handed over to the operations team. These decisions are usually when the project faces problems, such as the application is not operating as designed or a special management tool is required for a new piece of hardware. Decisions are then commonly made within the project team without consulting the operations team and thus not overseeing the consequences of those decisions once the result of the project is handed over to operations.

Consequently, the operations team is faced with a project that is not delivering a solution that really helps operations, and operations needs to either use that tool or choose to ignore it as much as possible and move on to business as usual.

Also, project managers have a different task and responsibility than an operations team. Project managers have to finish a project within time and budget and often with limited resources and assumptions. Most often their priority is not completely in line with how the end result of the project is to be managed and operated after the project, but more on the project itself. Once the project is finished and delivered, they will move on to a new project.

From a management perspective that behavior can be a valid point to keep the project within budget and manageable. It often also leads to extra workload on the operations team to keep that new tool or system up and running.

Intent-Based Networking is primarily about how the next generation of networks should be managed and operated. It provides a way for the operations team to manage that network. Everything in the transformation is directly related to the operations team. To successfully perform that transition, the related projects must be executed by the operations team. Project managers and external resources can, of course, be used as extra support, but the changes and tasks should primarily be executed by the operations team. It is their environment that is to be changed. They should take and have ownership of the transformation.

Training and Demonstration

Perhaps one of the most underestimated aspects of any change is the power of training. We tend to forget that every existing operation (installing a new switch, configuring a new VLAN) is based on training and lessons learned (experience from that training).

Intent-Based Networking is leveraging new tools and methods to deploy and operate a network. Training and demonstration of new features or functions are great ways to make a team more comfortable with new methods of operation.

A variety of training methods can be used to demonstrate and learn new skills, including workshops, vendor-provided courses, role playing, simulations, and company trainings. Each type of training can have a different effect.

As a lab is recommended for the transformation to an Intent-Based Network, the same lab can also be used to as a training opportunity for the operations team. Simulate situations in the lab that reflect a small Intent-enabled network, and allow the team to analyze and troubleshoot it. Or use the lab to test new tools and procedures.

It is recommended to also use training methods to support change.

Stakeholders and Governance

Although the need for change should be intrinsic to the persons and units involved, there will be situations where the proverbial carrot proves insufficient and a stick is required. In that case it is important to have sufficient backup and commitment from stakeholders and upper management. They can provide a more directive approach to prevent situations in which people say yes to the change but act differently (for any number of reasons).

Leveraging management can in those situations be of assistance to keep focus and push a team into a change.

A good practice for stakeholder management is to not only have formal periodic meetings with stakeholders (usually per quarter) but have informal bilateral meetings with individual stakeholders at a higher frequency. As these meetings are informal and more frequent, lessons or experiences of what recently happened can be discussed, and actions can be taken to redirect or correct a flow or behavior. Make sure that these informal meetings are scheduled, and keep commitment to have these meetings, even if the only communication is that all is well.

These informal meetings will help in keeping management and stakeholders involved. Chances are that stakeholders will use those meetings as a form of peer review of their experiences.

Lifecycle Management

The concept of a lifecycle management process has been explained in Chapter 8, “Phase Two: Prepare for Intent.” The lifecycle management process ensures that the network remains up-to-date on hardware and software via specified and committed procedures. As an Intent-Based Network is business critical in a digitalized business, it is a key requirement to keep the business going.

Use the experiences and lessons learned from the transition to IBN to set up a validated, proven, and supported life cycle management process. This benefits the enterprise on a number of levels, not only on a business outcome perspective (being able to execute change when required) but also the maturity level of the enterprise.

It also provides a warrant that when a specific new technology or solution can benefit the enterprise there is room and budget available to implement that new solution.

Summary

A key part of IBN is about change. Most of the changes in the transformation to IBN are not technically oriented but more organizational and behavioral. Making change happen is a complex process upon which many books have already been written. It requires a lot of adoption, flexibility, and focus from all parties involved. The information and recommendations described in this chapter are only a small part of a much larger toolkit with methods, methodologies, and concepts.

Determining when to use which aspect of the toolkit is a continuous balance based on past experiences, sensitivity, personal skillsets, and the available time and resources. You can use the recommendations and information in this chapter to facilitate that change.

Although a diverse set of recommendations and information was provided in this chapter, some aspects are slightly more important to focus on.

• Ownership: Perhaps one of the most important recommendations is that the journey to IBN is to be executed primarily by the network operations team. Try to avoid the use of separate project teams that do not involve the network operations team to prevent a solution from being presented that is not supported and beneficial to the network operations team. Project management is absolutely required for such a big transformation, but the executing staff of the identified projects must be the operations team. They are the ones who will operate and manage the IBN.

• Positiveness: The proverb “You can catch more flies with a drop of honey than with a barrel of vinegar” has a ring of truth to it in relation to change. Try to drive all changes with a positive attitude. Positive attitudes and providing (direct) benefits to changes allow for greater success and support within the operations team.

  Successful implementations (or parts) should also be celebrated with the team. This will provide a more positive vibe to the team.

  To celebrate successes, also allow for failures. In a sardonic way, failures can be celebrated as well to prevent a negative vibe around the failure that can create an implicit resistance.

• Change is slow: Successful changes take time. Regardless of the method, such as controlled disruption, quid pro quo, and challenging, each change is to be carried out by staff. Fallbacks to old processes will occur. Factor those in and be consistent, patient, and persistent to the changes. Make sure that the appropriate stakeholders are informed and that they stay committed to the transformation to IBN. Also, periodically take a step back and see what already has been accomplished.

• Training: Learning new skills equals training. Allow for enough training (including failures) on skills and changes required. The training should not only be on technology and tools, which is normal, but also on team building, learning new skills, and organizational aspects. If the role of employees changes, allow them to be trained on that new role as well.

• Forward thinking: A key recommendation to change is to foresee more steps that need to be taken. But keep those steps to a limited group of persons (to do peer review and reflect) while communicating the end strategy and the first step at hand. This is required to prevent losing the team by taking each step too fast.

In conclusion, organizational change itself is a complex task that requires effort, perseverance, patience, and commitment. It is also a different field of expertise with different knowledge domains. Leverage external knowledge and resources where possible, use personal experiences and soft persuasion, and apply pieces of the toolkit when and where necessary.

That will only help to accommodate the necessary organizational changes to successfully transform to IBN.