We’re all becoming software CIOs — a role Red Hat CIO Jim Palermo knows well

As products become more based in software, CIO roles will increasingly align with CIOs who’ve been selling software for decades, like Jim Palermo, CIO of open source solution provider Red Hat.

Whether you sell cars, candy, consulting, or construction, software is moving to the center of your business. Your products and services rely on software and data for nearly everything from product development to aftermarket support. So congratulations! You’ve become (or will become) what is, essentially, a software company CIO.

I’ve been writing about how life is different for software company CIOs for years — more specifically, on how they must make clearer distinctions between IT and product engineering than it is now for CIOs in other industries.

In 2014, I interviewed Gerri Martin-Flickinger, then CIO of Adobe, on this topic. “Traditionally, our product engineers have been responsible for any functionality that goes into the product,” she said. “When customers enter Adobe’s Creative Cloud, everything on their screen was developed by the Adobe product engineering team. But when they enter their credit card information to buy the product, it looks like the e-commerce functionality is embedded in the product. But it’s not. It’s actually being delivered by a web service that’s run by IT. We put IT offered services right into the product.”

Martin-Flickinger, who, before Adobe, was CIO of McAfee and VeriSign, became CTO of Starbucks for many years. Clearly, the leadership team at Starbucks had the foresight to hire a software company CIO.

So fast forward nearly a decade, and here we are with even blurrier lines between software engineering and IT, and with an even greater opportunity for all CIOs to take a page from the software CIO’s playbook.

Enter Jim Palermo, who’s been CIO of open source solution provider Red Hat since 2022, and with the company for 14 years before that. These days, like every CIO it seems, Palermo is leading a major transformation. “We know our customer engineering teams want to develop applications in one place and deploy them anywhere, whether on-prem or a public cloud,” he says. “So we recognize we need to support two business models: the traditional subscription-based model and an emerging consumption-based model. In terms of the latter, the ability to operate our software as a service within the hyperscaler platforms will increase our market share.”

The IT team’s role in this business model transformation is significant. First, says Palermo, is “instantiating our products in the marketplaces within the public clouds so people can easily consume them” along with “capturing the telemetry of how customers use our products so we can drive further opportunities for our sales and product teams. Our role in bringing telemetry from the hyperscalers back to our marketing, sales, and customer support teams is a big change. This is a new role for us.”

With the subscription-based model, customers download the software and run it on infrastructure in their data centers. This can create what Palermo refers to as an “air gap,” in that once the product is in the customer data center, the Red Hat product and marketing teams lose a lot of visibility into customer usage and experience.

The consumption-based model, on the other hand, gives access to new and valuable data. “Let’s say a software engineer decides to spin up an OpenShift cluster, but then doesn’t touch it for weeks,” says Palermo. “We can get that telemetry from the hyperscalers so we can increase adoption.”

Customer zero

The second major push for the IT organization is modernizing all those back-end processes to support both the subscription and the emerging consumption model. “With the evolution from a billings-based to a revenue-based model, we’re changing most of our backend systems, including ERP, CRM, and compensation systems to accommodate,” says Palermo. “The as-a-service model changes all our back-office value streams.”

Driving process change for a new business model and bringing product usage market data back to the product and marketing teams must sound familiar to any CIO, whether at a software company or not.

So, what’s unique about being a software CIO? What can other CIOs learn from their experience? First, we can talk about IT’s role as customer zero. “I get asked to do a lot of customer briefings and tell the ‘Red Hat on Red Hat’ story,” says Palermo. “Customers will say, ‘I’ve talked to the sales and marketing team. I get all that. But how are you, in IT, using your products to transform your business? How are they helping you modernize your application suite to acclimate to this new model?’”

Red Hat’s IT team looks for user interface glitches and performance issues, which the product teams have the chance to fix before they put the software in the market. The feedback from IT helps not only the engineering teams, but the product teams as well. “We help the product business units evolve the product, based on what we see as the demand,” says Palermo.

How does Red Hat’s IT role as customer zero apply to IT leadership in other companies? “Any CIO needs to evaluate a vendor’s product,” says Palermo. “My role in product development allows me some insight into how software products evolve over time, and gives me a different set of questions to evaluate a vendor’s product.”

When evaluating a vendor product, Palermo and his team focus on scalability, and fundamental principles for release and version management: how does the vendor use customer review boards, and how do they use telemetry to evolve the product.

In addition to having a different perspective on product evaluations, software CIOs have deep experience recruiting full-stack engineers. “Because we’re living in the promise of containerized application portfolios, we need people with some understanding of infrastructure, software development, and release management,” he says. “These people are worth their weight in gold to us because it’s getting harder to segment each layer of the stack out as a separate organization or function. There’s so much cross-pollination of the tech stack now.”

Palermo knows from experience that the market is not brimming with full-stack engineers, so he and his leadership team look for potential, not experience. “We’re big proponents of bringing in people with technical aptitude and curiosity,” he says. “We put them on a three- to five-year journey to expose them to skill development opportunities. We rarely hire a full-stack engineer off the street.”

Selecting the right partners

Software company CIOs also bring a different mindset to vendor partnerships. All CIOs must make bets on which technology investments are going to prove valuable in the long term. The quality of Palermo’s CIOs investment decisions reside right in Red Hat’s product suite. As such, vendor partnerships take on a different flavor than in non-software companies. Partnerships with vendors for CRMs, ERP, and HCM are critical, but they’re one level more tactical than bets made by a software CIO.

At Red Hat, vendor partnerships are less about using another company’s software to run their businesses and more about strategic co-approaches to going to market. “If we work with another software company to leverage OpenShift with an as-a-service offering they already have in the market, we have to ensure their value proposition is in line with ours,” says Palermo. “Our conversations are more about helping each other increase market share than how we can use their products. The go-to-market conversation is much more important than it used to be.”

These “let’s go to market together” conversations are increasingly the province of CIOs across industries, whose business models are shifting to software solutions. So, what’s the learning from a software CIO? “We used to think like IT leaders when selecting, for example, an ERP package,” he says. “But when we talk about embedding a vendor’s product in our offering, we think like software CEOs.”