You (Should Hopefully) Only (Need To) Execute Once

‍

In my previous article, I mentioned that “... without Alexander’s extensive military strategic planning underlying [his conquests], he would likely not be remembered as more than a footnote in history today.” But we do remember him as more than a footnote in history today. And the reason we do is because of his execution of those tactics.

Similarly, in business, we’re not paid to make plans, but to put those plans successfully into action. Actions are what keeps the economic and corporate wheels (and hence, your paycheck) turning. Making things happen is what immortalizes our political and corporate heroes (if you’re inclined to think of politicians and C-suite executives as such). And now that I’ve been particularly clear about the value of planning and preparation - to the point of repetition - I think it’s time to go where heroes are made.

If you want to be a change management hero, and be able to successfully execute on change management around adoption of demo automation software in an organization, you’ll need to master Steps 4, 5, 6 of our framework - Enlisting a Volunteer Army, Enabling Action by Removing Barriers, and Generating Short-Term Wins. Put differently, after having created momentum in Steps 1-3, now it’s time to convert that momentum into action.

Enlisting a Volunteer Army

While the core of Alexander’s army were made up of Macedonian elite troops and leaders (his “powerful coalition”, if you will), one of the major reasons he was so successful was that he was also able to recruit and integrate local forces from conquered regions into his combined forces. And when the most influential and powerful around you start to see a particular course of action (joining Alexander) as being the best one, it’s only natural that people will follow - whether your incentives are primarily coming from a carrot or from a stick (probably a hoplite spear, in this case). 

Similarly, if you've successfully built (by clearly and compellingly communicating the "so what") your own robust, cross-functional powerful coalition including key individuals with authority and influence, you'll find it easier to enlist your own volunteer army - simply because it becomes their best option.

Why? Think about it like this. Most organizations and teams will have certain “trend setters” or “high performers” that others look to. These can be your direct teammates, they can be people you work with to accomplish the same goals (if you’re an AE, think your SE or BDR), they can be your managers and leaders. If literally everyone whose opinion you value are telling you that “this demo automation stuff is the next big thing”, then that is going to be extremely compelling, even to the most stubborn, right-side-of-the-adoption-curve individuals. And just by virtue of how adopting something new works, you need to see a critical mass of users before you can expect to see widespread adoption. After all, large-scale change can only truly occur when massive numbers of people rally around a common opportunity.

At the same time, it’s naïve to think that just because you succeeded in building out your powerful coalition of trend setters and “influencers”, people will flock to your proverbial banners automatically. Don’t fall into the trap of thinking that the hardest work is done (it’s not). At this stage, your powerful coalition is more of a door opener to the right rooms than it is a guarantee for success. You (and your team) will need to, and should, drive the message and the comms relentlessly to your target audience, and some level of hand holding is to be expected as well. What you’re trying to do at this stage is to get widespread buy-in - but there’s a big gap between someone wanting to do something and them actually doing it. Put metaphorically, you’re trying to get the snowball to start rolling. How you get it to keep rolling and grow over time is where we’re going next.

And so how can you tell whether the snowball is rolling or not? What are some of the KPIs you should be looking for? At this stage, since what you’re really trying to do is generate buy-in, it’s less about results than it is about commitment to results. Assuming that your end users are Sellers, getting them and their managers/leaders to formally commit to using your tool by building usage and adoption metrics into their KPIs would be the dream, but that’s likely a tall ask for most at this stage. If this is out of reach, see if you can at least get commitment to nominate at least one “evangelist” per team (and also at least one first-line manager per second-line manager) to commit to using the tool and helping drive success for their team mates. And if you can’t tie it to their KPIs directly, competitions are a fantastic lever to pull as well. The prizes do not have to be monetary (but it certainly does help) - tapping into people’s competitive nature to incentivize them to display the behaviors and actions you’re looking for will typically also go a long way!

A short comment to round this section off - if, due to shortcomings in your preparation for change, you failed to create urgency, a powerful coalition, and a clear vision, does this automatically mean that your cause is lost? I’d argue no - but 1) you are much more likely to only see success with the ~5-10% of people who are natural early adopters, and 2) scaling adoption beyond this group is going to be exponentially harder. Failing to adequately prepare for war means you’re more likely to lose it, even if you win a few battles here and there.

Enabling Action by Removing Barriers

Now that your troops are assembled, you’ll want to make sure that you’ve cleared any obstacles so they have the resources and support needed to advance upon your enemies (aka. inefficient sales processes). 

First, you have to identify potential barriers. These can vary greatly from company to company, team to team, and culture to culture, but five of the most obvious ones are:

• Employee resistance to change and organizational inertia. People are naturally hesitant to change, preferring to stick to what they’re used to. In some companies, the organizational culture can make this worse, while in others, it can make it better
• Lack of awareness or understanding. Hopefully, at this stage, lack of awareness shouldn’t be an issue, but something good cannot be communicated enough! Equally relevant (but possibly harder to spot) is a lack of understanding of why or how to use the tool(s). People won’t always tell you if they don’t understand something, and misunderstandings may not always come to light, either
• Technical or UI/UX challenges. Even if the “why” and “how” are both clear in theory, good intentions do not always lead to action. Some users might find the tech too complex or the UI/UX to be so foreign compared to what they’re used to that it effectively stops them from using it
• Resource constraints and competing priorities. Most people are already busy enough as it is, and putting another thing on their plate, even if they are very bullish on it, could end up becoming the straw that breaks the camel’s back. When the proverbial excrement hits the fan, and people enter “back to basics” mode, you can either let this derail your efforts or use it as an opportunity
• Missing feedback mechanisms. When something inevitably does go wrong (it always does) or when opportunities for improvement are identified (they always exist), having the right infrastructure and processes in place to act on it is crucial. This is not just to ensure the tool is working as intended, but also to make end users feel empowered and further build and sustain momentum as a result

Second, you need to come up with a plan to remove (or even prevent) them, and then execute that plan. For these five specific potential barriers, here are my suggestions for how to do so:

• Employee resistance to change and organizational inertia: Make sure that the vision/”so what” is crystal clear and that senior leaders and the people your users look to are doubly committed to the tool and actively & visibly champions it
• Lack of awareness or understanding: Ensure that end users have received proper training on the tool - not just on the how (how and when to use it), but also the why (what’s in it for them). Don’t fall for the trap of thinking it will be a “one and done” - enablement efforts typically lead to a temporary adoption/usage boost, but need to be repeated to sustain and grow these effects over time
• Technical or UI/UX challenges: Once again, enablement is critical, but in this case the notion of “social proof” becomes important. There is generally always going to be some resistance to things that “come from HQ”, but if you have someone in each team that champions the tool and “speaks the language” of the other people on that team, things are going to go a lot smoother. Taking a “train the trainer” approach with your “volunteer army” is a great and scalable way to putting this into practice
• Resource constraints and competing priorities: The key here is to make sure people clearly understand the benefits of the tool. When people get busy and focus on getting the basics right, you want to make sure that they see the tool as a way of helping them with that, and not as a tool that lives separately. This is most easily done by having leaders and managers present a clear PoV on why and how the tool fits into (and improves) the current way of doing things, and then doubling down and expanding on this during training with use case/scenario-based examples
• Missing feedback mechanisms: Your best feedback mechanism is going to be your volunteer army, if you were able to assemble one. They will be able to help you not only cover the widest amount of perspective and information, but also proactively help you source it. Meetings with them on a regular cadence is the best way to ensure this happens. As a complement (or in the absence of such people), you’ll (also) want to regularly survey your users on their experiences - more frequently during launch/rollout, and then less frequently as your tool(s) start to see more and more adoption.

This is of course easier said than done and, as mentioned, you are likely to face other potential blockers that might be even more crucial than the five aforementioned ones in your own company, so here’s my final words of wisdom from a why perspective instead of a what and how perspective. If you can deeply empathize with your end user, understand their “job to be done”, what motivates them, and what prevents them from achieving their goals, the majority of potential blockers should be much easier to unearth. Figuring out how to remove them might still be hard, but at least it’ll be infinitely easier than if you didn’t even know what the problem was in the first place!

A similarly short note to end this section too. With the focus on the importance of training and enablement here, you might have noticed the absence of any higher-level training and enablement strategy considerations so far, and you might see that as a bit of a gap. Worry not! In an attempt to avoid too much repetition, I’ll be including that in the next - and final - article in this series.

Generating Short-Term Wins

Now that the path is clear, it’s time to strike. And to sustain the momentum of our army, it is critical that we not only celebrate the battles we win along the way, but that we actively involve ourselves in creating those wins so they can serve as both quantitative and qualitative proof that what we’re doing actually works. Only your creativity is the limit for what you could potentially do in this regard, but here are four things that should be staples of your approach:

• Pilot programs. Make sure you run one or more pilots if you haven’t already, both to help discover things that might negatively impact user experience (ie. find and remove more barriers) and to help you generate momentum for widespread adoption. Since you’ve already created your “volunteer army”, you already have your pilot participants eager and ready to go. Tap into that, and leverage these people as a way to gain feedback, create quick wins, and start taking demo automation from idea to reality. Then, take those people and their stories and turn them into your evangelists.
• Quick wins in workflow improvements. The stronger incentives you can create to start using the tool, the better. Overcoming that initial inertia (getting started is often the hardest part!) can be made substantially easier if you’ve been able to identify pain points in the current end user workflow that you can easily fix or improve with your new processes and tools. The goal here is to make them quick wins, however - this is not the time and place to pitch multi-year transformation efforts, it’s about getting scrappy and creating value fast.
• Proof of success - Metrics and Success Stories. With a pilot full of eager and forward-leaning participants who’ve now had their barriers removed, it’s only a matter of time before you’ll start to see successes trickle in. People may not proactively share how they’re succeeding, so make sure to monitor your data and keep your ear close to the ground (or at least your pilot group) so you can pick up and lift up early successes and wins. You’ll want to make sure you can clearly demonstrate how what you’ve done is helping drive KPI improvements among the KPIs that your key stakeholders actually care about, but this in itself is not enough. Humans are storytellers (and -consumers) at heart, and stories travel - creating strong success stories that can “sell the why” for you will be important to widespread adoption. 
• Recognition and rewards. Finally, as anyone who works with children, dogs, or salespeople will know, the right behaviors have to be rewarded if you want to see more of them. Make sure to reward both inputs (leveraging your tools/processes) as well as outputs (successes and wins), ideally with money (if you have it) and/or social motivators (like leadership visibility, competitions, non-monetary awards, etc).

A final note re: KPIs, as we’re now starting to talk about wins and how to show them off. The right question to ask here isn’t “which pre-baked KPIs can I use to convince my stakeholders that this is valuable”. You have to flip that entire line of reasoning on its head, and ask “how can I show that what I’m doing is influencing what people actually care about”. It’s about adapting the process to the people, not trying to get the people to adapt to the process. And, as established over the past two articles, with demo automation, you are generally always in a position to be able to find a way to show how you’re helping with their so what. As discussed in the previous article, if you’ve been able to build out the reporting infrastructure around your tool (for instance by making sure that each time it’s used for a Sales opportunity, that usage is captured and associated with that opportunity), then this is easy, and you can report on any derivative measure your stakeholders care about: Pipegen, Close Rates, cost-to-serve… it’s all within your grasp.

If you’ve been able to do all of this, you are now in a position where what you’re doing is starting to look too good to be ignored. And once it is, you’re ready to expand from pilots and “volunteer armies” to widespread adoption. From Greece to world domination (the world we know, anyway) 

Summary

This article has covered, after meticulously preparing and setting your organization up for success, how you capitalize on initial momentum when rolling out demo automation software, treating the entire effort as a change management effort and leaning on Steps 4, 5, 6 in Kotter’s 8-step model for change. It has highlighted the importance of creating and sustaining groundswell and grassroots momentum with a “volunteer army”, removing potential barriers to capitalizing on that momentum, and then fostering and communicating quick wins to turn momentum into value.

Hopefully, this has given you ideas and concrete tips & actions for how would go about doing something like this in your own company - and, perhaps even more importantly, you’re still with me despite my repeated insistence on metaphors insisting on death and destruction (creation and destruction are two sides of the same coin, after all - and thankfully, we only have one more death left to cover before this story ends).

In the next - and final - article, I’ll cover how to consolidate your demo automation tool gains after having successfully demonstrated - with conviction - that it works, make it “sticky” in your company, as well as round off the whole Alexander story, too. See you there!