Last week I participated in a panel discussion for SFELC Conf2020: an engineering leadership conference. The topic of discussion was How To Influence Others As A Senior IC.
Will Larson asked me a thought-provoking question that inspired me to write this post!
The Question
What are the anti-patterns of influencing? What are the approaches to influencing that folks should try to steer away from?
My Answer
Here are the three anti-patterns I came up with: back-channeling, appealing to authority, and rushing to take actions immediately.
- Avoid back-channeling, which is having side conversations about the issue without the person you’re trying to influence. Especially avoid back-channeling with folks in that person’s reporting chain. If you’re having trouble influencing someone directly, you may be tempted to reach out to their manager, especially if you already have a relationship established with that person.
- Back-channeling is a common influence technique, but it’s one that exists to solve symptoms rather than dealing with an issue head-on.
- Back-channeling creates in-groups, asymmetric information dynamics, and sows distrust.
- Healthy company cultures have fewer needs for back-channeling.
- Don’t appeal to your own authority from the start, only use this if a decision needs to be made to move on.
- Leading people to align on something works better if you don’t leverage your title.
- It’s ok to flex your knowledge and title when people are stuck and/or looking for a decision maker. But don’t assume that’s what’s needed.
- Not every issue needs to be escalated / discussed right away. A principal engineer I work with taught me a valuable lesson about picking battles and waiting for strategic timing to influence people.
- Rather than grabbing a pitch fork and joining the angry mob, wait and think through the situation strategically.
- Is this an opportunity to have impact?
- Can I solve this?
- Who can help?
- Plant seeds and coach people around you.
Story
Related to the third bullet above, I want to share a personal experience with how I learned that lesson.
I was hearing a lot of negative feedback from engineers that our new RFC process was slowing everyone down. It was confusing, people didn’t know which projects needed RFCs, who needed to review them, and what a negative review would mean. I was concerned that the negative sentiment was growing and wanted more data about how many people felt that way.
I reached out to a principal engineer to get advice. I mentioned that I wanted to start a slack poll to get a better understanding of how widespread those views were.
The engineer advised me to please not do it. This would have probably turned into a contentious, distracting discussion, with a bias to attract the most divided opinions.
She explained that we needed to wait until a few other things calmed down before addressing this issue. So we waited. In the coming weeks, we reminded people about an existing anonymous feedback survey, where they could send their strongly worded concerns. Then we held a retrospective to address what’s working and what’s not. Most recently, we established a subcommittee to work on evolving the RFC and architecture review processes.
By avoiding the initial urge to act immediately, I felt like I was able to influence improvements to the process in more strategic ways.
Conclusion
This is all very subjective, but I hope these three influence anti-patterns make sense. Are there any other ones you’ve noticed?
punkrockpolly 