Walk Me Through Your Week
I had a customer call the other day to discuss improving their processes and tools. Like many other companies, their staff waste a lot of time on tasks outside their core job.
When I join these calls, people usually want to show me the sheets, documents, forms, and everything else they use right away. That’s when I have to help them take a step back.
I ask them to walk me through their week. Their daily work. What do you do when you get to your computer? And then what? How do you get this information? How do you update this sheet? Why do you do that?
Without the right prompts and questions, people tend to tell you what they did to solve their problems rather than the original issues they were trying to address. If you’re familiar with the XY problem, where someone asks for help with their workaround instead of the problem behind it, this is very similar.
So we walked through the week. And something became clear pretty quickly.
They already had a fairly good idea of what the process should look like. They knew the steps. What they didn’t have were the tools to support it, so they had to jump through way too many hoops to get anything done.
The tools become the work.
Some of those hoops were almost funny. Almost.
When something was resubmitted, someone struck through the old spreadsheet row and added a duplicate below it. Status lived in free-text notes that kept piling up, with one tab per project and different columns on each tab. Handoffs happened through chat messages, and the same notes got logged in two different tools. Even the forms were split across three different services.
Keeping deadlines in sync took, in their own words, “a lot of back and forth and constant checking.” And one staff member described a long shared document as by far the least efficient way to share information.
None of this happens because people are careless. When companies grow organically, they usually stitch together processes and tools that get the job done but aren’t the right choice long term. More often than not, spreadsheets are involved, acting as a poor man’s database. Things work fine until they don’t anymore. When the toil of MacGyvering things together starts compounding, companies realize how much process debt they’ve accrued: workarounds stacked on top of workarounds.
That’s why I don’t start with the spreadsheets. The spreadsheets are the solution they came up with. The week is where the problem lives.
While they talk, I listen for a few things.
Repetition. Anything people do every day, or every single time something happens, is a candidate.
Copying and pasting between systems. Every time a human is the glue between two tools, information gets lost, duplicated, or goes stale.
And my favourite phrase: “we should really sort that out.” When I hear it, I write it down. It usually means everyone knows about the problem, everyone has a workaround, and nobody owns the fix.
There’s a line in John C. Maxwell’s Be a People Person that fits here perfectly:
“Millions of drills have been sold; yet not a single person wanted one. They are buying holes.”
Nobody wants a better spreadsheet either. They want the deadline met without anyone chasing it.
The usual advice is “automate it.” Pick the most annoying hoop, write a script or wire up a no-code tool, and move on.
Sometimes that’s the right call. Often, though, you just add one more tool to the pile. One more thing someone has to feed, check, and fix when it breaks.
This team already knew what their process should be. They didn’t need someone to invent it. They needed a place for it to live. One system, with a clear owner, where the process is built in instead of carried around in people’s heads and enforced by hand.
Automation removes a step. Ownership means someone is accountable for how the work flows from start to finish, and the tools serve the process.
Now, the exceptions.
Sometimes the client does know exactly what they need. They’ve already done the walk-through in their heads, and they just need someone to build it. In that case, my job is to confirm it quickly and get out of the way.
Sometimes the problem is people, not tools. No system will fix two teams that don’t talk to each other, or a process nobody actually agreed on. Software will just help them get it wrong faster.
And sometimes the right move is to delete a step, not automate it. Peter Drucker warned about doing efficiently what shouldn’t be done at all. That’s why, in Fix What Hurts Most, deleting comes long before automating.
So the next time someone wants to show you their spreadsheets, let them. Later.
Start with the week.
If your team spends more time feeding its tools than doing its job, my two-week Systems Map shows how your work actually flows and where it leaks. Here’s what I offer.