I used to think scheduling problems were mostly about making the schedule.
Put the right person on the right job. Pick a time. Send it out.
That sounds like the hard part.
But the more I looked at small teams, the more I started noticing something else: the messy part often starts after the schedule is already sent.
Someone sees the message but does not reply.
Someone says they cannot make it, but now someone has to remember who might be able to cover.
A job is still on the calendar, but no one is completely sure whether the assigned person actually confirmed.
None of this looks dramatic at first.
It is just one missed reply.
One unclear handoff.
One small assumption.
One message buried somewhere in a thread.
But when the job time gets closer, those little gaps start to feel much bigger.
I find this kind of problem interesting because it is not really about a lack of effort. Most of the time, people are already trying. They are texting, calling, checking notes, scrolling back through messages, and keeping too much in their head.
The issue is that the responsibility is spread across too many places.
One person knows part of the story.
Another person saw a message.
Someone else forgot to reply.
The owner is trying to connect all of it in real time.
That is the kind of small operational problem I want to build around.
Not huge systems.
Not another complicated tool that tries to manage everything.
Just small tools that make one messy part clearer.
It is a small problem, but it repeats.
And I think repeated small problems are often more useful to study than big dramatic ones.
They are quiet.
They are boring.
They are easy to ignore.
But they are also where a lot of real work gets stuck.
Top comments (0)