People and companies rarely avoid work. They pick the work that cannot reject them. Writing an article, fixing a bug, shipping the next roadmap item - all real work, all producing output, none of it producing a verdict from anyone who could say no. The work that decides whether a business grows almost always sits on the other side of that line: the price sent, the refactor argued for, the release put in front of people who will either use it or not. This piece sets out where the line falls, why pressure pushes everyone below it, and why AI made the drift both cheaper to produce and much harder to notice. It also argues the other side: below-line work is how capability gets built, the direction of your drift is the cheapest capability audit available, and what separates growth from avoidance is whether a date exists by which someone outside the room gets to answer. It closes on the identity-first response - naming the conditions under which you actually perform, deciding which of them are constraints to design around and which are deficiencies to close, and building the base out of the strongest available material rather than the most comfortable.
Three months of excellent work that sold nothing
In my first three months in business I worked hard, and I worked most days. I wrote articles. I designed and built the website, then rebuilt parts of it. I gave free consulting to anyone who asked, and the advice was good. At the end of most days I could point to something that had not existed that morning.
What I did not do, for three months, was the direct technical outreach. The message to a specific person at a specific company saying here is what I do, here is what it costs, do you want it.
I knew this was the thing that mattered. I did not do it anyway, and the reasons were specific rather than vague. I was afraid of being told my price was too high, which I read as being told I was worth less than I had decided. I was afraid of someone saying yes and then discovering I could not deliver what I had promised. Both fears attach to the same event: a person forming a judgement about me and telling me the answer.
An article cannot do that. A website cannot do that. Free advice, given generously, cannot really do that either - if it lands badly nobody has bought anything, so nothing was refused. Every one of those was real work, and every one of them was chosen, without my ever admitting it, because none of them could come back with a no.
Work below the line produces output. Work above the line produces a verdict from someone who can refuse you.
What sits on each side
The line is not about difficulty and it is not about importance. Below-line work is often harder and frequently useful. It is defined by one property: when it is finished, no one external renders a judgement that can go against you.
| What gets chosen | What was avoided | The verdict that was skipped |
|---|---|---|
| Writing another article, redesigning the site again | Sending a price to a named person | Someone tells you what you are worth |
| Fixing bugs in a feature almost nobody opens | Finding out whether the feature should exist | A decision to remove work you already shipped |
| Shipping the next item on the roadmap | Making the case for the refactor | A room full of people asking you to justify a quarter with no feature in it |
| Another round of internal polish before launch | Putting it in front of real users | Usage data that says they do not want it |
| Rewriting the strategy deck | Killing the initiative the deck is defending | Admitting publicly that two quarters went nowhere |
Why the pull is so strong
There is a well-measured version of this in a place nobody expects. Bar-Eli and colleagues analysed 286 penalty kicks in top leagues and found that goalkeepers dive to one side or the other 93.7% of the time, even though the distribution of kick direction makes staying in the centre the better strategy. The authors' explanation is the useful part: because jumping is the norm, a goal conceded feels worse after standing still than after diving. The keeper who dives and is beaten was unlucky. The keeper who stands still and is beaten did nothing.
That is action bias, and it explains why doing something beats doing nothing. It does not, on its own, explain my three months, because writing an article is also doing something. The second layer is the one that matters: among the actions available, the ones that produce no verdict are both more comfortable to perform and easier to defend afterwards. Nobody has ever been criticised for publishing a thoughtful article. Plenty of people have been criticised for a price that was too high, or a quarter with no shipped features in it.
So the drift is not laziness, and it is not a discipline problem. It is a rational response to asymmetric social risk, which is why willpower does not fix it and structure does.
What it costs a company
At the individual level this costs months. At the company level it compounds into the two most familiar failures in software organisations, and both are measurable.
The feature number is the harder one to sit with. It means that in an average product, most of what has been built is not being used much, and the maintenance attached to it is a permanent tax on the team. Fixing those bugs is below the line, because closing a ticket produces a tick and never produces a verdict. Asking whether the feature should exist at all is above it, because the answer might be that a quarter of somebody's work should be deleted.
The refactor is the same shape. Everyone in the room agrees it is needed. It keeps not happening, not because anyone disputes the case, but because shipping the next roadmap item is defensible in a way that a quarter spent on invisible structural work is not. The team is not confused about priority. They are correctly reading which choice they will have to justify.
What AI did to this
Two things, and the second is worse than the first.
It made below-line work nearly free to produce. The output that used to take a month of genuine effort - a website, twenty articles, a brand system, a redesigned deck, a set of internal documents - now takes days. The avoidance has better production values than it used to, and a larger volume of it fits inside the same week. Anyone avoiding a hard conversation can now avoid it much more impressively.
It corrupted the signal you were using to tell whether the day went well. METR ran a randomised controlled trial with sixteen experienced open-source developers working on their own repositories, randomising whether AI tools were allowed for each task. With AI allowed, tasks took 19% longer. The developers, after the fact, believed AI had made them 20% faster. That is a gap of roughly forty points between what happened and what it felt like.
That study is about coding speed, not about avoidance, and I am not going to stretch it into a claim it does not support. What it does establish is narrower and still important: the feeling of having been productive has become an unreliable instrument. If you were already using that feeling to decide whether a week counted - and most of us are - then the one internal check that might have caught the drift is now reading wrong in a predictable direction.
What to do about it
The fix is structural, because the cause is structural. Willpower loses to a genuine asymmetry in social risk, every time.
Name the one thing that would actually change the number
One sentence, written down. For me it was: send a specific price to a specific person. For a team it might be: find out whether anyone uses this module before we spend another sprint on it. If naming it is uncomfortable, that is confirmation rather than a reason to stop.
Run the verdict question over this week's list
For every item: if this goes perfectly, who says yes or no? Mark each one above or below. Most people are shocked at the ratio the first time, which is the entire value of doing it.
Put one above-line item before the below-line work, not after
Below-line work expands to fill whatever time it is given, so it cannot be allowed to go first. One verdict-producing action per day, taken before the comfortable work opens, is enough to break the pattern.
Make the ratio visible rather than the volume
Teams already report throughput, and throughput cannot distinguish between the two sides of the line. Count how many verdict-producing things happened this month: prices sent, releases put in front of real users, initiatives killed, structural work actually scheduled. A month with a high output and a zero here is the month worth investigating.
Reduce the cost of the verdict instead of avoiding it
Most of the fear is of an irreversible public no. Make it smaller and reversible: quote one person rather than announcing a price list, test the refactor case on one sceptical colleague before the roadmap meeting, release to a slice of users rather than all of them. The reversibility and blast-radius axes are useful here in the ordinary direction too - a small reversible no is cheap to collect, and it is information.
The strongest objection, which I think is right
Everything above describes those three months as avoidance. That is true and it is not the whole account, and the part it leaves out is the part worth arguing with.
The articles built a distinction that did not exist before, and they still work as something to hand a stranger. Building the website is how I found out how to describe what I sell - not by thinking about it, but by having to write the sentence and watching it fail several times. And the free consulting taught me something I could not have been told: that I am good at conceptualising and at finding the shape of a problem, and that I am weak at the ask. None of those returns showed up in month three. All of them are load-bearing now.
So a version of the below-line work is not waste at all. It is how capability gets built, and capability has to be built somewhere.
| What below-line work actually produced | When it paid |
|---|---|
| Distinction. A body of writing that says something specific, which is now the thing that makes a stranger take the call. | Months later, and still |
| Language. The ability to describe the offer in one sentence, learned by writing it badly a number of times. | On every call since |
| Self-knowledge. Where the capability is, and where the gap is. | Immediately, once I admitted it |
The distinction that makes this usable
James March drew the canonical version of this tension in 1991: organizations have to divide finite resources between exploitation, using what they already know to improve present returns, and exploration, searching for information that improves future ones. His finding runs against the direction of this article rather than with it - March argued that firms systematically over-invest in exploitation and starve exploration, because the returns to exploration are distant, uncertain, and easy to defer.
That is worth taking seriously, and the resolution is a definition rather than a compromise. Exploration, in March's sense, returns information about the world. It is above the line. An experiment, a new market tried, a price tested, a feature put in front of people who might ignore it - all of these come back and tell you something you did not know, and any of them can come back badly. That is exactly what makes them exploration rather than preparation.
Below-line work is not exploration. It is rehearsal. It builds the capability that a verdict will eventually test, and it returns nothing about the world on its own, because nothing about the world was consulted.
Is there a date by which something outside this room will tell me whether it worked?
Rehearsal is not a lesser activity. A performance nobody rehearsed for is usually bad. But rehearsal converts into capability only when a performance eventually happens, and a rehearsal with no scheduled performance does not compound - it just gets more elaborate. Which is precisely what my three months were: real capability being built, with no date on which anything would test it.
The part I got wrong, and it is the useful part
I learned that I am weak at the ask. Notice how. Not by doing outreach badly - by watching myself not do it. The avoidance was the diagnostic instrument. It told me where the gap was more reliably than any amount of self-assessment would have, because drift is honest in a way that intention is not.
Which turns the whole frame around, and this is the version I would now defend: what you gravitate toward tells you your capability, and what you keep postponing tells you your gap. The drift is not only a cost. Read on purpose, it is the cheapest capability audit available. The waste is not in drifting - it is in drifting for three months without ever asking what the direction of the drift was telling me.
The same argument inside a company
Organizations run this pattern at scale, and there the growth case is even stronger. The feature nobody used taught the product team something about the market. The migration that went badly taught the engineering group how to sequence the next one. Learning to prioritise is genuinely learned by prioritising wrongly at low stakes, and no amount of framework adoption substitutes for having done it. A company with no history of getting this wrong is a company that has not yet been tested.
Two conditions decide whether that becomes capability or cost.
The lesson has to be captured, or it gets re-purchased every year
The failure mode is not the unused feature. It is the fourth unused feature, built by a team that never wrote down what the first three taught them. When a company has been "learning to prioritise" for six years, it is not learning. It is paying tuition on the same course repeatedly, and the tuition is a quarter of engineering capacity each time.
What keeps getting deprioritised is a capability signal, not a priority signal
If the refactor has been postponed four quarters running while everyone agrees it matters, the organization is not telling you it is unimportant. It is telling you the organization cannot currently defend work that produces no demo. That is a governance gap, and it will keep eating the same item until someone fixes the mechanism rather than the backlog.
March's other warning applies here directly. A firm that only exploits gets efficient at something that stops mattering. A firm that only explores never converts any of it - he called that a failure trap, and it looks from the inside exactly like a company that is always learning and never shipping. Both failures feel like work. Only one of them feels like waste while it is happening, and it is not the dangerous one.
So the honest version
Below-line work builds what you will need. Above-line work finds out whether you needed it. A period made entirely of the first is not a wasted period, and it is also not a business yet - and the thing that converts one into the other is a date on which somebody outside the building gets to answer.
Two limits worth keeping, both narrower than the ones I started with. Sometimes below-line work genuinely is the constraint - brand, tooling, documentation and refactoring can each be the thing unblocking everything else. The test is not whether work produces a verdict, but whether it was chosen for a reason you can state. And some periods are legitimately preparatory - a real build phase, a regulated launch, a founder learning a domain. The signal to watch is not a week without verdicts. It is the verdict-producing item moving to next month with a fresh and reasonable justification each time. Mine had three consecutive reasonable justifications, and every one of them was true.
Identity first: plan for who you are now
Everything so far describes a pattern and a cost. It does not say what to do when you find the pattern in yourself, and the default answer is usually wrong.
The default answer to "I avoid the ask" is "get better at the ask." Read about sales, take the course, practise the objection handling. That is a legitimate project. It is also a project with its own timeline, its own reading list, and its own capacity to absorb three more months - and if it happens instead of asking anyone for anything, it is the same drift wearing a more responsible outfit. Self-improvement is the most defensible below-line work there is.
Identity first is the other move. It means describing the conditions under which you actually perform, and then designing the plan so those conditions are met, rather than writing a plan that assumes a person you are not yet.
Mine, stated plainly: I perform with confidence when I have a base under me - enough understanding of the domain, enough support around the work, enough experience to know what I am walking into. Without that I hesitate, and the hesitation shows up as choosing work that cannot refuse me.
Whether that requirement is objectively necessary or a protective habit I picked up somewhere is a genuinely open question, and a slow one to answer. For planning purposes it does not matter. It is true of me now, this quarter, on this timeline. A plan built on the version of me that does not need the base is a plan built for someone else.
Constraint or deficiency, and why the classification costs a year
The distinction that makes this operational is simple and almost always got wrong.
| A deficiency | A constraint | |
|---|---|---|
| What it is | Something absent that can be added on a known timeline | A stable property of how you work, at least for now |
| What you do | Close it. Train, hire, buy, practise. | Design around it. Sequence the plan so it is satisfied rather than tested. |
| Cost of misreading it | Treating a constraint as a deficiency: a year of self-improvement while the actual work waits | Treating a deficiency as a constraint: permanently routing around something you could have fixed in six weeks |
My need for a base is a constraint. It has been consistent across every job I have had, it does not respond to being disapproved of, and pretending otherwise has never once produced a different result. My inexperience with pricing conversations was a deficiency - a specific, closable gap. Those two require opposite responses, and I spent the first months applying the wrong one to both.
The base was real. The way I was building it was the weak one
Here is where the research is unkind in a useful way. Bandura's work on self-efficacy establishes that a person's belief in their capability on a specific task is the strongest single predictor of whether they will attempt it, how hard they will work, and how long they persist when it gets difficult. So the instinct that I need a base before I can perform is not an excuse. It is a description of a real mechanism, and building the base is legitimate preparation.
The problem is which base. Bandura ranks four sources of self-efficacy, and they are not equal. Mastery experience - having actually done the thing and had it go acceptably - is by a distance the strongest. Vicarious experience, watching someone similar succeed, is weaker. Verbal persuasion, being told or reading that you can, is weaker still.
Which lands somewhere uncomfortable. The base I needed in order to make the ask could only be built out of small versions of the ask. Articles and a website are not a weak version of that base. They are a different base entirely - useful for other things, and close to inert for this one. Three months of the weakest available source, to build confidence in the one activity that only responds to the strongest.
What this actually changes in a plan
Had I known this in month one, I would not have skipped the base. I would have bounded it. Six weeks, a stated end date, built from ten small asks rather than ten articles, with the articles running alongside as the thing they actually are - long-horizon distinction, not preparation for selling. The three months were not the wrong activity. They were an unbounded, unscheduled, weakly-sourced version of a real requirement.
That is the whole of identity first as a planning discipline: name the condition, decide whether it is a constraint or a deficiency, build the condition out of the strongest available material, and put a date on it. And meanwhile push where the ground is firmer, because working from a position of strength is not avoidance when it is chosen and bounded.
Organizations have an identity too
Every plan a company writes contains an implicit claim about what kind of company it is. Most failed plans are not wrong about the market. They are written for an organization that does not exist yet.
A company that has only ever sold to small teams cannot decide to sell to enterprise next quarter. That is not a resource problem, and adding an enterprise salesperson to an organization with no security review process, no procurement experience, and no reference customers does not close it. The org has a current state, and the plan either accounts for it or breaks against it.
Say what has to be true for this team to execute this
Not what the team should be. What must be in place for the plan to work: a capability that exists, a process that has been run before, a decision someone is authorised to make. Write the list before the timeline, because the list determines the timeline.
Sort each item into constraint or deficiency
Deficiencies get an owner and a date. Constraints get designed around, and the plan is sequenced so they are satisfied rather than tested. A quarter that tests four constraints at once is not ambitious, it is unscheduled.
Build capability from small real deliveries, not from a rollout
The organizational version of the mastery finding. A team learns to ship to enterprise by shipping to one demanding customer, not by adopting a framework for it. A team learns to prioritise by making three prioritisation calls that had consequences, not by installing a scoring model.
Read the backlog as a description, not a plan
What a team consistently postpones is its identity showing. That is information about what the organization can currently defend and currently do. Treat it as a diagnosis of the mechanism, then either design around it or change it deliberately - but not both in the same quarter.
The point of working identity first, for a person or a company, is not acceptance and it is not a softer standard. It is that the shortest route to a destination starts from where you are standing, and a plan drawn from anywhere else adds distance without anybody noticing it was added.
Why I write about this one
Because the three months were not wasted, exactly. The articles are still up, the site still works, and some of that free advice turned into people who know what I do. But none of it was the constraint, and I knew that the whole time. The work only started moving when I sent a price to a specific person and let them answer.
It is also the pattern I see most often inside companies, and it is almost never described as fear, because at the organisational level nobody experiences it as fear. It is experienced as a full roadmap, a busy team, and a quarter that somehow did not move the number. Underneath it is the same asymmetry: a scoreboard nobody owns, work that is easy to defend, and one decision that keeps not getting made.
Sources
- Bandura, A., self-efficacy theory. Overview via the American Psychological Association. Source of the finding that task-specific self-efficacy predicts whether a person attempts something and how long they persist, and of the ranking of the four sources of efficacy beliefs with mastery experience strongest and verbal persuasion among the weakest.
- March, J. G., "Exploration and Exploitation in Organizational Learning", Organization Science, 2(1), 71-87, 1991. Source of the exploration and exploitation framing, and of the argument that firms tend to over-invest in exploitation - a finding that runs against the direction of this article and is addressed rather than omitted.
- Bar-Eli, M., Azar, O. H., Ritov, I., Keidar-Levin, Y. and Schein, G., "Action bias among elite soccer goalkeepers: The case of penalty kicks", Journal of Economic Psychology, 28(5), 606-621, 2007. Source of the 93.7% figure across 286 analysed kicks, and of the norm-theory explanation for why a bad outcome feels worse after inaction.
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", July 2025. Randomised controlled trial, 16 experienced developers on their own repositories. Source of both the 19% slowdown and the 20% perceived speed-up. Small sample and a specific task type; read as a strong signal about perception rather than a universal claim about AI and speed.
- Pendo, 2024 Product Benchmarks. Source of the finding that 6.4 of every 100 launched features drive 80% of click volume, rising to 15.6 for best-in-class products. Vendor research based on the company's own analytics install base, and read here as directional.
- Companion pieces: The Deliberate Slow on reversibility and blast radius, and The Coverage Model on why an important number often has no owner.