This edition of Office Hours, a series spotlighting Two Sigma’s senior leadership, showcases Ashish Thakkar.
Ashish joined Two Sigma in 2014 and today leads engineering teams across Two Sigma Securities (TSS), building the trading and research capabilities behind the firm’s high frequency and short horizon forecast generation.
He began his career as a software engineer in Microsoft’s Core Operating Systems Division, working on the Windows Networking stack. Ashish holds a B.E. in Electronics Engineering from Mumbai University, an M.S. in Computer Engineering from the University of Wisconsin-Madison, and an MBA from NYU’s Stern School of Business.
Read on to learn about Ashish’s path from building operating systems to the intersection of technology and finance, his take on balancing reliability and performance in trading systems, and what he looks for when developing engineers into technical leaders.
What led you to your current role, and what are your main responsibilities at Two Sigma?
I have always been passionate about technology. When I graduated, I wanted to work on core technical problems and so I joined a team that was building an operating system. It was a great experience and it helped me build a strong technical foundation.
I also had an interest in finance and I wanted to explore whether I would enjoy a role with a combination of technology and finance. I moved from the west coast to the east coast primarily as an experiment. At the time, algorithmic trading was just beginning to gain ground. It was clear that finance had relatively complex problems which could be solved with technology, and if done well, could have a transformative effect across the industry. I was soon excited by how far we could collectively take the underlying idea. This eventually led me to my current role at Two Sigma.
My responsibilities include leadership of engineering teams in Two Sigma Securities. We develop trading and research capabilities for high frequency and short horizon forecast generation, and enable their monetization through cutting edge low latency technology.
TSS operates across market making and intraday alpha, options trading, and client trading. How does the technology organization support such a range of businesses?
It can sometimes be tempting to over-index on the common requirements and aim to build a single monolithic platform that tries to satisfy all needs for all businesses. While this provides benefits from reuse, it restricts our ability to perform problem-specific optimizations and it can impose coordination requirements that reduce agility.
It can also be tempting to over-index on the business-specific needs and build completely different platforms for each business. This can obviously lead to duplication of effort across teams. The common problems are often solved by multiple teams in multiple different ways. It leads to cost inefficiencies and more importantly, it reduces the likelihood of achieving excellence in any one area as each team needs to spread its focus across many different areas across the stack.
We have tried to achieve a balance by having a single solution for a single unit of functionality, as expressed by a combination of platform features and performance. If this functionality is required by multiple businesses, we reuse it. If the functionality is specific to a single business, we optimize for the corresponding use case. We combine these components to put together the overall trading and simulation stack for each business. This requires us to identify patterns and define a unit of functionality appropriately. For example, fast and reliable access to global equities exchanges is a single unit of functionality and we use the same Bump platform component across all three businesses. The same holds true for our post-trade Control Platform functionality. On the other hand, functionality such as crossing of two client orders is specific to the WMM business, and while there is only one implementation of this functionality, it is only used by the WMM business.
We have both horizontal platform focused engineering teams and vertical business aligned engineering teams. In both cases, when a team implements a strong solution for a common unit of functionality, we ensure a collaborative reuse of that implementation across businesses through either high level product reuse or detailed code level reuse with an internal open source ownership framework.
What does it take, from a technology standpoint, to compete in ultra-low latency market making at global scale?
Deep technical expertise and full-stack optimization through strong cross-functional collaboration are critical when competing in ultra low latency market making.
To win speed races, it is often important to combine software engineering with custom hardware technology such as Field Programmable Gate Arrays (FPGAs). Software engineers, hardware engineers, modelers and traders work together to identify what part of the trading decision logic needs to run on the fast critical path in hardware, and what part of the logic can be moved to an out-of-band process. For example, the smarter, heavier computations are often done by software and the results of these computations are fed to an FPGA. The FPGA, primed with this information, is ready to transmit its instruction as soon as it receives related triggering input from an external source such as an exchange.
To minimize the end-to-end latency, the teams partner closely with network engineers who optimize network paths. This involves physically colocating at the same datacenter as the exchange to minimize the optic fiber cable length in the trading path and using microwaves to communicate across components in different datacenters.
Engineers and modelers also work on making effective alpha-speed trade-offs. A lean simple calculation on the fast path may help with winning speed races while heavier calculations may lead to additional forecast alpha. When engineers identify new ways of reducing latency or when modelers identify new forecast computation ideas, they work together to identify the optimal way of using the critical path latency budget to maximize both the quantity and the quality of trades for a given market making strategy.
Client trading involves both reliable execution and attentive customer service. How do you think about building technology that serves the different needs across TSS?
While engineers focused on proprietary market making demonstrate a relentless focus on reducing latency, the engineers focused on high client uptime demonstrate an outstanding drive to identify what could go wrong and eliminate or mitigate the related impact.
This has sometimes led to questions around whether we need to make trade-offs between reliability and performance. I consider this to be a false forced choice. I think identification and use of strong software engineering best practices can help us accomplish both. These practices include a representative QA environment for functionality testing, a performance lab for stress testing, strong operational discipline when deploying new changes, effective monitoring of the production system, being open when things don’t work as desired, and being disciplined in implementing the corresponding improvements.
This approach has helped us reuse core low latency trading system components for client order handling. We collectively recognize that local component specific failures are essentially inevitable but global trading-wide failures are not. For client trading, we go the extra distance in deploying redundant hot backups for trading system components and ensure that they can seamlessly take over client order processing if the primary machine or instance stops functioning.
How has your thinking about technology and leadership evolved over the course of your career at Two Sigma?
I think technology has increasingly changed from being a binary enabler of functionality to being a differentiating factor in the overall success of our businesses. For example, the speed at which our FPGAs can help cancel our treasury options quotes in case of large market moves directly impacts how much adverse selection we may see and therefore determines what range of products we can successfully make markets in.
The increased need for lower latency across the entire trading stack and the related alpha-speed trade-offs have also led to a far closer integration across engineering and modeling. As an example, WMM historically had a separation between the container that engineers enhanced and the tactic that the modelers worked on. While this helped create abstraction boundaries between teams, we became limited in our ability to innovate across this artificial boundary, and our next generation platform enables far more seamless contributions from engineers and modelers across the overall stack.
This has shaped changes in how we lead our teams. We have continued to hire excellent engineers and we are providing them with a higher degree of autonomy. Many of our recent enhancements emerged from proactive suggestions made by individual contributors who had a detailed understanding of the problem space. We have also selectively hired a few senior individuals with strong domain knowledge to help accelerate our growth. Where there are significant unknowns, we have consciously facilitated controlled experimentation. I have historically been a big believer in the value of building a consensus. More recently, we have been balancing time spent on consensus building discussions with active decision making to help make forward progress with strong agility.
Where do you see AI having the biggest impact on the future of trading technology broadly?
AI is likely to have a pivotal impact on trading technology in two very different ways.
First, we are already experiencing strong productivity improvements among developers who are embracing use of AI. Engineers are using AI to enhance their understanding of existing code, automatically generate new code, generate new tests, run performance analysis, and then iteratively use the results of the tests and analysis to improve the quality and performance of the code. We recently had an example where one of the engineers improved the system’s client order handling capacity fivefold in a period of about two weeks by effectively leveraging LLMs. This is representative of what is occurring across the industry and it is accelerating.
A second, more complex area of impact is related to generation of new high frequency forecasts through use of the same research architecture that large language models are based on. While LLMs are trained on text and designed to generate the next word, new forecast sequence models can be trained on historic market events and designed to predict the next market event. Unlike traditional forecasts, these require heavy computation in the critical trading path, and benefit significantly from use of GPUs or custom inference hardware in production trading machines. These can have broad consequences for how we build and deploy new trading technology.
What do you look for when developing engineers into technical leaders?
I believe individuals often have disproportionate positive impact when they leverage their strengths, so I first try to identify and enhance their strengths. Engineers who grow into technical leaders often share a core set of foundational strengths such as deep technical skills and ability to collaborate well with others. In addition, different engineers bring their own distinctive combination of strengths to a leadership role.
Some of the engineers proactively identify opportunities that others have missed and propose concrete solutions that can help move the organization forward. Some bring tremendous depth in a specific technical area or business domain, and can serve as multipliers by mentoring other team members in their area of expertise. Some are particularly adept at flagging future risks and helping prevent groupthink. And some can play different roles depending on what the organization most needs at a given point in time.
Most of us undoubtedly have areas for improvement. I think it is valuable to be aware of them, and to put in effort to ensure that the weaknesses are not worse than a reasonable threshold. As long as that is accomplished, I focus on helping them amplify impact from their respective strengths.
What’s been capturing your interest outside of work lately?
I love playing tennis, and I love reading and talking about philosophy. My wife and I have also been trying to spend as much time as possible with our kids as the kids are likely to go to college soon. Fortunately, my son loves philosophy and my daughter loves playing tennis, so I have often been able to combine family time and hobbies.