Changing the process VS Solving a problem

To be clear, I'm not saying one of these is the right approach (to introducing new design activities). Just comparing my experience of both, and what worked or didn't.

The first time I introduced UX (User Experience) to a team was 2011. At that time, I got great advice from the Dev team manager (who was not only a developer, but also a web designer and a UX cynic; and is someone I consider as my real-life UX design mentor), who said that I should understand their existing process first, before I try to introduce anything new.

So I did. Did one of my first workflow-mapping activities by interviewing each team, understanding their pain points and deliverables.

• At that time, I never talked about "UX". Never mentioned I was doing a process change (until much later). Mainly said I was trying to understand how I can help the team.

Fast forward, to 6 years after that role. Joined an Enterprise environment again; this time hired by a Design Thinking pioneer in our region to help form a human-centered design team in a commercial bank.

• Different context: Supportive senior leadership, plus the "soil" to grow our team in was different. We were working alongside one of, if not THE biggest, most expensive consultancy in the world, who were onboarded as the digital transformation advisory arm.
• The centerpiece was all around "change". And, I get it. This was the era of "disruption" (e.g. ridesharing and other digital business models had sprouted by this time**).
• I followed the organizational direction, and I invested time in providing awareness, education, and training. A lot of vocabulary taught to the bankers: usability, UX, design thinking, minimum viable product (MVP), prototyping; and new concepts: Why discovery research was needed before developing an app.
• Beyond education, I also did a lot of group facilitation and ritual-setting to embed comprehension and processes (very "R" in ADKAR). We implemented (many) org restructures. Marketing leadership was in on the hype trail.

Knowing what I know now, what I would have done differently:

• I would've been more selective about whose feedback and whose pushback I was addressing. The design researcher in me assumed that I needed to cater to the most extreme detractors, thinking "if I made this work for them, then it works for everyone". Which is a principle I applied from IDEO's HCD – not realizing then, that change management is not similar to product design in that way (where accessibility and usability provide ease-of-use for the majority). I assumed I needed to be humble and that all feedback was constructive.
  But, catering to the strongest negative voices, waiting for them to "see the light", can alienate or bog down those who would've appreciated the new approaches anyway***.
• I would have chosen to cultivate champions, rather than resolve the concerns of detractors that may have been
  a) distracted by their own motivations and
  b) needed a totally different approach.
  Basically, "explaining louder" or "making things more digestible" past a certain point became its own workstream beyond solving the service problems.
• Yes, it is part of the work, but I could have put a ceiling on it.
  I took that job to solve customer and employee problems; I could have checked in earlier, on whether the constant internal education push was helping or harming that goal.
  [Postscript: Just attended a talk by Andy Polaine: Where he clearly illustrated the value of speaking to your audience's internal narrative, and not your "self-evident thinking" as a designer, and I think that was the key missing piece in this evangelization approach that we followed.]

I was asked earlier today if I had a position or conclusion around this "choice". But, I guess it's really a false dichotomy/ not an either-or, but a yes-and.

What might have burned me out – and made all the change management and re-education seem heavy – was the amount of it. When I was handed the reins, I should have taken a step back and identified what was solvable by "awareness" or comprehension, versus other change levers (such as incentives, or feedback loops).

In this sense, the effort mismatch in the two situations made it seem like I actually secured adoption faster during the time that I didn't "educate" colleagues about research and design (i.e. better ROI).

But, of course, it was a totally different context (media conglomerate vs regulated industry; team-of-one versus scrappy team partnered with expensive global consultancy; UX in its infancy vs UX as a buzzword). And, looking back, it depends on what metric you were looking at.

I did get faster adoption, but also minimal senior leadership support (I got a lot of things done, but ended up using my own money for projects and earning a...headstrong reputation). On the other hand, we did get a lot of corporate/management backing in the global consultancy-level/heavy change management route.

Now, I'm taking a different approach. Learning from the various ways I've attempted, I'm trying to find...bridges, for now.

I'm a big fan of the company I work in. So, I try to find the counterparts and analogues in my former and current "industry language".

*I did steer clear of "UX" on purpose. It was a relatively new term at that time (many Silicon Valley/North American companies were still using Cooper's "interaction designer" as a common job title). I saw it as risky to latch onto, given that I wasn't sure how long it would hold (i.e. see: "native advertising").

**For reference, the timeline of tech launches and developments mapped against my projects/focus areas:

'*** Thanks, B, for trying to teach me about this specific point.