Influence, part 4 of 5: Tactical tips

 This is the fourth part of a five part series on influence as a Staff+ Software Engineer (part 1, part 2, part 3, part 4, part 5).  I've ported this here from where I originally published it on Medium. 

Tactical tips

Give credit

If in doubt, add a credits section to your docs and presentations to thank the people who have worked on something with you. It’s likely that you’ve been talking to them to refine your ideas and make plans, and it’s only polite — they’ll be far more likely to work with you in the future and share ideas. The combined wisdom of these people is likely to be greater than your own.

This shouldn’t be a zero sum game, even when it comes to design docs for perf.

It’s entirely fair to ask others to also include credits sections.

Write the doc and know how to circulate it

If you have a good idea then put it into a one page doc. Bonus points if you can actually make it one page long! This is good for a few reasons: it’ll make you clarify exactly what you’re thinking, it gives people something to comment on that’s easier to track than an email thread, and it’s another artifact of the work you’ve been doing.

Great, you have a doc. Now what?

Don’t send it to every possible person at once. The odds are good that at least some bits of your doc aren’t ready yet, and if you send it to everyone then they’ll likely only ever read it once and so not see the finished version.

Instead, pick a few people who you trust and send it to them. Address their comments — a comment should lead to a change in the doc! — and include their ideas. Make sure to give credit as appropriate. If the idea still looks viable send it to a few more people until you have diminishing-comment returns. At that point send it out to a broader audience.

Not all of the docs you write will survive. Some of the ideas will be terrible. That’s okay, just so long as not all of them are terrible! See accept failures.

Use KPIs (aka OKRs)

Let’s talk about the OKRs that other teams have — these can tell you a lot and be extremely useful.

They’ll tell you precisely what the team’s priorities are. How will your project fit into there? If you think it’s a very high priority and for them it’s a low priority then hopefully you’ll be able to see that. Reading through a team’s planning history will also tell you how frequently they change direction and what they’ve shipped before.

The other place that OKRs are invaluable is in making sure that work you’d like a team to do will happen. If it’s not in their OKRs then all bets are off. Even if it’s there at a low priority it still might not happen. OKR planning is a negotiation between many parties so if a team can’t take on work you want then try to understand why not: is it incompatible with what they do? Or are they overstretched? (Hint: everyone is overstretched.)

Take meeting notes

Almost every meeting should have meeting notes. (Meetings with lawyers have their own rules.)

If no-one else takes them and sends them out then it’s useful if you do it. The main thing about doing this is that it helps to prevent miscommunication — sometimes people leave the same meeting with very different ideas of the next steps and what’s agreed on. It’s also a convenient place to list action items that you or others should be following up on.

It shouldn’t always be the same person taking notes, though — share the burden.

Defer to experts

You’re not an expert on everything. Try and find out who is and defer to them on pieces of design. This is effectively delegation. However, you need to know who’s good at what and what they like doing.

This can also play into escalation if both parties can agree that someone is a trusted expert then you can defer the decision to them.

How to use design reviews

The whole purpose of these is to look for flaws in the proposed design. However, frequently they happen as the very last stage before building a system and it can be expensive to change direction at this point.

To avoid this, try and review as early as possible before too much has been invested.

The framing of the review is hugely important — this isn’t about criticizing the author of the design, it’s about making sure that the design stands the best chance of succeeding as possible.