Name: Obasi
Role: Software Engineer, Trading Technology
Background: Obasi joined Bridgewater in 2017, after graduating from MIT and completing summer internships at Ab Initio and then Bridgewater. He is part of the team driving the systematization and automation of Bridgewater’s trading strategies at scale.
What is an interesting business challenge that you’re trying to answer?
As Bridgewater and the rest of the world become increasingly automated, a large portion of facilitating that evolution falls onto technology. Bridgewater believes in systematizing everything — on the Trading Technology team, we leverage our traders’ market understanding to build a unified and automated platform for trade execution.
As a software developer, my role on the team has touched both the platform side and the execution logic side. On the platform side, I think through questions like, “How do you build and design a robust automatic execution platform that meets all of our requirements within appropriate risk constraints?” And then on the execution logic side, I’m trying to solve questions like, “What have our traders been doing in our manual platform? How do we translate those manual workflows into fully automated workflows? Once we enter a fully automated state and resolve issues of scale or human capability, what are the types of things that we can achieve?”
What meaningful impact have you been able to make here?
Through automation, our team has transformed the way we execute trades. Now Bridgewater can execute a higher volume of trades at a lower cost than ever before, which translates into savings for our clients and time back to our traders that can be reinvested into more strategic work.
Seeing how our strategies are advancing and how our partnership with our traders has positively evolved over time has been very rewarding.
What is a recent project that you’ve really enjoyed working on?
One of the projects I have been deeply involved in recently is building a broad set of performance optimizations across the trading tech stack. As we continue to scale and implement complex strategies, performance increasingly becomes a central concern. Working to improve the system in this way has been very interesting as it’s changes at all levels; I’ve needed to work on everything from database query optimizations to design changes on how we represent orders to low-level code improvements decreasing our memory footprint. Building out such a broad set of improvements, as well as deploying and integrating them in a way that doesn’t disrupt the current business, has been a very rewarding challenge.
What is your favorite part of your job?
Hands-down, my favorite part of the job is the people we work with every day. I work with a top-flight group of technologists who have pushed me in a variety of ways, which is always very good. Sergiy, my team lead and one of my chief mentors since I’ve been here, is hands-down one of the most gifted software developers I’ve had the privilege of interacting with and learning from. And that’s across professors I’ve worked with, other technologists I’ve partnered with, and people I’ve encountered in the professional world. The fact that he very intentionally thinks about questions like, “How can I help Obasi grow? What opportunities should I be pushing him toward, and how can the team make Obasi the most impactful he can be?” has been tremendously useful to me personally. This is a story that I repeat, with almost every dimension of the people I interact with, including my manager, product managers, and traders. Having an opportunity to work in such a high-performance environment where you’re being pushed and you’re pushing other people because everyone is just at the top of their game has been tremendously rewarding.
What is a failure you’ve faced, and how have you handled it?
When I was starting out, probably a little less than a year in, I had my first big failure that impacted people outside my team. One of my colleagues and I were rolling out a major version upgrade for a software. What was supposed to be an hour-long rollout ended up taking three days. People were called in and woken up overnight. It was just a huge, gargantuan mess.
So, we finally get it rolled out and launched on a Friday afternoon. Then as I’m getting to leave for the day, a meeting lands on my calendar for Monday morning. It’s me and my colleague…and then there are also two team leads, our Head of Trading Technology, and our Head of Product. “Oh no,” I thought.
I went into this meeting, nervous out of my mind. But for the first 45 minutes of a 2-hour meeting, we just went step-by-step into what my colleague and I did and focused on understanding exactly what went wrong. The next 45 minutes, we went very deep into understanding why things went wrong. What was it about our approach that was wrong, and what was it about the team structure that failed to catch these mistakes? We talked through what areas we needed to develop personally, and we also discussed how the team needed to evolve and implement new guardrails to prevent similar outcomes in the future. And that was the meeting. We went on with our lives. Nobody got fired. But what stuck with me was that these very senior people invested part of their day to work with me to understand why I made my mistakes and how I could avoid bad outcomes in the future. This experience was really the moment that completely sold me on the Bridgewater culture.
What have you learned about yourself from working at Bridgewater?
Coming in, I thought that I was going to have a lot of the opposite problems that I actually have. I thought that I would have a lot of trouble receiving critical feedback. But I was confident that it would be very easy and fluid to call out things that other people were doing poorly. And this was absolutely not true. I actually found it a lot easier than I expected to take the critical feedback, and I struggled very much with both perceiving problems and then translating my perceptions into reasonable, actionable feedback when I saw things going poorly. I’ve had to work on building the discipline to have painful conversations about bad outcomes. The other thing I learned about myself is that I really hate getting to the point where I realize I can’t execute something by myself. It’s not so much that I will prevent myself from asking for help. It’s that I struggle to even realize that asking for help might be a good thing. One of the key aspects about Bridgewater is that people will continually push you to take on things that might be a bit outside of your capabilities as a method of growth. You’re going to need to ask for help. I had to make a very deliberate cognitive shift and constantly ask myself, “Is there a way that I could be doing this more efficiently? Do I know how to do this better? Will I succeed, or do I need to pull someone else in?”