Flying Blind

The core of Sopwith’s financial analytics is a system called RADAR. Once upon a time, RADAR was an elegant, efficient, robust and powerful system with a single well-defined task: to produce live risk-management reports (the very name RADAR stands for “Real-time Aggregation, Decomposition and Analysis of Risk”). But over the years, users have requested myriads of extensions to the original functionality, and programmers have responded with a multitude of quick fixes, each one uglier than the last. Today’s version of RADAR is a baroque monstrosity, a bloated mess of code that churns out dozens of wildly disparate reports every day: profit and loss accounting, risk management analysis, cash-flow and settlements information, trade valuation and hedge calculation, financing and liquidity projections, everything but the weather forecast. It’s a miracle that RADAR runs at all, but run it does.

Unfortunately, all the many hacks cobbled onto RADAR over the years have failed to address a fundamental weakness in its structure: its human interface. RADAR was originally designed to be used by programmers, and for good reason: its hideous complexity requires a huge amount of effort and technical skill to understand and manage. But any programmer with that amount of skill would simply hate working on RADAR: it’s a tedious, repetitive and utterly mind-numbing job. In point of fact, every single programmer we’ve assigned to RADAR has either quit or asked for a transfer within six months of the assignment. Even the person who created the system, the semi-mythical Original Programmer, chose to gracefully retire from the finance industry when faced with the alternative prospect of having to maintain RADAR indefinitely.

A rational company would have tried to find a long-term solution to this problem: either by redesigning RADAR so that it was less tedious for programmers to work with, or by simplifying RADAR so that it could be used directly by accountants and back-office staff, or by looking for (and paying) a programmer who could tolerate working with the existing system, or, as a last resort, by junking RADAR wholesale and outsourcing all our analytic needs. But Sopwith is not, and has never been, a rational company. Management decided that if six months was the upper limit for a programmer to work with RADAR, then that was that: we would simply higher a new programmer every six months (give or take a few) to fill the gap.

Enter the Sprouts. Encouraged by the success of an early hire from a famous engineering school, Sopwith instituted a policy of hiring a newly-minted engineer every year. Typically, this engineer would spend his first six months at the firm learning his way around RADAR, his second six months running and maintaining it, and his third six months passing his knowledge down to the next hire. After that he would be at a loose end, but since Sopwith was culturally incapable of firing anyone (other than the occasional trader), a job would be found for him: quantitative research, analytics, risk management, trading, somewhere. At one stage last year we had three junior traders, a junior risk manager and two junior quants, all spinning their wheels in the service of the firm, with no functional senior traders, risk managers or quants to guide them.

The current set of Sprouts, the fifth generation since fund inception, is in a bad way. By unhappy coincidence, the three previous Sprouts quit Sopwith en masse a few months ago, leaving the latest recruits with no immediate supervisors to learn from. And our IT department is currently without a head, or indeed, any senior personnel at all. (This is not unusual for the IT department. Although management is admittedly a rare commodity throughout the firm, the IT department takes the scarcity to extreme levels even by Sopwith standards).

This leaves the junior Sprouts in a vacuum. There’s no one to teach them the basics of analytical finance, no one to allocate their time and effort, and (most importantly) no one to run interference between them and the rest of the company. As a result of the former circumstance they have to figure RADAR out for themselves, almost from first principles; this is an incredibly painful and time-consuming process. And the latter circumstance means that they’re always being interrupted by users who need minor fixes to their workstations, or their email, or their printers, or other trivial matters, leaving the Sprouts no time to embark on any sort of serious education or project work.

To their credit, the Sprouts make the best of a bad job diligently and uncomplainingly – they’re still too young to have become apathetic. Sprout One is the older and more experienced of the pair; he has almost a full year behind him, which means he knows (barely) what a derivative is. Sprout Two has just finished his seventh month at Sopwith, and hence has no such pretensions to knowledge. Between the two of them, and aided by a hefty amount of sheer doggedness, they manage to satisfy all the trivial user requests while somehow coaxing RADAR to run every day.

But it’s a balance poised on the edge of a knife. Every day brings a new crisis, and eventually the situation gets so bad that the Original Programmer is called out of retirement two continents away, and asked to teach the Sprouts how RADAR actually works. He gives it a shot, but learns quickly that getting two clueless newbies to understand a complex system long-distance is a losing proposition; instead of teaching the Sprouts anything, he simply fixes each day’s problems by himself.

Consider, if you will, the implications of this state of affairs. We have the very latest in risk management technology, capable of analyzing complex portfolio movements to immense (albeit spurious) precision. We have hundreds of thousands of dollars’ worth of hardware, and have invested millions more in our software. We have upwards of a hundred employees, all utterly dependent on their spreadsheets, their email, their web apps, their databases. And this entire edifice is being manned by two college graduates with a grand total of eighteen months of experience between them. Yet nobody seems to think this is a problem!

Our risk manager floats merrily along in his cloud of Olympian detachment: as long as the clauses in the official risk management policy are being followed to the letter he couldn’t care less if our IT department were run by a poodle. Our traders recognize that a new Dark Age is setting in, and have replaced their quantitative arbitrage strategies with simpler, more primitive trades: these days they merely make wild bets on the market going up or down, based on nothing more sophisticated than gut feeling. Our back office staff muddle along as they’ve always done; IT has never really done anything for them, so the lack of an IT department doesn’t faze them in the least. The Big Boss knows that the state of affairs is farcical, but he just got married to a model twenty years his junior, and he can’t be bothered to get involved. His emissary Jimmy the Kid is dimly aware that there’s a problem, but since he lacks the competence to solve it he’s ignoring it, in the hope that it’ll go away.

The only people capable of appreciating the magnitude of the danger and caring enough to do something about it are our investors. But in a truly delicious piece of irony, they remain blissfully unaware of the entire mess. These are people who stay up late at night obsessing about various real and imagined risks to our portfolio, who call us thrice a day to chat about every unfounded rumor that’s making the rounds, who think every dollar lost is a catastrophe beyond compare. Yet the biggest risk of all, and the one closest to home, is ignored.

I feel almost sorry for them.