Your Staff Won’t Use That Expensive Site (Unless You Help Them)

Tell me if this situation is familiar: 

1. You pay for an expensive website or feature your organization needs.
2. After launching it, you roll it out to your staff.
3. …and it lands with a thud. You’re lucky if staff use 50% of what it can do.

It’s a problem not all leaders anticipate but happens with astonishing regularity.

It’s demoralizing because you put in so much effort, time, and money to get to this point, and yet you can’t seem to get people to use the new technology.

At this juncture, you’re not sure how to move forward. You sit wondering:

• Did we approach this the wrong way?
• Do I need to nudge my staff more?
• Is it the developer’s fault?
• Is it MY fault?

I wrote earlier this year about practical ways to approach website training. 

But I realize on a macro level, what’s most valuable is to prepare your expectations as a nonprofit leader for rolling out a big new tech project and why you may encounter resistance. Then you can worry about the specifics of training.

Why staff resist new technology rollouts

You already know this, but your staff are up to their eyeballs in work. Giving them a new tool to do their job will make them less productive in the short term.

Think about it:

Even if your former tech solution was incredibly lacking, it was familiar. Not only does it take time to learn the new way of doing things, but it also takes mental energy. Staff members have to be “on” to figure it out.

This “new way of doing things” has two knock-on reactions:

1. It takes staff longer to perform a task using the new tech, and it continues to take longer on subsequent attempts until it becomes familiar.
2. The job takes more energy to complete each time because the process is new—and that energy is precious when someone’s plate is full.

This set of problems is the hump on which new technology projects get stuck. 

Even if the new approach is objectively better, it takes additional time and energy to reap the benefits. Thus, you encounter resistance when it’s rolled out.

The pursuit of user-friendly technology

Leaders with experience rolling out tech projects typically recognize this dynamic and seek to counter it with a focus on “user-friendly” software.

The strategy is to acquire software that requires minimal training and is not intimidating to use. This approach makes it easy to push people over The Hump and increase the adoption of new software.

(It also makes it conspicuously easy to lead a tech project when you optimize the whole thing around “tossing it over the fence.”)

Cheeky comments aside, it can be a good strategy. But many leaders—especially ones burned by failed rollouts in the past—seem to be willing to die at the stake over it.

I can’t entirely agree with this black-and-white approach. While it’s rooted in experience (or, more specifically, reaction to a bad experience), there’s a level of tech maturity that allows for more nuance in how you select and roll out new software.

Because here’s the deal:

Usually, the most user-friendly software falls at the simple end of the feature spectrum. You obtain ease-of-use by trading for fewer features. 

And the choices that are both feature-rich AND user-friendly are usually a small handful of mature software offerings with an equally mature price point (if they exist at all).

If you don’t recognize this “user-friendly” strategy for what it is—a trade—then you may unwittingly end up with software everyone likes but which constrains your organization.

Sometimes, it makes strategic sense to lead your staff through a more complex software adoption when the benefits are worth it.

Unquestionably, adopting complex software is a more nuanced and challenging undertaking than choosing the most user-friendly option and tossing it over the fence to your staff. 

You have to consider:

• How tech-savvy your team currently is;
• How big of a training gap exists to get them up to speed;
• What tech capabilities you might need both now and in the future;
• How much your budget and timeline can afford;
• And whether you are willing to reprioritize your staff’s workload so they can put more energy into learning this complex technology.

It’s hard, and sometimes the user-friendly option ends up makes sense. Just realize it isn’t the only successful route to software adoption. 

At times, adopting a complex piece of software is necessary to give your organization capabilities it wouldn’t otherwise have.

Developing realistic expectations

So, we’ve established that rolling out complex software means you can’t just toss it over the fence to your staff and hope for the best.

Let’s recap with a few tips:

1. Get staff involved in planning and testing the software or features they will use. If they help shape the final result, there will be more buy-in, and The Hump will be smaller when it’s finally rolled out.
2. Provide training. And more than you think. (There’s a reason med students go through a multi-year residency before becoming an attending physician.)
3. For heaven’s sake, don’t expect staff members to be equally productive on the new platform until a few weeks (or months) into the rollout. You have to take something off their plate or otherwise adjust your expectations as they learn a new software tool.

Getting software adopted—especially in large organizations—takes time and effort. As a leader, you must expect and plan for this.

Because when you do, your tech projects will meet with more success—regardless of how user-friendly or complicated they are.