“When we’re right it’s because we’re lucky, not because we’re good.”

That quote sits in a tiny, old notebook squirreled away in a box I recently rummaged. It came from one of my financial services clients years ago, and it sparked some thoughts around the types of problems I get asked to fix as well as the repercussions of fixing them.

I work in IBM iX — IBM’s client-facing, business design service line— and for the past 20 years, I’ve worked almost exclusively in all areas of financial services. My design teams work on big, hairy problems. Quite often, we are pulled together to design (or redesign) systems meant to transform a complicated, data-heavy workflow for our clients’ employees. We make things simpler, faster, more automated, and more collaborative. We make them beautiful.

We start, of course, with stakeholder interviews, user research, and desk observation. I have witnessed some version of the following situation nearly every time: a user trying to do their best while jumping across multiple legacy applications that are well past their prime and which often include green screen tech, all while trying to make extremely important, high-stakes decisions very quickly. In this particular case, I remember one of the users having to open two separate, clunky applications on two different monitors and place his fingers on each screen, moving line item by line item — glancing back and forth — to make sure the data matched.

This is but a single example, and it was exhausting just to watch. Yet this beleaguered, dutiful fellow seemed resolved to it. Such situations are not unique among large, established companies that have been nursing along legacy systems because of the incredible data they contain. It just becomes “the way things are done around here.” It’s not evil or malevolently planned; it’s just a situation that develops around the need to keep the business going. Sooner or later though, the situation becomes untenable and too costly or risky and has to be fixed.

And we can certainly fix these things. We do it all the time. At the risk of grossly over-simplifying what all good designers know: we take our user research into a workshop with business stakeholders, the tech team and sponsor users; we craft a future state that eliminates all the pain; we mature that vision; then we mobilize a team and start delivering the solution that cleans up the mess.

But what then? What happens when you effectively eliminate “luck” from the workflow?

To answer that, let’s look at five important problems that I have seen caused by such dysfunctional workflows.

1. Compliance.

If someone has to make a high-stakes decision using inadequate support tools, that person is very likely going to create hacks and workarounds to get the job done. This could manifest itself in things such as spreadsheets with valuable and/or out of compliance data sitting, unsharable, on a laptop, or lots of sensitive information jotted down on post-it notes scattered around a desk. And these kinds of things lead to problems with…

2. Scale.

If someone somehow manages to get really good at gaming a poor system to get quality work done, their value as an employee increases, and they become very hard to replace. If that person leaves, they take all of that knowledge with them. Likewise, because they may be acting out of compliance, they can’t necessarily share these skills across the enterprise which means every new employee has to figure out the workarounds from scratch, and that causes…

3. Waste.

One of my clients had an operational system so complicated that a new hire needed 6 months on the job to become valuable. Assuming they last that long and they stay on the team, the company will then have problems with…

4. Quality.

If luck is necessary to the workflow, it can level the playing field in a negative way. When someone who isn’t skillful at their job has just as good a chance at being right as someone who is, it becomes hard to gauge the quality of the workforce and who is and isn’t deserving of promotion. Employees will sense this keenly and that can lead to…

5. Churn.

Someone who’s very good at what they do won’t remain in an environment where he or she can’t flourish, nor will they endure suffering just to perform daily tasks. In this dysfunction, the workforce is to simply going self-optimize toward a reliance on luck and hacking, which then takes us back to number 1, and the cycle continues.

Good companies come to recognize all of these things and will get the help they need to fix them. But poor performers are going to be exposed, and good employees who have carved niches are going to feel disenfranchised, so it’s important that this work be done meaningfully and that the change is managed positively.

When we solve these problems using Enterprise Design Thinking, the Keys that make our framework unique are a critical part of reaching this goal: Hills articulate the shared, hopefully measurable goals we aim to help our users accomplish; Playbacks are story-driven check-ins to gauge progress while uncovering and addressing misalignment; and Sponsor users are actual end-users who keep the team aligned. (If you want more detail, you can get that detail here.)

We must involve, from the beginning of any such effort, real users and influencers who can help both co-create the future and support the delivery. The Hills we use to scope that delivery must measurably reflect real value to those users and the business. And the Playbacks keep involved parties aligned and the work constantly course-corrected.

With a well-executed project and thoughtful change management, the endgame is a better, healthier work environment that rewards great talent and has the tools in place to foster quality work, no luck required.

Tony Moreno is an IBM Design Principal working at IBM iX and based in Cambridge, MA. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions. To view the original article published on Medium, view here.