Boring Problems

I was at my accountant's office one morning, waiting for her to send a few emails before we could talk. A few minutes, she said. I told her not to hurry and watched her work. The spreadsheet was already open. Client names ran down the left, document types across the top. She searched her inbox, marked each cell green or red, and emailed the clients whose cells were still red. By the time she looked up it was nearly noon. She forgot I was there, and when she remembered she apologized, and told me she did this the first week of every month.

I built her an app in a week. It tracked clients, listed documents, sent reminders, and closed the month with a single button. She pressed the button the first day and told me it was her favorite part.

My father ran a flower shop. He kept stock in a notebook, and the notebook lied. When he doubted it, he walked to the back room and counted stems.

I built him an app too. He had not asked for one.

Both apps do little. They hold a list, show what is present and what is missing, and send a message when someone needs one. That is enough.

Neither problem was hidden. The accountant knew her mornings. My father knew the back room. They had known for years. Knowing a problem and seeing it are different things.

I studied anthropology before I wrote code. The lesson that stayed: people cannot describe their own work. They describe a tidy version of it. The tidy version omits the parts that matter, because the parts that matter have become invisible to the person doing them.

To find those parts, watch. Sit in the corner. Say little. After a while the person forgets you. Then you notice the tab she opens and closes without reading, the folder she checks twice, the walk to the back room, the pause before she sends an email she may have sent already.

The pause is the thing.

Notion can hold the list. Airtable can hold the list. A spreadsheet can hold the list. A hammer can drive a screw. People do not want to drive screws with hammers. They want the screw to go in.

These problems are everywhere. A dental clinic tracks follow-ups by hand. A builder logs deliveries on paper. A teacher runs attendance through a spreadsheet she opened a thousand times and no longer thinks about. The not-thinking is what you are looking for.

When you find such a problem, three things are true. The work is real. The pain is real. Nobody has built the tool.

I am leaving something out. I am leaving out the first hour, when you see nothing. The second hour, when you still see nothing. The small motion in the third hour that shows you the shape of the whole. I am leaving out how long it takes to learn to wait.

Writing the code is easy. Watching is hard. The hard part is sitting with someone until the friction she has stopped seeing returns to view — hers first, and then your own.

The software comes later.

First, learn to look.