In several blogs since 2016, I pointed out the need for IT groups to change their structure and become a strategic partner to the business so they can quickly meet the needs of the business stakeholders. But as I discussed in my most recent blog, there are difficulties in getting IT aligned to the business needs. A significant difficulty is the inability of IT and business leaders to articulate their needs. Let’s look at how they can have more effective conversations to understand the real issues.
The need to bring about more effective conversations when IT and business leaders interface about product development cannot be overstated. The result of ineffective conversations is usually a product that makes no one happy because it is not perfectly fitted to solve the business problems.
Over the years, I spoke with several IT leaders whose consistent comment was that they “adopted all the agile stuff” but did not get the benefit of it. I recently mentioned this in a conversation with Stuart McGuigan, the former CIO of the U.S. Department of State and, earlier, the CIO of Johnson & Johnson.
He responded, “The idea that a set of agile teams could be working for months and not produce a business return is nonsensical. It means they are not really doing agile. Something critical is missing.”
That critical factor is businesspeople in the room making decisions with the IT people.
McGuigan says, in these situations where agile teams do not produce a business return, an IT person acts as a surrogate product owner and makes decisions because the business leaders say they don’t have time to “do IT work.”
He points out the fallacy of this mindset. If business leaders think the IT work is not important enough for them devote full-time resources to product development, then they should not do the work at all but, instead, devote the time and money to things they care about. If there is no business engagement, there will be no business return.
Instead of trying to build everything, McGuigan advocates working with business leaders, including the CFO, to narrow the focus to those things that clearly link to business results. Sounds obvious, but it often does not happen.
But coming up with that list brings us back to square one – being able to effectively communicate the business needs that a product needs to solve.
Where To Start
According to McGuigan’s decades of experience, the hardest way to start is to try to work only through the management chain. In a traditional hierarchy, issues get softened as they get escalated. Managers tend to “smooth out the rough edges” and, by the time information reaches the CIO, there are no negatives at all!
Instead, McGuigan recommends starting with the people who directly serve customers. For example, visit the underwriters in an insurance company or the customer service center taking orders for products at a healthcare company. “That way, you’ll see very quickly what works and what doesn’t work with the systems they are using. It can be a very humbling experience,” he says.
Alignment Starts With Finding Out What’s Really The Issue
McGuigan came up with one approach decades ago, which he refers to as “skip-level” meetings. These meetings include six to eight individual contributors or front-line supervisors – but with none of the attendees’ bosses in the room. After all attendees share their history and what they do, he asks a crucial question: “What makes your job harder than it should be?”
Consider the example of McGuigan asking this question of an IT person at a major insurance company. Release after release of new software had long created problems and outages. McGuigan asked the infrastructure person responsible for deploying the software what could be done to make this work better and make his life easier.
The infrastructure person’s answer: “Getting all the modules to me two days before go-live.” That does not sound like much and, in fact, was the company standard. The problem was that developers sent him changes up to the last minute, forcing a highly manual and error-prone release.
This changed when CIO McGuigan asked him to stop deploying manually and push deployment to two days after he received the last module, whenever that was. If he did not receive a module in time, he was to push back the deployment. This put the pressure where it belonged, back on the development team to get their code in on time. After that change, releases went very smoothly.
“I would never have found out the underlying reason for these persistent deployment problems if I had only followed the management channel,” McGuigan says. “We would not have heard anything nearly specific enough to get to a root cause. Asking that question – to the person who knew what was working and what was not working – made a huge difference in the quality of the deployments.”
With senior business leaders, McGuigan alters the question to: “What’s stopping you from realizing your business objectives? What do you need to be able to do tomorrow that you can’t do today?”
He shares an example of an insurance company divisional CEO who assessed market conditions and decided they needed to increase the company’s “risk appetite.” Every business leader in the room knew what that meant and what to do about it. “But you can’t write code from that. You need at least a few more details,” McGuigan points out.
He asked the business team, “What does that mean to you?” The answer: “We’re going to write more business.” McGuigan then asked, “How would that look?” The CEO’s response: “Well, my underwriters are going to put out more quotes. We multiply the number of quotes by the underlying asset value, and that gives me my business metric.” Then McGuigan asked the CEO, “What do we need to improve to make that work?” The answer came back very clearly. “We need to reduce cycle time to be responsive to our customers.” With that, they had a business metric they could build against.
Successfully conducting such a conversation with a senior business leader in business terms does not happen nearly often enough. When a new CIO comes in, business leaders are usually already very frustrated with their technology and the IT department.
McGuigan’s approach is to encourage the business leaders to talk through their frustrations. “You have to do a lot of listening and empathizing at first,” he says. “Don’t be defensive about what they say. At some point (and it may take more than one meeting), the business leader will be ready for the conversation to shift to ‘Ok, what do we do now?’ This is the start of a productive conversation.
In my next blog, I will share insights about hindrances and solutions for the interfacing conversation between IT and business leaders that result in an understanding of the real business issues and how to align.