LiminalArc

Business Focused. Technology Forward. Organizational Change.

[LiminalArc @liminalarcgroup]

A message from our CEO on why we changed our name and what you can expect in the future!

See what's new 👉 https://t.co/RygYrYLq00

[LiminalArc @liminalarcgroup]

Read the Article 👉 https://t.co/5f8YqhvDDx

[LiminalArc @liminalarcgroup]

Most organizations treat digital-first as a technology strategy.

They use the term to describe their platforms, their cloud migrations, their application portfolios. The tools get modernized. The underlying operating model stays the same.

The organizations that actually become digital-first start with a different question: what would the operating model have to look like to deliver digital capabilities reliably, at speed, and at scale?

That question leads somewhere different.

It leads to how work is organized: business domains instead of functional silos.

How teams are designed: cross-functional, with clear ownership of specific capabilities.

How software is built: to stay changeable rather than brittle, adapting as requirements evolve.

The technology follows from that. When the operating model is designed to support digital delivery, the technology does its job. When it isn't, no amount of new tooling closes the gap.

Getting there requires redesigning the foundation the technology sits on. The platforms are the easy part.

It leads to a different way of organizing work: business domains rather than functional silos.unctional silos.onal silos.nal silos..s.

[LiminalArc @liminalarcgroup]

79% of app modernizations fail. At an average cost of $1.5M and an average duration of 16 months, that's a lot of time and money to spend on something that's likely to fail.

Too often, organizations begin their modernization with a technology decision. Something like "we're going to rewrite in microservices."

But that decision gets made without asking the most important question:
What's the business value and what business outcomes is this meant to deliver?

If your goal is "rewriting to microservices," that's what the modernization produces: microservices.

Not lower operating cost.
Not faster delivery.
Not improved customer experience.

So, the modernization might hit all of its technical milestones, but it missed all the desired business outcomes.

When leadership asks what changed, the answer is: the architecture did. That's fine, but leadership wants tangible business value they can take back to their shareholders to show them promises were made, and promises were kept.

The organizations that modernize successfully start with a different set of questions.

🔹 Which business capabilities need to perform better?
🔹 Which of those are truly differentiating?
🔹 What does this modernization need to deliver to justify continued investment?

When you build around those questions, the system produces the type of results leaders and shareholders care about.

If your last modernization effort stalled or fell short: what do you think the real failure mode was?

-----
This post comes to you from our management consulting practice, which specializes in designing and implementing operating models that align governance, processes, and technology to drive measurable business outcomes.

[LiminalArc @liminalarcgroup]

Read the Article 👉 https://t.co/mkdeqG9l7i

[LiminalArc @liminalarcgroup]

When your best developer leaves, their code stays. Their reasoning doesn't.

The decisions behind the architecture. The tradeoffs that were deliberate. The edge cases handled on purpose and not by accident.

None of that is in the code. It's in the person.

Most organizations don't realize how much institutional knowledge walks out the door with a resignation until they're paying someone else to reverse-engineer decisions that should have been documented years ago.

Spec-driven AI development makes documentation a byproduct of the work, not extra work on top of it. Every feature ships with a written specification: what it does, what it must satisfy, and why it was built that way. It lives in the repo. It stays when people leave.

The knowledge doesn't walk out the door anymore. Because it was never stored there to begin with.

When was the last time someone on your team asked "why is it built this way?" and nobody had a good answer?

Learn More 👉 https://t.co/Ri7o1OpvQf

-----
This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

[LiminalArc @liminalarcgroup]

Cloud takes 47 cents of every IT dollar. SaaS takes another 29.

Personnel runs at 35% of total IT spend. You're already over budget at 111%, and we haven't even touched security infrastructure, DevOps tooling, or the AI-related costs that are about to hit every IT budget.

In the past, CIOs would simply capitalize enough application development labor to reduce operational spending.

But the advent of continuous delivery made that difficult, and the productivity boost that AI provides is making it nearly impossible.

When the time to deliver working software is measured in days rather than quarters, capitalizing a project no longer reflects the reality of how software is built and deployed.

The economics of software development have completely changed, and the old accounting tricks no longer work.

The questions have shifted from what can we captilaize to how can we quickly obtain the most value? And what funding model keeps us honest about cost and risk?

The CapEx and OpEx debate only ever existed because software investments were unaccountable to business value. When you can't calculate the ROI on your software investment, you manage the classification instead.

The organizations moving past this aren't looking for smarter ways to capitalize the work. They're making the work accountable to a clear return. And using that return to fund the next investment.

This requires making smaller investments, delivering on shorter time horizons, learning fast, and continuously delivering value to customers.

The feedback pattern looks like this:

Ship. Measure. Learn. Reinvest.

Technology leaders should capitalize on what is clearly durable, expense what is honestly uncertain, fund what can pay for itself, and let the feedback loop set the pace for everything else.

[LiminalArc @liminalarcgroup]

The assumption that's buried inside every project budget is that the people asking for money in January know what needs to get built in December.

That assumption was already fragile.

AI is breaking it completely.

When software can be designed, built, and shipped in weeks rather than quarters, the right unit of funding stops being a project with a timeline.
Instead, it becomes an experiment with a hypothesis.

- Fund a direction.
- Ship a slice.
- Measure what it returned.
- Use that to decide what's next.

This is how the successful AI-enabled organizations are thinking about capital today.

They value and fund proof over plans.

This means finance has to evolve alongside delivery.

When it doesn't, you end up with fast teams and slow money.

[LiminalArc @liminalarcgroup]

When your team adopted AI coding tools, the promise was speed. And it delivered.

Commits are up.
Features are shipping faster.
The velocity metrics look good.

What's harder to see is what's accumulating underneath.

Without a methodology, AI output varies by developer.

One prompts carefully.

Another pastes in whatever the AI returns.

Over time, the codebase fills with inconsistency:

Different conventions
Different patterns
Different standards.

All are technically functional. None of it is coherent.

That inconsistency has a cost.

It shows up as extended timelines when a new developer joins and can't orient to the codebase. Emergency sprints when a fast shortcut compounds into a real problem. Senior engineers spending their time on cleanup instead of architecture.

It doesn't appear as an AI line item. It shows up as friction that no one can quite explain.

This is the problem spec-driven AI development was designed to solve. By designing the feature in writing, and encoding your team's standards in a rules file, the AI reads first, the output becomes consistent regardless of who's prompting.

You get the speed. And you get the quality.

[LiminalArc @liminalarcgroup]

Read the Article 👉 https://t.co/V3xBemDCvZ

[LiminalArc @liminalarcgroup]

Most technology leaders assume their engineering organization is holding steady. It almost certainly isn't.

A clean, well-maintained codebase means the next feature costs roughly the same as the last one.

A complex, poorly maintained one means every feature gets more expensive.
The difference rarely shows up in a single quarter. It accumulates over the years. By the time it's visible in delivery metrics, missed commitments, or escalating headcount costs, the codebase has been moving in one direction for a long time.

Overcoming the rising complexity in your codebase and ensuring you're getting the most out of your engineering investment requires intentionality..
Intentionality about how teams work, how they share knowledge, and how they maintain the systems they build.

Not only do the organizations that get this right ship faster, they ship at roughly the same cost in year five as they did in year one.

Extreme Programming is one framework built specifically to solve these kinds of problems.

When you use XP, the results look different. Delivery becomes more predictable. Rework costs drop. And teams get faster, not slower, as the product grows.

Every dollar invested in software development is either building on itself or being consumed by the system it created.

[LiminalArc @liminalarcgroup]

Your strategy, technology, and execution are built to operate separately.
Different owners. Different metrics. Different definitions of progress.

🔹 Leadership approves an initiative.
🔹 Teams start working.
🔹 Technology gets implemented.

A year later, there's been a lot of activity and very few results.

Nobody was incompetent.

But while everyone was focused on output, no one was held accountable for the business's strategic outcomes.

A better strategy won't close that gap.

Neither will more tools and technology.

What closes it is a value creation model designed to keep strategy, execution, and technology aligned from the start.

Learn More: https://t.co/2u0Xc7a3dV

[LiminalArc @liminalarcgroup]

CMMC certification isn’t a compliance checkbox. It’s a revenue protection problem. If your organization holds DoD contracts, failing certification doesn’t just mean audit findings. It means losing contracts.

Most technology leaders are treating CMMC like a training exercise. That’s where programs stall, and where revenue sits at risk.

LiminalArc and DEFCERT are hosting a webinar for technology leaders who need a clearer, more executable path to certification.

Register Now: https://t.co/yAGFbWbTza

[LiminalArc @liminalarcgroup]

Most AI investment conversations focus on the cost of getting it wrong. Few focus on the cost of getting started late.

The organizations building AI competency today aren't just ahead on technology. They're ahead on:

🔹 Knowing which use cases actually work in their context.
🔹 Designing systems that hold up in production.
🔹 Getting teams to adopt new tools without a rebellion.

Knowledge accumulates, and every quarter of delay is a quarter in which competitors aren't standing still.

The question isn't whether AI is ready.

The question is whether your organization is ready for AI.

If not, what will you do to make it ready?

-----

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

[LiminalArc @liminalarcgroup]

Right now, somewhere on your team, a senior engineer is teaching a junior engineer conventions that should already be written down.

The naming patterns. The testing approach. The way your team structures a service. Things that exist in the codebase, but not in any form a new developer can actually learn from on day one.

So they learn the slow way. Through pull request feedback, trial and error, and three months of absorbing what should have been documented long ago.

That's a knowledge transfer problem.

And it has a cost your headcount plan doesn't account for: a quarter of reduced output from every new hire, and a quarter of distracted attention from every senior engineer doing the teaching.

Spec-driven AI development changes this by encoding your team's standards in a rules file that the AI reads before writing any code.

Every convention your team has agreed on is captured in a document that becomes the living standard for how you build.

A new developer reads the rules file. Picks up a specification. Implements with AI assistance.

Their first commit looks like the rest of the codebase. Not because they absorbed three months of tribal knowledge. Because the AI already has it.

For organizations that are hiring, scaling, or running on contractor rotations, this significantly changes the math on time-to-value.

How long does it take a new developer on your team to produce output that's consistent with the rest of the codebase?

------

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

[LiminalArc @liminalarcgroup]

Most AI conversations focus on whether the technology is ready, but the economics of adoption have moved past that question.

For well-scoped use cases with proper implementation, AI demonstrably delivers. The barrier to entry is lower than it's ever been. Customer support automation, document processing, and workflow automation are established use cases with clear, measurable returns across industries.

The cost of not starting? That's also real.

Organizations building AI competency today are learning which use cases work, which designs fail, and how to scale. By the time most organizations begin, their competitors will have already figured out what works.

That's the gap waiting creates.

You should evaluate AI the way you'd evaluate any significant investment. What's the return? What's the risk? What does inaction cost?

When you answer those questions honestly, waiting becomes the harder call to justify.

What's driving your organization's pace on AI adoption?

-----
This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

[LiminalArc @liminalarcgroup]

Most CMMC providers run an assessment, deliver a report, and leave your organization with a long list of controls to implement. But reports don’t lead to certification, and neither does an expensive, over-scoped compliance program.

If you're a DoD contractor who's up against the CMMC deadline, join LiminalArc and DEFCERT as we discuss a different approach; one that scopes CMMC to real-world contract requirements and turns certification into work your organization can actually execute.

What We'll Cover:

🔹 How to align CMMC compliance to the contracts and systems that actually put revenue at risk.

🔹Why most compliance engagements stall, and what it takes to drive real implementation across the organization.

🔹How leading defense contractors are achieving certification faster without over-engineering compliance.

Webinar Registration: https://t.co/nSlmLpc4gT

[LiminalArc @liminalarcgroup]

Your organization's competitive advantage isn't in the plan, it's in its ability to adapt the plan as reality unfolds.

[LiminalArc @liminalarcgroup]

Read the Article 👉 https://t.co/HTPRGOrHx4

[LiminalArc @liminalarcgroup]

Ready to elevate your product operations? Discover how an effective product operating model can transform your investment strategy and drive better outcomes.

[LiminalArc @liminalarcgroup]

Read the Article 👉 https://t.co/Q2Qj7sw87A