Lessons Learned From Goldman Sachs v. the Programmer

August 4, 2013 • Management Practice

There’s a lengthy article by Michael Lewis in Vanity Fair about a programmer who is being prosecuted for theft from his employers, Goldman Sachs. The first lesson to be learned here: don’t take code with you when you leave a wealthy and powerful company. Clear enough, but there’s more to glean here; however, if you want to learn a bit more you’ll need the facts:

Programmer Serge Aleynikov worked for Goldman Sachs, maintaining and extending their high-speed trading platform.
Aleynikov was motivated by the programming challenges more than money, although he was paid very well indeed.
Aleynikov used open source code to patch and modify Goldman Sachs’s high-frequency trading system
In the final six weeks of his employment at Goldman Sachs, when he had submitted his resignation and was handing over to those who would take over, he deposited about 8Mb of code outside the firewall where he could retrieve it (using a subversion server, which isn’t as nefarious as it sounds, being basically a tool for version control across networks).
That code contained open source and proprietary components. He knew that Goldman Sachs regarded all such code as wholly proprietary.
He plausibly claims that he did so in order to have a primer for the ways he’d used the open source code in the past. None of it would not have been useful directly in his new project.
When Aleynikov got off on appeal, the feds found grounds for new charges.

I drew these four conclusions from these facts after reading the article: 1) Aleynikov knowingly stole Goldman Sachs property with the intent to use it at his new job, 2) he didn’t expect Goldman Sachs to find out or called the cops, 3) Aleynikov was a very long way from being an idiot, and 4) somebody really wants him in jail.

Firstly, we may find Aleynikov a sympathetic figure but let’s admit that he broke the rules to do something that he knew would be regarded as stealing. He is clearly a little naive about social dynamics in a big bank, but he can’t possibly have thought that what he did would have been shrugged off if discovered. That makes it a little hard to reconcile conclusions 2 and 3, but the paradox is at least partly due to the fact that from time to time most IT folks will do exactly what he did. We tend not to believe the rules about network security are for us because we know why the rules are there and why we’re not violating their spirit. We craft a company’s IT infrastructure to support the business processes of the firm; but those aren’t our own business processes and sometimes we need to roam a little more widely to get the job done. We bend the rules when it efficient to do so and when we believe we are doing so in our employer’s interests or at least not harming them. But we have all probably signed something, as Alyenikov must have, that said we wouldn’t take such shortcuts.

This whole dismaying episode seems to come down to a culture clash between the dominant one at Goldman Sachs, in which success is measured wholly by money with individual achievement valued before that of the team, and that of the back-office technicians, driven by collaborative, team-based values and including intellectual achievement as a success metric. Goldman Sachs may be an extreme example of a profit-pursuing egocentric value system, but a variation can be found within most successful firms. It sounds like Aleynikov, on the other hand is an exemplar of the IT geek, less interested in the money than the programming challenge. He not only saw the value in adopting open source code, but was eager to return the favor by contributing his improvements for the use of others.

Most of the time, the trader’s culture simply marginalises that of the geeks. That’s a familiar story in all kinds of companies: it’s usually a constant struggle in the development department of a non-IT firm to get the programmers to see that the business problems and the IT problems are not the same thing and they need to focus on solving the former not the latter; just as it can be a challenge to get the business to understand that all that time and money IT spends doing things that you don’t understand have genuine business value. But most of the time when there’s a conflict the business imperative wins out over engineering ideals.

Sometimes it would pay the business to listen to their IT department and let some ideas flow the other way. Business leaders remain unwilling to listen to their IT executives on the topic of strategy and the idea that IT strategy should do more than simply align itself with that of the business receives only lip service. Opportunities to use IT strategy to directly contribute to the business are commonly missed. In the parable before us, there is an example in the Goldman Sachs trading platform, which had been maintained for years with each change in trading strategy being layered in as a patch until it was so creaky that it was no longer fast enough (in an application where literally every millisecond counts) to be competitive. Aleynikov had advocated for rebuilding it from scratch and been rebuffed – so he went to another firm that would let him do that. Goldman Sachs made a poor strategic decision, kept their teetering code base and lost a star programmer.

In the high-frequency trading world, with its outsize risks and rewards, the technology is so integral (and the stakes so high) that the business and IT acumen required to make the system work are in more equal parts than in most other banking applications where IT supports rather than drives a business process. Both disciplines are characterized by distinct and forthright cultures that can have conflicting values. Where they meet in balance there’s bound to be more than the usual friction; but one rarely wins a battle against those who control and care only about the money.