A Framework for Making Successful Technology Decisions Core Concepts

  • Date: February 15, 2022

The framework for making technology decisions is built on two core concepts.

1. Capacity building:

addresses the importance of empowering agencies to recognize they can be in the driver’s seat with regard to technology.

2. Systems thinking:

is essential to making solid organization-level decisions about technology.

Capacity Building

Long gone are the days when computing and automation of information were relegated to mainframes touched only by highly trained engineers. With supercomputers in nearly every pocket, the pervasiveness of information technology in our lives is one of the most striking characteristics of the modern era. Yet the tendency still persists today to segregate thinking about technology into roles filled by highly paid specialists, even as general understanding about how such things work has expanded tremendously and no one is left unimpacted by what’s ultimately built.

Much of this continued reliance on “techies” can be attributed to the myriad details needed to get a given piece of technology to work and a pace of change that’s hard for the average person to keep up with. For that there will always be a need for people with expertise in a given technology domain. But when it comes to thinking about the role technology is to play in an organization, we urgently need a different approach if we are to increase the likelihood of success.

In this white paper, the framework for technology decision making proposes an “all hands on deck” approach, where perspectives are sought from everyone involved or impacted; everyone is assumed to have the capacity to think critically about technology; and no one needs to look or act like the stereotypical techie to actually be one or become one. This is especially important when it comes to smaller agencies, where a belief that technology is beyond their understanding blocks possibilities that may be critical to its success. Wherever skills that support managing technology are already present, they need to be recognized so they can be brought to bear. Where they can be developed internally through support, training, or hiring, that opportunity should be explored free from the preconceptions left over from the distant past.

Systems Thinking

As a steward of complex transportation infrastructure, you are responsible for seeing how many parts of that system relate to and affect each other. That means you’re engaging in systems thinking, which Daniel Kim has defined as “a school of thought that focuses on recognizing the interconnections between the parts of a system and synthesizing them into a unified view of the whole.”2 We encourage you to explore this topic 3, but for our purposes, we want to introduce the general idea of having a systems thinking mindset.

Figure 1. Differences between Design Thinking and Systems Engineering.

Group of creatives brainstorming

Design Thinking

  • Helpful when the solution isn’t well defined or clear
  • Can look messy
  • Emphasizes adapting to new information
  • Encourages working with inexpensive elements and prototypes to see what works
  • Process doesn’t have to end; can be tinkered with to pursue refinements
  • Easy to respond to new information and changing conditions

computer engineer at workstation

Systems Engineering

  • Helpful when several components have to be customized to function together
  • Emphasizes planning and finding parts that will work together for the long term
  • Relies on careful selection of system components that relate to each other in very precise ways
  • Process has clear end point
  • Difficult to make changes once decisions have been made

We’ve selected two complementary flavors of systems thinking: design thinking and systems engineering. Figure 1 provides an overview of these ideas. These two approaches can be used together or separately, depending on your needs. Later on, we’ll point out situations that lend themselves to one versus the other


2 Daniel H. Kim, “Introduction to Systems Thinking”, available at: https://thesystemsthinker.com/wp- content/uploads/2016/03/Introduction-to-Systems-Thinking-IMS013Epk.pdf

3 One resource we suggest: “Habits of a Systems Thinker”, from the Waters Foundation for Systems Thinking, https://waterscenterst.org/systems-thinking-tools-and-strategies/habits-of-a-systems-thinker/


Design Thinking

The Interaction Design Foundation describes design thinking as “a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test.”4 Figure 2 shows the five phases or stages of design thinking: empathize, define, ideate, prototype, and test. A design thinking process is quite flexible, allowing teams to adapt to new information. Because of its emphasis on iteration—repeated questioning, generating of ideas, and cheap prototype testing— design thinking is useful in making technology decisions where there are many unknowns at the outset of the process. In the face of uncertainty (“we have a problem, but very little idea how to solve it”), design thinking permits an open-ended, exploratory approach that can help define a path forward. This type of thinking can be used throughout your decision-making process, on its own, or in conjunction with other methods, including systems engineering.

5 stages in Design Thinking.

Systems Engineering

In contrast with design thinking, systems engineering is a more formal, linear process. Systems engineering requires significant time and effort, perhaps with a consultant, because it calls for a detailed articulation of all system requirements before you’ve settled on any specific solution. For complex technology projects, this process can save time and money in the long run because it demands thinking things through systematically. It tends to be the best approach when the end result is long-lasting infrastructure. As an intentionally linear process, backtracking when problems arise can be difficult.

Systems Engineering’s “Vee” Design Emphasizes Testing and Validation

Chapters