Software as a Coefficient of Process

There is a common debate that I’ve encountered many times throughout my career in technology around the use of software tools and their effectiveness in solving problems for a team or business as a whole. The debate starts when someone finds a new software tool and makes the case that it will make the team’s lives easier, by automating common tasks, making information more structured and accessible, and increasing productivity.

Then someone else will challenge that idea, pointing out that software can’t solve their problems—what they really lack is a process. Once they fix their processes, they’ll operate more effectively, and the choice of software is, at best, an afterthought. .

There isn’t a correct side in this debate. Like many complex problems, the correct answer lies not in choosing one side or the other, but in choosing the right point in the spectrum between the two. And in most cases, the combination of good process with good software produces a result that’s greater, by multitudes, than process or software changes in isolation.

This is because, if done right, a good process gets codified into the software itself, which then reinforces and sustains the process.

Let’s break this down by looking at both process and software implementations separately, starting with process.

The Beleaguered Video Team #

Imagine an internal marketing team responsible for creating promotional videos for a company. Requests come in via a shared email distribution list monitored by two coordinators on the team who then assign the work to the appropriate people on the production team. They have many different teams making requests for new videos, and they can’t keep up with demand.

Someone on the team suggests two changes to the process:

1. Require department VP approval for every new request
2. Require all new requests to include a script

The first step reduces the number of requests by ensuring only high priority requests are made. The second allows parallel work: one team can record the narration while the other shoots footage, rather than waiting on the script after filming begins. This reduces idle time and increases throughput.

The team launches the process to the business via an all-company email explaining the new process. Unfortunately, not a lot of people read the email and continue making requests without a VP approval or a usable script.

Worse, approvals that do come in are vague. One VP writes “I’m good with this as long as there is budget for it.” The requester insist that this counts as an approval, but the coordinators aren’t sure and don’t know how to verify if the budget. And the scripts? They arrive in every format imaginable: PDFs, Word documents, text files. One requestor even sent in a blurry picture of words they wrote on a napkin.

The coordinators try to push back. Requesters get annoyed, claiming the new process is too complicated. Now it’s actually taking longer to complete requests due to the back-and-forth.

What went wrong?

The team had two solid process ideas and communicated them (in theory). But busy people tend not to read (or remember) all their email and easily fall back on old habits. Because the team continued to rely on an ad-hoc system to take requests, there was no way to require VP approval in a standard format, or to validate the script.

If the team had launched a structured form backed by a work management system, they could have:

• Explained the new requirements inline
• Routed requests for approval with clear accept/reject buttons
• Standardized script uploads (and limited to valid formats)
• Validated script content before submission
• Disabled the distribution list to cut off old habits

In this scenario, the team still had to think about how they wanted their process to work, and would still need to communicate the changes. But if (and when) those emails were ignored, there would be a system that automatically enforces the process.

The software wouldn’t be a panacea. There would still be issues to iterate on, and people would still grumble. But the best way to improve a process is to do it, learn from it, and refine it. Without automation, process changes are less likely to be followed, tested, or improved.

Out of the Box Approach #

In the marketing team example, we talked about a process-first approach to solving a problem, which was improved upon with the use of software. There is another way to tackle team productivity problems though: the “out of the box” software approach.

The “out of the box” approach to implementing software harkens back to the days when software came on physical media shipped in boxes. To implement software “out of the box” is to do so with minimal-to-no customizations. You set it up as the software developer intended it.

The argument is that the software designers have built the default experience using industry-best-practice workflows. And software that’s been around for a while benefits from broad user feedback, iterative improvements, and tested workflows.

It’s likely that your team is not a unique snowflake, and faces problems that have been solved many times and reflected in the default experience of the software. Instead of investing the time to design a perfect process from scratch, you get a great process “for free,” built into the cost of the software you buy.

This approach has merit, but again, it’s a spectrum. If you spend zero time understanding your operations, it’s unlikely that you’ll benefit from new software. Because even though the “out of the box” experience comes with a default way of working, there is always configuration work to do. Even the simple act of assigning users to roles requires you to understand and have an opinion on how things should work.

And while it’s popular to say that no team is a ‘snowflake,’ well… they kind of are? Companies and teams are made up of people, and every person is different. It’s great to take advantage of lessons from peers in your industry, but make sure you apply them in ways that fit your team and company.

Bringing It Together #

The most effective path forward doesn’t lie in picking sides between software and process. It lies in acknowledging that the two are interdependent. Good software can’t fix a broken process, and a good process can’t thrive without reinforcement. But when both are designed thoughtfully and evolve together, they create a system that not only works but improves over time.

So the next time someone asks, “Is this a process problem or a software problem?”, consider answering: Yes. Now let’s design both together.