One of the most difficult decisions in technology is deciding what not to build. That may seem counterintuitive. After all, technology teams are generally measured by what they deliver. Business leaders are rewarded for moving initiatives forward. When someone has an idea that promises to improve operations or solve a long-standing problem, the natural response is to ask, “How quickly can we get started?” Or the more popular one I get, “When will it be done?” Always mind-boggling to me, as I have to hold back saying, “you just came up with the idea five seconds ago, and you think I know exactly when I’ll have it done by? You’ll have ten more ideas before this meeting is over!”
I don’t say that. The better response is, “should we do this at all?” Getting to the heart of why we’re asking for a solution is more important than answering when we can. Michael E. Porter, professor at Harvard and leading authority on company strategy, once said:
“The essence of strategy is choosing what not to do.”
I don’t think that principle applies only to strategy. It applies equally to technology, operations, and even sales. But in technology, every new application, feature, integration, automation, or report carries a cost that extends well beyond the initial implementation. It needs to be maintained, supported, documented, secured, upgraded, and understood. Technology has a habit of becoming part of tomorrow’s operating expenses.
That doesn’t make new technology inherently a bad investment. It simply means that every investment deserves to be evaluated carefully.
I’ve worked with organizations that had dozens of systems solving dozens of problems. Most of the time, those systems didn’t cooperate with each other. Thus, individually, many of those systems made sense. But collectively, they created unnecessary complexity and too many endpoints to keep track of. Staff entered the same information into multiple applications. Reports produced different answers to the same question. In meetings, I used to regularly ask, “what exactly constitutes ‘a sale’? Because we have five different sales reports, all reporting different numbers, because each requester defined a sale differently.” As a result, integrations become increasingly fragile. Someone always inevitably suggests purchasing or building another application to help organize the existing applications.
So by that point, we’re using technology to solve problems created by technology, and no one has a clue what we’re doing. There’s a little humor in that, but only because it’s surprisingly common.
So before cooperating with adding a new project to the ever-growing list, I try to draw out the answers to a few simple questions:
- Does this solve a critical business problem or fulfill a significant need?
- Will the project deliver clear, measurable benefits within a defined time frame?
- Can the project’s success be replicated or scaled to enhance value or impact over time?
- Does an existing system already provide this capability?
- Will this make the organization simpler or more complicated?
- What ongoing commitment are we accepting by building or purchasing this solution?
Those questions rarely produce immediate answers, but they do encourage better conversations.
The challenge is that is that every request can sound reasonable on its own, and without any additional context. Viewed in isolation, a custom report, a new workflow, another dashboard, or a specialized application may all appear worthwhile. The difficulty comes when those requests begin accumulating over time, or if they require limited resources that are already allocated to other projects or initiatives. Eventually, the organization is supporting hundreds of individual decisions that were never evaluated as a whole.
This is where architecture becomes valuable.
A good architecture doesn’t restrict innovation, but it provides a framework for deciding whether a new idea strengthens the overall environment or simply adds another layer of complexity. Good architecture also recognizes that consistency has value. Building five different solutions to accomplish the same objective rarely makes the organization more capable.
The Standish Group has consistently identified clear business objectives, executive support, and optimizing scope among the strongest predictors of project success. While the rankings have evolved over the years, one theme has remained consistent: successful projects begin with a clear understanding of what the business is trying to achieve. (https://www.cafe-encounter.net/p1183/it-success-and-failure-the-chaos-report-factors, https://cdn1-public.infotech.com/agile/CHAOSReport2015-Final.pdf?utm_source=chatgpt.com)
Technology leaders sometimes feel pressure to say yes because saying yes appears to create progress. In reality, progress often comes from making thoughtful decisions about where effort should be invested. Every project that begins also consumes time that could have been spent elsewhere. That is why I believe technology leaders should be comfortable declining good ideas.
Notice I didn’t say bad ideas.
Good ideas become distractions when they don’t support the organization’s direction or strategy, or when they arrive before the business is ready for them. Timing matters just as much as value. A worthwhile initiative today may become an excellent initiative next year after a more foundational piece of work has been completed. Technology should make an organization easier to operate, not harder to understand.
Choosing what not to build isn’t about limiting innovation. It’s about protecting clarity, reducing unnecessary complexity, and ensuring that the work you choose today continues to serve the business tomorrow.