As engineers grow more senior, they tend to have more impact by influencing others. You can achieve more through collaboration than you can alone.
Many companies hide engineering levels and titles. To influence others, you’ll need to rely on more than just your place in the hierarchy. All influence without authority is based on one simple concept:
Dale Carnegie: “The only way on earth to influence other people is to talk about what they want and show them how to get it”
It sounds simple but there’s a lot to it in practice. Here’s a breakdown of how it applies when getting other teams to prioritize your projects.
Understanding What Others Want
The most straightforward way to understand what others want is to learn what their team’s goals are. You can find this in their team’s plan doc. In it, you should see the motivation behind their roadmap or the metrics they are trying to move.
This is one of the fastest ways to understand what they want. A side benefit is that you can influence whole teams rather than just individuals through these motives. Learning these should be sufficient for getting most of your projects prioritized.
In some cases, it’s helpful to also understand the motives of individuals. Every person is different so it’s hard to generalize but here are some examples:
Personal Interest & Learning - some people pick up projects because they are interested or want to learn new skills
Career Growth - some people are eager to take on opportunities that will advance their careers
Making Life Easier - some people want to save time or prevent annoying breakages (e.g. one of the motivations for this project was the high maintenance cost of the old pipeline)
Showing Them How To Get It
To get another team to prioritize your project, you need to explain how it will help them get what they want. Here are two tactics that have worked well for me:
Convincing with data - Show them how your project will move metrics they care about. Queries showing how big the opportunity is can go a long way.
Establishing credibility - Your past results, domain expertise, or relationships with the other team should give them some reason to work with you. Credibility makes it a lot easier to influence others.
Convincing with data is my personal favorite since data speaks for itself. If someone comes to me with proof that their project will achieve my team’s goals, I’ll prioritize it even if I just met them.
Always Look for “Win-Wins”
Some think this advice is manipulative. However, focusing on helping people get what they want is mutually beneficial. You’re just explaining the benefits of your suggestions in terms of what they care about.
That is also why it isn’t always possible to influence others. If there’s nothing in your project that they want, then you won’t be able to sell it no matter how good you are.
When influencing others, remember to be tactful. If you upset people while trying to convince them they won’t work with you (even if you’re right):
Samuel Butler: “A man convinced against his will, is of the same opinion still”
If you’d like to learn more about influence, you can start by reading “How to Win Friends and Influence People” by Dale Carnegie. However, an even better place to learn is through experience. Try speaking about your projects in terms of what others want and see how they respond.
If you found this useful, please share it with a friend and consider subscribing if you haven’t already.
Thanks for reading,
Ryan Peterman
Influence can be seen as the result of trust your team has towards you. This trust is not built through some secret, 5-step framework but by the compounding result of small actions you bake into your process.
Listen to people, help them, and work towards mutual instead of personal goals, such as a successful release, a new feature, or a refactoring.
Great stuff, Ryan! 👏
I'm interested in understanding, when we talk about the impact on people, what level of senior engineer is required, and the collaboration you mentioned in the context that more is achieved than when working alone.
A senior should be independent in their work, but when collaborating, it is no longer independent work but teamwork. So, you might receive feedback that you're not independent enough in your work.
I'm curious, where is the boundary between independence and lack of independence in work?
How can I ensure that I remain independent in my work while collaborating with others, without it turning into dependency and needing to ask others for everything?