Waters Wrap: Inside the mind of the CTO

Maybe it’s because my dad served in the US Marine Corps in the mid-to-late ’60s and he always talks about lessons learned from his time in the military, or maybe it’s just the result of getting old, but I find myself watching more and more documentaries and reading books about war and history. After finally finishing Ken Burns’ 18-hour documentary on the Vietnam War, this weekend I started reading a new book titled, Conflict: The Evolution of Warfare from 1945 to Ukraine. 

The book is co-authored by retired four-star US Army general David Petraeus and British military historian Andrew Roberts. In the book, Petraeus and Roberts say that military and political leaders need to master four tasks:

1. “They need comprehensively to grasp the overall strategic situation in a conflict and craft the appropriate strategic approach—in essence, to get the big ideas right.”
    
2. “They must communicate those big ideas, the strategy, effectively throughout the breadth and depth of their organization and to all other stakeholders.”
    
3. “They need to oversee the implementation of the big ideas, driving the execution of the campaign plan relentlessly and determinedly.”
    
4. “They have to determine how the big ideas need to be refined, adapted and augmented, so that they can perform the first three tasks again and again and again.”

And finally: “The witness of history demonstrates that exceptional strategic leadership is the one absolute for success, but also that it is as rare as the black swan.”

Reading this passage, I couldn’t help but think back on some of the conversations I had recently for our five-part Voice of the CTO series, which can be found here. At a large investment bank—as opposed to a born-and-bred technology company—too often, CTOs and CIOs are told what to do but rarely get the opportunity to drive the bank’s strategy, even as technology matters become critical.

The four tasks laid out by Petraeus and Roberts can easily be applied to business—and if you work in technology long enough, you’ve been involved in a fair number of quagmires. The reason for this is that the C-suite often isn’t able to comprehensively grasp the bank’s overall situation and craft an appropriate strategic approach. Or, they are unable to communicate those big ideas effectively throughout the bank. Or, they do not take the time to oversee the implementation of the bank’s big ideas. Or, they do not refine, adapt, and augment those big ideas. Maybe it’s a combination of all four. 

I asked the capital markets CTO at a global systemically important bank (G-Sib) about their experience of going through the budgeting process and some of the lessons they learned. They said it’s akin to the CEO telling you, the CTO, to build a rocket ship to Mars.

“You’re the head of technology and are asked to build this ship—you might have one of two responses. The first is, ‘I don’t know how to build a rocket,’ so you ask for an enormous amount of money in the hopes that your boss will decide not to build a rocket to Mars. The second is, if they’re foolish enough to give you that money, then you can at least take your time to ‘figure it out.’” 

They say this is how bank technology departments have traditionally worked. But what almost always happens is that the rocket never gets built. “So you spent a lot of money for something that you don’t end up making, and everyone makes excuses for why it didn’t work.” The goal was too big and unclear; why it was necessary wasn’t clearly communicated; IT was left to their own devices and simply expected to deliver; and the senior leaders didn’t make adjustments until after they were in too deep. Sound familiar? 

The solution, says the CTO, is not to build a rocket to Mars but to figure out what internal competencies the company has and build tools that help provide the foundation for space exploration. Then you play on these strengths by enlisting the help of strategic partners to build various pieces of the not-a-rocket. But you must be able to quickly adjust if something isn’t working, they say. It’s iterative, but where each iteration is clearly defined and communicated. 

“These problems exist in microcosms—in silos—throughout every organization,” says the CTO. “For example, credit will have a problem, rates will have a problem, and FX will have a problem. The equities guy has built a very good matching engine; the guy in rates cannot build one. Sure, the guy in rates can try and build one, but why not borrow from equities and then find a vendor to fill in gaps that are specific to rates? Or maybe FX can help. At its core, it’s simple, but when times are good, [the C-suite] loves to push to build everything internally to create some proprietary system. Then, when times get lean, everyone starts asking why the new rates platform hasn’t been delivered.”

The CIO at a second G-Sib echoes this point: “Budgeting changes year to year, and it changes based on organizational structure—how the top of house is aligned. Who’s running transformation of the bank? In my experience, there’s no set process that lasts very long. It just depends on, ultimately, where the bank priorities are at any given year and how they’re structured at that point in time. Sometimes, you’ve got technology at the top of the house. Some don’t have that, they have a transformation line.”

This changing-of-the-wind response sows confusion and frustration. And because the bank’s strategy hasn’t been clearly articulated to the various stakeholders, people at the bank start to think IT isn’t carrying its weight. Sometimes, that’s a fair assessment—not all tech departments are created equal, even if a clear strategy was imposed. 

A global head of technology at a third G-Sib says “vendors do a better job of thinking strategically about solutions compared to bank tech teams.” As a result, their bank is currently trying to implement “product functions” in the IT organization that would mimic the vendor method by thinking holistically about problems, as opposed to thinking in tech/operations/data/regulatory silos.

They mention how many senior managers at large banks have been there for decades, and they say there are many examples of where they were given a budget to pursue pet projects that ended up being point solutions that never got used. “But these managers had the network and the clout internally to get allocated budget,” they say.

This has led the head of tech to believe that—with the evolution of cloud, APIs, and open source—banks need to lean more heavily (but still strategically) into buying, rather than building. The simple fact is that banks don’t have the internal fortitude to stay the course for long-term tech projects.

And the CTO at a fourth bank says they believe that tech sits on an island in the capital markets, especially when it comes to the wants of the chief investment officer (the other kind of CIO), traders, and portfolio managers. 

“It’s one of these damned-if-you-do, damned-if-you-don’t situations because you have to get into a situation whereby the business buys into it, and says, ‘Oh, there is value,’ to get that leeway to have the budget for your back-end projects,” they say. “With those projects, it’s not immediately apparent how it directly benefits the organization, but there’s a second-order benefit. That’s how blockchain got so much hype—it opened up budget for previously underinvested areas of the bank,” meaning the back office and post-trade.

But they also acknowledge that tech needs to be better at telling the story of why these projects are important for the business. At the end of the day, the business leaders are the ones on the front lines dealing with clients, and technology needs to support those interactions. 

“It’s all about the business objective. What is the business trying to do? What is the business wanting to achieve?” they say. “If you [the technologist] don’t know that, there is zero point in having conversations about innovative new technologies.”

That’s a wrap

I think that if you read all five parts of our Voice of the CTO series (and I sincerely hope that you do), you will find that the pains that technologists face are fairly universal and that the solutions to those hurdles aren’t really that novel. If you go back to those four tasks laid out by Petraeus and Roberts, strategy starts at the top. You can’t get to task four if the CEO is passing the buck at the start of the project.

Then again, CTOs need to be better at articulating to the business—and then to the programmers, engineers, data professionals, administrators, project managers, risk managers, compliance officers, security specialists, and so on—why these overhauls are necessary and worthwhile.  

What is the problem the organization is facing? Clearly articulate that and put an ROI on the solution for that problem. Communicate to stakeholders why this isn’t donkey work and why there will be institutional buy-in for this project. Make sure that senior leaders are actively involved in this project that aims to solve an important issue. And then be quick to adjust strategy—and continually adjust—as need be, and then start the cycle again of crafting an appropriate strategic approach, communicating the need for the change, and overseeing those changes actively. Do it again and again and again.

As the authors note, though, leaders who can adhere to all four of the principles they laid out are as rare to find as black swans—and I suspect that in the world of investment banking, they’re even rarer. 

Thoughts on what I wrote here or in any of the Voice of the CTO articles? Let me know, good or bad: anthony.malakian@infopro-digital.com.

The image accompanying this column is “Various Caprices: The Philosopher Holding a Book” by Giovanni Battista Tiepolo, courtesy of the Cleveland Museum of Art’s open-access program.