Does this sound familiar?
It’s Friday afternoon at 4 p.m. when a frantic text arrives from the COO: “Hey, no one can get into our CRM. Did you start a weekend update early or something?” After some investigation (and a call home to delay the planned weekend getaway), it turns out there’s an obsolete application running that is no longer supported by the vendor, nor the recently updated platform. Earlier, the IT team had to jump through hoops just to get this application running, it was what the business side wanted.
It’s now 6:30 p.m., and all the relevant parties are assembled on a Teams call. The business side blames IT for failing to keep the lights on. The IT team blames the business side for insisting on using obsolete software just because “that’s what we’ve used for decades.”
The call ends. It’s now 7:30 p.m. Aside from yelling and finger pointing, no progress has been made. You say aloud, “No one wants to take ownership. Where is the accountability?
While something like the above situation plays out in different types of organizations in a range of markets, it does have a root cause: Ownership design. Understanding ownership design can help to minimize these issues and ultimately lead to efficiency in the overall IT environment.
What is Ownership Design?
Simply, Ownership Design is a way to precisely steer behavior by using carefully designed rules that define how people own things.
But how? Here’s a real-life example:
We all like to share our Netflix accounts – family members, neighbors, colleagues or even strangers! Yet many users don’t realize sharing their Netflix account could be a federal crime under the Computer Fraud and Abuse Act and punishable by up to one year of jail time. However, the CEO of Netflix, Reed Hastings, turned this into a marketing opportunity, saying “we love people sharing Netflix.”
This might sound counterintuitive – shouldn’t a company require everyone to pay for their own access? By allowing people to share their accounts, Netflix is hoping to make people obsessed with their shows and eventually get their own subscriptions. And this ownership design strategy has mostly succeeded.
Also known as “tolerated theft,” one of many ways ownership design can shape people’s behavior.
Common ownership design issues
Here are some of the common ownership design issues that can be found in many organizations.
“I reap, you sow”
Business wants an application, but it is IT’s responsibility to implement. When things work well, the business benefits. When something goes wrong, it is always IT’s fault. So, what is wrong here?
If we analyze this issue via the lens of ownership design, one of the root causes is an interest misalignment. In this relationship, the interest of the business is a better application, which requires IT to put in more effort. Meanwhile, IT operates with its own critical agenda, and diverting effort into additional work yields little or no benefit Yes, more policies and requirements, such as a Service Level Agreement (SLA), can be established to force IT to provide “better” quality. The reality is, it only sounds nice on paper. If the SLA must be enforced, someone is burning the bridge.
One common solution is a chargeback model. This allows IT to allocate its budget to specific business units rather than centralized to one department, which essentially makes the expenses traceable, increasing transparency.
“Cloud, the get out of jail free card”
More and more organizations are migrating to the cloud. Some of them are even cloud-first. The adoption of the cloud not only makes the boundary of network more and more ambiguous, but it also makes the ownership of responsibility equivocal. During a security assessment, the IT department at many organizations might say, “This is a cloud platform, not managed by us. This cloud vendor has a great reputation, so everyone uses them.” Cloud is almost used as a “get out of jail free” card.
Here’s the problem – this is not true. History has taught us that a poor implementation can undermine a great technology. In this case, it’s the ownership of responsibilities.
To overcome this issue, an organization should ensure they know what their responsibilities are. Many cloud services providers already have documentation that can be used for reference. For example, AWS has a shared responsibility model which outlines how responsibilities are shared between them and the customer.
“Build a community, not silos”
Traditional IT governance tells us to clearly define ownership, roles and responsibilities. It usually ends up with people spending more time finding someone to blame, turning IT governance into a finger pointing game. Now, let’s pause for a reality check: How many of these roles and responsibilities have been successfully implemented on a regular basis?
Overly sophisticated governance only creates a burden to enforce, which only creates tension rather than creating a sense of community. We are all humans, and our business practices should account for this. Data classification is a typical example. Too many data governance meetings turn into finger pointing games about who should be applying labels and how those labels should be applied. Then users are blamed for not properly applying labels. This hurts everyone’s feelings!
Instead of a cut-and-dried approach, IT governance needs to be more like a dial. You can turn the dial up or down as needed. This is also known as “designed ambiguity.” Again, using data classification as an example, at most organizations, how realistic is it for a user to memorize pages of definitions and properly categorize the sensitivity every time a document is created? Human factors must be taken into consideration – we are all busy (and a little bit lazy from time to time). It might be more effective to provide users a set “rule of thumb” for classifying rather than over-sophisticated policies. When automated technologies are ready, one option is to transfer enforcement ownership to automated technologies that can understand the context of a document rather than just simply matching patterns. For example, use AI to categorize the data based on these sophisticated rules in a much more reliable way. AI, after all, should be immune to some of our human flaws.
Use ownership design as a tool
The examples discussed here are just the tip of the iceberg. Design ownership issues can be found everywhere in IT governance and can often be the underlying causes of many IT governance issues. Unfortunately, this is due to human nature, because it’s inherent in our nature to ask, “what’s in it for me?”
Don’t be tricked by the term ownership design. It’s not simply a cut-and-dried approach. Instead, it should be used as a dial: dial up or dial down as needed. The ultimate objective is never about having a clear design of who owns what, but instead using it as a tool to shape people’s behavior. And when used properly, Ownership Design can be an extremely powerful tool in your pocket.