Zero Gain vs. Zero Loss: Practical Tales of Enterprise Decision-Making

Diagram made in real-time, by Ashton Rodenhisr, during Amélie Koran 2018 All Day DevOps keynote 

With more than 25 years of experience, Amélie Koran, who currently serves as the Deputy Chief Information Officer at the HHS Office of Inspector General, has seen a lot of ups and downs when it comes to software development; she’s worked through the full stack of technology and leadership.

And, over the years, she’s noticed that technologists struggle with advocating for their work. This results in IT being seen as a cost center and nothing more. This shouldn’t be the case, and is a detriment to innovation.  Koran wants to help technologists see how leadership views DevOps and DevSecOps - so they can help better advocate for their need. In her 2018 All Day DevOps Keynote - she provides practical advice that technologists can take home with them.

In that vein, let’s first consider the concept of zero. Zero indicates significance, magnitude, or absence. From game theory, “zero-sum” indicates the loss or gain of a situation. As for Koran, she strives to get as close to zero with her budget as she can.

But there’s always going to be gaps between expectation and reality. When you’re asking questions about those gaps, Koran advises you try to use those questions to create relevant goals or outcomes. Use them to determine what it takes to get from point A to point B to point Z. What drives a project through those points?

For DevOps, this means determining your “play”—an action you can take to affect an outcome. For example, one play that Koran recently used was to involve senior leadership in design sprints. This gave them the opportunity to better understand what teams were up against and helped reach the goal of improving communication between leadership and dev teams.

Let’s talk more about these plays you can make.

Play One: Metaphors

Metaphors connect on a common touchstone. Koran used the example of culture references, like Ghostbusters, to help conceptualize topics like antivirus and cybersecurity for those that aren’t technical. So finding a common metaphor can explain value. For example, you can conceptualize technical ideas related to risk by mapping them to business terms like actuarial tables, if you’re talking to the finance department.

This works because you’re speaking in terms of business. You don’t talk tech. You can explain spending a little to save a little—they’ll understand that. Or you can explain that by spending more now, we can save more later. This way, you’re helping the business understand security risk in financial terms.

Play Two: Participation

Here, Koran talks about the value of having a seat at a table. This means it’s not just technologists that should be discussing DevOps concepts. Leadership can provide insight; they show technologists which concerns are real to the business and which concerns are imaginary.

You should also share budgeting concerns. Keep technologists active in budgeting meetings, and provide them with additional information on what a particular line item means and why it’s important to the company. Technologists can, in their own right, provide background that the business leadership lacks.

And here’s great tip from Koran: set up brown bags and lunch and learns to cross technologists’ paths with leadership’s. These meetings also provide a connection between staff, mission, and operations. And they lessen communication barriers. You learn to communicate with folks in other parts of the business with a common language.

Participation will help foster empathy toward others. With empathy, you can fight for others’ needs and understand where they’re coming from.

Play Three: Conceptualization

With play three, you want to define everything to make sure everyone is able to conceptualize what’s going on. You work from a common lexicon. Agreement on what things mean helps make conversations easier. Also, it frames discussions. For example, when talking about server costs, you should use common language, and you should use concepts that all can understand.

Clear communication removes stress and anxiety. You don’t want people to take things the wrong way.

Clear communication can also assist in reuse. Good documentation provides background and finds new uses for repeated concepts. And it provides a good jumping off point for other teams that are looking at the same problem.

Storytime

Executives always want a dashboard, and this inspired Koran to introduce “storytime”—some examples from her life. There are a number of problematic things with dashboards, in her experience. Executives often want traffic light colors in their dashboards. However, there could be cultural significance to those colors that doesn’t work across the board. Or maybe the folks in charge want things summed up in a single number, which often makes Koran want to roll her eyes. After all, is a single number qualitative or quantitative? Risk is qualitative, giving shades to what the number is.

What decision is the dashboard intended to support? Does it help solve a problem or issue? For example, if your backlog is growing exponentially, it can show that you don’t have enough resources for the project.

So, if a dashboard has to happen, it doesn’t need to be pretty. It needs to add value.

As long as we’re having storytime, let’s discuss the story sparked this talk. Koran was inspired by an article by Brian Krebs on a bank that was breached twice. Koran notes the key word “twice.” This is result of an “out of sight, out of mind” attitude when trying to fix a problem. Since the bank was insured and had moved past the initial breach, they didn’t go back to fix the problem that caused it. They played the odds that the first breach would never happen again.

If we’re to learn from this, we want to use experiential learning for change. Another of Koran’s stories focused on being in a hurricane. Saying that “we’ll never have a hurricane” or other disasters may be statistically accurate because the actual probability is close to zero. But it could still happen.

If you don’t think about problems happening, they’ll still occur. You just won’t be prepared for them.

However, you shouldn’t always design for the black swan event. That may result in spending too much time dwelling on events that are unlikely to happen. Instead, let’s use these experiences as a base for a general behavior change. For example, a trading floor practiced live recovery events by sending everyone up to a disaster recovery room. Then they worked out of that room for a week.

To rationalize events in DevSecOps, think about how people use your system. Aim to reduce user errors. Automate testing. Utilize test environments—don’t deploy directly to production. And as for DevOps, argue for test environments to reduce errors and increase resiliency.

So, what’s Koran’s  advice? Perform root cause analysis, spend time with developers, security, operations, management, and even legal. And, always utilize every person at the table, share your department's story with the rest of the company in a clear and concise way. It’s the only way people will understand why this is so important.

***

Missed Amélie Koran’s session, or want to see some other great presentations from October 17? Head over to https://www.alldaydevops.com/live and make sure you’re registered. Then, catch up on what you missed (or re-watch your favorites)!

About the author, Sylvia Fronczak

Sylvia Fronczak is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time. You can find her at sylviafronczak.com.