Making Better Technology Decisions – Going beyond the One-Size-Fits-All
Organizations often struggle with lengthy technology decision-making processes due to the tendency to find a single solution that can be used across the business. Whether it is about using a new ML service or deciding on architectural patterns for a cloud migration, decision-making processes are often driven by a leader's ambition to find that one-size-fits-all solution or approach with limited complexity at the lowest possible cost.
While it sounds sensible at first, it can harm an organization's ability to innovate and deliver new customer experiences quickly. It also demotivates those in the organization who have product ideas with high customer value, who are required to wait for the time-consuming analysis to be completed to get the 'green light' to start executing, or worse, rebuild what they have already created.
In this article, I want to shed light on additional criteria for technology decision-making that can help leaders look beyond the urge for a simple, harmonized tech stack and process landscape.
Why Technology Standardization Is More Complex than It Seems – And Less of a Necessity than It Used to Be
The desire for a one-size-fits-all and simplicity often manifests in the wish for a single technology to cater to a large group of internal users, covering a broad functional scope. In addition, the desire is to have 'one way to do things' across the organization, limiting the need for different teams to learn how to operate multiple tools, simplifying training efforts, onboarding, governance, and maintenance.
This an understandable desire, especially from a leader's perspective, who frequently notices teams engaging in similar or overlapping activities, each on a different tech stack. The second argument is cost. With tightening budgets, every approach that promises lower technology spent is welcome. Volume discounts can be a compelling argument. The challenge that leaders frequently neglect is the organization's ability to align on using a single technology, even when it covers the mandatory requirements of each stakeholder. When teams have used technology successfully in the past, forcing them to adopt a different one will inevitably slow them down in the short term. This a tough sell for teams that are used to a high velocity when delivering products and services.
This intense desire for single, central solutions is driven by past experiences where technology decisions came with multi-million investments and long-term contractual obligations. These types of technology choices, of course, still exist. Think of CRM or ERP, where standardization and having a single, company-wide solution also comes with significant benefits and typically outweighs arguments like time-to-market. But there are more and more areas where pay-per-use models and services that can be quickly adopted and just as quickly discarded are prevalent. In addition, when technology delivers differentiating value for customers and speed of innovation is paramount to remain competitive in the marketplace, the focus on standardization may need to be reconsidered.
How Architectural Standards Can Block Organization's Ability to Deliver
An example of an unhealthy focus on organizational standards is how some organizations approach their cloud migration. They start by setting up a central team or 'Cloud Center of Excellence (CCoE)' to define a perfect, one-size-fits-all architectural runway - which, in theory, will be quickly adopted by all teams. The central team specifies standard architectural patterns, database types, and cloud services to be used. The problem is that analyzing current architectures and defining a target state takes a lot of time. Second, finding alignment across teams on how to do things and set organization-wide standards takes even more time. Specifically, application teams with previous cloud experience and defined patterns will naturally challenge a new, standardized way of architecting and operating. As a result, you end up with resistance and a lack of outcomes due to endless analysis and discussion, and often standards are already outdated by the time they are introduced. Further, you often see that analysis remains theoretical, and once concepts are applied, assumptions are proven wrong and need to be adapted.
This does not mean that standards are not required. Still, the decision for the right level of standardization needs to be very considerate, focusing on setting only the required boundaries while leaving enough space for teams to innovate and deliver quickly.
How can you ensure that you do not standardize technology for the sake of standardization but ensure you apply the proper decision-making criteria? Here are some ideas on how to use frameworks and mental models to ensure decisions are made, considering additional measures to make technology decisions.
Amazon's Two-Pizza Teams
At Amazon, the idea of 'two-pizza teams' focusing on ownership and independence to run fast and deliver innovation is part of the company's DNA. The focus is on getting learnings quickly and at lower stakes, with small, autonomous teams, but with alignment, for example, on how other teams can consume services. This autonomy does come at a price, however. There can be duplication and siloed development, and it requires governance structures to ensure that purely repetitive tasks are eliminated at a certain point. It stands in stark contrast to how many other organizations operate. But it enables rapid innovation and delivery to customers, which frequently outweighs the potential benefits of technology and process harmonization. While this may be extreme, it is worth considering how to adopt this thinking when time-to-market is of the essence but neglected [1].
Depending on the industry you operate in, some boundaries will require you to put specific governance rules in place. For example, if you are in the financial services or healthcare industry, application changes may require particular compliance validations, or you may be forced to ensure specific disaster recovery mechanisms. Using the mental model of 'two-pizza teams' will help you, even in regulated industries, to emphasize speed of delivery by giving autonomy to teams – as much as possible.
Make Expected Business Outcomes Part of the Equation
When teams argue against using non-standard technologies or want to deviate from architectural patterns, you should consider how doing as they wish will help them accelerate business outcomes.
Do they have a skill set that lets them deliver quicker using a specific technology?
Do they have good arguments for using a non-standard cloud service due to specific features they want to utilize?
And ultimately, does their business case create a strong top or bottom-line impact that makes cost efficiencies less of a priority?
Making these questions part of your decision-making enables you to adjust your decision-making criteria, giving teams more autonomy - if they make a good case. Specifically, when upfront investment is limited, these experiments can help drive innovation with little financial risk.
One-Way Door versus Two-Way Door Decisions
A framework that can support a leader's decision-making in situations that may create duplication but, at the same time, create significant short-term business impact is by asking whether a decision is a one-way or two-way door decision. Jeff Bezos explained in his 2016 Letter to Shareholders that speed matters and reversible decisions, i.e., two-way door decisions, can use a lightweight process. He argues that most decisions should be made with around 70% of the information you wish you had, and waiting for 90% will usually mean you are too slow.
This simple but powerful mental model can change how you approach decisions. If you look at whether you can pivot from a decision if it turns out to be the wrong one, with limited impact, take it. Be bold and make decisions without having the 'ideal' 90% of the information. When you start considering if decisions are reversible, you will notice how many of your decisions suddenly turn out to be less critical than initially expected [2].
Momentum and the Value of Real-World Evidence
Another aspect to consider in decision-making is consciously allowing teams to deliver their solution, even when noticing overlap with other teams. For example, suppose this competition comes with reasonably low investment. In that case, you create the opportunity for teams to showcase the business value they can generate and consider deciding on a central process or solution once you capture real-world data points. There are numerous examples where you can allow for the best solution to prove itself in production since, as discussed earlier, there is also a time-to-market benefit that must be balanced with the investment.
If you want to zoom out and look at how your operating model can be adapted to foster fast decision-making for your organization as a whole, I recommend a recent article in Harvard Business Review by Rita McGrath and Ram Charan on "The Permissionless Corporation" [3].
References
Independent Health Insurance Broker
6 个月Michael, thanks for sharing!