The Hidden Costs - Human Friction and Invisible Waste
Introduction
In the last two posts we looked at how business systems evolved into the complex platforms we use today, and at the visible costs that model produces. The patch cycle burden, the implementation complexity, the constrained change windows, the backlog that grows faster than it clears, and the layer upon layer of manual workarounds that accumulate when the system can’t keep pace with the business.
In this post I want to talk about costs that are not as visible but are present every day. These are the human costs that accumulate quietly in the background while everyone focuses on making the visible parts work, plus the deeper system-level waste that sits underneath every transaction.
Let’s look at the human costs and then move onto a different system related angle that occurred to me as I thought through these issues.
Maximum convergence of System and Process
At the point of initial implementation, the convergence of business process and system solution is at its maximum. User trust in the system is at its highest point, there may be some missing pieces, but these are minimized and effectively communicated and understood. Users have been trained, the processes are documented, everyone understands what the system is supposed to do and how their role interacts with it. There’s optimism. There’s investment; not just financial, but organizational and human. People want it to work.
Unfortunately for most businesses the change process we described last time means that the trust and optimism starts to erode.
Items on the backlog that were identified during the implementation, required for the efficient running of process get descoped in future releases. Newly defined enhancements and change requests, to support business change are not delivered. Prioritization of changes seems random and illogical as ‘must do’ vendor changes get delivered when efficiency updates or pain points are de-prioritized and fall outside the top items list. Users start to see the system becoming incongruent with the processes they actually follow. Existing manual workarounds persist when they were promised relief, and new ones accumulate as change requests go unanswered.
The trust that erodes
Over time more and more of the work that people do and information they record is done outside of the system, sometimes it is put back into the system in a flurry of updates just to satisfy the system or process need;
· A BDC mass creates 50 activity records, one after another, on a Friday afternoon, derived from the spreadsheet they used to record the actual conversations that took place at the time they took place, done to satisfy a badly designed KPI incentive because the system is inefficient for logging activities at the time they are performed.
· A Sales Rep who has to update multiple irrelevant Deal Qualification questions even though the deal type that they are working does not require those steps, just to satisfy a score used to monitor deal progress.
· A RevOps analyst forced to re-assign Leads as the routing did not place them correctly, the routing rule updates are ‘in the queue’ of work to be delivered. Until the changes are delivered the manual work persists.
All of these actions require additional work from humans in order to make the system ‘correct’. But even with these corrections the system remains dysfunctional as the data being entered or generated is not accurate.
Support tickets or bugs have been logged, change requests have been discussed, identified, documented and submitted. Users and Ops teams have followed the process to log issues or request change, the items are ’in the queue’ awaiting delivery. There is a sense of quiet hope when it next comes time to prioritize the top items to fix, “surely this time someone will recognize just how painful the workarounds are and we’ll get relief”. Only to find the requested change is once again outside the top list when the prioritization is done. Hope is dashed, Ops teams must now go back and inform stakeholders that, once again, their particular pain point is not a priority for the business to fix. Stakeholder participants suspect that nothing will change as a result of their work and that manual effort is now the norm
The business reality is drifting into the distance while the system stays fixed and rigid with minimal visible change. User trust erodes. Once that trust is gone, it is extraordinarily difficult to rebuild. What is the effect on the humans of this additional duplication of effort?
The human cost of repeated rejection
When teams invest real time and effort defining clear requirements, building business cases, explaining why a change is needed, documenting the cost of the pain point. Only to see those requests consistently deprioritized or rejected because of constrained change windows and an ever-growing backlog, a quiet cynicism sets in. Ops teams question their existence and fully internalize the adage that ‘there is nothing as permanent as a temporary workaround’. Stakeholders realize the area they work, that they put their effort into, is not a priority for the business as a whole. Users feel abandoned and ignored as they continue to duplicate effort to complete a task that they can see should be simple.
People stop believing their input will lead to meaningful improvement. Over time, this breeds disengagement. Employees begin to question whether the organization is serious about making the system work for the business, or whether they are simply expected to absorb the friction and carry on. The emotional cost of repeatedly investing in improvements that never materialize is rarely measured, but it is real, and it compounds with every cycle.
The second order effects
The second order effects of these missed changes also becomes visible, usually in the form of disconnected and incorrect data.
· An analyst pulls a report for activity logging, graphs the results, and notices that they seem to be logged in bursts of short time. They see a BDC that sent 23 emails and made 37 calls in three hours on a Friday afternoon.
· Another analyst is checking on Solution Architect time spent per deal and notices that a specific deal listed solution work, but no project was ever logged for it in the work allocation system. The denominator of closed opportunities with solution work is way too high compared with the work actually logged by the architects.
· Analysis of time to 1st activity on Leads is performed, the reporting shows some high value leads took 6 days to action. They were stuck in the wrong queue for 5 of those days.
More layers of dysfunction are added, each one compounding downstream.
In all of these examples we have to ask what can be gleaned from the reporting on this inaccurate data without manual interpretation or intervention? What would AI determine from this data as it is recorded in the system? Would it understand what has happened or would it give recommendations on ‘bad’ input data?
The three versions of reality
As drift accumulates and trust erodes over time, something interesting happens to organizational knowledge. Three separate versions of reality begin to coexist.
The first is the documented process. The official record of how things are supposed to work. Written for go-live of the original implementation. Updated inconsistently since then. It reflects the system as it was designed and the workflows as they were intended. Potentially includes, but not guaranteed, the manual workarounds users are actually doing
The second is the system configuration. How the platform is actually configured today, after multiple change cycles, partial deliveries, vendor updates that were adopted and backlog items delivered. This does not include anything that was not delivered nor does it include the manual workarounds being conducted as ‘business as usual’ flows.
The third is ‘ground truth’, how people actually do their work. This mostly lives in people’s heads and is rarely documented consistently. The combination of what the system does, the workarounds that have grown up around what it doesn’t do, and the tribal knowledge that experienced team members carry about how to navigate the gap between the system and the work.
None of the three versions match each other completely. Nobody has a complete picture of any of them. And the gap between them widens with every cycle. Dysfunction is the norm and, with a sigh and a feeling of inevitability, it is accepted at every level.
The invisible compute layer
Now I want to talk about something that sits underneath all of this. Something that operates at a level most people never think about, but whose consequences scale in ways nobody is currently measuring.
When you configured your platform, you didn’t remove anything from the codebase. You simply defined the subset your business would use. The code for every unused feature, every disabled module, and every capability built for other customers remains present in your environment. You told the system not to surface those things to your users, but the system still has to evaluate whether it should run them.
Every transaction, every record save, data update, API call, or user interaction, passes through the platform’s full evaluation logic. It checks configuration, decides what to execute and what to skip, and discards the paths that aren’t enabled. On any single transaction these checks are tiny: microseconds, fractions of compute. Individually negligible.
But they don’t run on one transaction. They run on every transaction, continuously, across your entire organization. And then across every deployment of that platform, worldwide. This hidden overhead also contributes to issues for the users; slower page loads, increased infrastructure costs, more complex debugging, and reduced overall system responsiveness.
The technology industry is loudly debating the massive new compute, energy, and water demands of AI. Yet very few people are talking about the existing structural waste already baked into these systems. Nobody is measuring what fraction of the compute running enterprise platforms today produces no business value for any specific customer. Nobody has put a serious number on the structural waste baked into thirty years of configure-down architecture, running permanently, at scale, across every platform, every day, as a consequence of the model itself.
This is architectural, it is baked in by its design, as an inevitable consequence of the way these platforms have been constructed over time with the intent to serve every possible customer. Unfortunately, with this paradigm the waste is ‘bundled’ into the product.
The point I’m making
We have seen over these three posts the effects of how the systems we use on a day-to-day basis are constraining the business. Dysfunction is replete through the entire system. Innovation is strangled, productivity is reduced with manual workarounds, efficiency is destroyed.
These systems were built with the tools and the thinking available at the time. The constraints that shaped the configure-down model were real. The model that emerged wasn’t a mistake. It was the best available answer given what existed then.
But those tools have changed. The technical landscape of today is not the technical landscape we have had previously. That means the future of business systems does not have to remain trapped by the logic of how they have always been built.
What it does require is harder than switching vendors or bolting on another tool. It requires an honest and unflinching rethink of the paradigm itself.
Let’s go back to our analogy of the tail wagging the dog. The tail is in a fixed position while the dog wags frantically. Its body doesn’t know which way to go, and its brain is being repeatedly shaken inside of its own skull, suffering the kind of cumulative trauma that leads to disorientation, impaired function, and long-term damage.
About 90 Degree Circle
Dysfunctional CRM is a money pit. How much is yours costing you?
I advise enterprise and scaling B2B revenue teams on CRM architecture, system drift, and the structural issues that create dysfunction in their revenue engine. With 30+ years at the intersection of business process and IT systems across ERP and CRM environments, I help organizations diagnose and resolve root cause problems, restoring functionality, operability, data quality, and process flows, so you can finally realize the full ROI your CRM system was built to deliver.
