← Notes
33 views

The Sticking Door

Most work friction is a door that sticks. Nobody fixes it, so everyone learns to live around it.

Friction is anything between you and the work.

The Teams call that should have been a message. The ticket you chase for a week to install normal software. The stand-up where eight people confirm nothing has changed.

The thing you need is buried in SharePoint, or trapped behind a half-hour slot in someone's calendar next Tuesday. None of it is the work. All of it slows the work down.

Most people stop noticing: they work around the squeak, the form, the delay, the meeting. I have spent enough time on the wrong side of it to stop being polite.

It is expensive too: interrupt hard work and it takes about twenty-five minutes to get properly back into it.[1]

Do that all day and you get the modern office: busy, tired, and mostly checked out.[2]

Most of it was someone's decision. A form, a rule, a sign-off. Nobody removed it, so everyone else learned to live around it.

I do not want to.

Leave things better than you found them

The job is to make things simpler: leave every system, process, or meeting cleaner than you found it.

If someone spends every Tuesday copying numbers between two systems, the question is not how to make them faster. It is why a person is doing it at all.

Repetitive work piles up until half the week is maintenance nobody chose. Even Google's SRE teams treat that as a hard limit: keep toil under half of anyone's time.[3]

Give me the problem

The worst instruction is "have a look into this." Look into what? By when? What would done look like?

Give a sharp person a clear, hard problem and they vanish into it. Give them a vague one and they stall, because there is nothing to push against.

Clear goals beat "do your best" in study after study.[4] A vague brief is a manager handing you their job without admitting that is what they are doing.

Work needs an owner, too. When a job belongs to everyone it belongs to no one, and people do less when nobody can see their part.[5]

Keep decisions close to the work

Most bad process is a decision made too far from the work.

Someone with the context writes a ticket for someone without it, who calls a meeting to recover it. By the time permission arrives, the ten-minute fix has become a project.

Put the decision where the knowledge is. If you trust someone with the result, trust them with the small choices that get there.

Protect focus

You sit down, the noise drops away, and three hours vanish. The hard part is done. Psychologists call it flow.[6]

It is where the good work happens, and it is easy to wreck. Most developers say recovering from an interruption is a serious problem.[7]

A wall-to-wall calendar is a broken week, not a badge of honour. Every meeting and every "quick question" should have to earn the damage it does. Most cannot.

Write things down. Work async by default. Treat a live meeting as the exception, not the reflex.

Trust adults

You spent weeks hiring this person. Then on day one you hand them a locked-down laptop and make them fill in a form to get a second monitor.

A capable adult should not need permission to fix the obvious thing or install the normal tools of their job.

Hire someone for their judgement, then treat them like they cannot be trusted with a browser extension, and you are paying them to stop thinking.

Developers want their own setup because they work better with tools they chose and know, not because they are precious about it. Fighting your tools is one of the things that measurably slows you down.[12]

Move someone from a tuned machine onto a sluggish remote desktop and watch their output collapse. Then everyone wonders why they seem slower.

Low control over your own work is linked to worse health over time.[8]

I have spent years removing the friction between me and my work. Do not spend my first week putting it back.

Build it, then judge what shipped

Some arguments run for weeks on paper and end in minutes once someone builds the thing. Build a rough version first and let it answer the question; working software has always told you more than a document can.[9]

Meetings are fine occasionally and dismal as the default. Unnecessary ones cost American business an estimated quarter of a trillion dollars a year.[10]

So build the thing and show it to people, instead of making a slideshow about it. And then judge what comes out, not how busy it looked along the way.

A full calendar, a green Slack dot, a camera-on stand-up, a tidy Jira board: none of it means anything if nobody shipped.

Show the diff, the prototype, the fixed bug, the customer actually using it, rather than a deck explaining that a workstream is amber.

The best idea should win

A good idea does not care about job titles. The newest person can be right and the founder can be wrong.

People have to feel safe enough to say so. It is what the best teams have in common: they can speak up, admit mistakes, and say "I think this is wrong."[11]

A colleague finding the flaw on Tuesday is cheap. A customer finding it in production on Friday night is not.

Make things, don't just use them

I want to build the thing, not get good at clicking buttons in someone else's software.

There is a path where you become the expert in some vendor product, fluent in menus you did not design, and never make anything of your own. I want no part of it.

Progress is the point: it is the biggest day-to-day motivator at work, ahead of money or praise,[13] and the managers in the same research ranked it last.

That gap is how you end up with pizza lunches for morale while the person who shipped the fix that mattered gets "nice work" buried in a chat thread.

Real belonging

For some people the social side of work runs itself. Others spend the Monday chat looking for a way in and never quite find one.

A workplace either makes room for the second kind of person or it does not, and you can tell which very quickly.

Real belonging is not a mug that says "bring your whole self to work." It is a place that makes room for how you work without making you ask three times in writing.

In the UK, only about three in ten autistic people are in work, against roughly eight in ten non-disabled people.[14] A lot of that gap is simply an unwillingness to adjust.

When two people who think differently misunderstand each other, the blame usually lands on the unusual one. The evidence says the misunderstanding runs both ways.[15]

Fake inclusion is worse than none. Once people see the gap between the words and the reality, they trust the place less than if it had said nothing at all.[16]

AI, used well, removes friction

I use AI every day, and I judge it the way I judge any other tool here: does it make the work easier, clearer, or faster?

When it does, it clears the dull work: boilerplate, comparison, summaries, first drafts. In one trial, developers with an AI assistant finished about 55% faster.[17]

A blank screen is friction too. Asking for a rough version, hating half of it, and editing from there is still movement.

The catch is that it does not think for you, and if you ask it a vague question you get a vague answer straight back.

Make it grind through the boring part, then let a human decide what survives, and it removes friction. Use it instead of thinking, and it just makes more slop, faster.

What I would actually build

Strip all of this down and it is simple.

Work arrives as a clear problem with your name on it. It is quiet enough to think. The computer is one you chose. Decisions sit with the people doing the work.

When people disagree, you build the thing and look. Trust is the default. Permission is the exception.

The evidence points the same way. In one randomised trial, home working raised output and roughly halved quitting.[18] The friction was never holding the work together. It was only ever slowing it down.

I am not spending forty years being bored to death by process nobody can be bothered to fix. I would rather build the alternative.

The sticking door

You have met this door.

The kitchen door that catches. The side gate everyone lifts and shoves without thinking. It annoyed people for a week. Then it became part of the house.

Most work friction is that door. It is why you reach Friday exhausted and still cannot point to one thing you made.

An engineer is the person who still hears the squeak and turns up with the oil. I would rather keep doing that than slowly go deaf to it.

References

  1. Mark, Gloria. Attention Span: A Groundbreaking Way to Restore Balance, Happiness and Productivity. Hanover Square Press, 2023. (Average attention on a screen around 47 seconds; about 25 minutes to return to an interrupted task.)
  2. Gallup. State of the Global Workplace: 2026 Report. (Roughly one in five employees engaged; low engagement costs the world economy an estimated $10 trillion, about 9% of GDP.) https://www.gallup.com/workplace/349484/state-of-the-global-workplace.aspx
  3. Rau, Vivek. "Eliminating Toil" (Ch. 5), in Site Reliability Engineering: How Google Runs Production Systems. O'Reilly, 2016. (Keep toil under 50% of an engineer's time; measured average around 33%.) https://sre.google/sre-book/eliminating-toil/
  4. Locke, E. A., & Latham, G. P. "Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey". American Psychologist, 57(9), 705-717, 2002. (Specific, difficult goals beat "do your best"; meta-analytic effect sizes .42 to .80.) https://doi.org/10.1037/0003-066X.57.9.705
  5. Karau, S. J., & Williams, K. D. "Social Loafing: A Meta-Analytic Review and Theoretical Integration". Journal of Personality and Social Psychology, 65(4), 681-706, 1993. (Effort drops when an individual's contribution can't be singled out; 78 studies.) See also Latane, Williams & Harkins, "Many hands make light the work", 1979. https://doi.org/10.1037/0022-3514.65.4.681
  6. Csikszentmihalyi, Mihaly. Flow: The Psychology of Optimal Experience. Harper & Row, 1990. https://openlibrary.org/isbn/0060162538
  7. Parnin, C., & Rugaber, S. "Resumption Strategies for Interrupted Programming Tasks". Proc. ICPC 2009, IEEE, 80-89. (62% of surveyed developers called recovering from interruptions a serious problem.) https://doi.org/10.1109/ICPC.2009.5090030
  8. Bosma, H., Marmot, M. G., Hemingway, H., et al. "Low job control and risk of coronary heart disease in Whitehall II (prospective cohort) study". BMJ, 314(7080), 558-565, 1997. (Persistently low job control: odds ratio 1.93, 95% CI 1.34 to 2.77.) https://doi.org/10.1136/bmj.314.7080.558
  9. Beck, K., et al. Manifesto for Agile Software Development, 2001. ("Working software over comprehensive documentation".) https://agilemanifesto.org/
  10. Rogelberg, S. G. The Surprising Science of Meetings: How You Can Lead Your Team to Peak Performance. Oxford University Press, 2019. (A reasonable estimate of more than $250 billion a year wasted on unnecessary meetings in the US.) https://global.oup.com/academic/product/the-surprising-science-of-meetings-9780190689216
  11. Edmondson, A. C. "Psychological Safety and Learning Behavior in Work Teams". Administrative Science Quarterly, 44(2), 350-383, 1999. The finding was echoed by Google's Project Aristotle (2015), which ranked psychological safety the most important factor in its most effective teams. https://doi.org/10.2307/2666999
  12. Noda, A., Storey, M.-A., Forsgren, N., & Greiler, M. "DevEx: What Actually Drives Productivity". ACM Queue, 21(2), 2023. (Friction in development tools measurably reduces productivity and flow.) https://doi.org/10.1145/3595878
  13. Amabile, T. M., & Kramer, S. J. "The Power of Small Wins". Harvard Business Review, 89(5), 2011. (Across roughly 12,000 daily diary entries, progress in meaningful work was the biggest day-to-day motivator; managers ranked it last.) https://hbr.org/2011/05/the-power-of-small-wins
  14. Office for National Statistics. Outcomes for disabled people in the UK: 2021. ONS, 2022. (Autistic employment rate 29.0% versus 81.6% for non-disabled people.) https://www.ons.gov.uk/peoplepopulationandcommunity/healthandsocialcare/disability/articles/outcomesfordisabledpeopleintheuk/2021
  15. Milton, D. E. M. "On the ontological status of autism: the 'double empathy problem'". Disability & Society, 27(6), 883-887, 2012. https://doi.org/10.1080/09687599.2012.710008
  16. Baker, A. C., Larcker, D. F., McClure, C. G., et al. "Diversity Washing". Journal of Accounting Research, 62(5), 2024. (Firms that discuss diversity beyond what they practise earn better ratings yet incur more discrimination problems.) See also Koch, Mechler & Denner, "The diversity washing dilemma", Public Relations Review, 2025: once people spot the gap, the signalling backfires. https://doi.org/10.1111/1475-679X.12542
  17. Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot". arXiv:2302.06590, 2023. (In a controlled trial, developers using an AI assistant completed a coding task 55.8% faster than those without.) https://arxiv.org/abs/2302.06590
  18. Bloom, N., Liang, J., Roberts, J., & Ying, Z. J. "Does Working from Home Work? Evidence from a Chinese Experiment". Quarterly Journal of Economics, 130(1), 2015. (Randomised home working: +13% performance, attrition roughly halved.) A 2024 follow-up in Nature found hybrid work cut attrition by about a third with no loss of performance. https://doi.org/10.1093/qje/qju032