In our B2B consulting practice, as well as our marketing outsourcing business, we often work with people who have been brought in as new leaders to a company or department as a “change agent” – and, as everyone knows, that role carries its own special challenges. Smart, ambitious, talented people are hired to make something different happen, and often find themselves chafing at the strictures of their environment, which isn’t necessarily receptive to their energies. Having the right person in this type of role can really turn things around in an organization, but it’s not for the faint of heart.
This is a great – and brief – article in Fast Company’s online design magazine, about a turnaround that’s framed from the customer in, rather than from the company out, because it’s about the redesign of a product (in this case, the Android phone). The key designer, Matias Duarte, went through a deceptively simple step by step process to create support internally as well as decide what exactly to do with the product, which I think is generalizable to all sorts of change situations. What I’ve done below is taken his steps in the process, and viewed them through the filter of the issues our clients bring to us.
Know that no one else might think there’s a problem, even if you do
- We see people hired into a company with a strong critique of how it’s been operating and, rightly or wrongly, from the inside, things may look quite different.
- This is the trickiest where the issues identified are truly strategic, but where the case for them is harder to quantify – quality in professional services, for instance, or impending strategic vulnerability due to technological changes which haven’t quite manifested themselves yet, or HR and culture issues. It is also difficult where the problem may be evident – shrinking revenue – but the root cause(s) are not generally agreed-upon.
Run a baseline study to identify your core issues
- This is the point when a company like ours is often engaged, in order to conduct research. It might entail speaking with internal stakeholders, clients (both current and – hopefully – past), potential clients, competitors, service providers, etc. This research can be an enormous undertaking, and generally can’t be conducted by the company itself, because people just won’t speak to them, or won’t be candid. We can also get interesting results from more limited samples, to at least provide some direction.
- One fascinating point raised in the article is that what you don’t hear is often just as important as what you do hear. In analyzing results of interviews, we will generally look at what we might have expected comments on, or what a truly excellent opinion might consist of, and assess where we have gotten explicit feedback, versus where we can hear the crickets chirping.
Bring your stakeholders along on your research
- This helps build support for the notion of change as you go through the process.
- In our projects this often includes having a fairly broad circulation of proposed research questions or target people to speak with for review among the client team. We don’t always get suggestions from everyone, but they do get a chance to see the machinery of the project, and start to expect the outputs that will emerge.
- We also generally share tidbits of findings with clients as we proceed, so that, while there’s no shortcut to a systematic and holistic review of the findings, they see the surprises or interesting areas for further exploration that we hear along the way. We also find that often we can see the threads in the research emerge fairly early in the process, so this gets our clients thinking about key issues sooner rather than later.
Use the baseline research to establish your [business] design goals
- Once the research components are in place, a change agent is in a much better position to present a case to do things differently. Maybe the platform is burning, or maybe there’s a highly attractive opportunity that’s been identified. Whatever the research findings, a process that takes the existing organization into account is going to go much more smoothly, not just during research, but during the critical adoption and implementation phases to come.
How do you proceed when you see a big problem that needs fixing but others don’t agree? Do you have any success stories (or perhaps cautionary tales) to share?