How to be bold

A staff engineer I worked with sat through a ninety-minute design review and said one thing in it. The team was about to put a new service behind a queue that she had already watched fail in this exact way, at her last company, twice. What she said was: "I wonder if we should think about what happens under backpressure."

Nobody argued with her, which is the tell. Someone wrote "look at backpressure" on the whiteboard, the meeting moved on, and eleven weeks later the queue did the thing she knew it would do. On a Friday. During a customer demo.

She wasn't wrong about the technology. She was wrong about the sentence. What she needed to say was: "this will fall over under backpressure inside a quarter, the mechanism is the retry storm on the consumer side, and if it doesn't happen I'll buy the round." Same knowledge, same person, same room. Completely different outcome, because only one of those two sentences can be checked, and a sentence that can't be checked doesn't survive the walk to the car park.

Most people who get told they should be bolder hear it as a note about their personality. Speak up more. Have more presence. Show more conviction. That's useless as advice, because it names a feeling, and feelings aren't instructions. Boldness is mechanical. It's a small set of things you do with sentences, with timing, and with your own records, and you can learn them the way you learned to write a design doc.

This guide is the mechanics. The org-level machinery around decisions (who decides, how fast, how you disagree and commit) is covered in Decisions, disagreement, and speed. What's here is the other half: what you personally do, in the room, when you have a view.

Bold means a claim you can lose

Here's the operational definition, and everything else in this guide falls out of it. You're being bold when you say something specific enough that you could be publicly, checkably wrong about it.

Not louder. Not more certain. Specific.

That's the difference between a preference and a position. "I'd probably lean towards Postgres here" is a preference. Nobody can score it, nobody can act on it, and in six months nobody will remember you said it. "We should use Postgres, and if we go with the document store we'll be hand-rolling a join layer by March" is a position. It has a claim, a timeframe, and a way to tell afterwards whether you were right.

There's a body of research on this that's worth knowing, mostly because half of it is a trap.

The encouraging half: hedged speech measurably costs you. One communications study found that executives who stripped the qualifiers out of their presentations were rated 28% more competent and 25% more persuasive by the same audiences hearing the same content. Every "I might be wrong but," "just a thought," and "does that make sense?" is doing work against you.

The trap is the other half. There's a long line of research on what's called the confidence heuristic, and it says something uncomfortable: confident advisers hold sway regardless of whether they're accurate. Worse, in Kennedy, Anderson and Moore's work on overconfidence and status and the advice-taking studies that followed, people's interest in checking an adviser's track record went down as the adviser's confidence went up. The more sure you sound, the less anyone bothers finding out if you were right.

So sounding certain works whether or not you are. Which means your organisation will happily reward you for being confidently wrong for years, and it will not correct you, and you should find that alarming rather than convenient. The discipline has to be self-imposed, because the environment isn't going to impose it. That's what the scorecard at the end of this guide is for.

The goal, then, isn't to sound more certain. Certainty is cheap and the market for it is rigged. The goal is to be more specific, because specificity is the only thing that's both persuasive and falsifiable at the same time.

Where an opinion actually comes from

You can't be bold about something you haven't looked at, and a lot of what reads as timidity is just not having done the reading. Fix that first. It's boring and it works.

Once you have looked, it helps to know which of three things you're standing on, because they don't have the same strength and pretending otherwise is how you lose arguments you were right about.

Pattern. You've watched this happen more than twice, in different companies, with different people, and it went the same way each time. This is the strongest source you have for anything about people, delivery and organisational structure, because that stuff moves slowly and the failure modes rhyme across decades. It's also the one that betrays you hardest on technology, because the thing you watched fail in 2019 may have been rebuilt twice since, and "I've seen this before" is indistinguishable from "I've stopped looking" right up until someone checks.

Evidence. The numbers in front of you say it. Strong when you took the measurement and know what it leaves out, weak when it's a vendor's chart or a benchmark run on somebody else's workload.

Taste. You believe systems should work a certain way. Completely legitimate, and a lot of good architecture comes from nothing else. Just say that's what it is. Taste presented as evidence gets found out, usually by the one person in the room who checks, and the cost isn't losing that argument, it's that everything you say afterwards gets quietly discounted.

Which brings up "strong opinions, loosely held," a phrase that has done more damage than the forecasting practice it came from ever intended. The problem isn't the idea. It's that the two halves get performed for different audiences. You perform the strong half out loud, and you hold the loose half privately, so everyone in the room hears pure conviction and you're the only person who knows there's a dial behind it. Then when you update, it looks like you flip-flopped rather than like the system working.

Tetlock's version is better and it's one word longer: say the number. "I'm about 70% on this" tells the room how hard to push back, which "I feel strongly" does not. It also gives you something to score yourself against later.

And a number does one more thing, quietly. It makes updating cheap. Moving from 70% to 40% is an ordinary Tuesday. Moving from "I was certain" to "I was wrong" is an identity event, and people avoid identity events, which is exactly how organisations end up with senior leaders who can't reverse anything they've said out loud.

Two questions pick your posture

Whether to drive, push, or say nothing comes down to two questions, and you can answer both in about four seconds.

Do you own the outcome? And do you have the context?

Own it and know it, and you drive. Decide. Say what you decided and why, in writing, and move on. No meeting, no consultation round, no socialising it first. If it's reversible and it's yours, the deliberation costs more than the occasional wrong answer does.

Own it without the context, and you go get the context, on a clock you set out loud. "I'll decide by Thursday, I need to talk to two people first." The clock is the important half, because an owner without context defaults to whoever is loudest in the room, and loudest is uncorrelated with right. The confidence heuristic is dangerous precisely because it fills this gap.

Know it without owning it, and you push once, properly, then let go. This is the cell that generates almost all of the pain, and people fail it in both directions.

Neither, and you ask a question. Not a statement disguised as a question, which everyone can hear anyway. An actual question. This cell is bigger than ambitious people want it to be, and the fastest way to be taken seriously in a new job is to live in it honestly for a month.

That third cell deserves more than a line, because it's where careers get quietly decided.

The first way to fail it is silence. It's not your call, you don't want to step on the owner, so you say the safe version or nothing. That's what happened in the design review. The information dies in your head and the org pays for it later without ever knowing there was a moment where it could have been avoided.

The second way is the long campaign. You raise it in the meeting. Then again in the follow-up thread. Then in a DM to two sympathetic people. Then at the offsite, with a slide. It feels like conviction from the inside. From the outside it reads as lobbying, and it burns the credibility that made the first version worth listening to. You'll be described as having a bee in your bonnet about it, and after that the substance stops mattering.

Push once, at full strength, on the record, to the person whose call it is. Then commit or leave. Those are the two options and there isn't a third one hiding behind them.

The mechanics of pushing

Six things, all of them small.

Go early in the conversation. Once three people have spoken, you're commenting on a frame someone else built. The first four minutes set what the discussion is even about, and whoever sets it has an advantage so large that most people never notice it's there.

Say three sentences: claim, confidence, condition. "I think we keep this in the monolith. I'm about 80% on it. What would move me is if deploy contention is genuinely costing us more than a day a week, which I doubt but haven't measured." That's it. The third sentence is the one people skip, and it's the one that turns you from someone with a strong opinion into someone worth arguing with.

Put a date on it. "This will hurt" is not a position. "This will hurt by Q2, and the way we'll know is on-call pager volume" is.

A date is what lets the future settle an argument you're having now.

Write it down. A thing said in a meeting reaches the people in the meeting; a thing written reaches everyone who comes after it, including whoever joins in six months and has to work out why any of this looks the way it does. Writing also forces the specificity, which is precisely why people avoid it and reach for the meeting instead. See Writing is the multiplier.

Go to the owner, not around them. If it matters enough to escalate, escalate up your own line, once, and tell the owner you're doing it before you do it. Building a coalition sideways before the person whose call it is has even heard the argument is the single fastest way to become someone the organisation manages rather than consults, and the reputation outlives the issue by years.

Then commit properly, in the execution, without the running commentary. No slow version, no "well, I did say." Your willingness to lose an argument and then implement the winning answer well is the entire reason anyone will let you push next time. Nobody makes room for someone who sulks.

When to hold back

This is the half that gets left out of most advice about boldness, and without it you just get a louder version of the same person. Six situations where the right move is to say less.

You haven't done the reading. Ask instead, and say that's what you're doing. "I don't know enough about this to have a view, what am I missing?" costs you nothing and buys you the right to have a view next time.

You're the most senior person in the room and the question is genuinely open. Speaking first collapses the range. You'll get agreement and mistake it for consensus, and you'll never find out what the three people who deferred actually thought.

Say it out loud when you do it: "I have a view, I'll give it at the end, I want yours first." Otherwise your silence reads as disapproval and you get the same collapse by a different route.

It's reversible and it isn't yours. Let people be wrong in the two-way doors. That's how they build the judgement you'll want them to have when a one-way door finally shows up, and there's no other way to build it, because judgement doesn't transfer by being told. The urge to correct a cheap mistake is one of the most expensive habits a senior person can develop, and it's expensive in a way that's genuinely hard to see, since every individual correction looks helpful. What it teaches, cumulatively, is that decisions route upward. You'll be complaining about that within the year while continuing to cause it.

What you want to say is about the person rather than the work. Different conversation, different room, nobody else in it.

You've already said it once. Covered above, but it's the rule people break most, so it gets listed twice.

You're out of budget. Which needs its own section.

The conviction budget

You get roughly three things a quarter that you'll go to the wall for. Not because of a rule somebody made up, but because of arithmetic. Each one costs political capital, other people's patience, and several weeks of your own attention after the fact, and there isn't more of any of those than there is. Most people spend theirs by accident anyway, in ones and twos, on whatever happened to come up in whatever meeting they happened to be sitting in, and then the thing that genuinely mattered arrives in week ten and there's nothing left in the account.

So pick them in advance.

Write down the two or three things you would actually escalate over this quarter. Everything else gets a position stated clearly, once, and then your full support regardless of which way it goes. The list changes when the business changes. It should be short enough that you can say it out loud without looking it up.

The test is simple and slightly uncomfortable. If you can't name, right now, the thing you're currently willing to be wrong about in front of your CEO, you're not being bold. You're being loud on a schedule.

Keep your own scorecard

The org won't keep it for you. That's what the confidence research means in practice: nobody's buying the data on whether you were right, so the feedback loop that would calibrate you doesn't exist unless you build it yourself.

Four columns, one line per call. What you claimed, the date, the confidence number, and what would have changed your mind. Ten minutes at the end of the quarter to go back through it, which is less time than you'll spend that same week deciding where to have lunch.

Two patterns to look for.

If you're never wrong, you aren't being specific enough. Go back and read what you actually wrote, and you'll usually find the vagueness was doing exactly the job you hired it to do. Some proportion of your calls should turn out badly. If none of them do, you're waiting for a certainty that isn't available, and the cost of that shows up in things that never happened, which is the hardest cost in the world to notice.

If you're wrong about the same category twice, that's a source problem rather than a judgement problem. You're running on pattern where the pattern has expired, or on taste you've been presenting as evidence. Both are fixable once you can see which one it is, and neither is visible without the record.

One warning about how you read the scorecard. Annie Duke's word for the failure mode is resulting: judging a decision by how it turned out rather than by what you knew when you made it. It cuts both ways. A well-reasoned call that went badly was still a good call, and a lucky guess is not a track record. Score the reasoning, not the outcome, and score the outcome separately so you can tell the difference.

Then there's the move that buys more credibility than anything else in this guide, and that almost nobody makes: reversing yourself out loud, on the record, naming what changed. "In March I said we'd need a platform team by now. I was wrong, and here's specifically what I got wrong about it." It costs a great deal less than it feels like it's going to, and it's the thing that makes your next confident statement worth listening to. A leader who has never publicly reversed anything is a leader nobody brings new information to.

What it actually costs

Worth being honest about the price, because most writing on this subject isn't.

You'll be wrong in public a few times a year, and it stings more than the calibration argument makes it sound. Some people will find you difficult, and a few of them will be right. Decisions will go against you and you'll have to execute them well anyway, which is harder than being overruled and gets very little sympathy.

What you get back is that people start bringing you things before they're decided instead of after. That's the whole return, and it's enormous, because the difference between a technical leader who changes outcomes and one who explains them is almost entirely a question of when they hear about things.

Start small. Pick the next meeting where you know the answer and would normally give the safe version of it. Give it in three sentences instead: the claim, the number, and what would change your mind. Write it down afterwards with a date on it.

Then go and see, in a quarter, whether you were right.