Teams often reach for software when work starts to feel harder than it should. A new platform promises visibility, consistency, and speed. But when the underlying problem is unclear ownership, scattered information, or a decision that has nowhere to happen, changing tools simply relocates the friction.
I have found it more useful to begin with the work itself: where information enters, who needs it, where it waits, and what breaks during a handoff. That view makes it possible to separate a technology problem from a workflow problem—and to understand what a better system actually needs to do.
The tool should support the workflow.
It should not become the workflow.
A workflow-first framework
The goal is not to document every possible action. It is to find the few conditions that determine whether work moves with clarity or accumulates friction.
Identify the friction
Find where work is losing time, information, clarity, or ownership.
Map how the work moves
Understand where requests enter, who makes decisions, where handoffs happen, and where work waits.
Remove unnecessary complexity
Eliminate duplicated information, redundant approvals, unnecessary manual steps, or avoidable decision points.
Structure what remains
Clarify ownership, standardize the parts that benefit from consistency, and keep flexibility where the work genuinely differs.
Choose the tool last
Select or configure technology only after the workflow itself is understood.
The same principle, two different problems.
The same principle can lead to very different systems depending on where the friction actually exists.
Moving information between systems
At DIGU, one example was recruitment.
Publishing a job opening used to require coordination between recruiting and development. The role information had to move between people before it could appear on the website, and the application process was disconnected from the internal systems used to manage candidates.
The problem was not that we needed “better recruiting software.” The problem was that the same information was being handed from one place to another manually.
So I structured the workflow around a single source of information.
A job opening is created and managed in ClickUp. That information can then be published to the DIGU website through the integration built by the development team. When someone applies through the website, the applicant enters the recruitment workflow in ClickUp and is also captured in HubSpot.
Instead of asking people to repeatedly move the same information between systems, the systems now move it.
The technology matters, but the important decision came earlier: identify where the information should originate, where it needs to go, and which handoffs did not need to remain manual.
Turning static information into usable information
At SCAD, the friction looked different.
Model information had historically lived in an Excel-based list. It contained useful information, but as the number of records and production needs grew, finding the right person meant working through a static collection of data that was difficult to maintain, filter, and use consistently.
The better question was not, “What should replace Excel?”
It was, “What do producers and creative teams actually need to know when they are looking for someone?”
That led to a more structured model-management workflow in ClickUp. Intake forms collect model information directly into the system, fields separate the information into usable criteria, and the database can be filtered around production needs instead of manually searched through as a spreadsheet.
Information such as student status, graduation timing, program, location, interests, approval status, and other relevant criteria can be structured so the useful question becomes much easier to answer:
Who actually fits this shoot?
Same principle. Different structure.
These two systems do not look the same because the work does not behave the same.
At DIGU, the main problem was moving information reliably between teams and platforms.
At SCAD, the problem was turning a large body of information into something people could actually search, filter, maintain, and use.
The common principle was not the software.
It was understanding the friction first.