I was recently asked by a customer, “How do we change the culture in our organization to create an API culture?”
Changing culture or changing behavior is very difficult. People are creatures of habit. When people find an approach that works for them, most go back to that approach when faced with the same or similar problem. They do not try to figure out the solution again and frequently do not look for a better way. They just do what worked before. Behaviors and ways of working become part of an organizational approach that develops over time and becomes more and more ingrained – a culture. Abrupt changes to this are extremely difficult to make happen. However, there are times when a better solution or better approach comes along and we want to push for this ‘new way’.
What is the Real Goal?
I am about to commit heresy on the APIscene, an API focused web site, questioning whether creating an “API culture” is really the goal. I do not think it is.
APIs are a tool, not a destination. If we were successful in creating an API culture what would that mean? Does that mean we create large numbers of APIs? Does that mean the more APIs, the better? This is probably not the goal. More likely the goal is to drive the business benefits we see achieved using APIs. So, goals related to speed to market, increasing customers, innovation, or increased sharing of assets are probably the true goals for a culture shift. For this discussion I will focus on Innovation as a target example.
APIs are a tool that helps achieve increased innovation. The problem is: how do we get the necessary constituents to use our new tool to achieve increased innovation? Without impetus to change our business application developers continue to try to access business assets as they have always done previously. How do they know that APIs exist as an alternative and that this might be an improvement? How do they know when / why they should be used? For IT projects that are implementing new or changed back-end systems, how do they know that they might want to provide access via APIs? And, what APIs might they want to expose and how do they go about doing this? But, most importantly, why is it better for any of them to use this new approach over the prior proven method?
How Committed to Change Are You?
The old business fable about the chicken and the pig applies here. The story is about commitment. In the story the goal is to create a breakfast of eggs with bacon or ham. The saying goes that the chicken is involved, but the pig is committed.
When this comes to innovation, I am not suggesting you go quite as far as slaughtering yourself for the cause. However, a higher level of commitment to change can drive success far more quickly and is more likely to succeed.
Following IBMs acquisition of Red Hat, we have had many discussions about culture. In IBM we are trying to learn from the culture that Red Hat brings to us (and perhaps the other way around as well). Jim Whitehurst was the CEO at Red Hat and is now the President of Cloud and Cognitive computing at IBM. One of Jim’s first meetings with the IBM team was about culture. Jim said, “Culture is the output of a management system. It stems from leadership behavior and what gets rewarded. It is not an input.” Simply put, telling people to do something differently as the sole impetus to change is highly unlikely to be successful.
The Most Common Approach – The “Involved” Chicken
Unfortunately, the most common approach does not change what gets rewarded or the management system. The commitment level is involved (chicken-level) but not fully committed (pig). Typically, the buy-in is not at a high enough leadership level in most companies to make significant change – at least initially. Instead companies put the responsibility for driving change on the roles of the API Product Manager and API Initiative Leader. These roles are discussed in greater detail in prior articles and papers (What are the Recommended Roles for an API Initiative? and Recommendations for an API Economy Center of Excellence). This approach is lower risk, but also lower reward.
It is the job of the API Product Manager to understand the business needs of target consumers (application developers), drive these APIs to be developed, and then drive this target audience to use these APIs. The Product Manager is responsible to change the behavior of the application developers. However, these application developers do not report to the API Product Manager and the person in this role typically has no mechanism to force the change or reward the change if/when it occurs. So, the persuasive ability of the Product Manager to convince the target audience to change behavior is the key. If the correct APIs were built and the Product Manager is skilled at this task, then the behavior might change.
Similarly, it is the job of the API Initiative Leader to drive API use to additional projects and organizations across the business. But also, similarly, the API Initiative Leader does not have the authority to force the use of APIs or reward it.
With talented persuasive people in these roles, changing behavior can be successful. But there will also be missed opportunities and lapses, and the duration to change behavior is elongated.
The Most Successful Approach – The “Committed” Pig
Executive leadership establishes the organization goal to be innovation. They also change the organizational structure to drive to this goal. Innovation is measured and rewarded. The organization that does this is ‘all in’ – pig-level committed to innovation.
Organizational change causes disruption to the norm. Along with a change in leadership behavior and what gets rewarded, these drive employees to look for new approaches and change to what they have done before. Managing toward innovation is different from project delivery. Managers might inject variants to drive innovation rather than inspecting people to do as they were told to do. Good dialog across the team is essential and constant iteration and feedback should be implemented.
I have seen some organizations that form segments in the organization to focus on innovation and/or create a Chief Innovation Officer role. These may help draw focus to the initiative but if done poorly may also create only a focused segment of the company that cares about the new goal and not the broader organization. You need to decide how pervasive you want to make the change.
The same API Product Manager and Initiative Leader roles described previously exist in this approach and they have the same responsibilities. And, like the prior example, the audiences they need to influence still do not report to them. However, they are far more likely to succeed in their desired areas of influence because the audiences they are trying to influence are being measured and rewarded based on results these roles can help them achieve.
An Approach That Does Not Work – The Hungry Diner
The diner sits at the table and orders bacon and eggs. If there is no chicken or pig, no food arrives. Unfortunately, we see this approach in API initiatives too. Management starts an initiative to build APIs. They have heard that this is a good thing and can drive innovation. However, they do not instantiate any organizational change or modified measurements, nor do they staff the critically important roles of API Product Manager or Initiative Leader. Without any driver for change in the organization or any person assigned to drive the usage, the developers build APIs – sometimes, they are used – sometimes, and there really is no quantifiable change in the company to achieve increased innovation. The API initiative is deemed to be unsuccessful.
Culture/behavior change is difficult. Commitment is critical to success in culture change and the more commitment the better. Understand and focus on what change you want to create. Too often there is focus on the tool rather than the resulting benefit. Understand that if innovation is your goal, not all innovation is successful – and that is okay. I recently heard a story of a class where whenever anyone – teacher or student – makes a mistake everyone applauds to recognize the attempt. The teacher explained, “Mistakes are proof you are trying.” They get it.
If you have questions, please let me know. Connect with me through comments here or via twitter @Arglick to continue the discussion.
Graphics courtesy of Pixabay.com – Mensor, pixel2013, Reinhard Thrainer, and RitaE
