Tale of Software Engineer: Influencing without authority

Have you ever found yourself brimming with a groundbreaking idea, only to face a daunting wall of bureaucracy and limited influence? How do you navigate the intricate paths of organizational dynamics when authority is not on your side?

When you are in a position of authority, it becomes easier to influence because you can have the final say, you can override the decision. But what if you do not have the authority?

Let's take an example:

Suppose you have a super amazing idea about improving your organization's code deployment time. So what would you do? In a brute force attempt, you would create a technical specification listing the merits of your approach and share the document with the concerned team.

But to your disappointment, there is an anti-climax as the concerned team comes back to you stating that they liked your idea but at the moment they do not have any bandwidth related to this. Surely, you were not expecting this. You thought the team would be as excited about the idea as much as you were.

What are the next steps?

1. Blame approach: Start cribbing about the organization's culture: This is the easiest option. This option is helpful when you are no longer interested in working in that organization. If you have already decided to move on then this approach is better.

2. Deep dive approach: One thing that was missing from the tech spec was the concerned team's context i.e. what are their current priorities, what are their yearly goals, etc, and which of their existing priority could be replaced with your idea.

You figured out where are the yearly/quarterly priorities defined, you got hold of the information, you went through the associated key performance indicators weighed them against your idea's impact, and decided which one would be better suited.

You modified your tech spec with the added details and shared it with the team. Some of the teammates were convinced and some were again not convinced. Again an anti-climax. You were expecting a near 100% approval of your proposal.

What did we miss here?

Identifying the right stakeholders. Not all reviewers have an equal say in the decision-making process. Rather than sharing the tech spec with everyone and trying to get everybody onboard at the first attempt, we could have tried to convince the right stakeholders. For the sake of example, let's assume that the Engineering manager and Product manager are the stakeholders who make the final call on the concerned team's priority. Knowing this narrows down the problem.

You set up a meeting with both of them. You try to convince with your idea with the added context of knowing the team's current priorities and how we can put your idea on the roadmap. You have a plan this time!

Voila! To your disbelief, they agreed and decided to take your idea forward.

Let's take a step back and summarise the learnings here.

1. Execution >>> Ideas: Knowing the next best thing to bring impact is different than getting it executed in a medium to large organization.

2. Be aware of priorities: Ability to know where the organization's priorities are defined ranging from org to team level. This could be the OKR dashboard or some Excel sheet. Wherever it is, you should know about it. Be aware of any dedicated Slack channels or meeting invites where ideas are discussed and brainstormed. If you are unsure, fall back to your manager/skip manager to know the priorities of your team/org and where they are documented.

3. Identifying the right stakeholders: The ability to figure out the right stakeholders for a given initiative is very crucial. The art of navigating your organization maze is an important skill if you want to bring in a broader impact. Knowing the organization structure and who is responsible for which line of business/team could become handy to identify the right stakeholders. (The book "Staff Engineer Path" by Tanya Reilly describes this step in depth, if you are interested do have a read)

4. Building meaningful connections: Try to form as many meaningful connections in your organization as possible as it would give you a personal connection whenever you are dealing with any multiple team project/proposal. One can start by having some regular 1:1 with the existing team member with whom you work daily. This step becomes particularly difficult but all the more important when you are working in a remote environment.

Influence without authority is difficult. Every situation would demand a different solution as every org is different.

Let's take another example,

Suppose you join a new company, you have loads of learning from your previous stints at various organizations, you are filled with loads of different ideas.

As part of your onboarding process in the team in the first few weeks, you figured out that the current code review process is sub-optimal, there is no defined turnaround time (TAT) for a code review process which leads to longer time in doing code reviews, some of the review comments are going through a lot of to-fro on the repository leading to a lot of time being spent on the review.

Based on your previous learning you decided to come up with a plan, you proposed the following changes:

1. Time is of the Essence: Define TAT
2. One Shot, One Review: Streamline Feedback
3. Channeling Discussions: From Comments to Calls

What happens next? To your disappointment, not everybody was convinced. They had a pushback stating that this is not how things are done in the current organization and they do not do any discussion on the calls and since the team has a lot of ad-hoc work, they cannot agree on a TAT (turnaround time).

What did we miss here? We missed the building meaningful connection aspect (point no. 4 mentioned above). Even though you felt that your idea was right, the execution part needed everyone to be on board but since you proposed the idea too quickly without building any meaningful connection, you came across as someone stepping on someone's toes.

If you had waited for a few more weeks and taken the team to build meaningful connections first, your suggestion might not have had the same level of pushback as now you have more personal mileage apart from your suggestion.

As I said before, every situation demands a different solution for getting ideas executed, and in the end, it boils down to knowing how the respective stakeholders are taking their decision i.e. what is their mental model and what can you do to convince them so that their thought process aligns with yours.

Sometimes you will succeed and more often you will be rejected. But every failure here would help you in knowing what did not work so that you can figure out the missing piece.