The Myth of Role Based Leadership
Most people who work in software absorb a very specific myth early on, usually so early and so thoroughly that it never registers as a belief at all, just a description of how things obviously are.
Leadership, according to this story, begins at the moment someone tells you it has begun.
A title appears. A role description stabilizes. A box on the org chart acquires your name. Only then, finally authorized, are you meant to think in terms of direction instead of execution, outcomes instead of tickets, other people’s work instead of your own.
This belief persists because it is useful. It keeps the world navigable. It divides labor cleanly between those who decide and those who implement. It allows you to tell yourself, with a kind of professional innocence, that coherence is someone else’s problem. For a long time, especially early in a career, this even appears to be true. There really is someone steering. There really is a person whose job it is to know where things are going. You can focus locally and trust that the system, in aggregate, has a plan.
The problem is that this belief expires quietly.
It does not collapse in a dramatic failure. It erodes. It erodes in meetings where everyone is senior, everyone is competent, and yet the conversation drifts in circles because no one can quite say what success would look like without sounding either naive or exposed. It erodes when architectural decisions that clearly matter keep getting deferred, not because they are controversial, but because owning them would mean absorbing risk without explicit permission. It erodes when alignment exists only at the level of slogans, while day to day work pulls in mutually incompatible directions.
This is hopefully the moment when an experienced IC has a realization that feels less like insight and more like vertigo. There is no one driving. Or rather, there are many people driving, each with a partial map, each convinced they are being responsible, none of whom have both the authority and the clarity required to steer the whole thing.
The Staff engineer role tends to emerge right here, often before it ever appears on paper. Not as a promotion, but as a pressure gradient. It does not arrive with a ceremony. It arrives as expectation. You notice that people start looking at you when discussions stall, not because you are officially in charge, but because someone needs to say something that moves the conversation forward. They ask for your read when tradeoffs get uncomfortable. They forward you threads that are already too long and say some version of can you help untangle this, which is another way of saying please make this make sense.
What makes this moment unsettling is that nothing about your formal power has changed. You still cannot hire. You still cannot fire. You still cannot set priorities by decree. And yet, there is a growing, mostly unspoken assumption that you will help the system move anyway. That you will provide shape where there is drift. That you will name the thing that everyone else can feel but no one quite wants to articulate.
This is where the myth of role based leadership finally breaks down. Leadership, it turns out, is not something conferred by title so much as something that emerges when a system lacks direction and someone begins to supply it. Authority is an artifact of organizational design. Leadership is a behavior. It shows up whether or not the org chart is prepared to acknowledge it.
The discomfort here matters. It forces a reckoning. If leadership were only about roles, then the absence of a role would excuse inaction. You could wait. You could stay clean. You could tell yourself that noticing the problem was enough. But once you see that leadership is already happening, just unevenly and often badly, the question becomes harder to avoid.
If you can reduce confusion. If you can lower risk. If you can make the next step clearer.
What exactly is stopping you?
The Constraint. Power You Do Not Have
There is a tempting version of this conversation that skips the constraint entirely. It talks about influence and communication and leading from where you are, and it sounds generous and affirming and just vague enough to let everyone feel included. It is also wrong in a very specific way. It pretends that power is either irrelevant or evenly distributed, which is comforting until the moment you try to change something that actually matters.
So it is worth stopping here and stating the limitation plainly, without apology and without trying to sand it down.
As an IC, you do not have power in the enforceable sense. You cannot compel behavior. You cannot attach consequences to disagreement. You cannot resolve conflict by invoking hierarchy and watching the room recalibrate. You do not control headcount, compensation, performance reviews, or promotions. When priorities collide, you do not get the final word simply because you are experienced, articulate, or correct.
This is not an oversight. It is the shape of the role.
Pretending that authority does not matter is not principled. It is naive. Large systems move the way they do precisely because authority exists somewhere, even when it is fragmented, even when it is poorly aligned, even when it is exercised indirectly. If you ignore this reality, you end up with leadership advice that works only in hypotheticals. Just set direction. Just hold people accountable. These instructions quietly assume a kind of power you do not actually possess, which is why they fail so reliably in practice.
The absence of formal authority is not a footnote to technical leadership as an IC. It is the defining condition. Everything else follows from this.
Once you accept that you cannot force alignment, the nature of the work changes. The question is no longer how to make people do things. The question becomes how to make forward motion feel safer than stasis. How to make clarity cheaper than confusion. How to make decisions less frightening than the slow erosion that comes from not making them at all.
This is where many senior engineers stall, often without realizing it. The instinct, especially for people who have been rewarded for individual execution, is to compensate for lack of authority with effort. More documents. More messages. More meetings. More presence. The activity level rises. The system gets louder. And somehow, nothing actually moves. Pushing harder starts to feel like leadership, which is how noise disguises itself as progress.
Effective leadership under this constraint does not come from intensity. It comes from usefulness. Very specific, very targeted usefulness.
Usefulness here means absorbing ambiguity instead of redistributing it. It means noticing when a discussion is circling because nobody wants to be the one who names the tradeoff and therefore the risk. It means making that risk explicit enough that it can be discussed, which is another way of saying shared, instead of silently avoided. It means taking responsibility for sense making even when you cannot take responsibility for outcomes in the formal, org chart sense.
There is an uncomfortable shift embedded in this. Leadership stops being about permission and starts being about responsibility. Not responsibility as in blame, but responsibility as in response ability. The capacity to respond when the system is unclear and waiting for someone else to act would itself be a choice.
At this point, technical leadership stops being aspirational. It stops being something you imagine yourself doing someday. It becomes practical. Immediate. Slightly burdensome.
You either learn how to operate inside this constraint, or you retreat back into the safety of execution and quietly resent the people who seem to have more power than they deserve, which is a very human response and also a dead end.
Everything that follows lives inside this limitation.
Influence as the Primary Mechanism
Once you accept that you do not have authority, and once you stop hoping that some future title will retroactively justify your discomfort, you are left with a quieter and more unsettling question.
Why would anyone listen to you at all?
Influence is what remains when authority is absent. It is not persuasion in the rhetorical sense and it is not charisma, despite how often those get confused. It is voluntary followership. People choosing to take your input seriously even when there is no obligation to do so, even when ignoring you would be cheaper in the short term. People adjusting their behavior because your involvement reduces uncertainty rather than adding another variable to account for.
This kind of influence does not come from brilliance, which is convenient because brilliance is unreliable. It arrives in bursts. It disappears under stress. It also has the unfortunate habit of making other people defensive. Influence, by contrast, is built on reliability, which is so unglamorous that it often goes unnoticed until the moment it fails. Reliability is closing loops. It is doing what you said you would do. It is showing up when things get messy instead of going quiet and hoping someone else will absorb the damage.
Over time, something subtle happens. People stop checking. They stop reminding. They stop hedging around your involvement. Your name on a thread lowers anxiety instead of raising it. This is not admiration. It is relief. And relief is a powerful motivator.
From reliability grows credibility, which is frequently misunderstood and often misused. Credibility is not being right all the time. In fact, people who are right all the time are usually exhausting to work with. Credibility is judgment that holds under pressure. It is knowing which details matter and which ones are noise. It is being able to say "this worries me" without triggering panic, and "this is fine" without sounding complacent. It is being wrong occasionally in visible ways and handling it without defensiveness, which paradoxically makes people trust you more.
Alongside reliability and credibility sits social capital, a phrase that sounds transactional until you look closely at how it actually accumulates. Social capital is not networking. It is generosity under constraint. You help people succeed when it costs you something. Time. Attention. Focus. You explain context instead of hoarding it. You sponsor ideas that are not yours. You give credit away publicly and feedback privately. None of this feels like leadership while you are doing it. It feels like extra work, which is why many people avoid it.
The strange thing about influence built this way is how invisible it feels from the inside. There is no moment where it switches on. No announcement. No internal notification that you have crossed some threshold. One day you simply notice that conversations slow down when you speak. People ask follow up questions instead of moving on. Threads pause instead of fragmenting. This is not dominance. It is trust.
And trust alone is still not leadership.
Leadership begins when influence stops being a way to win arguments and starts being a way to remove the excuses that were making those arguments feel necessary in the first place. When the goal stops being agreement and starts being shared understanding. This is the transition point where many technically strong ICs fail. They can persuade. They can convince. They can even rally. But persuasion without clarity just creates louder confusion.
The deeper value they can offer is sense making. Taking a messy situation and making it intelligible enough that other people can act without constant supervision or reassurance.
Which is where the work actually gets uncomfortable.
Clarity as Leadership
Most technical failures are explained, after the fact and with great confidence, as execution problems. We shipped too slowly. We chose the wrong abstraction. We underestimated complexity. These explanations are attractive because they imply a fix that lives at the level of skill. If we had better engineers, better processes, better estimates, this would not have happened.
What they tend to hide is a simpler and more uncomfortable truth. People were solving different problems while believing they were aligned.
Misalignment is quiet. It does not announce itself. It hides behind shared language. Everyone agrees on the words and disagrees on the meaning. Scale means one thing to one team and something else entirely to another. Ownership sounds clear until something breaks and suddenly it belongs to everyone and therefore to no one. By the time the failure becomes visible, it has usually been locked in for months.
This is where technical leadership without authority does its most consequential work. Not by deciding, and not by asserting correctness, but by clarifying what is actually being decided.
The IC leader becomes a synthesizer. Someone who notices that three parallel conversations are circling the same anxiety without naming it. Someone who can see that teams are optimizing locally in ways that feel responsible in isolation and damaging in aggregate. Someone who can zoom out without floating away, who can talk about system health without losing contact with the lived reality of day to day work.
This zooming out is not abstraction for its own sake. It is an act of reattachment. It reconnects technical choices to their consequences. Not in general terms, but in uncomfortable specifics.
- What becomes easier if this works?
- What breaks if it does not?
- Who pays the cost?
- When?
These questions are rarely asked out loud because they force tradeoffs into the open. Once a tradeoff is named, neutrality disappears. Silence stops being safe. Someone has to own the fact that choosing one thing means not choosing another. Clarity removes plausible deniability, which is precisely why organizations resist it even as they claim to want it.
Naming reality clearly and early is a leadership act because it changes the physics of the conversation. Vague discomfort turns into something discussable. Circular debate collapses into explicit disagreement. People stop arguing past each other and start arguing about the same thing, which is real progress even when it does not feel like it.
This kind of clarity is not about being right. It is about being legible. About making the current state of the system understandable enough that people can orient themselves inside it without constantly checking the room for signals. When you do this consistently, you reduce cognitive load across the organization. Fewer people are guessing. Fewer people are hedging. Fewer people are waiting for permission that will never come.
At a certain point, something shifts. Influence stops being personal and starts becoming structural. The way you frame problems begins to outlast your presence. Decisions get made using your language even when you are not there to defend it.
Which is precisely why the next step matters.
Because clarity that lives only in conversation evaporates. And leadership that cannot survive absence does not scale.
Writing as a Force Multiplier
Conversation is where ideas are born, which is also where they learn how easy it is to stay vague.
Spoken agreement is cheap. It feels productive. It produces nods, momentum, and the pleasant sensation that something important just happened. Everyone leaves the call believing they are aligned, which is technically true only in the weakest possible sense. They share a mood. They do not share a model. Two hours later, each person is executing against a slightly different interpretation, and the divergence is invisible until it is expensive.
Writing interferes with this process in a way that is both irritating and essential.
When you write a design document, an RFC, or even a plain problem statement, you are forcing thinking to slow down to a speed where contradictions can no longer outrun it. Vague goals harden into sentences that either mean something or collapse under their own weight. Assumptions that felt harmless in conversation suddenly demand to be named, because the page does not let them hide behind tone or confidence.
This is why writing is such an effective leadership tool for ICs. It does not rely on presence. It does not rely on authority. It does not rely on social leverage. It creates an object that anyone can point at and react to. Agreement becomes explicit. Disagreement becomes legible. Silence becomes informative instead of ambiguous.
There is also a redistribution of power that happens here. Meetings reward speed, confidence, and the ability to think out loud without self consciousness. Written artifacts reward clarity. They give quieter engineers time to form thoughts without competing for airtime. They allow disagreement without performance. They surface concerns that would never survive the social friction of a live room.
This is not incidental. It is cultural.
A written culture accumulates understanding. It creates memory. Decisions stop needing to be re litigated every time a new person joins or a week passes. Alignment becomes something you can reference instead of something you have to recreate. The system becomes less fragile because it relies less on who happens to be present at the right moment.
This is also where writing quietly scales your leadership.
When clarity lives in documents instead of conversations, your influence is no longer bounded by the rooms you can physically enter or the meetings you can attend. People make decisions using your framing without needing you there to restate it. New hires absorb context without a guided oral history. Teams move without waiting for another sync to feel safe doing so.
This is why meeting driven organizations feel both busy and strangely static. So much energy is spent recreating alignment that very little is left for movement. Written cultures, by contrast, turn alignment into infrastructure.
For the IC leader, this is not optional overhead. It is the mechanism by which leadership survives absence. If you want your thinking to matter after you leave the room, you put it somewhere others can interrogate, challenge, and improve.
And once you can do that, once you can create durable clarity in writing, another door opens.
You can propose direction without pretending it is a decree. You can sketch futures without claiming ownership of them.
You can lead without a mandate.
Vision and Strategy Without Mandate
There is a persistent confusion in technical organizations between proposing direction and declaring it. The confusion is understandable, because both actions use the same language and produce the same documents, and yet they land very differently in the room.
Managers declare. They are allowed to. IC leaders propose. They have to.
Pretending otherwise is one of the fastest ways to generate quiet resistance.
A technical vision is not a prediction and it is not a promise. It is not a prophecy about the future or a commitment to deliver specific outcomes. It is an attempt at coherence. It answers a question that many organizations avoid answering out loud because doing so would make tradeoffs unavoidable. Given who we are, what we are building, and the constraints we are not escaping, where does it make sense to go.
A technical strategy exists to keep that vision from collapsing under contact with reality. It is not a roadmap with better vocabulary. It is an explanation of how movement actually happens under constraint. Headcount that will not magically double. Systems that will not be rewritten. Skills that exist unevenly across the team. Time that is already spoken for. Fatigue that accumulates whether or not it is acknowledged. Strategy does not deny these things. It works inside them.
Leading directionally without a mandate means holding vision and strategy lightly but clearly. You write them down. You share them early, before they feel finished. You invite criticism that might reshape them instead of defending every sentence as if it were law. You make it obvious that what you are offering is a proposal, not a verdict.
This distinction matters because people will follow direction they had a chance to understand and contest in ways they will resist if it arrives fully formed. Proposing direction creates space for ownership to spread. Declaring direction without authority creates friction and erodes trust, even when the direction itself is sound.
Written artifacts make this possible. They allow alignment to emerge without control. Teams can make local decisions that still point in roughly the same direction because the direction is legible enough to orient against. Coordination becomes lighter. Supervision becomes less necessary.
There is also a subtle psychological shift that happens when vision exists in writing. Disagreement stops feeling personal. People argue with the idea instead of the person. This is essential for IC leadership. You are not trying to win. You are trying to converge. You are trying to create a future state that survives more than one voice.
At a certain scale, however, proposals reach a limit. Some work requires resources that only formal authority can allocate. Time. People. Priority. This is the point where many IC leaders hesitate, either out of discomfort or out of a belief that engaging with power somehow contaminates the work.
It does not.
Leadership that refuses to engage with power is not principled. It is ineffective.
Borrowed Authority. Sponsorship and Power Proxies
There is a moment when clarity, influence, and even beautifully written proposals run into a boundary that cannot be negotiated away. The work needs time. It needs people. It needs priority. And none of those appear simply because an idea is good or widely understood.
This is where sponsorship enters, and where many IC leaders feel a reflexive discomfort they do not always examine.
Sponsorship is not approval. Approval is cheap. It is a nod in a meeting. A positive emoji on a document. A “sounds right” that dissolves the first time something louder demands attention. Sponsorship is different. Sponsorship is someone with formal authority deciding to spend that authority on your behalf. To protect the work when it competes with other work. To say yes to people you'll never meet. To accept that if this fails, some of the responsibility is theirs.
Large initiatives fail constantly because this distinction is ignored. A plan can be technically sound, socially accepted, and still starve because no one with power feels accountable for its survival. Without sponsorship, your work remains optional. Optional work is what organizations sacrifice first, usually while insisting they are still committed to it in spirit.
Borrowing authority starts with making the work legible to the people who hold it. This means translating technical risk into organizational risk. Delay. Reliability. Revenue. Reputation. It means being explicit about what you need. Not vaguely. Headcount. Time. Sequencing. Tradeoffs. It also means resisting the temptation to oversell certainty. Sponsors do not need guarantees. They need clarity about what they are agreeing to absorb.
A sponsor is not someone who agrees with you. A sponsor is someone who is willing to own the consequences with you.
When this relationship exists, the nature of your leadership changes. You are no longer pushing from the margins, hoping alignment holds. You are operating with a power proxy. The initiative stops being your idea and becomes the organization’s intent. This shift is subtle and decisive. Conversations change tone. Resistance surfaces earlier. Decisions that once drifted now land.
It is also temporary. Borrowed authority expires. It is tied to the work, not to you. This is not a flaw. It is what keeps IC leadership grounded in contribution rather than control.
Once sponsorship is in place, another illusion tends to fall apart. The idea that decisions are made where the agenda says they are made.
Decision Making Reality. Where Power Actually Lives
Formal meetings are where decisions are announced. They are almost never where decisions are made.
By the time a high stakes question reaches a large forum, most of the thinking has already happened, just not collectively and not in one place. Opinions have formed in private. Concerns have been tested quietly. Alliances have shifted without ever being named as such. The meeting exists to confirm what has already congealed, not to discover anything new.
This is why last minute objections feel so disruptive. They are not new information. They are evidence that alignment work failed earlier, when disagreement was still cheap and reputations were not yet attached to positions. What looks like stubbornness in the room is often fear. Fear of being held responsible for a decision that arrived fully formed and too late to influence.
IC leaders who learn this stop treating meetings as the primary venue for leadership. They move upstream. They share drafts before they feel ready. They ask for reactions instead of approval. They surface discomfort while it can still reshape the work instead of hardening into resistance.
This is not politics in the pejorative sense. It is respect for how human systems coordinate under uncertainty.
Pre work is how you turn meetings from battlegrounds into convergence points. It allows people to save face. It reduces surprise. It lets disagreement show up as improvement rather than obstruction. When this groundwork is done well, the meeting feels almost boring, which is usually a sign that leadership has already happened.
Understanding where power actually lives lets the IC leader work with the system instead of exhausting themselves by pushing against it. Influence becomes coordination. Alignment becomes something you build gradually instead of something you demand all at once.
And then, once the decision is made, the work that looks the least like leadership begins.
Execution Under Ambiguity
Execution without line management is where many well intentioned initiatives quietly decay.
The failure mode is rarely effort. People are usually trying. The failure mode is ambiguity. Unclear ownership. Unnamed dependencies. Assumptions that everyone believes everyone else shares. Work moves until it encounters the first conflict, and then it stalls while everyone waits for someone else to clarify what is supposed to happen next.
This is where IC leadership becomes unapologetically unglamorous.
You define roles explicitly, even when it feels awkward. Who decides. Who does the work. Who is consulted. Who just needs to know. You treat ownership as a design decision rather than a social accident. You name the thing that everyone is tiptoeing around because naming it would make someone responsible.
You watch for stalls. Threads that go quiet without resolution. Tasks that bounce between teams. Decisions that keep reopening under slightly different names. When you see them, you intervene by restoring orientation. You restate the goal. You restate the constraints. You identify the next step that actually reduces uncertainty.
You ask the obvious question others avoid because it sounds naive or confrontational. Are we actually agreeing to do this. What happens if we do not. Who is on the hook.
This kind of leadership feels risky because it removes excuses. It forces the system to acknowledge that inaction is also a choice. But it is also what keeps work moving when authority is diffuse and responsibility is easy to avoid.
Over time, something subtle happens again.
People start copying you.
Modeling the Standard
Much of technical leadership happens without instruction, and often without intention. People learn what matters by watching what is tolerated.
Code reviews are cultural artifacts. They teach what the organization values. Are they careful or performative? Are they generous or territorial? Are they focused on long term health or short term cleverness? Incidents are moral theater. They reveal whether mistakes produce learning or blame, calm or panic, curiosity or fear.
As an IC leader, you set the standard simply by how you behave when things are under stress. You absorb pressure instead of amplifying it. You take responsibility for outcomes without hoarding credit. You treat failures as signals from the system rather than indictments of individuals.
This influence is passive and powerful precisely because it is not announced. People copy what works. Calm spreads. Rigor spreads. Care spreads. So does cynicism, which is why this part of the role is heavier than it looks.
All of this, however, rests on something that cannot be improvised.
Technical Competence as the Load Bearing Wall
Leadership without technical competence collapses the moment a hard decision appears.
You do not need to be the deepest expert in every area. You do need to understand the system well enough to know where uncertainty lives. You need to recognize when abstraction is helpful and when it is hiding risk. You need to make decisions that age reasonably well, which is a different skill than being correct in the moment.
Staying close to the system is not about ego or control. It is about maintaining judgment. Code, architecture, and operational reality provide constant feedback. Distance dulls that signal. Over time, detachment feels like clarity, right up until it fails.
When people trust your technical judgment, they will accept your leadership even when they disagree with your conclusions. When they do not, influence evaporates quickly and often without warning.
Which brings us to the quiet ending of this whole argument.
Leadership as an Emergent Property
If you want to know whether you are leading, do not look at your title. Look at what people bring you.
Messy problems. Unclear ownership. Decisions with real downside. Situations where the system is stuck and someone needs to make sense of it before anything else can happen.
That pull is the signal. Leadership is already occurring. The org chart is simply lagging behind reality.
The uncomfortable truth is that you do not get to opt out once the system starts relying on you. You can ignore it. You can retreat back into execution. You can tell yourself that this is not your job. But the need does not disappear. It just reappears somewhere else, usually in worse form.
Technical leadership without authority is harder, more fragile, and more honest than role based power. It cannot be delegated to a title. It cannot be enforced. It has to be earned again and again, often without recognition and almost always without permission.
And if you are already doing it, someone noticed long before you did.