The seven frictions, and how to find yours in two hours
Almost every delay between an approved idea and a live user lands in one of seven places. A whiteboard, two dates and the people who waited are enough to find yours.
Mahesh Tatiparthy, 3 min read
Adapted from Chapter 3 of The Seven Frictions
Block out two hours and pick the last idea that took too long. Not a failed idea, and not a moonshot. Pick the small, sensible pilot that everyone agreed with and nobody could start.
Write two dates on a whiteboard. On the left, the day the idea was accepted for a small, safe test. On the right, the day a real user or a real workflow first touched it, or today’s date if that day has not arrived. Then fill in the middle with what the calendar recorded, not what the plan said.
Now name each gap on the board. Across industries and company sizes, seven names cover almost all of them. By the end of the session you will be arguing about two of the seven rather than about which team is slow.
Access: a ticket, not a toggle
A developer who wants a sandbox key for a model API files a request, receives a number, and waits behind requests that have nothing to do with hers. The catalog subset needs its owner’s approval, and the owner is on leave until the 19th. None of this is hard. All of it is queued.
Approval: serial reviews kill momentum
The work is finished and the waiting starts. Architecture meets Tuesdays. The change board meets Thursdays. Vendor risk runs on a two-week cycle, and privacy answers email when it can. Add up the hands-on effort in those four reviews and you get less than a day. Put them in a line and you get a month.
Environment: bespoke, fragile, scarce
One shared staging environment, a booking spreadsheet, and a standing request not to run tests after 4 p.m. because the nightly job starts at 5 p.m. Ask when staging last matched production and watch the room go quiet.
Data: policies exist, usable datasets don’t
Legal approved the use in the first week and the classification was clear. A support-console pilot still waited ten days for a masked slice of tickets, because nobody had ever written down how to mask that table.
Security: bolt-on controls arrive too late
Security arrives at the end, when changing anything is expensive. The review finds that the pilot logs prompts containing customer names. That was one configuration line in week one and is now a rework ticket, a retest and a second review.
Change: release assumes big bangs
Ask how a change reaches a customer and you will hear about a train. Releases go out monthly, there is a freeze the week of quarter close, and the cut-off for the next one was Friday. A pilot that wants one percent of traffic for two weeks has to board a vehicle built to carry a month of everyone’s work.
Talent: uptime rewarded, learning ignored
Look at the monthly operations review: availability, incident count, mean time to restore, audit findings closed, a slide on the on-call rotation. Now look for the number that says how long it took to learn something from a customer. It is not on the deck, and nobody has asked for it.
How they chain
Each wait is small and each is defensible on its own. A data wait forces a re-review, the re-review misses a release window, and the window costs a month. That is the difference between four learning loops in a quarter and one.
Score where the days landed first, then diagnose the causes behind the two biggest buckets. The book has the scorecard, the workshop script and the playbook for removing them.