The Spreadsheet Is Never Just a Spreadsheet

It's normally a symptom of something else

The brief said “develop and enhance” their productivity tools in AutoCAD.

They had some tools developed by different people over the years and were maintaining them in-house. But they didn’t have the expertise to extend them, which is why they got me in.

In the first meeting, we started discussing what I could actually help with. Things to fix, things to improve. I mean “develop and enhance” doesn’t tell me much at all. I needed to understand what was actually hurting them.

They told me that they actually have a system to track bugs and features from their users.

I was like wow. Most companies don’t actually invest in something like this.

So, Aiden (not his real name) started sharing his screen.

Honestly, I don’t know what I was expecting.

It was a spreadsheet.

Their “system” was a spreadsheet.

I shook off my initial shock and started asking some questions. What were the most critical problems right now ? Are there any common features that are highly requested ? Are they looking for a complete overhaul?

And try as Aiden did, he couldn’t use the spreadsheet to answer the questions. We spent the rest of the meeting trying to find the next few things to implement in the tool. The spreadsheet was so complicated and messy that it was hard to figure out which items were critical without reading through all of them. They just knew they needed the tool to be “better”. We eventually ran out of time but I at least understood more of their problem. hint: it’s not the tool itself

So, I had another call with Aiden later and he told me the story of that “system”.

It started out with good intentions. The tool had scaled to the entire company and management wanted a better way to track bugs and features. That’s a good reason. But instead of picking one out of the twenty bug-tracking tools that already exist, they spent 3 months in meetings deciding on how to do it. And it’s still ongoing.

They’re debating programs and workflows. They brought in their legal team to create a new policy. They wanted the quality committee, the technical committee, the directors, you know, the people who don’t have time, to all approve the new system before anything could move forward.

Meanwhile, Aiden still needed a way to track the bugs and features. So, he spent his nights and whatever free time he had building and maintaining that Excel sheet. Manually logging every feature request and bug that came through him.

It became clear that before we could even work on the tool, we needed to fix this “system” first. There was a lot of useful information buried in it, but extracting and managing it was painful.

So, I sent in a variation to the client, suggesting that we work on the infrastructure that supports the tool first, before we go in to fixing the tool itself.

And to my surprise, they accepted it. Maybe Aiden did some “persuasion” on his side.

The tool wasn’t actually the problem

When it comes to digital tools, there’s a misconception that only the tool matters. But the infrastructure around it is equally important. No amount of clean code or better architecture can fix a broken infrastructure.

Deployment. Bug/feature tracking. Usage tracking. Data safety. Change management. These are all things that need to exist to support the tool itself. And most of them were missing or held together by Aiden’s spreadsheet.

Yes, the client needed someone to make the tool better. But they also needed help clarifying what to fix and what to build next. They needed a better overall system. And the work doesn’t stop just because you can’t decide on one.

Indecision is how homebrew gets created

There’s a bias towards meetings and “planning” for new processes which is especially pertinent in larger organizations. And I think, in reality, it’s because no one wants to take responsibility. If I can hold a meeting with every important person and get them to sign off on it, I’ll be absolved of blame if something goes wrong.

I get that. But adding more people to the decision pool just makes decisions take longer. There’s a reason that the saying “too many chefs in the kitchen” exist. At some point, involving too many people will hurt the process.

And while you debate, people start to homebrew things because the work doesn’t stop.

I’ve seen it many times. Engineers making their own tools with AI because the company can’t decide on a program. Drafters using their personal computers to learn how to code because the company wants to roll out a “training program”, but it’s been “work in progress” for 7 months now.

Bug and feature tracking is not a novel problem. You’re not asking for something cutting edge. There are plenty of tools that do this out of the box. The biggest challenge was getting everyone to decide on something.

What I look for now

I used to go into client engagements focused entirely on the technical work. After all, that’s what I’m hired to do. Build the tool, increase their efficiency.

But now, instead of just looking at the tool, I keep an eye out of systemic issues like these.

Sometimes, even though the tool is the pain point, a broken tool is actually a symptom of a bigger systemic problem. And if it makes sense for me to help with that, I will.

In the absence of anything better, the Excel tracker worked. But it was fragile, and it only scaled as far as Aiden’s patience did.

The decision to build a proper system was always going to get made. The only question was when and who would pay the cost in the meantime. It’s almost always the people who actually have to use the system.

Thanks for reading
Subscribe to CodedShapes and I’ll send you my free guide on how to actually do that