[AVI Systems Chief Technology Officer, Brad Sousa, contributed this article. It was originally published in Forbes.]
As a CTO, the result I see too often is a system that meets the specifications but does nothing to create pervasive change in the organization. As technology leaders, we’ve all probably wondered why, even when we provide the best technical solution, people either won’t use it or worse, they’ll choose to use something inferior. Experience has taught us the answer: Specifications and engineering may define the ruggedness of the solution, but design addresses the human need and defines the level of adoption.
Twenty years ago, MP3 manufacturers thought people wanted a device that could play music, fit in their pocket and hold thousands of songs. In October 2001, Apple introduced a different approach, a device that people could use to access their entire music library and take it with them anywhere. In doing so, Apple launched a simple ecosystem that tied tech and people together: the iPod.
The iPod wasn’t just a device that satisfied a function. It addressed the desire to share music with friends, simplified how a person found new music and created a social gathering based on the experience. The iPod resonated so deeply with people that it changed the phones we carry, the stereos in our homes and the media in our cars.
It addressed the human need, and went crazy with wide-scale adoption. There were hundreds of MP3 players before the iPod, many engineered very well. Yet Apple’s commitment to understanding the “people” part of the technical equation resulted in the unmatched success. Seventeen years later, it’s still the products that move beyond engineering and specifications to embrace design and humanity that impact us the most.
If the idea that design addresses adoption and engineering addresses robustness resonates with you, then the next question is: What does it take to make the change and move the adoption needle? Here are three leadership behaviors that I have seen make a huge impact in workforce adoption.
1. Understand Employee Behavior
Specs are easy to discuss, unemotional and tidy. It’s simple to create a spreadsheet and compare specs as it provides a solid rationale to justify the decision. But does that move the needle? Design questions related to workforce adoption are not always clear-cut. Adoption requires an emotional connection to the technology and outcome. It requires asking different kinds of questions and listening carefully to your employees. To achieve better adoption, go deeper and listen for reasons why employees struggle to accomplish a task. Dig for the “why” behind the project, not just the “what.”
2. Be Wary Of Early Adopters
The hard truth is, regardless of how good the engineering, success is defined by user satisfaction. And user satisfaction is hard to quantify. Mean Opinion Scores or performance satisfaction surveys can help quantify user sentiment. But the reality is that a well-engineered solution can still fail. Why? Because engineering is related to how something is built, while design is related to human expectations. We should embrace the “squishy,” hard-to-measure expectations of user communities. This often means embracing the expectations of knowledge workers, who don’t always know what they want, instead of the early adopter.
Early adopters can tell us what they need, but I find that their needs often don’t translate into adoption. Sometimes this means embracing differences, such as those created by the multigenerational workforce we have today. Someone from one generation probably has a different problem-solving approach than someone from another. Commit your organization to developing the skills needed to define the expectations your user communities have and then learn how those expectations translate into satisfaction.
3. Deliver An Ecosystem
The days of listing the user’s needs, defining the specs and selecting the platform are long gone — especially when the goal is wide-scale adoption by a workforce that thinks the technology is amazing. No single platform can provide the services and experiences all user communities expect. Add to this the differences in how various generations consume these technologies, and now you have the requirement for an ecosystem.
Ecosystems were avoided in the past — they are complex, require integration and can be messy. But in my opinion, ecosystems are the requirement today. For example, unified collaboration platforms are required to integrate with each other, as are work-productivity applications. Cloud platforms are required to integrate with on-premises platforms and with other cloud platforms.
Applications and BYOD force ecosystems to work together because that is the natural way people work. In the technology industry at large, the highest adoption has occurred when we as leaders understand user communities and their expectations and integrate new technologies into their current workflows. The key seems to be multiple platforms, one ecosystem and one native workflow that is easy to adopt.
I clearly love engineering and I get excited when it’s done well. The brilliance of the iPod is that it moved beyond great engineering and uncovered the “why” behind the “what.” I can’t help but wonder if Apple knew the impact the iPod would have 17 years later.
I encourage you to apply this model to your technology planning. Develop deep insights into your employee’s behavior, understand the expectations that translate into satisfaction and discover a passion for design and adoption, in addition to specs and engineering.