by CIO Executive Council

3 Ways the CTO Job is Evolving

Dec 21, 20124 mins
CareersCTOIT Leadership

Three companies are redefining the role of the chief technology officer.

What type of Chief Technology Officer are you?

Are you a realist, an unbiased cop or a product leader? Or maybe you’re all three. CTOs at three companies talk about the ways the role is evolving.

The CTO as Realist

Rose Smith, CTO, Campbell Soup Company: Campbell’s CIO Joe Spagnoletti sets the company’s IT agenda and relies on me and my team, the technology experts, to bring the plan to life. At Campbell, we understand that our people are as important as our tools, and we value management skills as much as we do technical skills in a CTO.

Drawing on my experience in both applications and management, I empower my team to gather and share technical knowledge with our leadership team, the function and the broader organization, acting as both students and teachers of IT. For example, we develop formal road maps, conduct regular meetings with our vendors, and share articles on trends and hot topics.

Joe and I are fortunate to have built a strong relationship based on mutual understanding of each other’s objectives and the challenges we face in our respective roles, which leads to easy agreement on key decisions. And he and I balance each other out–he is the forward-thinking visionary, while I am the practical realist. That combination helps us craft solutions that connect our 19,000 employees to each other, our customers and our partners.

The CTO as Unbiased Cop

Christopher Reigrut, CTO, SquareTwo Financial: The CIO and I divide up IT on the basis of “what” versus “how.” The CIO, Bill Weeks, is responsible for the “what”–investment planning, beginning with understanding what our lines of business are trying to accomplish.

As CTO, I am responsible for the “how,” as in how we plan to deliver on our promises. Because we are a midsize IT shop, we cannot do everything ourselves; part of my responsibility is figuring out how to staff projects and when we need to bring in outside help.

Regardless of job titles, the CIO and I consider ourselves diagnosticians tasked with helping the business solve problems even when the solution has nothing to do with technology. We’re not order-takers. In that sense, my CIO needs me to do two things:

  1. Provide an outsider’s view of the business problem based on my consulting experience
  2. Help him frame our technology plans in terms that resonate with our business partners. It’s not good cop-bad cop, but more like good cop-unbiased cop.

My approach to this role is shaped by my belief that there’s a difference between “leading with technology” and “leading–comma–with technology.” If I’m leading with technology, I am simply making a suboptimal business process more permanent by implementing new IT to support it.

I’m letting the technical solution dictate how we do business. In contrast, leading, with technology, is having the wisdom to recognize when IT is dictating a process, and instead helping our business partners redesign and improve inadequate processes that we can better support with technology.

The CTO as Product Leader

Hagen Wenzek, Global CTO, IPG Mediabrands: As global CTO for IPG Mediabrands, I manage the technology capabilities that we provide to our external customers, as well as the back-office tools we use internally.

My client-facing responsibilities are not unlike those of a CIO, or even a product-innovation executive. As such, I rely on the technical expertise of my executive leadership team, including my IT director, in much the same way a traditional CIO relies on a traditional CTO.

My job is to present technology solutions in terms that make sense to our clients, and over the years, I have learned what resonates with them and what gets ignored. The key is to focus on the results–what your customers will get and when they will they get it.

My clients do not need to understand all the details, such as how cloud works, to appreciate what will work best for them. I generally avoid asking clients what they want because often they don’t really know, and we might end up trying to meet the wrong requirements. Instead, I describe outcomes, rely on existing examples, and use iterative development techniques to produce proofs-of-concept that serve as conversation starters.

Follow everything from on Twitter @CIOonline, on Facebook, and on Google +.