Business Focused. Technology Forward. Organizational Change.
Atlanta, GA
Joined July 2010
- Tweets20K
- Following526
- Followers7.6K
- Likes992
Pinned Tweet
A message from our CEO on why we changed our name and what you can expect in the future!
See what's new 👉 go.liminalarc.co/lwo
AI isn't causing layoffs. Cost myopia is, which makes labor the easiest line item to cut once AI spending lands in the budget.
Learn why value engineering beats AI-driven cost cutting, because better math is better than no math.
Agentic modernization isn't something that AI can do alone. What makes it work is knowing where human judgment belongs, and that comes from 16 years of doing it by hand.
Your AI pilot didn't prove that AI works in your company.
It proved that AI works in the conditions you built for the pilot.
Think about what that pilot had.
🔹 A narrow, well-defined scope.
🔹 Data someone picked by hand.
🔹 One team that owned the whole thing.
🔹A leader with a mandate who cared how it turned out.
That's a protected world. Of course the demo worked.
Then it moved toward production. Production is where the shared systems live, along with the data nobody owns, the competing commitments, and the teams that weren't part of the pilot. None of the conditions the pilot ran on came along, because nobody built them anywhere else.
That matters because production is where AI is supposed to pay for itself. A pilot that never gets there hasn't delivered anything yet.
So the useful question about a stalled pilot isn't "why won't it scale?" It's "what did the pilot have that the rest of the company doesn't?"
That list is where your AI roadmap actually starts.
Get the Ebook 👉 go.liminalarc.co/ux4
If you're a leader tired of watching AI pilots succeed in the demo just to die in production, here's your chance to discover why, and get your AI transformation moving in the right direction.
Your delivery teams now build in weeks what used to take quarters. Your strategy changes when the evidence changes. Most funding decisions still get made once a year.
That mismatch has a cost. Projects keep their funding after the evidence says stop. Good ideas wait months for the next budget cycle. The annual plan ends up deciding what the company works on, whether or not it still reflects the strategy.
Four changes help:
🔹 Fund specific problems rather than broad objectives. Each one should be small enough to approve within a quarter and tied to one key result.
🔹 Approve work only when there's capacity to do it. If nobody can start it, reallocate or say no.
🔹 Check whether your customers can take on the change. Your teams' capacity to build is one limit. Your customers' capacity to adopt is another, and you can't buy more of it.
🔹 Release the next round of funding when results come in, not when the quarter ends.
AI can rank a backlog consistently and flag when the assumptions behind a funded project stop holding. Deciding what matters, and deciding to stop funding something, are still leadership calls.
How often does your organization revisit its funding decisions?
Let us know in the comments.
A successful AI pilot tells you the environment was protected. It doesn't tell you whether your organization is ready to run AI in production.
When AI makes writing code fast and cheap, the thing that slows you down is the inability to make a quick decision.
When AI accelerates your ability to build and makes it cheaper than its ever been, every component of your operating model has to change to meet the new capability.
What's that look like?
🔹 Capabilities and domains
The change here is indirect but relentless. A fast build engine creates new capabilities faster than the business architecture can place them, and every one of them needs a home: a domain it belongs to, an owner who answers for it, and data whose ownership is settled rather than assumed. Capabilities without a home recreate the gray area faster than anyone can own it.
🔹 Structure and boundaries
Boundaries get redrawn in both directions. When a domain needs less engineering capacity, team structures consolidate: accounts payable and invoicing keep their own bounded contexts, but one delivery team can now own both, because the demand side changed. And a new gray area opens between strategy and delivery, a seam that needs a named owner exactly as any unowned boundary does.
🔹 Governance and decision rights
The quiet change is beneath the waterline: every deployment hands AI more decisions, and few organizations can say which ones, or at what threshold of risk and value a person must re-enter the loop. It accrues slowly, then catches the organization off guard. What a portfolio governs, what a product group governs, and what a team governs with AI now look different, and each is managing risk at a speed governance has never had to move at. Where the right measurement does not yet exist, compensating controls hold the line until it does.
🔹 People and roles
The product roles become pivotal. Product managers and owners who connect customer needs, internal and external, to strategy, and who carry the competencies to make those value decisions well, including the decision to stop, now sit exactly where the constraint sits. That is no knock on the AI engineer or the delivery system; it reflects where the scarcity moved. And the division of labor has to be explicit: what AI does, what humans decide, and where they meet, written down rather than assumed.
🔹 Cadence
The deepest change. Annual planning cannot govern a weekly build engine. Strategy, funding, and validation have to move at the rhythm of a continuous flow, with intake ultimately paced to customer absorption rather than team capacity. As Gartner’s Chris Howard puts it, “gone are the days when organizations planned annually and locked in workstreams for the year.”
Ask one question of your own organization: where does work wait longest today?
If the answer is still the build queue, the structural work remains.
If the answer is a decision, a funding cycle, or a customer’s capacity to take on change, the constraint has already moved, and the components above are where it's hiding.
Organizations have good reason to move to the cloud:
🔹Lower cost
🔹Better performance
🔹Elastic scale
🔹Stronger disaster recovery
🔹Earlier ROI
Yet many find the move isn't that cost-effective. Or worse, that it obstructs the very transformation it was meant to enable.
They finish the technical migration, but the savings never materialize, and they end up maintaining two environments instead of one.
The reason is rarely the cloud.
Legacy systems cannot move cleanly because they're not encapsulated: their components are entangled through buses, APIs, connectors, and shared data into a dependency network no single team or vendor owns.
The most dangerous dependencies live in the gray area between components, where each vendor’s piece works in isolation yet the integrated whole fails because nobody owns the path between them.
Applied to an unencapsulated system landscape, migration produces predictable failures. Companies recreate the monolith in the cloud, lifting everything onto SaaS, customizing it region by region, and leaving processes and org design untouched, so the same tangled up mess reassembles in a costlier place.
And, still, the data center persists. A single missed gray-area dependency, a hardwired payment-processor or compliance connection that cannot be re-pointed, can force an organization to carry physical infrastructure for years.
And if your business case is funded by retiring the data center, one unowned dependency can erase your entire ROI.
