3 Approaches for Decoding People

Ryan Meyer – Principal

Decoding the People Side of Tech: Lessons from a Technologist

In the world of software engineering, there’s a certain way of thinking that’s just accepted as truth: every problem is an abstraction with a correct solution that can be determined through analysis and logic. There’s a discrete set of inputs that map to a predefined set of outputs and, ultimately, you’re either right or wrong. One or zero. Unfortunately, this approach doesn’t address the people side of tech. As a software developer, in the past all I wanted was for someone to give me clearly defined requirements so that I could go off and build an efficient application that everyone would immediately start using. (Go ahead, it’s OK to laugh.) But I came to realize, that way of thinking just doesn’t work when creating technology solutions for people. We’re not machines, reliably mapping inputs to outputs. We’re messy, unpredictable, emotional, even fragile. That means our solutions must solve for the people side of tech, not just the technical requirements themselves. Here are some lessons that I’ve learned over the years for approaching the people side of tech. of creating technology solutions that work for people (and how you can be more successful with technology solutions, no matter your role).

Challenge #1: People don’t know what they want.

“If I had asked people what they wanted, they would have said faster horses.” – Henry Ford, but not really

Although often attributed to him, there’s no evidence Henry Ford ever actually uttered this well-known quote. Regardless, it’s a powerful concept. People can almost always identify their pain points, but that doesn’t mean they have insight into the root causes behind them. Even when they do, that doesn’t mean they can translate those root causes into an effective solution. And even then, they often struggle to articulate that solution in a way that others can easily understand. Approach: design thinking If consumers can’t tell us what they want, how do we figure it out? Design thinking has evolved to address this specific challenge. While there are various methodologies, the approach generally involves these five phases:

Empathize. Fully understand your audience by getting into their head—their goals, internal motivations, pain points, and physical and technical environments.
Define. Clearly identify the root cause or issue that is trying to be solved in the terms of the person who is experiencing it.
Ideate. Use various techniques and a diverse team to diverge and generate as many ideas as possible; then, converge on the most promising approaches.
Prototype. Rapidly generate a low-fidelity, concrete experience that represents the most important aspects of the solution approach.
Test. Create opportunities for real users to interact with the prototype, gathering insights on its strengths and weaknesses for iterative improvement.

Challenge #2: People are bad at predictions.

“Trying to predict the future is like trying to drive down a country road at night with no lights while looking out the back window.” – Peter Drucker

Our shared inability to accurately predict the future plays out in two very different, but equally disruptive, ways. First, business needs are changing at an ever-increasing rate. What seemed trivial a few months ago might be a critical issue today, and vice versa. We do our best to understand current challenges, then design, develop, and fully implement solutions. But the longer that process takes, the more likely that priorities have already shifted. Second, we’re asking more and more of developers: more complex solutions, new frameworks and platforms, larger teams, and bigger plans. With that complexity comes an increasing amount of assumptions, dependencies, and estimates. Approach: agile development It turns out that our ineffectiveness at predictions isn’t new. Software developers were dealing with these very issues 20+ years ago as they developed the Agile Manifesto (a series of values and principles that define the agile philosophy). We can use these same principles to drive agile development Four of the original 12 principles are particularly relevant to this discussion:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. This reduces forecasting; better yet, we get to validate that we’re creating what people really need.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. By anticipating, even embracing, change, it reduces the mental shock that can come when plans inevitably shift.
Business people and developers must work together daily throughout the project. Only those who are deeply part of the business will be able to sense when priorities change and communicate those shifts to the team creating the solution.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Developers are people, too. By acknowledging the imperfection of teams of people, they can continually work to align and improve.

Challenge #3: People don’t easily change their habits.

“If you build it, they will come.” – Field of Dreams (with all due respect to Kevin Costner, that’s just not how people work)

We all see the benefits of exercising more, journaling, or keeping our inbox clean. Yet, starting a new behavior and maintaining momentum remains elusive for many, even when the overall effort might not be huge. The same goes for a new technology solution. No matter how great it is, if it requires people to change their habits, they’re not going to readily adopt it. Even if a solution has the potential for a huge impact on the organization, the true impact is always realized through people using it. Approach: change management Organizational change management is a collection of practices that address this specific challenge. Pulling influences from neuroscience, leadership, project management, training, and communications, there are several key tactics that can help people adopt new behaviors:

Help people understand the “why.” Before jumping into telling people what your great new solution is and how to use it, be sure they understand why it was created in the first place.
Ensure leaders are aligned and communicating. Leaders can bring attention, focus, and credibility to your solutions, but only if they’re all vocally on the same page.
Leverage peers for social support. From gamification techniques introducing positive peer pressure, to change agent networks providing grassroots support, nothing inspires trust like a peer who has found value in the new approach.
Follow up with ongoing sustainment activities. Change is hard! By following up over a longer period of time, you help people avoid falling back into their old habits.

Lessons learned: the people side of tech

Through my journey, I’ve come to realize that these three challenges are vital to address when solving for the people side of tech. To create a successful technology solution, for many technology developers that means changing mindsets and beliefs about how to make solutions that work for people, not just technically work. Mastering the people side of tech often means rallying a cross-functional team of UI/UX designers, product owners, scrum masters, and change management practitioners. If you’re part of this extended team, I hope this article helps you understand how to get the most out of your next development cycle for a technology solution. And if you’re an end user, this should give you an appreciation for the level of effort and dedication that goes into creating a solution to improve your experience (even if it does make you change a habit).

If you’d like to connect with our team to learn more insights behind the people side of technology, give us a call at 859-415-1000 or reach out through the form below.