What It Is: Balancing priorities in medium- to large-scale organizations is complex, especially in a high-paced environment where speed-to-value is critical, but there is existing infrastructure and technical debt to consider
Why It Matters: Deferred decisions and the resulting complexity tend to slow an organization’s ability to remain agile and cost-effective over time. Speed can come at a very heavy cost, and a balance should be struck that helps mitigate downstream risk while enabling quality delivery
Key Concepts
- Have an enterprise blueprint and understand your leverage points
- Engage architecture in scoping decisions early to understand and document tradeoffs
- Estimate and plan time for important design decisions to mitigate downstream risk
- Schedule deferred capabilities or track their impact to understand economic impact and debt
- Explicitly account and plan for decommissioning solutions and technical debt reduction
Key Dimensions
A short anecdote
In my time as a CTO, I had a conversation with a partner proposing to use a market-leading database technology that was not in our existing footprint as part of a major upcoming program.
A few points:
- The partner had implemented other work and not used this technology before in deference to ones we had in place
- The platform was a market leader and good technology, so there was rationale to support why it could be a viable alternative
- There was no capability gap to warrant why we had to use the new technology by comparison with existing technologies
I asked our partners what they would do, given that the decision would require us to expand our talent base to cover the new platform, integrate it with other data solutions, connect with our security tooling, manage identities and authorization across multiple back-end platforms, determine how to host, manage, and scale it from an infrastructure standpoint, etc. No answers came back, just why it could be good for the project, but not for the company. Ultimately, both things matter.
Having a blueprint
Project and product teams need to be able to execute in parallel to achieve any scale and efficiency, but doing so highlights the importance of having an enterprise blueprint and an appropriate level of standards to guide those efforts. With the introduction of AI, the criticality of these things can’t be emphasized enough, for a multitude of reasons, not the least of which is maintaining a healthy security posture.
As a proponent of best-of-breed, component-based, and composable architecture, I don’t believe it is necessary to be overly prescriptive, but rather to identify boundaries across various business domains (sales, operations, finance, procurement, HR, etc.), the critical integration points that need to be standardized (it definitely isn’t “all of them”), core transactional, analytic, and master data, and the non-negotiables in terms of infrastructure and security.
Said differently, no one would build a new house without a blueprint that accounts for all the constituent elements, down to the plumbing and electrical wiring, yet it happens in technology all the time (sometimes at scale)… building without a design, and sometimes without a strategy… and the impact is cost, complexity, and risk. Eventually that hinders agility and competitive advantage.
Engaging architecture in scoping
Aside from having an overall blueprint and some level of actionable standards, engaging an architecture capability early in the scoping process should help to surface leverage points and opportunities to align new delivery solutions to the strategy where possible.
This is a careful balance to strike, because typically the front-end of the ideation and planning process, especially for critical programs, can move quickly with a significant number of stakeholders involved. If the architecture team slows that process or approaches discussions in a way that feels cumbersome or “ivory tower”, the impact they have can be marginalized very quickly. By comparison, if the team helps to identify opportunities for reuse, leverage of capabilities that will accelerate delivery, and ways to avoid decisions that could cause significant rework or downstream cost, there will be business value created in the process.
Estimating and allowing time for decisions
I remember a situation where a team was running a $100M+ multi-year program and reached a point mid-design where they announced, “we have a week to make the integration decision”. A multi-year program. A week to make a critical infrastructure decision…. and the team’s response to any challenge was that the cost of extending the program and/or missing the delivery dates mandated that the decision be made that quickly.
As it happened, the program was delayed for many other reasons downstream and the integration choices led to high operating cost, but the point is that critical decisions need time to be evaluated and possibly proven out through proofs-of-concept. The greater the knowledge risk or cutting edge the solution is, the more time that probably should be accounted for to ensure the solution will perform and scale as expected (if it is a strategic effort).
The alternate delivery approach is to “fail fast” and test out small pilots to learn what does and doesn’t work, but I’ve seen many of these efforts fail to scale and integrate over time because of a fundamental lack of design and architecture. Fast does not need to mean a lack of process and discipline, but that can be the tradeoff that is made at times.
Managing “deferrals”
Having spent most of my career delivering solutions, I am biased towards action and making difficult decisions where tradeoffs on speed versus quality need to be made.
That being said, deferred decisions tend to become technical debt, so I believe it is a good thing to maintain active transparency on issues that should be remediated as part of an ongoing simplification and modernization effort. Where these decisions are too tightly coupled with a program or solution, they almost always get deprioritized in deference to new features or capabilities, and no one typically wants to invest in “infrastructure” when something “works” at a functional level.
Planning the cleanup
In a similar way, when planning is too project-centric, the focus can be entirely on deployment of new capabilities without properly addressing the decommissioning of existing solutions that were previously in place, that can be a material effort, and not doing so can result in hidden complexity, inefficiency, and cost.
The remedy is fairly simple in this case, which is to ensure that the list of existing solutions to be replaced or retired is included in the project/program scope, roadmap, and plan. Where this is not in place, there is risk that things will be missed and additional complexity created post-deployment.
Wrapping Up
Balancing speed and quality/resilience is a continual challenge in technology, especially with the advent of AI. Discipline isn’t about moving slowly, it’s about moving thoughtfully, acting locally, but thinking globally in terms of implications.
It may not be a substantial change to have a more deliberate balance in what benefits a project versus the enterprise, but a simple matter having just enough of the right activities in the right places as the right time.
For Additional Information: Fast and Cheap, Isn’t Good, On “Delivering at Speed”
Excellence doesn’t happen by accident. Courageous leadership is essential.
Put value creation first, be disciplined, but nimble.
Want to discuss more? Please send me a message. I’m happy to explore with you.
-CJG 09/29/2026
