New Graduates in Fast-Tech vs Slow-Tech – The Unfortunate Truth

I’m a huge fan of a16z’s thoughtful pieces, both the podcast and individual blogs.  This morning however, I found myself grinning and shaking my head through the podcast “Slow-Tech Companies Navigating in a Fast-Tech World” hosted by Michael Copeland @MVC interviewing guest PWC CTO Chris Curran @cbcurran.  

The podcast is on-point regarding some major steps “slow-tech” companies can take to attract “fast-tech” talent and become better performing organizations (creating strike-teams with alternative agile pathways and creating a corporate learning function sourcing external ideas from the fast-moving world.)

Explore whether your organization has a desire to enable change, not just a desire for better end-results.

Unfortunately, the reality is far worse than discussed.  Step 0 was missing in the discussion — explore whether your organization has a desire to enable change, not just a desire for better end-results.  I can speak to this in detail as I’ve had the opportunity to work/consult with companies across the gamut of technical maturity and desire for change.  I currently spend a lot of my time setting up a corporate innovation function.

Referring to excited interns handcuffs [url= ][img][/img][/url] [url= ][img][/img][/url]at startups and agile large firms (Google, Uber, etc.), Chris Curran argues on the podcast that “that’s not the only place out there.” True, but that is probably the only place where ambitious, aggressive interns and new graduates will have an unhindered opportunity to quickly make large technical contributions and see them to fruition.

Michael Copeland notes that the slow-tech incumbents desperately need the ideas and energy of new graduates.  True, they do, but having these ambitious new graduates would not help a firm with obstructionist innovation policies.  Attracting talent without first fixing internal obstructionism is a huge disservice to ambitious technology graduates.

Michael Copeland correctly asks “What does the slow tech company have to offer” and Curran correctly points out there are “lots of interesting problems to solve and lots of interesting data to analyze.”  This is also true, but none of that happens until a skunk-works team or fast-track is actually set up and measurably enabled to succeed.

There has to be a real desire for change, not just a desire for results.  This means the c-suite has to enable those seeking agility and actively remove barriers to innovation efforts.  Otherwise, why should students today work at “slow-tech” companies?  Here are three obvious reasons they probably should not:

Reason 1: “Slow-tech” Companies’ Strategic Advantages Are Non-Technical

I’m not saying slow-tech companies cannot be successful, they obviously can be and indeed are.  But their success usually stems from non-technical advantages:

  • Existing sales and distribution channels
  • Sheer momentum
  • Strong legacy brands and recognition
  • Existing Master Servicing Agreements

If you are a new graduate seeking to learn quickly and build something for the world, none of these are technical advantages.  They are all advantages only once you actually build something, and all the advantages are in other departments, not in technology.  How much fun can that be?

Reason 2: “Fast-tech” Companies Can Move 100x Faster

Yes, two orders of magnitude faster.  Some of this is unfair, since many fast-tech companies can choose any technology, any stack, any framework and host externally with little legacy to carry.  Much of it is legitimately faster — most fast-tech companies have modern policies that make development and product releases absurdly faster than slow-tech peers.  Some simple examples:

  • CIO-Obstructionism – I’ve worked at several slow-tech corporations where developers simply cannot get admin rights to their machines.  At a fast-tech company installing a new package might be as easy as “venv pip install xyz”; at a slow-tech company it might be a three week process involving a half-dozen signoffs.  Heck, you may not even be able to chatJust because you are in a strike-team with an innovation mandate does not mean you are immune to regressive organizational policies.
  • CTO-Obstructionism – I’ve worked at many slow-tech companies where getting a development or test environment can be a many-months effort.  Granted, there are good reasons to control environments if you are at a capital markets or asset-management firm for example, but the restrictions are often one-size-fits-all.  For example, even if you are developing a market surveillance application with no transactional information and no holdings information and nothing but public data, you still couldn’t host your application externally (e.g., AWS, Heroku, etc.)  A fast-tech company can spin up a VM or use cloud services (often free tiers) while a slow-tech company slogs through months of cost benefit analyses.  This makes throw-away prototyping efforts almost impossible at slow-tech firms.  It consequently creates a low-tolerance for experimentation and fewer opportunities and experiences for new graduates.  Even if you have complete architectural and functional freedom, you may find infrastructural to be a rate-limiting step.
  • Architecture-Committees – Many Fortune 500 firm architecture committees are often just paper-mills where the only right answer is an Oracle or Microsoft stack.  I’ve seen two slow-tech companies with blanket restrictions on open-source software.  The SCO debacle didn’t help, but seriously, why would anyone block usage of an Apache HTTP server?  Politically-motivated organizational flaming hoops which will hone new graduates’ political skills but will kill momentum and dampen motivation.

Reason 3: Risk Aversion is Lowest at Graduation, So Are Absolute Compensation Spreads

New graduates are likely to have the least personal carry they will ever have.  Most are not yet married, likely do not have children, and are very unlikely to own homes.  Why not use this singular best moment in life to reach for risk?  New graduates can move anywhere keycuffwithout worrying about subletting/selling homes, they can work long or strange hours and meet other young energetic new graduates.  You usually don’t have those opportunities at large stable firms.

Large “slow-tech” companies can usually pay senior workers more.  The absolute compensation spread at entry-levels, however, are tiny or zero.  So the only “cost” of working at fast-moving agile companies is probably only limited to greater risk of fledgling company bankruptcy.  Seems like a great risk-reward-learning ratio.

What If You Are Already There?

So what happens when a fast-moving technology team finds themselves trapped in a slow-moving organization with a desire for results but without the willingness to actually enable it?  I’ll share my experiences in another blog post, but I was stuck in this exact situation.  AIG Investments’ CIO recruited me from Goldman Sachs in 2006.  Both companies had huge Credit Default Swaps operations, but AIG Investments had a team of ~18 people managing operations with photocopiers and fax machines while Goldman Sachs had achieved a real-time firm-wide message bus.  That is how wide the difference was — AIG Investments was almost 20 years behind.  

Our CIO charged me with the transformation.  We did achieve modernity eventually, but the effort was entirely organizational and political, not technical.  While this was a superb opportunity for management consultants, I would hate to expose any aspiring technologist to such a grueling experience.  They would have been much better off working at an agile FinTech startup.  Not all technology graduates want to slog through a risky transformational project, many would just like to build & ship product and learn along the way.   Some don’t know what they want, though i’d bet they prefer the likely certainty of the latter vs the risky proposition of the former.

On a related note, I’ll share our experiences on this particular project and our road-map for success in another blog posting soon.  

Do SLAs Matter for On Premise Systems?

That is an overly broad question of course, it depends on the industry, the function, and expectations of software maturity.  But my answer is no!  Service Level Agreements do not matter in many such cases.  Revision cycle time and feature/bug backlogs are far more important.  Some background is in order.

In all my years on Wall Street, I don’t know of a single time we sued a vendor for failing to meet Service Level Agreements, withheld payment, or even threatened a product vendor.  If anything, we were usually secretly praying for a meaningful response to issues.  I can see how SLAs would be more important for hosted solutions such as Bloomberg AIM, BVAL, Reval or Barclays POINT.  But what about for on-premise solutions?  

In my experience (and I’ll soon give two detailed cases) on-premise solutions operating in Production settings either work, or they won’t work until the next product revision.  Between now and then, the best you can usually get is an acknowledgement of the issue or an explanation on how to address it post-process.  

During my 8+ years at AIG Investments, I dealt with dozens of vendor products, but two products were at the nucleus of most Investments activities:

  • our Derivatives Pricing+Valuation+Trading system ($94B of CDS, IR Swaps, and vol products)
  • our Fixed Income Pricing + Analytics system (93% of our $240B Fixed Income portfolio)

I had the dis/pleasure of working with each for 5 years (18 months on overlapped double duty.)

When we were purchasing our multi-million dollar derivatives system back in 2006, we differentiated vendors on criteria such as 24×7 support vs 8×5 support.  After almost a year-long planning and RFP evaluation, we purchased a to-remain-unnamed product from a conglomerate European vendor.  After we signed on, we were lucky if anyone responded to service calls.  Usually, the SLA was “met” with just an auto-acknowledgement that the ticket has been received.  Questions from us would be answered with requests for clarification and more questions until novellas were produced with intricacies of how various solvers would fail in some arcane circumstance.  Eventually, we would tire out of the reverse-questioning and — already a week into a Production issue — we’d just accept some deal wouldn’t be valued correctly.  Most infuriatingly, major issues would remain on the defect correction backlog for months — our professional services representative would have to champion our cause at HQ to prioritize the bug.

My experience with our Fixed Income Pricing & Analytics system was the polar opposite.  We couldn’t be happier with the vendor, PolyPaths.  Our wallet followed our happiness, as we went from a dozen desktop installations to a 300-core distributed farm installation.  Interestingly, we had business-hours-only support from them (on paper, far less than what we had for our derivatives system.)  However, in reality the vendor never failed us.  Issues were acknowledged immediately and we’d get enough detail to immediately fix issues post-process.  They issued several patches almost immediately and almost all issues would be addressed in the monthly revision cycle.  

Our faith in PolyPaths became so strong over time that our use of PolyPaths expanded from just Agency RMBS to all RMBS to all Structured Products and eventually to all Fixed Income products. With respect to function, we went from just calculating curve/price-implied nightly OAS to a range of analytics and eventually all available analytics for all holdings across 21+ scenarios.  We ran our uber-critical Federal Reserve Stress Test on it.  And as a plus, we also produced all our solved yield curves and volatility surfaces from the system — essentially serving as an input to all other quantitative systems.  This was not because the system was capable of doing so (i’m sure other systems are also capable) — it was because of our trust in the vendor.  

I’m not comparing apples and oranges.  I was the in-house owner of each platform, co-owned the vendor relationship on each, and operated each platform from a quantitative standpoint.  Each was in a similar price range and each was a central calculator for a major business in our firm.  Just the customer service philosophy differed enormously.  

What is the take-away?  I’m evaluating several vendors at the moment, all of which we’d use on-premise.  Much like with our last two RFPs, we’ll be interviewing other customers.  Except our criteria will be heavily weighted in favor of vendors with quick product revision cycles, short backlogs, and the experience of dealing with the vendor rather than time slots and the like.  I hope we find a vendor as committed as PolyPaths.


Modern Messaging

I’ve had the pleasure of working with both simple messaging and (what used to be called) an Enterprise Service Bus.  Things have come a long way.

  • While at Accenture, in 2002, we implemented IBM MQ Server at a client (it was overkill for the trickle of traffic, we ripped it out 2yrs later.)
  • At Goldman Sachs, in 2005, I dealt with the nightmare of GDR messaging on their Enterprise Message Bus.  Though horrendously complex, it was actually quite a well-architected solution and serves the company well, but I never saw the cost (I shudder to think how many $750k/yr software architects are required to maintain that beast!)
  • At AIG dozens of us talked about messaging from 2007 to 2015, many end-users desired it, but nothing Production quality ever came to fruition.

Finally, at my startup in 2015, i’ve had the pleasure to work with PubNub’s platform.  Wow.  Obviously this type of externally-hosted service scares the daylights out of financial organizations (PubNub…any on-prem version in the works?)  But it shows how easy messaging could be, if designed thoughtfully.  I’m not sure why it took a startup to achieve this, but IBM, Tibco, and all the others should take note.

My past colleagues should also take note, because PubNub made it so easy to get messaging up and running that I felt something must be missing.  Curious how it would perform underneath a capital markets system, I integrated it into my personal automated trading system — all in five hours.  The five hours is not just for the various clients, desktop dashboard, but also for my mobile applications which I use as dashboards.  I’m streaming FX and Listed Equity top-of-the-book data from three separate data providers onto a single channel.  Amazing.

bigdataI should note that my personal automated trading system is still paper-trading.  So you might argue that the stakes are not high.  However, i’m fully intending to set it to live trading — with my own money — no OPM.  As a dual Chief Investment Officer + Chief Technology Officer, that is quite a vote of confidence for PubNub.

For small (or even large) hedge funds, I would argue that anything not requiring ultra-low-latency and anything already public (quotes) or otherwise undecipherable (derived curves) should be a candidate for outsourced messaging.  The SLAs make it sell-able internally.  But the APIs are the real sell to me, so an on-premise alternative would be an instant sell, even with relaxed SLAs.

New Alternative and P2P Lenders – More Money, Same Old Problems

I read Ali Hamed’s post “Why Alternative Lending Platforms Should Not Own the Loans They Originate — And the Danger of Asset Backed Securities” with keen interest since I previously worked at a major underwriter and am a huge fan of marketplace models.  I like to cheer the underdog, so P2P FinTech models greatly excite me — but they also make me fearful because I can see old problems still unresolved.FinTech

The posting discusses ways to keep Alternative Lenders’ interests aligned.  I think the proposals are absolutely fine if the only re-purchasers of debt were sophisticated investors. But with retail investors putting p2p loans into their IRAs and treating p2p platforms as high-yield savings funds, much more thought is required.

Forcing alternative lenders to keep some portion of the loan, as proposed, is wise but even that may not go far enough.  I really question whether a pro-rata loss sharing structure will be sufficient skin in the game. Recall how Fannie and Freddie’s g-fees and servicing strips didn’t prevent Fannie or Freddie from the 2008 disaster. It would be ideal if the Alternative Lenders or a major sophisticated partner (e.g., Magnetar, though obviously without the bit about shorting upper tranches) held part of the equity tranche facing first losses. This would really align interests and force proper pricing of loans.

All the other mechanisms discussed in the posting have demonstrably failed, and it is silly to think they would suddenly start working now.

Consider the argument: “Investor purchase agreements” are strict about what types of loans will get purchased — yes they are, yet they completely failed in 2003-2008. Many purchasers just want to tick a box, securitize, dump, and collect their year-end bonus. They will be long-gone before loans become seasoned, if they ever season. Further, I have yet to hear a proper rebuttal to Doug Dachille’s arguments about loan quality and unchecked attributes from any of the big lending marketplaces.

Regarding “reputation” — the posting makes the argument “and finally, the marketplace lender will lose its reputation and have trouble sourcing more debt capital.” Correct, the lender might lose their reputation, but this hasn’t mattered. Notice the the latest crop of CDO issuers — minus banks which went bankrupt, it is largely the same set of players. Reputation doesn’t matter much with an oligopoly, purchasers have too few options and competitors too many barriers.

Finally, origination fees: It is a big ambiguous what the article thinks about origination fees (they note later “The marketplace lender then makes an “origination fee” for sourcing the loan and a “servicing fee”….”This is the best model, the most scalable model…”) From my standpoint, origination fees seem like the worst possible model as they would encourage poor underwriting and completely misaligned interests (more later.) Keeping partial P+I income streams (as I would propose) seem a better option and would not necessarily require the balance sheet, the held interest could theoretically be securitized, but at least it would be vetted by professional investors and examined eyes wide open and forcing proper pricing.

Don’t get me wrong, FinTech startups have a superb opportunity to grab market share and re-make the landscape with modern, lean setups. I’m incredibly excited about the entire alternative lending and alternative capital raise markets — but i’d hate for them to fail by adopting the failed practices of yesteryear.

I’ve been meaning to vent on the topic for several months.  Thanks to Ali Hamed @AliBHamed from CoVenture for starting this very-needed discussion.  Friends and former Wall St colleagues – I’d love to hear your ideas!

AIM, Spark, Bloomberg and the Road to Slack

Back at Accenture — and I know i’m dating myself here — projects almost universally used AIM (AOL Instant Messenger.)  Being on a distributed team under crushing deadlines was almost impossible unless you had frictionless communication.  At the time, we thought it was frictionless, as there were few alternatives.

Things went backwards in 2004.  The wave of regulations clamped down on almost any messaging on most of Wall Street.  I would use Bloomberg messaging — but only because I was lucky enough to have a $24k/yr Bloomberg Terminal.  For most of the team, the only option came years later — Spark.  It was an ugly messaging tool that supposedly met all the security and audit requirements for use at Broker-Dealers.  Our employer (in 2011) adopted it, but none of the workers would turn it on — it was clunkier than something from 1996.

You cannot force people to like a product, or to use it wholeheartedly.  You also cant keep a good product down.

Eventually our employer opened up the port on Google Chat, but officially disallowed it, shifting the burden of responsibility to employees.  But if you had to choose between working late and being productive, the choice was clear.

Now that I’m at a startup, I’ve mandated Slack for our team (to the extent that anything can be “mandated.”)  It is lightening fast, logical, and the concept of channels and private groups makes our team hyper-productive, even when some members are remote.  The concept of integrations (e.g., all our GitHub source control check-in’s are pushed into a Slack channel) is great and allows you to passively monitor a channel rather than poll disparate places (that rarely happens like it should…)  Most importantly, asynchronously monitoring channels helps us focus on tasks requiring deep concentration.

Now that we are using Slack, I don’t know what we would do without it — and I pity my former colleagues on Wall St.  I wish there could be a good controlled study of the productivity spread on teams using good communications tools vs those that are not — but sadly it would probably be split along industry lines and not easily comparable.

This also makes me wonder — why aren’t Slack or competitors offering on-premise solutions or audited solutions?  This seems like an ideal selling point.  It would be wonderful to bring the productivity from the West to the East.