Module 4: Technical Leadership Without Authority

3. Borrowed authority: the trust account

Next →

Overview

By the end of this lesson you'll understand what, exactly, the influence lesson 2 showed to work is made of —because "influence instead of mandate" is good advice and an open question: influence with what?—. The answer is the central idea of this lesson: influence is paid for from a trust account. The architect's authority is borrowed —you already saw this—, and whoever lends it is each team they work with, in exchange for believing that following them leads to a better place. That trust isn't a vague state of the environment; it behaves like an account with a balance: deposits are made (correct calls that come true, help in a hard moment, admitting one's own mistake, giving credit to others) and withdrawals are made (imposing without listening, insisting on something that later fails, taking others' credit, blocking without explaining). And every time the architect tries to influence —push a decision, ask for a standard to be adopted— they spend from that balance. The consequence, which this lesson measures, is harsh and liberating at once: the same technical proposal, correct word for word, is followed or ignored according to the balance of the one who makes it. Being right doesn't travel alone; it travels on top of trust.

This matters because it explains the phenomenon that most baffles the engineer who believes in the meritocracy of ideas: why two people can say exactly the same thing and one is listened to and the other isn't. It's not injustice or office politics (though it sometimes looks like it); it's the trust account operating. When someone with a high balance proposes something, the team extends the benefit of the doubt —"they've been right before, let's try it"— and the proposal advances cheaply. When someone with a depleted balance proposes the same thing, the team spends its energy resisting —"this one imposing again, now what do they want?"— and the proposal dies even if it's impeccable. Understanding this changes the architect's strategy completely: they stop thinking their job is to be more forcefully right and start understanding that their job, most of the time, is to keep the account funded —because with no balance, being right buys nothing—.

Connection with the module: this lesson is the currency; the four practices that follow spend it. Lesson 2 established that influence is the lever; this one explains what it's paid with. Everything that comes is measured, at bottom, in this account: the guardrails (lesson 4) are a way of spending little balance —you don't spend trust approving every PR, you invest it once in a good lane—; disagree-and-commit (lesson 5) protects the balance —blocking burns it, committing cares for it—; the load-bearing conversations (lesson 6) are where most deposits are made —the hallway, the 1:1—; and consensus (lesson 7) is what you buy when you have enough balance. If lesson 2 said "influence", this one says "influencing costs trust, so learn what deposits it and what withdraws it —because you'll spend your career managing this account—".

The mountain guide you follow because they know the way

Think about it with a situation where your life depends on whom you listen to: a mountain trek. You hire a guide and go up with a group. At a certain point, the trail forks: one of the paths looks shorter and more direct, the other goes around and up an uncomfortable slope. Your instinct says "the short one". The guide says "take the long one, the short one has a stretch of loose rock that after the rain is a trap". Why do you listen to them, against your own instinct? Not because they can force you —they can't: they're your legs, you decide where you put them—. Not because they shout. You listen to them because you trust they know the way better than you: they've climbed that mountain a hundred times, they got you well out of the day's hard stretches, and when they said "it'll cloud over at two" it clouded over at two. Their authority is pure earned trust, and that's why you follow it even when it contradicts your instinct.

Now imagine that guide, in the hours before, had done the opposite. That they were wrong in every prediction ("it won't rain" and it rained), that they sent you on a shortcut that turned out to be a mudpit, that when you asked them something they answered with contempt, that they took credit for a route that another in the group actually found. You reach the fork and the guide says "take the long one". Do you listen now? Probably not —or you seriously doubt it—: "this one's been wrong all morning, the short one looks fine, I'll take the short one". And notice the important part: the guide may be right this time —the short one may really be a trap—, but they already spent all their trust, so their correct advice no longer moves you. The same phrase ("take the long one"), said by the trustworthy guide, saves you; said by the guide who burned your trust, you ignore it and maybe you fall.

That guide is the architect, and the mountain is each technical decision. The architect can't force the squad to take any path —they're their hands, their code, they decide—. They follow them, when they follow them, because they trust they know the terrain better: they've been right before, they helped when it mattered, they admitted when they were wrong. That trust is their balance, and with it they "buy" being listened to even when their advice contradicts the team's instinct. But if they burned it —imposing, failing after insisting, stealing credit—, then their correct advice no longer moves anyone: the squad takes the short path that looks good, and the architect, with all the reason in the world and not a gram of trust, is left shouting at the fork. This lesson measures that account: how it fills, how it empties, and what its balance buys.

Worked example: the same proposal, two balances, two outcomes

We model trust as an account with a ledger of events: each event deposits or withdraws trust with the payments squad. Two architects, A and B, have opposite histories —A built up a balance, B spent it—. Today, both make exactly the same correct technical proposal, which costs a certain balance to push (influencing always costs). The code computes each one's balance and decides whether the squad follows or ignores them.

# Trust is an ACCOUNT. It's DEPOSITED (correct calls, helping, admitting mistakes,
# giving credit) and WITHDRAWN (imposing, being wrong after insisting, taking the
# credit). Influence is PAID from that balance: proposing something "costs" trust,
# and if there's no balance, the proposal is ignored even if it's technically correct.

# Two architects make the SAME correct technical proposal TODAY. They differ only
# in their trust history with the payments squad.

ledger_A = [   # architect A: built up a balance
    ("Helped payments out of an incident on a Sunday",       +3),
    ("Predicted a bottleneck that did occur",                +2),
    ("Admitted that their previous proposal failed",         +2),
    ("Gave the squad public credit for an improvement",      +2),
    ("Listened and changed their mind with a good argument", +1),
]
ledger_B = [   # architect B: spent the balance
    ("Imposed a library without listening to the squad",     -2),
    ("Insisted on a design that later fell over in prod",     -3),
    ("Took the credit for an idea from the squad",           -2),
    ("Blocked PRs for months without giving context",        -2),
    ("Never acknowledged a mistake of their own",            -1),
]

PROPOSAL_COST = 4   # pushing a new standard costs 4 of trust

def balance(ledger):
    return sum(delta for _, delta in ledger)

bal_A = balance(ledger_A)
bal_B = balance(ledger_B)

print("Trust history of each architect with the payments squad:")
print()
print(f"Architect A (deposits): balance = {bal_A:+d}")
for ev, d in ledger_A:
    print(f"   {d:+d}  {ev}")
print()
print(f"Architect B (withdraws): balance = {bal_B:+d}")
for ev, d in ledger_B:
    print(f"   {d:+d}  {ev}")
print()
print(f"Both make the SAME correct proposal TODAY (pushing it costs {PROPOSAL_COST} of trust):")
for name, bal in [("A", bal_A), ("B", bal_B)]:
    if bal >= PROPOSAL_COST:
        print(f"   Architect {name}: balance {bal:+d} >= {PROPOSAL_COST}  ->  the squad follows them.")
    else:
        print(f"   Architect {name}: balance {bal:+d} <  {PROPOSAL_COST}  ->  the squad ignores them (no balance, being right isn't enough).")

What to expect. Running it:

Trust history of each architect with the payments squad:

Architect A (deposits): balance = +10
   +3  Helped payments out of an incident on a Sunday
   +2  Predicted a bottleneck that did occur
   +2  Admitted that their previous proposal failed
   +2  Gave the squad public credit for an improvement
   +1  Listened and changed their mind with a good argument

Architect B (withdraws): balance = -10
   -2  Imposed a library without listening to the squad
   -3  Insisted on a design that later fell over in prod
   -2  Took the credit for an idea from the squad
   -2  Blocked PRs for months without giving context
   -1  Never acknowledged a mistake of their own

Both make the SAME correct proposal TODAY (pushing it costs 4 of trust):
   Architect A: balance +10 >= 4  ->  the squad follows them.
   Architect B: balance -10 <  4  ->  the squad ignores them (no balance, being right isn't enough).

Stop at the line that says it all: the proposal is the same, the outcome is opposite. A and B arrive today with the same correct idea, word for word —the same standard, the same justification, the same diagram—. The difference isn't in the proposal; it's in the balance each one arrives with. A has +10 because for months they made deposits: helped in an incident on a Sunday, predicted a problem that occurred, admitted that a previous proposal of theirs failed (yes, admitting a mistake deposits trust, doesn't subtract it —we'll come back to this—), gave the squad credit, listened and changed their mind. B has −10 because they made withdrawals: imposed without listening, insisted on a design that fell over, stole credit, blocked without explaining, never acknowledged a mistake. Pushing the proposal costs 4 of trust —influencing always costs—. A can pay it (10 ≥ 4) and the squad follows them; B has nothing to pay with (−10 < 4) and the squad ignores them, even though they're right.

This is the lesson made into a number, and it dismantles a myth: the architect doesn't compete for having the best idea; they compete for having a balance so their idea is heard. B could arrive with the idea of the century and it wouldn't matter —their account is in the red, and an account in the red funds no influence—. A could arrive with a barely good idea and it would advance —their balance backs it—. This doesn't mean the quality of the idea doesn't matter (it matters for the adoption to hold, as you saw in lesson 2); it means the quality of the idea is necessary and not sufficient: with no balance, it doesn't even get evaluated on its merits, because the team already decided not to listen. Being right buys adoption only when it travels on top of trust; alone, it buys nothing.

Now look at the signs of A's ledger carefully, because they contain the counterintuitive part. Four of their five events are obvious deposits (helping, being right, giving credit, listening). But one —"admitted that their previous proposal failed"— seems like it should be a withdrawal (they were wrong!) and yet it adds +2. It's not a model error: admitting one's own mistake deposits trust, because it shows the team the architect is honest, that they won't defend the indefensible out of pride, and that their word can be trusted —when they say "this works", it'll be because they believe it, not because they don't admit otherwise—. The architect who never acknowledges a mistake (B's event, −1) doesn't seem stronger; they seem less trustworthy, because the team knows something has failed and that they're covering it up. Honesty about one's own mistakes is one of the biggest deposits available, and it's free —it only costs pride—.

Deep dive: how the account fills, how it empties, and why it's spent

The account metaphor comes from Stephen Covey (the emotional bank account), and it's worth making it operational for the architect: what deposits, what withdraws, and the odd rules of this particular account.

What deposits trust. The architect's deposits are concrete and almost all have to do with putting the team ahead of their ego. Being right in a verifiable prediction: when the architect says "this is going to become a bottleneck" and it does, next time they're listened to more —they predicted, it came true, they earned credit—. Helping when it hurts: getting in to resolve an incident on a Sunday, sitting down to pair on a thorny problem, reviewing a hard PR carefully; real help in the hard moment is worth more than ten talks. Admitting mistakes: we already saw it, it costs pride and deposits trust. Giving credit: publicly attributing a good idea to whoever had it, instead of appropriating it; every time the architect says "Ana from payments thought of this", they deposit —and make the next good idea also want to pass through them—. Listening and changing their mind: showing that their position depends on the argument and not on ego; an architect who sometimes says "you're right, you convinced me" is infinitely more influential than one who never gives.

What withdraws trust. The withdrawals are the mirror. Imposing without listening: every "because I say so" spends balance, because it communicates to the team that their judgment doesn't count. Being wrong after having insisted: it's not being wrong that withdraws (being wrong and admitting it deposits); it's being wrong after having trampled others' objections —"I insisted my design was the right one, ignored their doubts, and it fell over in prod"—; there the withdrawal is double, for the error and for the prior arrogance. Stealing credit: appropriating someone else's idea is one of the most expensive withdrawals, because the team always notices and stops bringing you their best ideas. Blocking without explaining: sitting on a PR or a decision for weeks without giving context treats the team as if it didn't deserve a reason, and spends balance every day that passes.

The odd rules of this account. It has three properties that make it different from a normal bank account, and you have to know them. First: it's asymmetric —withdrawals weigh more than deposits—. A single act of stealing credit or of imposing with arrogance can empty months of small deposits; building trust is slow and losing it is fast, like reputation. Second: it's specific to the relationship —the architect doesn't have "one" trust account, they have one with each squad—. They can have +10 with platform (whom they helped a lot) and −3 with payments (on whom they imposed a library), and their influence with each depends on their balance, not on an average. That's why an architect can move one team and crash with another with the same idea. Third, and it's the one most forgotten: the account is spent by using it, but also rots if it's never used. Spending balance by influencing is normal and necessary —that's what it's accumulated for—; the error isn't spending, it's spending faster than you deposit, or spending it all on a decision that wasn't worth it. The wise architect chooses what they spend their trust on: they reserve it for the few decisions that really matter (the cross-cutting ones, the expensive-to-revert ones) and let the others pass, because every battle they fight spends balance they won't have for the next.

The strategic consequence. All this reorders the architect's priorities. If influence is paid for from trust, then most of their work is not producing the correct ideas —that's the easy and necessary part—; it's keeping the account funded with each team, and choosing wisely what they spend it on. A brilliant architect with the account in the red is impotent; one with barely good ideas and a full account moves mountains. That's why this lesson's behaviors —helping, admitting mistakes, giving credit, listening— aren't optional "soft skills" that adorn the technical person; they're the infrastructure that makes all technical influence possible. Without them, being right is left shouting at the fork.

Common mistakes

Believing the quality of the idea is enough and neglecting the balance (of naive meritocracy). What happens: the architect invests everything in having the best idea and nothing in building trust, and crashes —their correct ideas are ignored—. Why it happens: they were trained in a world (that of machines) where the right answer wins, and they transfer that belief to the world of people, where adoption depends on the balance. How to spot it: if it frustrates you that "being right" they don't follow you, and you can't remember the last time you helped that squad or admitted a mistake in front of them, your account is empty. How to fix it: treat building trust as part of the technical work, not as something separate —deposit with correct calls, help, credit, and honesty, so that when the correct idea arrives you have something to fund its adoption—.

Spending the balance on battles that aren't worth it (of misallocation). What happens: the architect fights every decision they disagree with —a variable's name, the structure of a local table—, spends their trust on trifles, and when the cross-cutting decision that really matters arrives, they have no balance to move it. Why it happens: they don't distinguish the decisions that need their influence from the ones the squad can make alone; they treat everything as a battle. How to spot it: if you argue over many small decisions and arrive exhausted (and with no credit) at the big ones, you're misallocating. How to fix it: reserve the balance for the few decisions that justify it —the cross-cutting ones, the expensive-to-revert ones— and let the rest pass; every battle avoided is balance saved for the one that does matter. (The guardrails of lesson 4 are precisely the way not to spend balance on the small stuff.)

Not acknowledging mistakes so as "not to seem weak" (of misunderstood pride). What happens: the architect, fearing that admitting a mistake will make them look less competent, defends indefensible positions or stays silent when they're wrong —and with that they withdraw the trust they thought they were protecting—. Why it happens: they confuse authority with infallibility, and believe respect comes from never being wrong. How to spot it: if you can't remember the last time you said "I was wrong" in front of a team, and you feel doing so would cost you authority, you have the model inverted. How to fix it: understand that admitting a mistake deposits trust (A's +2) because it proves honesty and makes your word credible; the team trusts more whoever acknowledges their failures than whoever pretends not to have any, because only from the first can they rely when they say "this does work".

Exercises

Exercise 1 — Classify the account movements. For each architect action, say whether it deposits or withdraws trust with the squad, and approximately how much (a lot/a little): (a) they review a hard PR the same day, with careful comments; (b) in a meeting, they present as their own a solution a junior of the squad proposed last week; (c) they say publicly "I was wrong with last month's recommendation, yours was better"; (d) they answer "I don't have time to explain why, just do it this way".

See solution

  • (a) Reviewing a hard PR the same day, carefully → deposits (quite a bit). It's real help on something that matters to the squad, done with effort and on time. It shows the architect is available and cares about the team's work, not just their own ideas. A solid deposit.

  • (b) Presenting the junior's idea as their own → withdraws (a lot). Stealing credit is one of the most expensive withdrawals, and against a junior it's worse: the junior notices, the squad notices, and everyone learns that bringing good ideas to the architect means losing the credit. It empties trust and also dries up the flow of future ideas toward the architect.

  • (c) Admitting publicly "I was wrong, yours was better" → deposits (a lot). Counterintuitive but clear: admitting the mistake and giving credit to the squad, in public, is a double deposit. It proves honesty (their word is credible) and humility (their ego isn't above the result). The team trusts an architect capable of this far more.

  • (d) "I don't have time to explain, just do it this way" → withdraws (quite a bit). It's imposing without giving a reason —it treats the team as executors with no judgment, not as peers—. Every "just do it this way" spends balance, because it communicates to the squad that their understanding doesn't matter. Besides, it contradicts the whole module: influence is built by giving the why, not hiding it.

The rule for classifying: deposits what puts the team ahead of the architect's ego (helping, giving credit, admitting mistakes, explaining); withdraws what puts the architect's ego ahead of the team (stealing credit, imposing, hiding mistakes, denying the why).

Exercise 2 — The relationship-specific account. An architect has a balance of +8 with platform (they've helped them a lot) and a balance of −4 with payments (on whom they imposed a library they hated). They propose the same standard to both squads on the same day. Predict what happens with each one and explain why the "average" of their trust (+2) is no use to predict anything.

See solution

With platform (balance +8): the squad follows them. They have plenty of balance to pay the cost of pushing the standard (say 4); they extend the benefit of the doubt because they've been helped before, so their proposal advances cheaply —"if they say it's worth it, let's try it"—.

With payments (balance −4): the squad ignores or resists them. Not only do they have no balance to pay the influence; they have the account in the red for having imposed something they hated. Their proposal, even if identical and correct, crashes against the memory of the previous abuse —"this one imposing things on us again"—. The same idea dies here.

Why the average (+2) doesn't predict anything: trust isn't a global attribute of the architect; it's specific to each relationship. They don't have "one" reputation of +2; they have +8 with one squad and −4 with another, and their influence with each depends on that balance, not on the average. Averaging mixes two opposite realities into a number that corresponds to neither: there's no squad with which they have "+2 of trust". That's why the same architect, the same day, with the same idea, moves platform and crashes with payments. The practical lesson: the architect must keep a mental account per team and know that a negative balance with a squad has to be rebuilt with that squad (concrete deposits with them: help, admitting the mistake of the imposed library, giving credit) before expecting to influence —the credit with platform is no use at all against payments—.

Exercise 3 — Rebuild an account in the red. The lesson's architect B has −10 with payments (imposed, failed after insisting, stole credit, blocked, never admitted a mistake). They need to influence payments for an important cross-cutting decision in three months. Design a concrete deposit plan —not "earn their trust", but specific actions— and explain why the order matters.

See solution

The plan has to reverse the specific withdrawals they made, not deposit generically, and the order matters because the account is asymmetric (withdrawals weigh) and distrustful (starting from −10, every gesture is read with suspicion at first).

First, stop the bleeding and repair the concrete. Before any new deposit, stop making the withdrawals: unblock the PRs they're sitting on and give them the context that was missing (reverses the "blocked without explaining"). And repair the most visible damage: acknowledge, publicly and without excuses, that the library they imposed was a mistake and that they should have listened ("I was wrong to impose that library on you without listening to your objections; you were right"). This combines admitting the mistake (+) with acknowledging the abuse of imposing, and directly attacks two of the five withdrawals. It goes first because you can't fill an account that keeps leaking, and because a concrete and verifiable apology is the only credible deposit when the balance is so low.

Second, return the stolen credit. On the next public occasion, explicitly attribute to payments the idea they appropriated ("payments thought of this a few months ago, they were right"). It repairs the most corrosive withdrawal (stealing credit) and starts to rebuild the flow of trust.

Third, help when it hurts, without asking for anything in return. Get in to resolve a payments incident on a weekend, pair on a thorny problem, review carefully —deposits of real help, made without yet bringing the proposal they want to push—. The key is that these deposits don't come attached to an "and that's why you now adopt my standard", because that devalues them (they read as bribery). You deposit first, you ask later.

Why the order matters: starting from −10, if B arrives straight with their cross-cutting proposal, the squad reads it as the umpteenth attempt to impose and rejects it —there's no balance—. They have to first stop withdrawing (unblock, apologize), then repair the specific (return credit), then deposit unconditionally (help), and only when the balance goes positive again, then bring the important decision. Rebuilding an account in the red is slow and goes in that order —repair before asking— because lost trust isn't recovered with a great idea, but with a sequence of small and verifiable acts that prove the architect changed. And the honest nuance: three months may not be enough to get from −10 to a comfortable balance —building trust is slow—, which means for that specific decision B may need to lean on the balance of another architect or leader who does have it with payments, while they rebuild their own for the next time.

Summary and next step

In this lesson you understood what influence is made of: a trust account that's deposited and spent. With the mountain guide you saw that you follow someone against your instinct only when you trust they know the way —an authority of pure earned trust—, and that a guide who burned your trust is left shouting at the fork even if they're right. And you measured it by executing: two architects with the same correct proposal and opposite balances (+10 and −10) get opposite outcomes —A is followed, B is ignored—, because pushing a proposal costs trust and with no balance being right isn't enough. You learned what deposits (being right, helping, admitting mistakes, giving credit, listening) and what withdraws (imposing, failing after insisting, stealing credit, blocking), the surprise that admitting a mistake deposits, and the odd rules of the account: asymmetric (withdrawals weigh more), specific to each relationship (one account per squad), and that it's spent by using it —so you have to choose what to spend it on—.

Before moving on you should be able to: explain why the same proposal is followed or ignored according to the balance of the one who makes it; list concrete deposits and withdrawals; explain why admitting a mistake deposits trust; and why the architect keeps an account per team and reserves their balance for the decisions that are worth it.

What follows is the first practice that spends little balance and multiplies reach. In lesson 4 you'll see why approving every decision —being the gate— burns balance and creates the bottleneck module 1 measured, and how guardrails —investing the trust once in a good lane instead of spending it PR by PR— let the squads decide alone while the architect only touches what really touches boundaries. You'll measure the throughput of the two ways and understand the architect as a multiplier —they decide and mentor— instead of a single reviewer. It's the step from "I know influence costs trust" to "I know how to spend little and reach many decisions at once".

Resources

← Previous2. Influence instead of mandateNext →4. Guardrails instead of gates