At CVS Health we have a framework that we’ve formed and embedded inside the IT organization that drives our culture and outcomes. It’s what I call the ACT framework, A-C-T, and it stands for accountability, collaboration, and tenacity. These three cultural and behavioral ingredients, combined with the right technology and the right process, make the recipe for running an effective IT organization.
It all starts with accountability. Ultimately, as a CIO, what I’m looking to cultivate is an “accountable organization” as opposed to “an organization that is held accountable.” This is an important nuance that is perhaps best illustrated in a real world example.
When you watch a basketball game and a foul is called (assuming the call was accurate), there are three typical player reactions. There is the player who commits the foul and doesn’t respond with any reaction or emotion. It’s kind of an inert, passive response. Then there are two extreme reactions on either end of the accountability spectrum. The worst kind of reaction is the player who takes out his mouthpiece and starts screaming at the referee, aggressively arguing, “That wasn’t a foul!” This kind of behavior is the furthest thing from being accountable. On the opposite end of the accountability spectrum is the player who raises his hand and simply says, “That foul is on me.” This is a person who is accountable for his actions.
In all of these scenarios, a foul was in fact committed. The referee is going to hold the person accountable, regardless of how they respond. Similarly in technology, we make mistakes or issues arise that team members know we will be held accountable for. But when this happens, I don't want our people to let it roll off their backs with no reaction, or worse, try to defer blame or point fingers. I want to foster, culturally and behaviorally, a team that is accountable for our actions and willing to own our outcomes.
Getting to the root of accountability
When you are working with accountable people, the first thing they will do when an issue arises is become passionately and unwaveringly committed to understanding the root cause of the issue – not just fixing the symptoms, but rather treating the illness. We use the “Five Whys” methodology, which states that you have to ask “why” five times in order to find out the real truth, the real root cause, of an issue.
Let’s use a fictitious example that has nothing to do with technology. Say somebody calls into work: “Joe, I can’t come to work today.” In a typical work environment, that might be the end of the discussion. But in a truly accountable workplace, it's just the beginning. Let's use the “Five Whys” to find out the root cause of the issue:
“Joe, I can’t come to work today.”
1. “OK, just out of curiosity why not? Is everything OK”?
“My car won’t start.”
2. “Why won’t your car start?”
“The battery died.”
3. “Why did the battery die?”
“Because my alternator belt snapped.”
4. “Why did your alternator belt snap?”
“Because it was five years old.”
5. “Why was your alternator belt five years old?”
“Because, I did not follow the prescribed maintenance schedule for the vehicle.”
Now we’ve gotten to the root cause. It’s a lot easier to blame the car or the battery, but at the end of the day, our actions or inactions drive outcomes. Obviously, people in technology aren't talking about a car battery or alternator belt. They’re talking about hardware or they’re talking about software. But, ultimately, just like the example above, the discussion is not about a router, for example, it's about the person behind the router. We know that routers fail, plain and simple. So now that we know routers fail, we need to explain why we don’t have two of them; we need to explain why they’re not configured for 100 percent failover. This has nothing to do with the router; this has everything to do with how we architect and engineer these systems.
The “Five Whys” is a great acid test to see whether we are acting with accountability. When a system crashes, or there is a defect, or a project is late, or whatever the issue – ask why, and keep asking why until the answer to the question begins with the words “I” or “we”. When the answer begins with “I” or “we”, then you know you have an accountable organization.
Collaboration and tenacity round out the framework
Collaboration and tenacity are the two other essential elements of the ACT framework. Collaboration is all about working with our customers on solutions. The process shouldn’t be a series of handoffs between departments; we need to work together to solve problems.
When things are done serially, requirements are thrown over the wall and then we do a design and we throw the design back over the wall, and they sign off on it and we go off and develop it, and back and forth. That’s really not the most effective or efficient process. Instead, we try to embed ourselves inside the business and work with our customers to achieve the best outcomes.
Tenacity, to me, is like Superman laying over the tracks. As you evolve organizations, there are always going to be gaps. The gaps could be technological, they could be process gaps, and they could be people gaps. What I try to cultivate and aggressively reward are the behaviors that overcome those gaps.
A tenacious organization is one that is dedicated to keeping our commitments to our customers at all costs. I've come to realize that the better you get at people, process, and technology, the less you need to depend on the tenacious nature of this ACT formula. But especially in times of transformation, you need a tenacious organization to carry you through any obstacles that may be standing in the way to success.
