Robinhood is an online trading platform that is on a mission to democratize finance and make it possible for everyone to participate in the financial system. The company has experienced explosive growth in the past year, the growing pains that go with it, and some important lessons along the way. Adam Wolff spent two years as the VP of Engineering. He is also a member of ENG, the peer-network of VPEs and CTOs at leading SaaS companies. Adam joined me for an interview on Scalying New Heights. Below are a few highlights.

First, a bit of context. As online trading and cryptocurrency explodes, Robinhood has enjoyed a huge increase in new user signups plus expansion of trading on the platform, and this impacted every part of the business and the underlying infrastructure. As new users grew quickly, along with trading volumes, the engineering team needed to be sure they were hitting the new peaks during their own load tests, not as part of the business runtime.  Adam explains it this way:

If you’ve ever tried to build these kinds of tools and these kinds of frameworks, you know it’s a non-trivial engineering task.  As with most things in business, leadership is key, and leaders themselves are continually challenged to set appropriate goals, push teams to change or adopt new technology, and find the right balance between innovation and optimization. Adam’s experience is emblematic of what happens when the business objectives and the tools to achieve them get mixed up.

When Adam joined Robinhood there was a new project to implement – Kubernetes – and at first, he thought that sounded like a good idea. “The business objective was simply to move to Kubernetes,” he says. He had come from Facebook, where they had sophisticated and high-quality frameworks for deploying different kinds of jobs in a very abstract way. You didn’t have to think about it, you could deploy new code and it just worked. The marketing materials for Kubernetes, and the demo, made it look like exactly what they needed, so he jumped on board. But years later, they’re still working on the migration, and they’ve made a lot of progress, but it was more difficult than expected. In this respect, they are not alone.

When you deploy a technology like Kubernetes, it’s not just one team that’s impacted, it’s every team – infrastructure platform, security, product, and so forth. “When you frame the goal in terms of the technology, you leave room for interpretation by all of these teams, and each one of these teams will bring their own goals, desires, and fantasies to the project,” Adam says. Without a clear and unified business objective, the Kubernetes project had no unified, defined direction. The real goal was to help product teams deploy software quickly. THAT was the objective.

“In retrospect, it’s pretty easy to say that management and leadership –myself –made a mistake in saying that we wanted Kubernetes,” he explains. “Because Kubernetes is not what I want. I actually have no real opinion about the technology that we use – what I want is faster release velocity.”

Copyright © 2020 IDG Communications, Inc.

Source Article