Rajneesh Das explains why organizational change management determines whether technology delivers value, and how technical debt and people are often left out of the plan.
A company invests in a sophisticated CRM platform. The system is live, but when the weekly review meeting begins, someone still opens an Excel sheet. Nobody remarks on it. The platform exists, and the investment has been made, yet one of the business's most important conversations is still happening somewhere else.
Rajneesh Das has watched versions of that scene play out throughout his career, and he uses it to illustrate something leadership teams often underestimate. The technology may be functioning exactly as intended, but if people have not changed how they work, the transformation has not really happened.
Organizational change management is often where that gap begins.
Rajneesh is the CEO of AgentropyX. Across roughly thirty years, he has occupied nearly every seat around a technology decision. He began as a developer, moved into project management on large programs for Fortune 500 companies, including State Farm Insurance, and then ran accounts and profit and loss responsibilities while selling the kind of technology work he once built. Later, he sat on the buyer's side as a CIO and technology leader across large enterprises and government.
That range gives him an unusual view of transformation. He has built technology, sold it, bought it, and lived with the consequences after implementation. Across those different perspectives, one conclusion has remained consistent: technology creates value only when it fits the business around it.
Rajneesh starts from a position that sounds obvious until you follow where it leads. There is almost no company today that can operate without technology. In that sense, every organization is participating in the technology business, whether it describes itself that way or not.
But he immediately places an important limit on that idea. Technology is not the end goal. It exists to solve a business problem.
Rajneesh describes one common failure mode through the image of a red Mercedes. You see an impressive car drive past and immediately want one. What you have not considered is whether it fits in your garage or whether your garage has enough space at all.
The same instinct appears in enterprise technology. Businesses see sophisticated platforms, ERP systems, and emerging tools and want to bring them into the organization. What often receives less attention is whether the technology fits the existing environment and what the organization itself will need to change for the investment to deliver value.
Skip that thinking, and millions can be spent on technology that does not integrate effectively or produce the expected business result. The deeper issue is whether the technology was the right fit for the organization in the first place.
Two forces often push organizations into this position, and both begin long before the delivery team reaches implementation.
The first is pressure to demonstrate progress. Companies invest in technology expecting it to become a silver bullet and then establish aggressive timelines around delivery. For organizations under pressure to report visible results, the desire to show progress can move faster than the work required to create sustainable adoption.
The second challenge is what already exists beneath the new technology. Implementing anything inside a legacy environment is difficult because technical debt accumulates over years. Companies carry layers of previous systems, integrations, and operating decisions. Many older transformation programs also left behind incomplete change management, creating informal processes that may never appear on an architecture diagram.
People find workarounds. Departments create shortcuts. A formal process exists, but someone maintains their own spreadsheet or cheat sheet because that is how the work actually gets done.
Rajneesh's point is that organizations often approach transformation as though the environment they are changing is cleaner than it really is. That assumption makes implementation harder before a single new line of code is written.
Underestimating that complexity creates another problem. It compounds.
Senior executives allocate budgets and timelines based on what they believe a successful implementation should require. As the project moves closer to its deadline, unexpected complexity appears. Teams begin to rush, decisions are compressed, and corners are cut.
Those compromises do not disappear once the system goes live. They become part of the environment that the next transformation will inherit.
Rajneesh describes this as accumulated junk. Each generation of technology arrives on top of the incomplete decisions, integrations, and workarounds created by the one before it.
Adoption failure compounds in the same way. If employees never fully embraced the previous system, replacing it becomes even more difficult. The organization is trying to move people away from a platform they may never have genuinely moved onto in the first place.
That is why organizational change management cannot be treated as something separate from technology delivery. The choices made around people and process today become part of tomorrow's technical debt.
This is where Rajneesh's argument becomes most human.
Transformation business cases usually talk about efficiency, capability, and customer experience. What they often fail to explain clearly is what those outcomes mean for the people whose daily work is about to change.
A new technology can alter processes, responsibilities, and expectations. In some cases, roles may be repurposed or disappear entirely.
Rajneesh gives the example of a mainframe programmer who has spent thirty years developing a particular expertise and suddenly sees that work changing. His point is simple and memorable: people have mortgages. Systems do not.
That reality should change how transformation is planned.
In some programs, employees may be asked to support changes that significantly reshape, or even remove, their existing roles. That human impact needs to be considered from the beginning.
Leaders therefore need to ask whether there is alignment between the people affected by the change and the outcome the organization expects them to help create. If that question is raised only when implementation is almost complete, many of the decisions that shape employee trust have already been made.
Organizational change management cannot be the final bolt added at the end of a transformation. By then, there may be little left to manage except the announcement.
Rajneesh deliberately avoids prescribing another change management framework because established frameworks already exist. In his view, the challenge is not a shortage of methodology. It is whether organizations do the underlying work.
Every major change touches people, processes, data, and technology.
For each area, leaders need to understand where the organization is today, where it needs to go, and how the transition will happen in stages. That thinking needs to occur during planning rather than after the technology has already been selected.
Communication then becomes critical. People need to know early that change is coming, what will change, and how the journey will unfold. Leadership also has to allocate enough time and resources to manage that transition properly.
Rajneesh's concern is that projects frequently budget heavily for the tool and integration while failing to resource organizational change management with the same discipline.
The result is familiar. The system technically works, but problems emerge around adoption, data, and the people expected to use it.
The thinking behind Rajneesh's company comes from physics rather than management theory.
Entropy describes movement from order toward chaos. Rajneesh has watched that happen inside organizations of different sizes. Processes that once appeared streamlined gradually become more complicated as new systems, shortcuts, teams, and dependencies are added.
AgentropyX is built around helping organizations move in the opposite direction, from operational chaos toward greater readiness. That means addressing people, processes, data, and technology before expecting another new capability to solve the problem.
AI is a clear example.
Rajneesh's advice is not to jump into AI simply because the technology is available. Organizations need to become ready before they consume it, and data is central to that readiness.
AI cannot compensate for data that is factually wrong, structurally weak, or immature. The familiar principle still applies: garbage in, garbage out.
His thirty years in technology also give him perspective on the current urgency around AI. He has seen similar patterns with earlier technology waves. Something new arrives, organizations rush toward it, and then they discover that adoption is harder than expected.
Another part of Rajneesh's thinking connects organizational change management to the way technical professionals understand their own work.
IT teams should not focus only on the technology they are creating. They should understand what that work changes for the business.
If a developer writes a program, what business process does it support? If a team creates a data pipeline, moves workloads to the cloud or redesigns an IT operation, how does that activity connect to a measurable outcome?
Rajneesh points to several outcomes that technical work can ultimately support: increasing revenue, improving profitability, creating a better customer experience, or producing broader value for society.
The important part is making that connection visible.
A technical professional who understands the business impact of their work approaches decisions differently. They can discuss not only how something should be built but also why it matters.
Leadership has a role in creating that understanding. Rajneesh suggests giving technical teams direct exposure to the business. Let them listen to a call center conversation. Allow them to sit in a sales meeting. Help them see how customers experience the processes their technology supports.
That exchange can narrow one of the most persistent gaps in transformation: the distance between the people building the technology and the people living with its outcomes.
Four leadership lessons emerge from Rajneesh's experience, and each begins before another technology purchase is made.
The first is to understand fit before committing to the platform. Leaders need to ask whether the technology suits the existing environment and what changes the organization itself will have to make for the investment to work. A technically impressive platform can still produce disappointing results if the business is not prepared to absorb it.
The second is to resource organizational change management as real work rather than an informal responsibility. If nobody owns adoption, communication and the transition between the current state and the future state, those activities are likely to receive less attention than the technology itself.
The third is to understand people, process and data alongside technology. Selecting the tool first can mean designing the answer before the organization fully understands the question. This is especially important in data engineering, where technical work often exposes problems in ownership, quality and process that existed long before the new platform arrived.
The fourth is to understand who is affected by the change. Which roles will evolve? Which processes will disappear? What new skills will people need? And how will leaders create alignment with employees whose cooperation is essential to making the transformation work?
The Excel sheet in the review meeting is not simply an outdated habit. It can be the visible evidence of decisions that were skipped before the system went live. The platform may have been installed. The transformation was not.
For leaders, that distinction matters. Technology can enable change, but it cannot create adoption on its own. Sustainable transformation happens when people, process, data and technology move together, with the business outcome clear from the beginning.
That is what organizational change management is ultimately protecting: not the implementation itself, but the value the organization expected the implementation to create.
Are you a CIO, CDO, data leader, AI executive or technology CEO with a perspective that can help global leaders make better decisions?
Share your experience, leadership lessons and industry insights with The Executive Outlook and join the conversations shaping the future of data, AI and digital transformation.
Listen in for business strategies and interviews with business experts to help you build a business and a life that you love.
About Us
