Influencing Large Change With Little to No Authority

Hello, I've been cross domain IC for 8 months now. My focus is on significantly shifting the trajectory of data at a large 5000 person enterprise organization. I've had a number of wins and many challenges, but here are some of the strategies that I've found to successfully influence change while lacking any formal authority.

Understand and Document Reality.

Speculations and opinions only add friction to initiatives. Documenting reality requires objectively discovery and identifying the current state of things. If you want to shift delivery velocity, documenting reality requires understanding the current velocity. If you want to increase system reliability, what is the current level of reliability? What is the current state?

Documenting reality serves 2 primary purposes:

Validate or Invalidate a hypothesis about a proposed change
Provide data on the current state to inform investment into a future state

Imagine that you have an impression that the company deploys slowly because a couple of key services seem to deploy infrequently. Instead of building a case to immediately propose a change, I find it much more beneficial to openely seek an understanding of the current state. How many deploys are occurring per week? Per Service? Per Team?

It's essential to understand the current state of a system before modifying the system. Without this understanding sub optimal changes can occur.

Many times it will be difficult to get metrics, especially if your initiative is currently not a priority. Qualitative feedback in the form of interviews and surveys are critical in this case.

When documenting reality I create a document where I include reference links and data sources. The target audience is for an end user interested in the topic.

Make The Business Case.

Business is driven by the customer and is reflected in financials. Changes that link to business outcomes will tell a more compelling story than those based on experience or implementation details. Investing in unit tests may make developers lives easier, but a more compelling argument is linking it to a reduction in customer facing defects. Some common business cases are:

Customer outcomes like engagement (product usage), upselling, reducing churn, or a reduction in customer facing bugs.

Increase in revenue.
Reduction in costs.
Increase of human capacity by reduction in toil (automation).

An argument using business dimensions is widely applicable across domains. Business outcomes provide a language that can be used across the organization. Every team is interested in money, customer happiness, and moving faster. These concepts resonate, use them.

Get Inline With Your Team.

If you can't convince your team of your initiative, it's unlikely you'll convince others. Even though you don't directly manage anyone or any domain, you most likely work and collaborate closely with others. Your teammates provide a great audience to field and test your ideas. Leverage and collaborate with them to refine ideas into initiatives that will weather the larger organization.

Have a North Star.

Create a forward looking vision. What is the desired state in 3 years from now? What does a perfect state look like? A north star acts as a guide and provides a vision of what you're working towards. A north star is a visionary process that motivates your team. I’ve found a north star can be created by combining:

Customer interviews
Reasearch on how other companies have solved the issue.
The unique elements of your culture and tech.

Define Your Principles.

Principles represent an approach to problem solving. Principles provide a playbook for handling unknown problems by incorporating past learnings. As a platform team lead, I've seen from experience that bespoke 1 off single stakeholder solutions don't scale. There is a large opportunity cost in creating and maintaining one-off solutions, over more generic solutions. A principle that reflects this learning is:

Solutions should address multiple use cases or multiple teams.

This means that each solution will instantly create leverage by solving multiple problems at the same time. This document provides a list of principles.

Suppose one of your principles is:

Favor revenue generation over cost reduction.

This principle is biased towards growth and not controlling COGS. Given two competing priorities, this principles errs on the side of revenue generation. Principles help establish a framework for decision making.

Principles are maleable and should be updated as you learn and encounter new problems. Principles will be refined, new ones introduced and old ones dropped. Write your principles down. Reference them when you make decisions, and update them when you encounter new information.

Use Your Principles to Say No.

Principles can act as a defensive moat. They allow you to say "No... and here's why", backing up your decision by explaining your principles and the reasoning behind them. Use them, stick to them, and update them as you learn new information.

Understand Realistic Timelines.

Large organizations change slowly, especially when that change is driven without any official authority. Make realistic estimates. If a service takes a quarter to develop and then it's expected that each team takes 1 month to onboard to it, and the company has 30 teams that puts total project length at:

3 months development + (30 Teams * 1 Month) = 33 Months Total

Change is not instantaneous. An unrealistic idea of how fast change occurs can lead to disappointment.

Modify What You Can Control.

There will be things in your control. If your team has a budget, use it to start to build towards your vision using the alignment from your team. If you’d like to change the world, start with your own services. If you can’t succeed in a small and controlled setting than it’s unlikely you’ll succeed across the entire organization.

Most initiatives can be rescoped to demonstrate value at a smaller level in a controlled manner. These small and controlled wins are important to build your story, document impact and convince the larger organization to invest in your change.

Celebrate the Wins.

Sometimes long term change without authority might feel like an uphill battle. It’s really important to celebrate wins. Broadcast them. Link them up to business impact. Tie them back to the vision and the north star. Document how they impacted reality. Wins act as a carrot and demonstrate success and boost morale.

Accept You Will Be Overruled.

Sometimes tasks will be mandated. Sometimes by your manager, sometimes by their manager, sometimes by product, sometimes by the market or executives. The only thing to do in this case is to understand the context behind it and make sure you provide others with the context when they question why a particular initiative is being worked on. Maybe you’ll be able to spin the overruling to incorporate some aspects of your change, many times you won’t. Change in a large organization is a marathon and not a sprint.

Capitalize on Inertia.

Capture the wins of your products, document the pain of your users that your vision will solve. When someone shows interest in your solution, or a need for it, document it, meet with them, interview them, show them your vision, sell the dream. Change requires people. Interest or overlap with your change gives you an opportunity to create a relationship and tell your story. Take advantage of these opportunities. At the very least it gives you an opportunity to tell your story and put your initiative on other’s roadmaps.

Define Your Success Metrics.

Metrics are hard to get right. Bad metrics create poor incentives and can be detrimental to an organization. Initiatives need some sort of objective measurement to track towards or else success becomes qualitative based on feelings and not business outcomes.

A good metric is focused on a specific business outcome such as customer happiness, revenue, churn rate, upgrade rate, error incidents, bug rates, engagement, retention, etc.

Good metrics largely focus on outcomes that are a degree beyond your control. An example or a bad metric is one fully in your control, such as lines of code. The team could write more verbose code to hit lines of code targets. Poor metrics can create perverse incentives, which are incentives that make issues worse and move you further from the change that you would like to see.

Good metrics can be used to track the health and the impact of your change. They can be used to broadcast the value that your change provides the organization.

Build Partnerships.

Partners branch out from your team. You need to start somewhere. Look for teams feeling the pain that your change addresses. Look for teams that you can pitch your vision to and that benefit from your change succeeding.

Don’t Assume Anyone Else Can See What You See.

Don't assume that your insights and observations are known by anyone else, no matter how obvious they may seem to you. Document your thought process. Document reality as you understand it. Build the vision and project how your change impacts reality.

Send the Message And Don’t Stop.

Write, speak, demo, MVP, write some more. Don’t stop until your change is a reality. Celebrate each win. Celebrate each impacted business metric. Update and broadcast the document you created that researches the current state of reality. Each win feeds into your story and your change inertia, each team that complains about the problem that you solve, document it all, keep documenting it all, keep broadcasting it. You need to get your ideas on the companies radar.

Trust Your Vision.

You've built a northstar, defined reality, have buy-in for your team. You're enacting change in the parts of the system you control. Trust your teammates, trust your manager, trust your peers, trust that your work is making a difference in your organization and are capitalizing on every opportunity you see. If your vision is sound and defended through metrics proving it to be a good business investment it will eventually succeed.