I’ve worked inside of a number of large trading shops now, both as an employee and as a consultant. As a result I’ve worked with some really smart people…people who can tell you all the minutae of how to price complex options, people who can build technology systems to compute the value of thousands of trades at the push of a button and leaders who run globally distributed groups serving a complex matrix of stakeholders all with different needs. Quantitatively, it’s been a daily learning experience. Qualitatively, it’s like watching the head of snake trying to swallow a mouse too big and giving itself whiplash while trying to eat.
The process pretty works like this…
A trader or sales person (commonly known as the Front Office) needs something from his technology systems to make his job easier. Could be as simple as the way he views his positions to something more difficult like explaining the factors leading to the change in his portfolio value overnight. Almost inevitably, the Front Office person will snap their fingers and work with someone from IT to make the required change(s). The IT developer, buried under a growing list of such requests, greases “it” to come up with the fastest solution. It’s like watching someone row a boat with holes in the bottom…they are rowing at full tilt just to stay afloat.
The IT Manager is measuring the Developer based on how much they have “done” for the Front Office (not always how they have done it) and the pressure only adds incentive for short cuts and band-aid solutions. What’s the net effect for the enterprise?
Front Office person is temporarily satisfied. Developer goes back to addressing their laundry list of such fixes and the IT Manager feels like they are running a successful team. Except that building systems with limited foresight is like putting up scaffolding held together with thread. Once it starts to rattle, you need to prop it up. And the fastest way to prop up enterprise systems is to throw people at the problem.
So the next time that Front Office person requests an incremental change to the original fix, the effort is double as they must revise the original fix to cater to the new request and then actually complete the new request. Extrapolate this out a couple years with many Front Office folks making many such requests and you get:
- Underperforming tools for Front Office users
- Computer Engineers whose jobs are reduced to holding up scaffolding
- Middle Office folks whose requests never get addressed
As the scaffolding becomes more fragile the relationships between these groups can become fractured. Turns out that it doesn’t have to be this way.
Global IT spent this year is going to be around $1.2 trillion (Gartner) and 25% of it ($300billion) will be spent on building system interfaces. So we built a product, K3, that aims to remove the scaffolding around system interfaces. Open source components for developers to build interfaces and a simple GUI for Middle Office people to manage the data flow thereafter. Empowering users to self-drive allows the Middle Office to handle 80% of the Front Office requests around interfaces and Developers to focus on being engineers instead of data janitors.
Results for the Enterprise? Front Office folks can focus on revenue, Developers can return to being Engineers on strategic initiatives and Middle Office people can raise their hand with the hope of being noticed. Now everybody hug.
If you’re a visionary CIO, CTO or COO who is looking to build an enterprise and get past the scaffolding, email me. We need to talk.
