Implementing New Technologies: Systems Thinking

Jacques hadn’t used his department’s database for a few weeks while he was assigned to a special project. Now, he’d forgotten his password.  He knew about the company’s brand new password reset tool and had set up his security questions. Confident, he logged into the reset system and changed his password. He still couldn’t get into the database, and now he was getting prompts to lock his computer and unlock it with his new password. Confused and frustrated, Jacques called the service desk.

Confused and frustrated, Jacques called the service desk.

It still happens. Applications are introduced into the organization’s environment that don’t use the central directory (AD in this case) and don’t talk to their password reset tool. While it should be a standing requirement that every new application must use the central directory and work with the reset tool, it still happens that developers don’t—or can’t, because of platform limitations—execute this.

The problem is, of course, much larger than passwords. It’s in the way we approach implementing new technologies. We target one solution and tend not to think about the upstream and downstream effects. We see the components in front of us, but not the system of which the components are part. We make a change that benefits us without considering its overall impact on the organization’s value stream. We react to today’s pressure only to find that we’ve created more technical debt for tomorrow.

Pardon my reluctance to introduce the term DevOps into this conversation. It has become such a buzzword that you might turn away thinking, “Oh, no, another blog about DevOps.” This post really isn’t about DevOps, but rather about one of the ways DevOps thinking can help us. If we begin looking at the entire organization as a system, we can avoid introducing components that are not compatible, or which will interrupt workflows, causing extra work for some or all involved. This is true not only for developers, but for anyone who is specifying, evaluating, or approving technologies.

“The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department—this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).”
—Gene Kim, IT Revolution Press blog

Systems thinking is nothing really new, but there is an increased interest in applying this view throughout organizations. Before we go about investing in and implementing new technologies, we should be asking:

• How will the change help create better business outcomes?
• Whose work will decrease or increase because of the new technology?
• Have we included all the relevant stakeholders in the discussion about the change?
• How will the change improve the flow of information, work, and value?

Organizations, especially large ones, can be exceedingly complex and sometimes difficult to understand. If we begin building relationships with our peers in other business units, we can start to see how the pieces fit together and then think about how changes can be beneficial to the entire organization, not just our own group or department.

I’ll talk more about how The Three Ways can benefit us in future posts. Thanks to Stuart Rance for inspiration.