I’m a huge West Wing fan, and I often think about interactions I have at work in the context of various storylines. Recently, I had an experience that reminded me of this lesson in influencing without authority.
I was thinking about an episode in which the Deputy Chief of Staff, Josh Lyman, is telling the First Lady why her pick for chief of staff is a bad idea. He sums it up in this quote:
“He thinks decisions are made in meetings.”
On the face of it, this doesn’t make any sense. In a corporate environment, aren’t meetings created so that people will get together, hash out a problem, then come to an agreement on what to do next?
Short answer: no.
Many UX writers have grand dreams: style guides, changes to processes, testing procedures they want to implement. But they often lack the skills to implement those changes because they come from cultures where structural changes are much more difficult. E.g. Newsrooms, academia, advertising, and so on.
It’s taken me years to cultivate strategies to make change happen. Influencing without authority is a skill that UX writers need to learn – and here’s how.
The problem: a change to UX writing crews
My department at MYOB is divided into “crews”. Each crew has its own responsibility: e.g. component governance, support, ecommerce, etc.
Previously, UX writers sat in specialized crews. Each writer would have responsibility for helping out design requirements in that crew. Makes sense on the face of it, but this often led to a lot of lop-sided work and a lot of admin for me: in order to see what other writers are doing, I’d have to view different boards.
I proposed a change: create a shared service wherein UX writers sit across the entire department. We wouldn’t be attached to specific crews, but writers would organize among ourselves what projects to tackle.
I was successful in creating this change. But how?
Influencing without authority starts at the top
The change I was proposing was big. It would add a new reporting channel for higher-ups. In order to make that happen, I needed to start at the top. Not to get all the details right, but just to see if this would be a waste of time to even investigate.
I asked our UX lead: would he theoretically be in support of such a change?
Yes, was the answer. As long as the crews are in agreement, and we clearly document and get support for any change. Now, you might say this is actually influencing with authority. But I still didn’t have full autonomy – I couldn’t dictate the plan. That’s what influencing without authority is meant to help navigate.
First problem: solved. I have buy-in from the top, which will help with the individual product managers. Now comes the next step…
Understand individual motivation and roadblocks
My suggested change for UX copy to become a shared service affects individual crews, and therefore product managers. I needed to sit down with each one, explain the benefits of the plan (“what’s in it for me?”), and get their opinion on the proposed change.
In doing so, I’d ask the same question I asked our UX lead. Would you theoretically be okay with this? If not, why not? What would stop you from supporting it?
Keeping the conversation light at this point is critical. I’m not wanting to understand all the details just yet. I just want to know, would they theoretically support this change, and if not, why not?
Thankfully, most people said they would be open to such a change. The only hesitation I encountered focused on the process. How would such a new “copy crew” work? What would be the support structures in place? How would product managers brief in copy, or bring writers into the design process?
Clearly, a theme is emerging here. Everyone supports the idea, we just need to hash out the details. Now comes the next problem.
Work on removing those roadblocks before you meet
Among the many things I’ve learned in my career, one is that if you walk into a meeting with the intention of leading a project then people actually expect you to propose a change.
At the beginning of my career, I had a very egalitarian approach. “Let’s figure it all out together!” I would say. That quickly fails. People are busy, they don’t have time to solve every problem. They need you to at least propose a plan and then they’ll naturally give critique.
With that in mind, I had these problems to solve:
- How would the new process work?
- How would product managers brief jobs in?
- What tools would we use?
- Where would this process be documented?
- How would SEO briefing be involved?
- Would the copy crew use sprints aligned with the rest of the team?
I needed to come up with answers to this question. So I went about creating a model framework that I could present. I documented it in Confluence, and received some initial critique from the UX lead before I brought the product managers together.
That way, I could show it already confident it had some support from the top.
Bring everyone together with answers already prepared
With my framework in hand, I called a meeting. I let every product manager know it was going to happen and told them I would be discussing answers to their various questions.
With that context, the meeting now has a purpose. It also becomes easier for the attendees because all they need to do is give feedback, not come up with an entire process themselves.
I presented my framework and was able to answer every single question the product managers had, even before I asked for questions. There was some discussion back and forth about some minor details, but the main pillars of conversation had been dealt with.
Imagine if I hadn’t done the prep work
Think about what might have happened if I hadn’t followed this process.
I would have gathered the product managers for a meeting without explaining the context or meaning. They would have been blindsided and the meeting wouldn’t have lasted very long. I probably would have received feedback that it was a waste of time because I still needed buy-in from the UX leader.
Then, the UX leader might have heard from someone at the meeting that I had proposed this change – without looping him in! He may have even thought this was an error in judgment and stopped my agenda immediately.
Then, if I had walked into another meeting without a proposed plan, it would have created even more problems. The discussion would have been chaotic. There would be no guiding principle for the meeting or a framework to hang the conversation on. It could easily have been derailed into different, unrelated or irrelevant topics.
Finally, if I hadn’t done any work to explain the process and document it clearly, any change would have been confusing and damaged my reputation to create beneficial, structural change.
Some principles to keep in mind
This is just one example, and every organization is different. But here are some things you should keep in mind:
Don’t view peers as the enemy
One of the first rules of influencing without authority is that you cannot view your agenda as a warpath, with colleagues taking the role of enemies who must be overcome.
Instead, every person in your team or organization is a colleague with their own personal motivation. They have challenges of their own. Your job isn’t so much to fulfill your agenda as it is to help them fulfill theirs. If you do that, the rest will fall into place.
Don’t be afraid to go over people’s heads
Now, don’t misunderstand me. You want buy-in from everyone. But often, structural change only happens because you get support from the top-down. If necessary, and if the relationship allows, you should ask a higher authority for at least some philosophical or theoretical support for your change.
That gives you ammo when you speak with various team leaders. People often want to know, is this project a waste of time? The fact you’ve achieved support from decision-makers lets them know it isn’t – you just need to hash out the detail.
Influence without authority: create change with a servant’s mindset
Think less about “what I need to make this happen”, and instead speak with decision-makers with a “what can I do for you?” mindset.
The more you do that, the more change you’ll create.