Designing Software Around How Your Team Actually Works, Not the Org Chart
3 August 2026
There is a particular kind of software failure that has nothing to do with code quality. The system is well built. It passes its tests. It went live on schedule. And six months later, half the team has quietly reverted to a shared spreadsheet, because the software insists that work flows in a way it never actually does.
This happens more often than most businesses admit, and the cause is almost always the same. Somewhere early in the project, someone described the process the way it appears on paper: sales hands off to operations, operations hands off to finance, each department owns its stage. That description became the requirements document, the requirements document became the data model, and the data model hardened into screens that only make sense if the paper version were true.
The paper version is rarely true. Real work moves sideways, loops backwards, and routes around whoever happens to be on holiday. The gap between the documented process and the lived one is where adoption dies.
This article is about closing that gap: how to find out how your team actually works, what to build once you know, and how to keep the system honest as the work keeps changing.
Why the Org Chart Is the Wrong Blueprint
An org chart answers a question about accountability: who reports to whom, and who is answerable for what. It is a useful document. It is simply not a description of how information moves through your business, and those two things diverge almost immediately in any company past about fifteen people.
When software is designed from the reporting structure rather than the work, a predictable set of problems follows:
- Handoffs that do not exist. The system demands a formal approval step between two people who, in practice, sit next to each other and settle it in thirty seconds. Now they do the real thing, then log the fake approval afterwards.
- Work that has nowhere to live. The genuinely cross-functional cases, the ones that involve three departments and no clear owner, do not fit any screen. They end up in email, where nothing is tracked.
- Shadow systems. Every time the software cannot express something the team needs to express, a spreadsheet appears to hold it. Within a year your real operational data is split across a database and a dozen files nobody backs up.
- Data that describes the wrong thing. Reports come out clean and confident, and they measure the ceremony rather than the work. Cycle times look excellent because the timestamps record when someone updated the record, not when anything happened.
- Rewrites that repeat the mistake. The project gets branded a failure, a replacement is commissioned, and the new team is handed the same process document that broke the last one.
None of this is a technology problem. It is a modelling problem, and it is fixable before a line of code is written.
Finding Out How the Work Actually Moves
The good news is that the real process is not hidden. It leaves traces everywhere, and a few days of deliberate observation will usually surface more than weeks of workshops.
Watch the work, do not just ask about it
Ask someone to describe their process and you will get the official version, because that is the version they have words for. Sit with them while they do it and you will see the rest: the message they send to check something before starting, the tab they keep open with last quarter's numbers, the case they set aside because it needs a decision from someone who is out today.
Shadow three or four people across different roles for a couple of hours each. Write down every tool they touch and every person they contact. The list is almost always longer than anyone expected, and the surprises in it are the most valuable requirements you will gather.
Follow one unit of work end to end
Pick a single order, claim, ticket, or project and trace it from arrival to completion. Not a representative example: a real one, with its real detours. Where did it wait? Who touched it that nobody mentioned? Which step took two minutes of work and four days of waiting?
This exercise consistently reveals that the bottleneck is not where people assume. Teams tend to point at the busiest-looking step, while the actual delay sits in a queue nobody owns.
Ask what people do when things go wrong
Standard processes are the easy part. What separates software people use from software people tolerate is how it handles the exceptions: the rush job, the customer who changes their mind mid-way, the correction after invoicing. Every business has a set of these, and every business treats them as edge cases despite them making up a third of the volume.
If your system can only express the happy path, the exceptions will leave the system, and the exceptions are where the money and the risk both live.
Look at the spreadsheets
Existing spreadsheets are documentation. Each one exists because a real need had no home in the official tooling. Read the column headers, they are a specification written by the people who do the job. When we begin a discovery process with a client, the shared drive usually tells us more in an hour than the process manual does in a week.
This is one reason internal tools are so often the highest-ROI software a business overlooks. The need is already proven by the workaround. All that is missing is a proper home for it.
Building For the Work You Found
Once you understand the actual flow, some fairly specific design choices follow. The through-line is the same in all of them: model the work, then let roles and permissions sit on top, rather than building roles into the foundations.
Make the unit of work the centre of the system. Structure the software around the thing that moves, the order, the case, the shipment, with a full history attached to it. Departments become views onto that object rather than separate silos with their own copies of the truth. When someone asks what happened to a case, there is one place to look.
Design states that match reality, including the messy ones. If work genuinely sits in "waiting on the customer" or "approved but not yet invoiced," those should be real states, not a status field set to "in progress" with a note in a comment. Honest states give you honest metrics, and they let you automate the follow-ups that currently rely on someone remembering.
Let work move sideways. Sequential pipelines are easy to build and rarely accurate. Real cases get reassigned, pulled forward, sent back for a correction. Allowing legitimate transitions, and recording who made them and why, beats forcing people to fake a linear path.
Keep flexibility where the business changes, and structure where it does not. Core records benefit from a firm schema. The classification scheme your operations team revises twice a year does not, and should be configurable without a deployment. Getting this split right is much of what separates a scalable, robust platform from one that needs a developer for every small change.
Reduce the work, do not just digitise it. The best outcome of a discovery process is often the discovery that a step is unnecessary. Three approvals where one would do, a status update that exists because a report needs it, a re-keying step between two systems that could simply talk to each other. Automate what remains and you get the efficiency gain twice over. This is where thoughtful workflow automation earns its keep, because you are automating a process worth keeping rather than cementing a bad one in code.
Build for the person doing the job. A screen designed around the actual sequence of a task, with the information the user needs already on it, will be adopted without training. One that mirrors the database structure will not, regardless of how correct it is underneath. This is the practical meaning of user-centric design: the user in question is your own colleague, and their time is your operating cost.
What This Looks Like in Practice
Consider a services business with roughly forty staff, running a quoting and delivery process across sales, technical, and finance. The official flow had four stages and three approvals. Observing it for a week showed something different: about 30% of jobs were being scoped informally by a technical lead before the quote existed, because sales could not price them alone, and roughly a fifth came back for revision after delivery started.
The first version of their system had modelled the official four stages. It had no way to record a pre-quote technical review and no way to revise a job in flight without cancelling and recreating it. Both realities lived in a spreadsheet and an email thread, which meant nobody could answer how long quoting actually took.
Rebuilding around the observed flow changed three things. Pre-quote review became a first-class step with its own queue, so technical input stopped being invisible work. Revisions became a versioned change on the existing job rather than a new record. And the two approvals that existed only to notify someone were replaced with notifications, leaving one genuine sign-off.
The measurable outcome was a meaningful reduction in quote turnaround time, but the more important one was that the reporting became trustworthy for the first time. Once the system described real work, the numbers coming out of it could be used to make decisions. That pattern repeats across industries: the same approach applies whether the unit of work is a patient referral, a property listing, a shipment, or a support case.
It is also why we treat discovery as part of the build rather than a formality before it, and why a phased approach to replacing a legacy system usually beats a single cutover. Each phase teaches you something about the real process that the previous phase could not have told you.
Putting It Into Practice
If you are about to commission internal software, or you are looking at a system your team is quietly working around, here is a sensible sequence.
Immediate, this month:
- Shadow three people in different roles for two hours each and list every tool and person they touch.
- Trace one real case end to end and mark where it waited rather than where it was worked on.
- Inventory the spreadsheets and shared documents in active use. Each one is an unmet requirement.
Short-term, this quarter:
- Write down the exceptions your current process does not officially handle, and estimate what share of volume they represent.
- Identify which steps exist to create information for someone else, and ask whether the system could produce that information directly.
- Agree the unit of work your software should be organised around, and get the states right before anyone designs a screen.
Longer-term:
- Instrument the system so you can see real cycle times per state, and revisit the model when the data disagrees with the design.
- Plan for the process to change. Configuration over deployment, wherever the business is likely to move.
- Review adoption honestly at six months. If a workaround has appeared, treat it as a specification rather than a discipline problem.
A useful test throughout: could a new joiner do their job using only this system, without being told the unwritten rules? If not, the unwritten rules are still requirements you have not captured. If this sits inside a wider modernisation effort, the same principle belongs in your transformation planning: sequence the work around real operational pain, not around departmental boundaries.
Conclusion
Software adoption problems are usually design problems wearing a disguise. When a team abandons a system, they are rarely being difficult. They are routing around a model of their work that was never accurate, and doing so is the only way to get the work done.
The fix is not more training or stricter policy. It is building from an honest picture of how work actually moves, giving the messy realities a proper home in the system, and treating the process itself as something to improve rather than merely to digitise. Systems built this way get adopted quickly, produce data worth trusting, and keep paying back as the business grows.
The work of finding that honest picture is not glamorous, but it is where most of the value in a custom platform is decided. If you are weighing up an internal system and want a second opinion on what to observe before you specify anything, we would be glad to talk it through.
Related reading:
