The lag was the lock
Speed will walk past the check you never wrote down
Put a named second human on cash, contracts, and private data before you let the chase get instant.
A control that depends on people being slow is not a control. It is a pause you have been treating as policy. Speed does not make that pause wiser. It makes it disappear. The process on paper can look unchanged on Friday and still be unsupervised by Monday, because the wait was doing work you never hired a person to do.
Slow is still doing a job
Walk collections with the person who actually chases invoices. The reason a bad bill used to get caught is not a clever rule in the handbook. It is that your bookkeeper had a day or two before the next chase went out. In a shop of twenty, that pause is how finance still notices a duplicate, a wrong entity, or a customer who should have been on hold. Nobody named the pause as a control. The calendar did the job anyway.
Renewals work the same way. So do access grants. The form takes long enough that a second pair of eyes sees the name twice. Those three loops show the problem first because they already have a chase and a delay. Refunds, vendor payments, and staff logins sit in the same family. If the only reason a second person ever looks is that the first person got tired of typing, you do not have a second look. You have friction.
Ethan Mollick (@emollick), who studies how real organizations absorb this, put it plainly. We are going to learn how many systems only work today because they are built around friction that will no longer exist soon. He is not asking you to freeze the work. He is saying the slog was load-bearing. If you speed the chase and leave the rest alone, you did not improve collections. You removed the only check you had.
Treat that as an operations fact, not a future essay. The follow-up that used to take a week of nagging can now be drafted and sent before lunch, on the mail and tickets you already run. The risk is not that the team gets faster. The risk is that speed arrives and the lock does not.
Cash, contracts, private data
You already know which loops can actually hurt you. Money leaving the account. A contract going out with the wrong term. A login that should not exist. Those three still need a named human even when the typing gets cheap. Everything else can get faster this week without a ceremony. Internal status pings. Meeting notes. The tenth nudge about a form nobody will die over. Speed those. Do not pretend they are the same as a refund.
The owner sets the line. Not the person who likes new helpers. You decide which loops may touch cash, contracts, and private customer or staff data. Write that list in one place the team already uses. A sheet is enough. A field on the ticket is enough. Do not wait for a new stack, and do not hide the list in a slide.
If a loop is on that list, a second person has to act. The wait is not the act. A two-day inbox is not a signature. A painful form is not a policy. Once the request can be filled in a minute, the form stops protecting you. The name you write next to "can say no" is what protects you.
Keep the drafting help if you already have it. Let someone sketch the chase, the renewal note, or the access request. Sending money, binding a term, or opening a login stays a human yes. You set which automations may touch those three. If you cannot name the human who can still block them, the automation is not ready, even if the draft looks polite.
Two people, not two days
In your shop the same person can now request a refund and mark it paid before anyone else is in the building. Segregation of duties is the dull name for that risk. It means one thing at this size. The person who asks cannot be the person who grants.
That used to be free, because the form was a pain and the email sat. Once the request can be drafted and sent in a minute, the same person can request and approve before lunch. The org chart did not change. The risk did. Two days of waiting is not two people. Same-day review by a different human is still a control. An empty delay is not.
Put a name on the second look for every loop you keep on the cash, contract, and private-data list.
- Requester: the person who wants the money, the renewal, or the access
- Grantor: a different person who can say no, in hours you choose
- Owner: you, the moment those two names are the same person
Time the second look on purpose. "By 3pm" is a rule. "Whenever the inbox unsticks" is hope. A grantor who is out on Thursday needs a named backup, or the loop waits in the open with nobody on it. Write the backup now, while you still remember who actually says no.
If the requester and the grantor are the same person after you speed the loop, you do not have a control. You have a faster leak.
What you can count by Friday
By Friday you should know how many of your money, contract, and private-data loops still have no named closer. Nobody has a credible public figure for how many delay-only gates sit inside a business this size. Count the live ones on your board.
| Measure | Count |
|---|---|
| Loops whose only gate is waiting or a painful form | |
| Of those, loops that touch cash, contracts, or private data | |
| Loops on that list with two different named humans |
Friday is simple. The middle row should match the bottom row. Empty names on money loops are the miss. Do not convert that into a percentage. An unnamed refund path is worse than a tidy story about most of the process.
Figure 1
Finance does not need a new title for this. Whoever already watches cash names the grantor. Ops may speed anything that failed the cash, contract, and private-data test. You own the leftover count. If the diagram stalls, it is because a name is missing, not because a tool is missing.
Run the three-process walk this week
Do this on work that already exists. One collections thread. One renewal. One access grant. No demo data, and no workshop that produces a poster.
- Sit with the person who runs collections. Write down what the delay currently prevents, in one sentence.
- Sit with whoever owns renewals. Same question, same one sentence.
- Sit with whoever grants access. Same question again.
- For each, write the requester, the grantor, and a backup, and confirm those are different people.
- Speed only the loops where those names are different, or where the loop does not touch cash, contracts, or private data.
Keep the grantor human. Drafting the chase can be assisted. Sending money, binding a term, or opening a login cannot become a solo act just because typing got cheap. If a loop fails that test, leave it slow until the second name is real.
You already have the board. Walk it before Friday.
Sources
If one workflow is eating your week, tell me which one. I'll tell you if it's worth deploying — and if it isn't.
Message Mikko on LinkedIn