I have become less interested in the word influence and more interested in credibility. People do not follow an individual contributor because the person sounds important; they follow when the work, timing, and evidence are useful.
For individual contributors, the better goal is credible impact without authority. People trust your judgment because your work reduces risk, clarifies tradeoffs, and helps teams make better decisions. You do not need the highest title for that. You do need evidence, relationships, timing, and consistency.
What influence means for individual contributors
When I talk about "What influence means for individual contributors", I am looking for the behavior change, not the wording of the principle.
For an individual contributor, influence is not telling people what to do. It is increasing the chance that the right technical decision happens even when you are not the manager, architect, or executive in the room.
At the team level, influence may mean your team adopts a safer release checklist because your incident review showed where releases were failing. At the organizational level, it may mean three teams stop creating separate customer status logic because you showed the cost in support tickets and billing defects. At the cross organizational level, it may mean product, legal, data, and platform teams agree on a transcript retention policy because you translated an engineering issue into customer impact and risk.
In all three cases, people are not following you because you are powerful. They are following the work because the case is clear.
Why people do not listen when you lack authority
My recommendation in "Why people do not listen when you lack authority" is to make the next action small enough that the team can try it quickly.
People do not ignore you only because they are political. Often, they ignore you because your idea arrives without enough trust, context, or cost clarity.
A team may not listen because your proposal creates work for them while the benefit looks like it helps only your team. An organization may not listen because your recommendation is technically correct but not tied to a funded priority. A cross organizational group may not listen because nobody knows who owns the decision, who pays the migration cost, or what breaks if they say yes.
Correctness is not enough. If you say, "We need a shared authorization library," teams hear migration work, release risk, unclear ownership, and possible outages. A stronger version is: "We had four authorization defects in six months. Two came from duplicated role checks. I propose we start with payment and account services, measure defect reduction, and publish a migration guide before asking other teams to move."
Examples at different levels
How to measure influence in a meaningful way
Do not measure influence by how many meetings you attend or how many people know your name. That rewards visibility more than impact.
- Decision adoption: Did the team or organization adopt the recommendation?
- Decision durability: Did the decision survive pressure after the first meeting?
- Behavior change: Did people change how they build, review, deploy, operate, or communicate?
- Reduced risk: Did incidents, rework, defects, escalations, or ambiguity go down?
- Reuse: Did another team reuse the pattern without being forced?
- Decision speed: Did your work make a hard decision faster because the tradeoffs were clear?
- Independence: Can the work continue when you are not in the room?
That last one matters. Real influence is not dependency on you. Real influence leaves behind better defaults.
The framework I try to use
What I learnt around "The framework I try to use" is that people trust change more when the cost is visible and the first step is safe.
When I am trying to move a decision without authority, I try to follow a simple sequence:
- Start with the customer, business, or production pain.
- Show evidence, not just opinion.
- Name who pays the cost.
- Make the first step smaller than the full vision.
- Give people a review point.
- Write the decision down.
- Measure whether behavior changed.
This works because people rarely resist clear, low risk, useful progress. They resist surprise, unclear ownership, and unfunded work.
Account API influence example
Imagine a platform engineer wants teams to stop calling a shared database directly and move reads behind an account API. The title is not enough to force that change. A better path is to show the problem: direct reads blocked schema changes three times, created two production defects, and made ownership unclear during support incidents.
The first ask should be small. Move two high value consumers, keep compatibility for one quarter, publish the migration guide, and review defect reduction before asking the rest of the organization to follow.
Outcome scorecard example
I use "Outcome scorecard example" to keep Influence Is Overrated grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
A small scorecard keeps the discussion tied to outcomes instead of personality. For the account API migration, the useful questions are direct: did two or more teams adopt the pattern, did defects go down, did another team reuse the migration guide, and can the work continue without the original author in every meeting?
That kind of scorecard avoids vanity metrics. It treats influence as useful only when the decision is adopted, risk goes down, other teams can reuse the pattern, and the work keeps moving without constant personal involvement.
Closing
The way I close this topic is to bring it back to credibility: did my work make the right decision easier for other people to choose?
Influence is overrated when it means personal persuasion. Credibility is underrated when it comes from doing the hard work: understanding the system, showing evidence, making tradeoffs clear, and helping people move without feeling trapped.
The best individual contributors do not win by sounding important. They win by making the right decision easier for everyone else to choose.