Capital Markets CIO: Lifeblood Provider, not Bridge Builder
Many people compare the role of Chief Information Officer (CIO) to that of a bridge builder– connecting the separate worlds of technology and business. Analogies can be useful in giving us a mental model to overlay onto a complex concept, in this case yielding a basic view of how to approach an extremely challenging executive role. Unfortunately, the “CIO as bridge builder” analogy falls short in many ways, particularly in a capital markets’ context.
Of course, IT groups need to deliver technology solutions to our organizations, but those solutions shouldn’t be conceived or evaluated in a separate “world” and then brought across a “bridge” to the business. IT departments should strive to create stable, scalable architectures, to develop innovative systems and reporting platforms, to do excellent technical work…just not in isolation on the other side of the “river,” and not for its own sake. Ideally capital markets CIOs should think of us not as bridge builders, but as providers of the lifeblood our firms need to succeed.
Information—The Life-blood of Enterprises
In other industries in which IT need only provide “commodity” services to their organizations, it may be accurate, and without any negative connotation to IT in those businesses, to envision them as separate isolated groups, between which a connecting bridge may be sufficient. Not so with capital markets firms because we are comprised of information workers who utilize data to get their work done all day, every day.
Everyone in IT must understand the truth that when the organization wins, we all win; when it loses, we all lose
Beyond that, for our firms, systems and data can rise to the level of competitive advantage, enabling unique insights, enhancing business capabilities, and ultimately driving revenue. We can’t let it be thought of as living “on the other side of the river” from our core business operations.
Teamwork Bridging the Workforce
I am a huge believer in the power of mindset in the workplace. Too often, individuals and teams underperform not because they lack the technical skills to do better, but because they have the wrong idea in their mind of how they can and should contribute to the firm. IT suffers from this problem far more frequently than other groups, for several reasons:
• IT training focuses mainly on the technical aspects of our roles. There is far more focus on How than Why
• There is an enormous amount of energy focused on obtaining technical certifications as proof of competency
• Many IT professionals choose this line of work because of the satisfaction they derive in solving challenging technical problems
• Many IT managers view revenue and competitive advantage as problems for “business” people
The more a capital markets CIO can move the mindset of everyone in IT to grasp our unity with the business, the more teamwork and trust will flow in every direction. Everyone in IT must understand the truth that when the organization wins, we all win; when it loses, we all lose. Are we finding solutions to business challenges, even when they’re not specifically requested? Do we have the right sense of urgency when responsive support is needed? Do we prioritize in the same way our CEO would set priorities? Are we fully leveraging our role as the provider of lifeblood information to the firm?
This mindset affects day-to-day maintenance and support requests as well as strategic planning because it widens the context in which judgments like “better,” “more efficient,” and “cheaper” are defined and evaluated. From management to staff, from applications architects to help desk technicians, adopting this approach helps drive better alignment and changes the language and culture of IT to better fit, and partner with, our organizations.
The Right Mindset and “Best Practices”
Viewing IT as one with our organization is extremely critical when scanning the IT horizon for potential tools, methodologies and technologies. It becomes clear that the right question isn’t “would this change improve our IT?” But rather “would this change benefit the firm?” Sometimes the answers to these two questions will match up completely, but in other instances, asking the right question will make all the difference to IT success.
Applying this philosophy to some of the dominant current trends in IT illustrates the point. Although many white papers claim near-universal applicability of these concepts to most IT shops and companies, CIOs must apply the right mindset together with our technical and business expertise to make the right decision for our firm. The only “best practices” we should care about are those which are “best for us.”
Agile development: Agile was possibly the first example of the overarching IT trend to break down complexity in smaller pieces. For firms which can wait for a system to evolve into being, this can be a powerful approach which enables adaptation and tailoring based on user feedback as the system comes to life. If our firm needs a system launched as a cohesive whole, though, Agile can be code-speak for “less planning,” resulting in a lower quality product.
DevOps: The coordination of operations/ infrastructure evolution with Agile development is a natural fit where Agile makes sense on its own, and where the investment in tools and new infrastructure makes financial sense. If development isn’t moving the needle on our firm’s infrastructure needs and/or applications changes are very limited “tweaks,” DevOps makes less sense.
Cloud Applications/Storage: This is a category in which many CIOs are gaining wisdom as the cloud concept leaves its honeymoon phase. The benefits of flexibility and scalability are obvious, but IT professionals increasingly realize that costs are rarely reduced; that users will experience higher latency from the cloud than from a local server; and that the firm’s circuit bandwidth needs and dependency will increase substantially.
Microservices/Containerization: Amazon, eBay, and Netflix have shown their effectiveness as an architecture for uber-complexity, but that is a far cry from proof of applicability to capital markets firms. For firms needing frequent changes to certain sections of code, turning these into microservices can make them independently changeable black-boxes, maximizing nimbleness without sacrificing stability. On the other hand, for more stable/ interrelated code bases, going down this road could amount to buying an expensive piecemeal version of the system already up and running.
From an IT purist and white paper perspective, and often when considered from a bridge builder view of the CIO role, each of the mega-trends above are no-brainers for some level of adoption. But our role as CIOs, particularly capital markets CIOs, is not to operate IT separately with only ourselves as a bridge to the business.
We must decide where, when, and how different solutions should be taken from the advancing, expanding tide of technology options to meet our firms’ specific needs and opportunities, to fulfill and empower our firms’ specific strategies. I can think of no better industry in which to lead IT than Wcapital markets!