Quant devs and product engineers

Back when I was in quantitative trading I was a big proponent of the ‘quant developer’ role — a hybrid between quant researcher (strong math and stats background) and software engineer (often with an HPC background). Pure engineers tended to be ineffective since they weren’t able to spot problems with the data and didn’t have a good enough grasp of what great research tooling needed to look like, therefore building software that researchers found hard to use. Quant trading is the kind of problem that requires a mix of deep domain expertise and getting your hands dirty. If you’ve never tried to come up with a profitable signal, construct a portfolio or pick the right execution algo, you just don’t know about all the ways things can go wrong. The software you write will be liable to contain a large number of subtle defects. It looks mechanically correct but will be wrong statistically, in the sense that the resulting strategies won’t make any money — because of data bugs, causality violations, subtle issues with how the data is transformed, or code that’s too slow when it actually matters.

And the same was true in the other direction. Pure researchers also tended to be less effective since they were unable to write production quality code, therefore creating a large class of ‘translation bugs’, where signals were profitable in simulation on their local box but then failed to generate any alpha in production. Frequently this was due to overfitting and careless research, but often enough this was also because the spec wasn’t quite right or the data in production had subtle differences compared to what the researcher was working with. Closing the gap between research and production can eliminate those kinds of unforced errors.

Working in fintech the last couple of years, I’ve become a big proponent of the ‘product engineer’ role where the same considerations apply. Pure engineers without a strong grasp of the domain, deep understanding of the customer and the problem, and good product sensibilities tend to be ineffective. They’re unable to work in a self-directed manner and it takes a lot more cycles to get things right. Feedback loops with a PM and a QA team in the middle tend to be slow and costly.

Conversely, pure product managers without a strong engineering foundation also tend to be ineffective. They’re bad at estimation and often can’t tell which features are hard vs easy to build. They don’t have a good sense for what the right data model looks like and they will be less effective at communicating with engineers — again lengthening the feedback loops.

This raises the question whether everyone should be a product engineer or quant dev. I believe the answer is yes, by and large. At Kappa, we’ve been successful so far without hiring a PM, and that’s largely because our engineering team is made up of folks who deeply understand the problem and the customer, and who cherish getting their hands dirty. Likewise, in the hedge funds I worked at we did well by hiring researchers who were also strong developers as a pre-requisite, and vice versa developers who also had a strong grounding in math, stats and finance.

What does a great product engineer do? They use the product. They end-to-end test their own changes and do all the acceptance-testing themselves. They have an account in production and make use of feature flags to truly test the last mile. They sit in on customer interviews and do shifts on customer support. They’re goal-driven and care about customer experience above all else.

What does a great quant dev do? They obsess about the data. They visualize it, do outlier analysis and look at distributional properties. They read everything about markets, finance and statistics they can get their hands on. They understand arbitrage and market efficiency. They monitor signal performance in production. They’re goal-driven and care about portfolio performance and PnL above all else.