James Rundle: The Heat of the Moment

I remember having a coffee with a fairly senior technology executive at one of the largest banks in the world last year, when the conversation turned to mobile. The bank didn’t have a mobility strategy, or at least, it wasn’t one in line with what people were talking about at the time. The firm’s traders weren’t tapping away on Apple iPads on the floor and its programs weren’t particularly transferrable from desktop to tablet. ­­­­­­­­­­Given the amount that mobility had come up, I was fairly surprised. I asked him why this was.

“We don’t really need to do anything like that—it’s not essential to how we operate,” he replied. It struck a chord. Often, the push to new technologies is so strong that developers end up in a black hole, committing time and money to a project that doesn’t necessarily have a beneficial end once it’s completed. Making a sober analysis of how you’re spending your resources is therefore essential to how you outline your technology strategy in the future.

Distinguished Engineers
One way to do this is to allow your talent to reach its full potential. Earlier this month, I caught up with Pat Healey, head of engineering and shared services for markets at RBS, who described the bank’s distinguished engineer (DE) scheme and how it had benefited the institution as a whole. Working on the Google principle of giving crack technologists 20 percent of their schedule off to work on projects each week, not only resulted in new and innovative development at RBS, but was also crucial in another area. The people in question—10, at the time of writing—who had earned the privilege, were able to give deeper thought to the way in which the bank was currently pursuing its technology strategy, and identify which projects weren’t leading anywhere.

This is a huge commitment in terms of invisible cost, of course, such as having your best minds off the critical jobs, but it allows for long-reaching benefits that the bank, four months in, has already noticed. Other institutions also have DE schemes or analogous programs, and while it may seem like creating labs for mad scientists, the complexity of modern technology requires the focus and attention that projects with deliverables, timeframes and deadlines may limit top employees from engaging in.

Individual Requirements
This strategy works for the big institutions with large budgets and thousands of staff, but it doesn’t necessarily work for the smaller brokers and other sell-side actors who don’t have access to that kind of muscle. Still, the principles of working on what works for you are the same, even if it’s reduced in size. Big Data is definitely something that’s occurring, for instance, even if you disagree on the particulars of what it entails.

Often, the push to new technologies is so strong that developers end up in a black hole, committing time and money to a project that doesn’t necessarily have a beneficial end once it’s completed.

However, just because data volumes are increasing, is it necessary to invest in complex software for analyzing large, unstructured data sets, or hardware to crunch the numbers in real time? Some, more sensibly, take the approach of not jumping in feet first.

“Do I deal with Big Data?” asks one New York-based sales trader at a large brokerage. “Look, I spend most of my time on the phone. We’re not a quantitative trading house, and although we do research, it’s not our overriding concern. I don’t need to sift through hundreds of thousands of gigabytes of data to do my job, and investing in the technology to do that would be pointless.”

It sounds like common sense, but developing based on need rather than desire is important at a time of shrinking budgets. Whether that’s giving mobile functionality to salespeople rather than traders on the floor, or using cloud in some instances but not others, the whole-hog method isn’t appropriate for many, any more.