Geoff Penney recently retired as CIO of Charles Schwab and Co. after a 25 year IT management career. Enterprise Insight’s Dave Margulius sat down with Geoff to get his views on leadership:


On delivery vs. efficiency:

“The essence of IT leadership is this endless dialectic between what the business needs in terms of speed and responsiveness of delivery, versus economy and centralization and re-use. You’re constantly trying to anticipate and respond to the needs of the business. But if that was your only objective you’d just give every business leader a bunch of IT folks and say have at it. For the sake of the firm as a whole, you have to have a single infrastructure, a single set of skills, to get the maximum re-use out of the network, out of the data centers, out of the technology. The struggle, and whether you win or lose, is driven by your success in balancing out those forces.

During the bubble, who the hell cared about centralization and re-use, it was all hands on deck and grow as fast as you can. In the deflation from the bubble it was the opposite—let’s figure out how we’re going to re-use everything we can and save as much money as possible. Right now people are beginning to talk about revenue again, and as soon as they talk about revenue, the next word out of their mouth is usually innovation, and where’s the IT guy on innovation.”


On partnering with the business:

“Interacting with the business … that’s a constant struggle. If you’re 100% responsive and always do what they say, that’s no good. You’re not offering the benefit of technology in a proactive way, the progress is entirely dependent on everybody else doing things and then seeing it and copying it. It’s not enough to be responsive and an order taker, you have to be proactive as well, be a partner.

The more credibility you have, the more able you are to push back and say I don’t think that makes sense from a business point of view. Make sure that the conversation you’re having with your business partner is being had in his or her territory, not your territory—that it’s a business conversation, not a technology conversation.”


On doing the right thing (and accountability):

“Doing the right thing is just so much easier than all those political things which are just so exhausting to do—it’s just much easier to stand up for what’s right. Things don’t get done by wishing. You have to look at people and figure out what they need, how to get them on board by meeting their needs. But almost always sooner or later you have to look them in the eye and say, well are you going to do this or are you not going to do it?

One thing I learned from [former Fidelity CIO Al Aiello], is that if you want something done, make it somebody’s job, so it’s really clear who you’re expecting to get this thing done—don’t throw problems out to groups of people and see what happens. Give it to somebody specific. And if you really want to make sure it happens, don’t give them any other responsibilities.”


On governance:

“I never know exactly what governance means, but to me, it’s the mechanisms you put in place to counterbalance the direct forces of the hierarchical organization. For example, if you have a bunch of people whose job it is to interface with some particular business unit—find out what they need, become expert on their business or industry—they are going to do a good job meeting those needs, because it’s their job. But to counterbalance those forces for the good of the whole, or for the long term as opposed to the short term, that’s what you need governance for.

I happen to think that the best organization is one which faces off against the business directly, and you kind of centralize the governance internally within the IT department. That way all the conflict—the technology mess, if you like—is closer to home. Better not to play out the mess in front of the business, better to play out the mess closer to home.”


On measuring success, and morale:

“There’s no direct measure of success like a P&L, we’re not a revenue business. In terms of how to manage and lead people, there’s no difference between being a CIO or a CFO or a COO. But you don’t have a single number like a revenue number or a margin number. IT of course has a million measurements, but anyone who thinks success in IT is around the measurements is not going to make it, because the measurements are all the stuff like availability, which more and more is taken as a given. Your success is going to be measured in terms of how well is the firm doing, in terms of this dialectic between responsiveness and economy—how does the firm feel that’s playing out.

The most important thing is that people feel interested in what they’re doing and want to work hard at it. Try to keep their expectations as closely aligned with reality as possible. I never discourage people from testing the market or interviewing. The more people understand the way it is in many different companies, the more they will say: you know, this is pretty good here, at the end of the day, I’m not sending stuff to the moon, but I’m not digging coal out with my bare hands either.

IT people clearly belong to a profession as well as a company. So the more you can make them feel like they’re learning, and building something which is not company specific but profession-wide, or building their resume for the next thing, the better. Whatever happens, in a technology group you cannot cut training ... a lot of what I’ve done over the past three years has been just more and more training. And there’s been a huge payoff.

The third thing is, the overwhelming reason people leave companies is because of a bad boss. They feel their boss is being unfair to them or unreasonable. I think people get more out of a company if they’re connected to it in as many ways as possible. So the more you can build special interest groups, mentorship groups, training groups, the more connected people feel as a whole. And while they view their boss as important they also know that bosses will come and go but Schwab will go on forever.”


On IT management training programs:

“We put about 400 supervisors through our Leading Edge training program, in cohorts of 20-25. Each cohort did four separate days of training, over about a year. The first of the four days was managing yourself, another one was managing your group, another one was managing your environment, and your boss and your clients; and the final one was strategic thinking, thinking about things not in terms of day-to-day tactics, but how does this fit in with what Schwab’s trying to do. In between they would meet as a group with a couple of mentors, more senior people, and discuss what they’d learned last time and how it applied to their jobs. My experience is that people learn much more from the group than they do from the course.

People get more out of things if they think what they’re doing is important. So in the first year I talked to pretty much every class. In the first session I spent an hour with them, giving them my own thoughts. It was a mandatory program, you didn’t have any choice about it, which is a very un-Californian thing to do. We had an excellent consultant who helped us with the leadership content, but the vast majority of the work was done by internal Schwab people. Each supervisor we did a 360 with before we started and a 360 after we finished, so we had some sense of how successful it was.”


On offshoring, IT careers and leadership development:

“There’s a wholesale change going on in the IT profession, like a perfect storm of events. Three trends are happening at the same time—the offshoring trend, the trend toward more methodology, and the increasing focus on enterprise architecture.

There’s been a considerable amount of offshore outsourcing—those are basically jobs that are not coming back. It happened in manufacturing and it’s going to happen in services and nothing’s going to stop it. I don’t see why it has to be limited to support and low-level, truthfully. It’s easy to start that way, but with information jobs, as long as you have adequate bandwidth to India, and they’re well-educated, well-disciplined, I think you can do much more than low-level jobs. I’ve obviously been talking to my employees all the way through this process and they’ve had a lot of heartache over the whole thing, as you would expect.

I had a lady say to me in one of my get-togethers—every month I sit in a room for an hour and anybody who turns up can ask me a question—should I advise my kids that a career in IT is kind of over? And I said no, I think it’s a great career, but the idea that you can join a company as a programmer and basically write code and specs and do that for 30 years and make money and retire, I think that is over. You’ve got to keep on learning and changing, and in general it’s the higher level jobs—the architecture jobs, the project management jobs—they’re the ones that are going to survive longer.

I’ve heard the argument that offshoring low-level IT jobs will make leadership development more difficult and I think it’s absolutely BS. In all the companies I’ve been in, none of them have taken people right out of college. Wall Street notoriously hires halfway up the pyramid, they always hire what they need, they don’t believe in training people for 15 years.

Very few CIOs today actually ever wrote any code … or if they did it was for a very short period of time. So then you say, well at a national level where are these people going to come from—they’re going to get trained tomorrow in the same way as today. What counts are where the brains are … as long as we have the brains, I don’t think it matters.”


On the rise of process and the demise of the cowboy hacker:

“People really want predictable projects. When they hear that the thing’s getting delivered on July 1, they really want the thing to go live on July 1 or earlier. We all do a better and better job, but it’s still pretty pathetic ... you know the construction industry is far more reliable than the IT industry. So everybody’s pushing toward methodologies—we adopted the Rational Unified Process a couple of years ago, and we’ve been working with it ever since. In my mind, there are no real competitors to that, that’s kind of the way you have to go. I think it’s a great advantage if our key people can become really conversant with it because I think it will become the lingua franca of the business. There’s no doubt that it tells you what to do next, this is how you do the project—I think the cowboy hacker is kind of being reined in.”


On the IT assembly line:

“When I started in this business there were islands of computer systems in a sea of manual process. But most firms today are a sea of computer systems with islands of people. In other words, everything’s connected. So instead of it being like the early days of building point-to-point railroads, it’s more like you’re constantly working on upgrading the New York City transit system. You’re constantly recognizing reality, that you have a huge investment, you cannot throw it away.

Architecture—at the enterprise level—has gone from being a theoretical idea to, well, how else can you work? How can you possibly work if you don’t specify interfaces, and make them as far as possible generalized, preferably industry standardized? And of course that’s what’s going on, with XML and web services and all that stuff. People used to get a real kick out the fact that they could sit down on Monday with the business people, hear about a problem, sketch out a design on Tuesday, do some coding on Wednesday, test it on Thursday and implement it on Friday, without basically speaking to anyone else—I’m exaggerating here.

Nowadays you almost never sit down and write code from scratch—almost always the core of what you want is available either in-house already, or on the street. What you’re really doing is integrating stuff that’s coming from all over the place. That’s been a real struggle even at Schwab, where I think we’ve had a pretty good handle on it. It used to be that people could make the whole car, and now they’ve in fact become either domain experts—component experts—or software integrators, assemblers. The same thing happens in every industry as it matures, and IT is becoming more industrialized and more mature.”


On the path to the CIO job:

“There’s never any one path to any job. Having said that, I think it’s much easier to become CIO out of the development group than out of an infrastructure group. In the development group, you live or die by your success with the business. Anyone who’s survived for a few years doing development almost certainly understands the business, and has a good reputation with the business people. Whereas running infrastructure, it doesn’t force you into learning how the business really works. And you don’t necessarily get to bond up with the business people—you don’t live with them through formative and relationship building experiences like delivering critical projects. Developers deal with change: their entire lives are about driving change. If there’s no change they don’t have a job anymore, their job is change. And I think that is a very useful characteristic to have, much more in demand than the ability to manage an existing operation tightly.”


On the scientific method and IT management:

“Carmine Vona at Bankers Trust was a Ph.D. in Physics. He had a strong belief in the scientific method—and I share this, I’m a Ph.D. in Chemistry. You go out into the field and find things out, you do some analysis, you form a theory, and you test that theory. He felt that scientists could do anything, because that basic method would apply just as well to running a business or developing a system as it does to astrophysics or cell biology. You try and form sense out of the facts, and then form convictions based on them, and then act on those convictions, and then pay attention to what actually happens.

Developers live in that world, too—going to find out what the situation is, doing analysis, figuring out a design, what the business case is, and then kind of making it happen. It’s very similar to science, and I think, as a result of that, developers can do many line jobs, because they just view them as another project. I’ve done several line jobs, and I always view them basically as projects. I view my job as not to run this particular group, but to find out why is there a problem with the group, what have I got to do to fix it, and move on.”


On the need for CIOs to focus externally:

“A big surprise to me was how externally focused the CIO’s job has to be. I’ve always been used to the idea that 95% of your job as a developer, which I’ve always been, was internal: your business and the technology that matters to you. As soon as I became CIO I was kind of surprised to find out that you have an accountability to understand all of what future technologies are coming—so you can’t shut yourself off from Silicon Valley, in our particular case.

You really need to meet people, to know what other CIOs are doing. You immediately feel, boy, I’ve got to have benchmark comparisons, I’ve got to have people I can reach out to. The reality is, how people feel about technology at Schwab is to some extent driven by how it’s perceived outside as well as how it’s perceived inside. The job was much more externally focused than I thought—instead of 5%, it was kind of 20-25%.”


On learning from CIO mentors:

“I strongly believe that each person you work for is somebody you should look at, try to critique—don’t let the bad stuff get to you, and the good stuff, learn from it. You know, people don’t become boss by accident.

Carmine Vona, who was CIO of Bankers Trust for many years, taught me a number of things, such as the importance of architecture. Get the architecture right and then you can figure out what kind of organization you need to build it or maintain it, as opposed to, well, let’s build the organization and then figure out the architecture.

Former Schwab CIO Dawn Lepore has a strong belief in using the strengths of people—not agonizing over their weaknesses—to get the right leadership in place, and in viewing problems from a people aspect as well as the structural aspect. And also vision … Dawn has an instinctual grasp of what is the big thing that we’re trying to do, the forest. She doesn’t get lost in the trees.”


On leadership advice to new CIOs:

“You have to think about IT leadership like a triangle or a pyramid. The bottom is like delivering the systems every day—if availability stinks, no one is going to be interested in your thoughts on the strategic future of technology. You’ve got to get everything to work. And the next layer is you’ve got to be able to do projects that deliver. At the top, you have a responsibility to understand the firm’s strategy and contribute to it, and know what the future of technology is a year out and two years out.

In that pyramid—there has to be a base before there can be a middle, and there has to be a middle before there can be a top. But you can’t just say, I won’t speak to anyone in the firm until I’ve got everything working. You have to work all of it at once, but you have to know what in reality the prerequisites are. So new CIOs have got to start talking to people straight away, but I would do a lot more listening than talking until I’ve got the base solid.”

Was this useful from a CIO Leadership perspective?

Send us an email with your feedback or suggestions - thanks!