On influencing team decisions (without power): reflections on tech leading

On influencing team decisions (without power): reflections on tech leading

Tags
PeopleProcessCulture
Published
March 31, 2021

Defining Power

By “power”, I mean the ability to compel others to do something, regardless of how they feel about doing it. As individual contributors, the amount of power that we can wield, as defined here, is limited.

💡
Even if/when you have an abundance of power in a given context, utilizing influence-over-power tools is still helpful for fostering alignment, getting buy-in, and maintaining trusting relationships

Background

These are a collection of my thoughts on how to make your thoughts clear to yourself and others and influence decisions that can’t be easily made in one or two meetings.

The thoughts expressed herein are my own and are not intended to represent the specific viewpoints of any employers past or present.

At the time of this publication, I have transitioned into manager. This means that I have different relationship with power now than when I initially wrote this. But the fact still remains that these tools served me well as an individual contributor, and I plan to continue to leverage them on my journey.

Consider starting with an RFC

A “Request For Comment”, or RFC for short, is a document used to facilitate informed decision making.

💡
Use RFCs when you want to get buy-in or have many open questions

Benefits:

  • Helps you to organize your thoughts
  • Helps you to anticipate and think through alternatives/likely responses
  • Gives readers a chance to process and response async
  • Leverage the RFC template

Include the relevant stakeholders and decision makers

Set a deadline for feedback. Helps to hold reviewers accountable

Consider meeting with decision makers after the review period to synthesize feedback and make a decision. Communicate said decision

Tech Specs: Going from decision to action

💡
Use Tech Specs when you are ready to break down a feature

Turn the outcome of the RFC into a Tech Spec

Great article: How to Write Awesome Tech Specs by Black Queen of Tech

“Your tech spec serves as documentation both during feature implementation and after feature launch. During feature implementation, it specifies exactly what work needs to be done. After launch, it helps uninformed engineers get up to speed quickly on the inner workings of a feature and the tradeoffs involved.
...A well thought out tech spec is a tool that works on your behalf, making your job easier and your feature better. It has a purpose — improving intra-team communication, for example, or anticipating and addressing stakeholder concerns. A tech spec without a purpose? It’s a waste of time.”

Break down the milestones that would lead to the successful execution of the initiative.

Work with domain experts to provide estimates on how long each milestone might take, how many contributors might be required, and possibly for how long.

Work with PMs and EMs to throughout the process of RFCing and Tech Specing with the ultimate goal of

  • Making the value proposition clear,
  • Getting buy in
  • Mapping the work to an OKR (or mapping an OKR to the work, if that makes sense)

Manage your expectations

This can be a time intensive process for you. Be mindful of your own capacity and hold off if you need to (although you can still jot down your ideas for later)

This can be a time intensive process for reviewers/target audience. Be mindful of timing. It may not be wise to try to push an initiative when the team that it would impact is already inundated

If you feel like you've clearly made your case, you've been heard and understood, and things still don't go your way, don't take it personally. Let it go, and if you feel strongly enough, iterate on the approach and bring it back up when timing feels better/the environment is more receptive/the need is greater/clearer