Take the smallest bet you can be trusted with

Everything in this book assumes something that is not true yet: that you are allowed.

Allowed to question the ticket, to set the appetite, to spend a Tuesday on containment nobody asked for, to tell a stakeholder the number came back against you. None of that is granted by reading. It is granted by somebody who has decided you can be trusted with it, and that decision is made about you long before it is made about your proposal.

What actually predicts being handed scope

I want to be careful here, because the usual version of this advice is asserted rather than measured, and I would rather give you the real state of the evidence.

The strongest finding I can offer is unglamorous. Studying why managers delegate, Yukl and Fu found that more delegation went to a subordinate “who was competent, shared the leader’s task objectives, had worked longer for the manager, was a supervisor also, and had a favorable exchange relationship with the manager.” And the other half, which is the part worth sitting with: many managers were “reluctant to give up control over important decisions or assign an important task to an inexperienced subordinate.”

Read that as a list of the doors. Competence you have. Tenure you cannot rush. Shared objectives and a favourable working relationship are the two you can actually move, and both of them are built by delivering things, not by describing them.

Now the honest caveat. The claim that trust compounds from small delivered things is my argument, not a measured result. The nearest evidence is laboratory: reciprocity games showing people return what was extended to them, with the link between trust and payback strengthening markedly once there is a visible history of past behaviour, and the old foot-in-the-door studies showing that agreeing to a small request makes a larger one more likely to be granted. Neither of those measured a manager handing a developer a bigger problem. Treat the compounding story as a working theory that matches what I have seen, and not as data.

The move

Ask for the smallest piece of the problem that one person could verify in an afternoon, and deliver it completely.

Two constraints doing the work. Small enough to verify means somebody can check you were right, which is what converts a delivery into evidence. Completely means finished, including the unglamorous end: the migration run, the old path deleted, the alert wired, the doc updated. A half-finished small thing teaches people the opposite lesson at twice the speed.

Why small matters more now than it did

This part is measured, and it is the reason this move closes an Act III rather than a career-advice book.

Producing a large change has become cheap and absorbing one has not. Across 22,000 developers, pull request size rose 51.3% while median review time rose 441.5%, and 31.3% more pull requests merged with no review at all. Organisations with mature practices got the same deterioration. Nobody’s excellence protected them.

So the constraint that used to be about your own capacity is now about everyone else’s. And DORA is explicit that batch size is one of the things deciding whether AI helps you: “working in small batches amplifies the positive impact of AI adoption on product performance.”

Choose the ground carefully too. DORA’s modelling puts AI effectiveness around 10% on complex legacy code against 35 to 40% on greenfield. Your first bet should not be the ten-year-old billing module, however much it deserves it.

A BAD FIRST BET               A GOOD FIRST BET

"let me rewrite the           "let me fix the thing that pages
 sync layer"                   us on Sundays"

  6 weeks                       3 days
  nobody can verify it          the pager stops. everyone notices.
    except you                  legacy, but one narrow seam
  touches everything            done means: fixed, alerted,
  done is a matter of             runbook updated, old path gone
    opinion
                              the person who has to say yes can
  the payoff is three           check the result without asking you
    years away

What it costs

Small does not mean faster to merge, and you should know that before you promise it. A study of 845,316 pull requests across a hundred popular projects found that size and composition “do not relate to time-to-merge”, and data from two other review platforms confirmed it. Small batches are worth doing for verifiability and blast radius. They will not get you through review any quicker, and anyone who has told you otherwise was guessing.

Trust is asymmetric, and that asymmetry is measured. Slovic’s work on trust found that trust-destroying events are rated as substantially more powerful than trust-building ones. Years of delivered small things can be undone by one confidently-wrong claim, which is the real reason the previous move insisted you honour a measurement that went against you.

And you will feel underused. Asking for a three-day problem when you can see a six-week one is genuinely uncomfortable, and for a while people will underestimate what you could take on. That is the price of the first bet and it only has to be paid once.

Try this week

Find the smallest thing you have complained about twice, and ask to own it end to end. Not to contribute to it. To own it, including the boring end.

Then say when it will be done and what done means, in one sentence, in writing, to the person who would have to notice.

And then

The number this book opened with is worth ending on. Between 2023 and 2025, US employment for people called programmers fell 27.5%. For people called software developers, the more design-oriented title, it fell 0.3%.

That gap is not about tools, or talent, or how much of your code you type yourself. It is about who decides what gets built and who is trusted to decide it. Every move in this book is a way of moving across that gap, and none of them starts with a rewrite.

They start with one small thing, finished, that somebody else could check.

Go and pick it.