Influence, part 1 of 4: Communication
What is influence in software engineering? Why is it important?
Influence is what happens when it’s not just you any more.
One day while you’re blissfully writing code your boss comes to you and says “I need you to lead project MemeShoe. It’s a little complicated, though, as it’s not just our team. It’ll involve these five other teams, who I don’t think you know yet? Oh, and one of them’s in a different office — they’re based in Sydney.”
Or, maybe, it’s your idea. This time you’re blissfully coding when genius strikes and you see in front of you a path forward to product excellence, resource savings, and user raptures. But it’s going to need more than just your team.
Uncomfortably exciting! Where do you start? Who do you talk to? How do you get them on board with putting Memes on shoes? What are their goals? Do they align with yours? Do the timelines match up? This is important because a single team can only do so much.
Background
To give some credits first: I'm using some of the structure of this post from a history blog that I admire, ACOUP. The idea is that this'll be a four-part post happening each week about a sub-topic that's too big for one long post.
The content of this series also comes from a whole variety of people who I used to work with. When I set out to learn about how influence works in practice I did that by talking to people who seemed to be good at it. The ideas are theirs. If there are mistakes in how they’re presented here then those are mine.
I previously tried to write some of this down on Medium and I'm in the process of moving that, and other content, here instead.
Today’s big topic is: communication.
Patience
This was by far the point that came up the most. You need to have a lot of patience when working between multiple teams — things will take longer than expected, priorities will change, you may end up working on something different.
This is deeply related to timing. It may be that you have a good idea but the current moment isn’t the best time to work on it. Put it on the shelf, don’t forget about it, and come back later.
If you have a good idea then the odds are that someone else has already been thinking about it. If the company is large they might already be working on it. Find out before you get too far, especially if they stopped because it wasn’t practical to solve. If there is someone else solving the problem then that’s fine, you can move on to the next one. Do find out if they want help, though.
Listen to people
Second only to patience, you need to talk to people to be successful on broad projects. Yes, you can still be an introvert engineer and do this. No, it’s not easy.
Talking isn’t enough though, you have to understand them as best you can. What are they working on? What’s their team working on? What do they want to be working on? Are they in the middle of a launch crunch, a Code Red, or other high-stress time? What are they good at? What do they want to be good at?
This is a pretty daunting list and you’re unlikely to figure it out quickly. It also changes. Aaaarrgh!
The payoff for understanding someone, though, is that you’ll be able to work more efficiently with them and their team by looking for what matches. If there’s work that needs a certain skill, fits the team direction, and someone likes to do that sort of work it might be a good match.
Voice, vote, or veto
This is a trick that can help you understand your communication with someone when you’re asking them about a decision: are you notifying them of something? Or giving them a vote? Or a veto?
Now take a second and make sure that they are thinking of the same one as you. If in doubt, make this clear early on to avoid miscommunication.
This is a similar concept as the Responsibility Alignment Matrix — this is about agreeing on the roles of each person involved in a decision.
Lines of communication
When it comes to talking to people, you have a few options:
In person
- Slack
- Video call
- Document
- Bugs tracking pages, pull requests, etc.
Some of what you choose is going to be driven by geography and team locations, but it’s also worth thinking through what you use each one for and exactly who is included. The amount of trust that already exists is a critical factor here — impersonal methods are fine if trust is established.
Do you need a team meeting with everyone? How about a 1:1 with the Product Manager or Tech Lead or Engineering Manager every so often?
These decisions are also not static, as a project evolves you’ll want to change the comms structure. Often you can start with small meetings in person or over video calls and then as more people start to work on something you’ll have to expand with real work tracking docs, project plans, etc.
(On a related note, listen to project managers as they are experts in this and can help you.)
Solving the problem vs setting up the environment
If you have a problem to solve then should you be working on solving it? Or on setting up the environment to solve it? This is a little subtle and it applies especially to broad problems. If you can bring people together to work on a problem, and get them time to do so, then you might find that that’s going to be enough to solve the problem without you actually solving it.
You could partially rephrase this as delegation or setting up the right communication structures.
Setting up the right environment scales significantly better than you solving it yourself.
Do you need a team meeting with everyone? How about a 1:1 with the Product Manager or Tech Lead or Engineering Manager every so often?
These decisions are also not static, as a project evolves you’ll want to change the comms structure. Often you can start with small meetings in person or over video calls and then as more people start to work on something you’ll have to expand with real work tracking docs, project plans, etc.
(On a related note, listen to project managers as they are experts in this and can help you.)
Solving the problem vs setting up the environment
If you have a problem to solve then should you be working on solving it? Or on setting up the environment to solve it? This is a little subtle and it applies especially to broad problems. If you can bring people together to work on a problem, and get them time to do so, then you might find that that’s going to be enough to solve the problem without you actually solving it.
You could partially rephrase this as delegation or setting up the right communication structures.
Setting up the right environment scales significantly better than you solving it yourself.
- Some examples are:
- Getting headcount to hire people to work on a problem.
Escalating
Deferring a decision to those above you in your management chain is something that happens a lot less frequently that it should.
The simplest example is when you’re overloaded with too much work to ask your manager what they would like you to prioritize. Now you know what to work on and your manager feels like they have some control — everyone wins.
The same works when it comes to making decisions between teams. If you can’t agree on the direction to go and things have reached an impasse then it’s time to escalate. If you aren’t converging on a decision then it’s time to escalate. The first step is to agree on who should be the decider for this decision and then present both sides and let them decide.
Note that the decision may not end up being the one that you want!
We’ve shipped our org chart
This is a concise way of explaining Conway’s Law that loosely says that what we end up building will reflect the way the organization is laid out. Have an infrastructure team? You’ll end up with infrastructure! No infrastream team? Then people are more likely to build their own things.
Why is this interesting? Because the hardest communication problems tend to fall into the gaps between teams. Put another way, it’s the APIs and RPCs that are hard in a system.
If you’re starting to look at a problem that’s very broad then it’s incredibly useful to understand the org chart of the teams involved: how do they interact? Do they have different reporting lines, with different goals? Are they in different physical office locations or timezones?
It’s also useful, but not quite as important, to understand the history of how the org chart got to where it is now. How much does it change as Executives, change? What did it look like a year ago?
Deferring a decision to those above you in your management chain is something that happens a lot less frequently that it should.
The simplest example is when you’re overloaded with too much work to ask your manager what they would like you to prioritize. Now you know what to work on and your manager feels like they have some control — everyone wins.
The same works when it comes to making decisions between teams. If you can’t agree on the direction to go and things have reached an impasse then it’s time to escalate. If you aren’t converging on a decision then it’s time to escalate. The first step is to agree on who should be the decider for this decision and then present both sides and let them decide.
Note that the decision may not end up being the one that you want!
We’ve shipped our org chart
This is a concise way of explaining Conway’s Law that loosely says that what we end up building will reflect the way the organization is laid out. Have an infrastructure team? You’ll end up with infrastructure! No infrastream team? Then people are more likely to build their own things.
Why is this interesting? Because the hardest communication problems tend to fall into the gaps between teams. Put another way, it’s the APIs and RPCs that are hard in a system.
If you’re starting to look at a problem that’s very broad then it’s incredibly useful to understand the org chart of the teams involved: how do they interact? Do they have different reporting lines, with different goals? Are they in different physical office locations or timezones?
It’s also useful, but not quite as important, to understand the history of how the org chart got to where it is now. How much does it change as Executives, change? What did it look like a year ago?