Odd Lots - Camille Fournier on Building Tech at Two Sigma

Episode Date: December 21, 2020

We talk a lot about quantitative trading on the podcast, but typically from a rather big picture perspective, and not at the level of actually building the systems needed for trading and data analysis. On this episode, we speak with Camille Fournier, the head of Platform Engineering at Two Sigma, the financial services firm that, among other things, runs a large hedge fund. Fournier, previously the CTO at Rent the Runway, discusses how her job works, the challenge of managing software engineers, and how tech within a financial services company is different than tech within a consumer-facing startup.See omnystudio.com/listener for privacy information.

Thanks for listening to Odd Lots. Follow the show on Amazon Music for more future episodes or just ask, Alexa, play the Odd Lots podcast on Amazon Music. Hello and welcome to another episode of the Odd Lots podcast. I'm Joe Wisenthal. And I'm Tracy Allaway. So Tracy, you know, we've had a number of episodes, not that many, but certainly a handful of them. One of our themes is like quantitative finance, quant stuff. We always sort of talk. talk about it from a sort of very big theoretical level, like what's happening with different factors, alpha decay, stuff like that, always sort of like tends to be at the sort of big picture abstraction level, I would say. Yeah, I think that's right. We talk a lot about the future

of quantitative finance. What's most important, I guess, when it comes to running a successful quant strategy, like whether it's the actual formula or program that you're using or whether it's something like the data set that you're using, we've discussed all of those now. Yeah, absolutely. And, you know, so we talk about it theoretically. We talk about it academically. But one thing that we haven't really discussed is, you know, when you like think about quantitative finance, you think about lots of really smart people, mathematicians, people using computers to find data, to analyze huge amounts. data, who've never really talked about it from the bottoms up, like, the actual process of

using computers, using technology to perform all these calculations and to, in theory, beat the market. Yeah, I think that's right. And I'm going to go ahead and admit that I don't know that much about engineering in the financial industry. We can talk a lot about what gives a competitive edge when it comes to quant strategies, but a competitive edge when it comes to engineering, when it comes to installing particular products or systems, I really have no idea what that looks like nowadays. No, I literally have no idea. But it's kind of, you know, it's this huge whole component of it and every financial firm, whether it's a major bank, whether it's a fund, want to advertise their tech stack, their tech advantage, so to speak.

But I don't really know much about the actual process of like building that tech and how you build a competitive edge from that tech. And yeah, it's like it's a whole sort of facet of this that I don't think we've, I don't think most people know very much about. Yeah. And I'm also interested in knowing whether the culture of being an engineer and at a financial company is different to the culture of being, say, a trader or a banker at a financial company. And I'm definitely interested in knowing whether or not the culture of being an engineer

at a financial company is different to being an engineer at, say, Google or Apple or something like that. Right. I'm extremely curious about this as well because, again, it's like one of these things where in theory, more and more financial institutions would like to be competitive for talent, the likes of Google and Facebook and other startups and so on. But it raises the question of like how similar differences and what a how the two compare. Yeah, absolutely. This is going to be a fun episode, I can tell. Yeah, I'm super excited about this one.

This is a conversation I've wanted to have for a long time. Today our guest is Camille Fournier. She is the managing director or a managing director head of platform engineering at Two Sigma, which is a big financial services. It has a hedge fund. It also does VC stuff. Very sort of well-known, famous firm in the space. Camille was previously the CTO at Rent the Runway, the popular fashion. I don't know how you describe it, but I guess people rent dresses on a temporary basis or rent clothes on temporary basis. And prior to that, Camille was at Goldman Sachs. So has seen all of this from both sides, the tech hemisphere of all these services. So, So Camille, thank you very much for joining us. Yeah, thank you for having me. Excited to be here.

Yeah, I'm really looking forward to this. So before we get going, why don't you sort of give us the quick summary of your career? How did you get to be your path to being the head of platform engineering at 2 Sigma? Sure. I have something, I guess I have a fairly standard educational background. So I have a computer science degree from Carnegie Mellon for my undergraduate degree. I worked at Microsoft for a hot second. Went to graduate school at the University of Wisconsin.

Decided I didn't want to get a Ph.D. I did want to live in New York City. And so ended up getting a job at this company that I had literally never heard of until I interviewed there called Goldman Sachs, which I'm sure will be very amusing to your listeners. I went to Goldman and was there for about six and a half years. and I worked in risk technology for a long time, which was actually like really awesome area to work in building a lot of really big scaled systems to do, you know, really massive risk analysis. And then I also worked in a similar kind of technology group to the one that I run today for a couple of years. And then around 2011, I decided that, you know, I wasn't quite ready to be settled down and like making a career at a giant company like Goldman.

and I wanted to try something new. And the startup world was really, you know, getting to be very hot, very popular. Even in New York, there were lots of interesting startups. And I got approached by Rent the Runway. And I had also not heard of Rent the Runway until I interviewed there. But of course, they were very small, a small startup at the time. And I was just so blown away by the product idea. It was one of those things where every time I described the product to,

another woman, she immediately understood what I was talking about. When it comes to consumer-facing startups, that's really such an important sign of a good idea, is just how fast your potential customer gets it. So I was like, all right, like, this company seems like it has really short business people, right? The founders were just incredibly smart, you know, Harvard MBAs, PhDs with operations research backgrounds on the data side. So it was like, they're really smart people, in the leadership team and the technology was a complete mess. And so I was like, great, I'm a great engineer and I want to like, you know, become a leader. So this is a great opportunity for me to, you know, join this company and fixing the tech will be easy.

And, you know, this is going to be a slam dunk. And, of course, life never works out that way. It was significantly more challenging to come in to a startup that's sort of in that growth stage. and, you know, both do a lot of work to really turn the technology around and make it really stable and scalable and easy to add new stuff to because that's really a lot of the challenge in a startup is how fast can you iterate, how fast can you do new things. And it's also just, that was a, you know, a massively challenging learning experience to learn how to become a manager and an executive and a leader. but I did that. I did that for four years. So I became the CTO. I was there for about four years. And it was a really, it was an amazing, amazing learning experience. You know, after after four years, I sort of felt like I had done what I came to do. I had come to learn a lot. I had come to establish myself a little bit as as a leader in the industry. Frankly, I did want to have more of a public career than I was able to have. have at Goldman at the time. Goldman was still very secretive. They didn't really want you, you know, out there in public talking about your work. And I like talking about my work.

I like sharing my ideas. You know, I learned a lot about being a leader. I grew the team. I stabilized the technology. And then I decided that, all right, I wanted to, you know, being a startup is exhausting. So I was like, all right, I'm going to take a break. I'm going to think about starting my own company. I actually wrote a book about engineering management in the year and a half that I was doing various things, is how I like to describe it. And then I was like, all right, you know what? I'm this, me starting a startup by myself is not working out because I don't have any great ideas and, you know, maybe this is not the right thing for me to be doing right now. So I was like, okay, I need a job. And I got approached by two sigma. You know, I would talk to a bunch of

company. I talked to Google. I talked to a bunch of smaller startups. And, you know, I'll be honest, when I was approached by 2 Sigma, my first reaction was, oh, I don't know. I had actually, I know a lot of people who worked at 2 Sigma already. And my impression was actually that the company was really academic. I wasn't sure how well I would fit in in a super academic culture. But I went and interviewed and I was actually blown away by just how smart and nice everyone was. And, you know, the role that they wanted me to come in to run their platform engineering organization was a really interesting role. Really kind of getting back to my technical roots as, you know, a large systems developer. That's really kind of the technology area that I'm most interested in personally.

And it was a great, you know, great team. I got to, you know, I'm part of the engineering leadership team at Two Sigma. And so, you know, I took the job and, you know, here we are today. And it's been, you know, it's been really a great experience so far. I've been there for almost four years now. So you mentioned when you moved from Goldman to rent the runway, which was a startup at the time. And has really, I got to say, like, I have used rent the runway and it's blown up a lot since then. And pretty much all of the women that you might ask about this probably know about it.

But when you move from Goldman to Rent the Runway, you mentioned that it was more challenging than you had expected. Can you go into a little bit more detail on why that was and what was the difference between either the technology that you were actually working on at Goldman versus the technology at Rent the Run the runway or maybe the differences in the ways the companies actually operated and did things? There were a few things. So first of all, like at Goldman, certainly at the time and the areas that I was in, I was just not used to working in. So I was not used to working in an environment that sort of combined being a very, the needing to move really, really fast, right? So needing to build new stuff really quickly. There are areas of Goldman that are like this, but that wasn't really where I was working. And having really high sort of uptime requirements.

So I think one of the interesting things about the difference between a lot of parts of finance and consumer technology is that it is still possible in a lot of parts of finance to work on systems that actually don't have to be up 24-7, meaning that they don't run on the weekend sometimes, right? Like, you know, the markets are closed, so the system doesn't actually need to be running, for example. That is not the case with consumer technology, right? The expectation is if you're building a product, you're building a website or an app or whatever that, you know, consumers are going to use, then it's going to be available when they want to use it. And that is actually a really big technical difference because it really does mean that, you know, if something goes wrong on, you know, at 2 o'clock in the morning on a Sunday, you have to deal with it. someone has to deal with it, right? It can't just, like, leave it until, you know, sometime when you're more wide awake and, all right, like, we've got to get this ready for, you know, business open on Monday morning,

but we've got some time, right? Which is often the case in finance. That's really not the case in consumer. And so I think that is actually a really big, different kind of challenge that, you know, I wasn't totally thinking about, I think, when I came in. So I think that was a big challenge. And then there's just, like, a lot of. technology pieces that, you know, when you're building, when you're building for consumers,

particularly frankly in fashion where things need to look and feel good, right, in the technology. There's a, you know, there's sort of a spit and polish and, you know, branding and element to everything that you're building that, you know, a lot of times in finance, you know, you're building an interface for, you know, a trader or, you know, a risk analyst or whatever. It just needs to work. It to be beautiful. So, you know, really having to think much, much more about, you know, the customer who isn't sitting, you know, in the desk next to you telling you exactly what they need, you know, because the customer is, you know, thousands and tens of thousands of women all over the country who, you know, each has kind of different preferences, right? So how do you figure out

what to build for them? How do you, you know, how do you build something great without necessarily having, the person telling you exactly what it is that they want built. Those are some of the challenges just on the kind of technical side that it was really a very different kind of both, you know, some of the technical challenges on the availability, but also on, you know, the actual way you decide what to build is really different. And then, you know, look, big company to small company, you know, obviously you got a lot, you don't even notice the things that are provided for you in big companies like, you know, HR and training and IT and all of that stuff that's just kind of there and working and has been

established over years and years. You have to establish it yourself at a small company. That's fun, but it's a lot of work. On April 4, 23, around 2 in the morning, a man was found stabbed multiple times on a sidewalk in downtown San Francisco. Hey, who did this to you? What happened next turned the source. story into a political firestorm. Reports have identified the victim as Bob Lee, the founder of Cash App. From Bloomberg Podcasts, this is Foundering, the Killing of Bob Lee, beginning April 16. So you mentioned between Rent the Runway and your current job, which we'll get to soon.

You did write this book, and I meant to plug it in the beginning, and I'll plug it at the end, but the manager's path, a guide for tech leaders navigating growth and change. And so I have to imagine, like, during that time, like coming to rent the runway when it was a small startup and then leaving when it was this household name, I have to imagine that like your role and your evolved a lot during this time. My assumption would be that in the beginning, you were doing a lot more like hands-on technical stuff by the end. My guess would be a lot more management and per your book. I imagined that that's a really tough progression for a lot of people. And engineering and management, they're very different jobs. It's kind of like in our industry, like being a journalist and being, or sorry, being a reporter and being an editor.

They're very different jobs, even though a lot of people go on that trajectory. Now, I guess this is, you know, this is a book-length topic. But for you, like, sort of like, what are the big pain points that people experience or that you experienced on that journey to actually sort of managing engineers as opposed to building technology direction? Yeah, you're absolutely right that it is a book length topic, but I think some of the highlights are in the early days you can still sort of manage and write code or, you know, be kind of somewhat hands on for a while. But as your team grows, you start to, you have to consciously, like, ease off and pick out what you're going to work on if you're going to be hands on. And then at some point, you just can't be hands on anymore, right? You can't, you know, you cannot really be

writing production quality software if you're in meetings six to eight hours a day because you're not going to be focused and then you're going to be working you know maybe you're writing that code at night after your day is done but you know in engineering teams right you don't just like write code and then it's done you write code someone has to review it tell you whether it's good or not you know you've got to make sure it actually works you've got to actually get it running in, you know, to customers have to be actually using it. And if it breaks, it has to be fixed. And so when managers who are really managing very large teams write code, they may be able

to do the writing part, but they often can't do the rest of those parts. And that's actually really frustrating as an engineer. I've been an engineer with managers who have, like, thrown code at me that way. And it's really, it's really frustrating to experience that. So, you know, I really strongly advise, you know, managers once they get to a certain point to stop doing that, stop writing code, right? That's not really your job. You can do it as a hobby on the weekends, but don't do it for your actual team because they'll probably get mad at you, actually. But that transition is so painful because as engineers, we're taught for years and

years and years that our value is in the software that we create, that like that is what we are rewarded for is, you know, writing good software, building good systems and being clever and fixing, you know, fixing hard bugs and being smart about that thing. And it really feels very, it's very scary to stop doing it. Um, you know, also because everyone tells you, you know, and there's just kind of, you know, tech is a very agist industry, right? And there's this great sense of like, if I stop writing code, you know, I'm immediately on the path to obsolescence and my technical knowledge is going to fade. And I'm not going, you know, I'm not going to be taken and seriously by the people that I'm managing anymore.

And, you know, that is a very, so it's like you've got all these cultural messages that are like your value is in software, but you can't really do your job well if you're writing a lot of software as a manager of a large team. And you have to kind of get over that and figure out how to feel like you're still staying technically in the loop and credible without, you know, having, you know, writing code being your main job. So I think that was that was a huge transition for me and a huge transition for a lot of engineers. I think that's that's that's a huge one event. I think you know there are a lot of them as your team gets larger, you also have to you have to develop the skill of helping your your organization

make good technical decisions without knowing every single detail of what they're doing. And that's sort of a it's sort of a similar challenge but a little bit different right. So when you're actually, again, writing the code, reading the code very much in the details of the work. You, and you're probably an expert. If you've been, you know, you're getting into management, you've been doing this for a long time. You know, generally speaking, people get promoted into management do tend to be viewed as technically credible by their teams. You know, I don't think you should always just promote the best engineers as managers because they're the best engineers. They might actually like writing code. But, you know, sometimes, right, like they're, you know,

you do want to promote people into management who are technically credible and, you know, have good judgment, right? Because that is part of your job as an engineering manager is sort of helping your team make good decisions. But you, you definitely need to still be able to help them make those good decisions, even as a team that's larger and larger and you get farther away from the details of the problems. And so I think that's the other really challenging transition that a lot of managers go through and that I certainly went through, which was like, how do you, like, how do you get the right information and get you sort of about what's going on in a team that's maybe, you know, you don't even, you're managing the manager of their manager, you know, whatever, you're like several

management layers away from it. But you kind of need to know, oh, something's going wrong here, because if it goes too wrong, it could affect, you know, the ability for your whole organization to get stuff done, right? Or it could affect, it's going to make you look bad because something is late or it's broken or, you know, it's constantly falling over. And so you have to still be able to influence their technical decisions, but without actually like looking through their code and reading it and actually knowing all the details of their systems design. So how do you do that? And I think that is a similar challenge that a lot of people go through and certainly that I went through. And so those are, those are some of the challenges that I talk about in my book among many others.

So I may be projecting here, but I see a lot of parallels between the, the engineering profession and how it, sorry, let me rephrase that. So I may be projecting a little bit here, but I feel like there are quite a few parallels between journalists who transition from reporters to editors or some other sort of management job in journalism and engineers who do something similar. You know, journalists are judged by their output, the quality and maybe sometimes the quantity of the stories they produce. And once you move into an editing role or a management role, it's hard to come up with like new ways of judging your performance. But the other thing that tends to happen in journalism is journalists and particular reporters are competitive people who

often have an anti-authority streak. Like, they like calling authority up on the decisions that they're making. And therefore, sometimes they do not make the greatest managers. So one thing I'm wondering is in tech, it's kind of similar, right? You have a lot of competitive people who want to move fast and break things. And I think there, at least for a long time, there was this culture of management being bad and that you should have fewer managers, you should just hire good people and let them do their own thing. How did you deal with that aspect of it? And do you think that managers are more widely accepted in tech as a lot of the players get bigger? Oh, yes. This is a, this is a very, very interesting area. One of my friends and I sometimes refer to ourselves as as

punk managers, because we're kind of both both a little bit punks in various ways. You know, and I do think absolutely. So I actually think tech is sort of interesting. There are definitely the sort of anti-authority types of which I'm sort of one in some ways, right? Where, you know, I mean, part of the reason that I ended up getting into management is that I looked around and I was like, look, I think I can make better decisions than other people. I think I can, you know, I think I make good decisions. I think I make better decisions on the whole. I think I'm, you know, going to do a better job of treating people well and, you know, creating healthy, healthy organizations.

But, I mean, also, I think I'm going to like, you know, I think we're going to be more successful under me because I've, you know, I've got what it takes, right? I do think there is some of that, but there are actually plenty of people in tech who are, you know, very rule abiding, thoughtful. I mean, look, tech, part of being an engineer, being a really good engineer is, actually like learning the rules of the systems really well, right? You're you're sort of writing very, very, very precise rules into, you know, into software as you write software, right? And so there are actually plenty of people in tech who I think are, are, you know, our rule abiding and

quite, quite willing to kind of, I don't know, they're definitely not like anti-authority necessarily. But you're absolutely right that for a long time, that really back when I started at Rent the Runway, this was like really very popular the idea that like managers are a waste they're a you know again hires front people and get out of their way and let them you know and they'll just figure it out and you know managers are dead weight right both engineers and like vCs would say this right frankly part of the reason i started blogging about management and ended up writing the book was that i just thought that was so so ridiculous because it's so obvious to me that look modern engineering is is building very complex systems that require large teams of people to build and maintain and evolve.

It is a team sport is what a lot of people say, right? And I think that's true. I don't think that, you know, that is a somewhat more modern evolution of software engineering, right? You know, 30 years ago or the early days of software engineering, lone wolves could do more by themselves. But as systems have grown and grown in complexity, and there are more components and more, more things that need to be done, it's just much harder to build, you know, a really interesting and compelling product as, you know, a lone wolf or as a team of like sort of individuals just working on their own stuff. And so I do think that when you need that really like team-based

coordination to go really well, you do need capable management to help with that. You know, you need the coach. You need the person who is, you know, observing everything that's happening and making sure that you're covering all the pieces that need to be covered, making sure that the group is working well together because, you know, when the group isn't working well together, they're not as productive, they're not as happy, you know, you get a lot of conflict, you get a lot of, you know, you're just, you're getting bad results out of that, right? You're not going to get the greatest creativity out of the overall group when they're, you know, when they're not collaborating well, right? And so I do think that, you know, that there was, I just, in my opinion, frankly, like kind of a, you know, legacy attitude about management that I think for the most part has gone away, although I'm always waiting for the backlash to happen, you know, inevitably there will be a backlash and people will be like, oh my God, there's too many managers and everyone wants to be a manager and, you know, or wasting all this overhead on management, you know, so I'm just sort of waiting for that to drop personally. But I do, like, I think that.

management, I do think that management became more accepted, even at startups in tech, because a lot of people were suffering from the lack of it. A lot of teams were just not efficient, even small teams at startups. It's really hard to run an efficient, it's really hard to build a multi-person product, a group effort if you don't have leadership. And, you know, you need someone who's willing to to do that, you know, both the good and the bad work of that, right? You know, the fun work maybe of sometimes you get to, you know, you get to be the final decision maker on some stuff, maybe, right, but the grunt work of like, actually you have to kind of influence a lot of people and, you know, you have to deal with a lot of conflict and you have to, you know, have hard

conversations. And so, you know, I do think that management has become more popular in tech, not just because the big tech companies have grown up, but actually because everyone has just realized it makes their teams happier and more effective. So let's skip ahead or let's skip to your current role. I introduced to managing director, head of platform engineering at 2 Sigma. What is the head platform engineering at 2 Sigma do? Yeah. So I run the team that builds the software systems that anyone at 2 Sigma who writes software

themselves will use. So that could be other engineers or modelers. But we build things like our data storage products. We do all of our sort of public cloud work. We build tools for software developers to, you know, test their code and execute their code. We build frameworks. So, you know, really it's all of the software that other people who write software use is, you know, foundational software is built by might.

How different is an engineer at a financial services firm such as 2 Sigma to an engineer at a tech company or some sort of startup? Like, does it take a different skill set or does it take a different personality? I think that depends a little bit. So like in my team, we are, are actually have a lot of people. I mean, 2 Sigma in general has like 60% of the staff is not from financial background, financial company backgrounds. So, so we definitely, you know, Two Sigma in general is like a very diverse in terms of a former employer background kind

of company. And my team is actually very heavily populated by people who have worked in the tech industry before coming to Two Sigma because a lot of the products that we build are very much like, it's very tech heavy. The team is, The team that I run, you would see similar kinds of teams at all kinds of big tech companies. They'd be much, much larger than the team that I run. But, you know, it's a very kind of like transferable work. So I think that some of the differences that I've noticed between engineers, certainly at startups versus somewhat larger, either tech or finance,

companies, I do think that, you know, that as you get larger or, you know, more, you can, you can hire more specialists and more depth experts. And so I do think that what you'll see, if you look at a startup, but you're going to see a lot more generalists. And you'll see engineers who are not necessarily the best engineer in terms of like, real, like, sort of deep expertise and you know they they know everything about you know this kind of deep technical system or whatever right or you know they're there they're much this the skills that startups tend of value are much more about people who can just be like all right like how quickly can I get through this problem and onto the next thing and that is not that is valued um at big

companies to some extent but I think big companies tend to have more time to spend on solving problems. And so they'd rather spend the time to solve a problem right or more right than to just get it, you know, get something out there and move on to the next thing. So I think that's, that is a difference. I also actually think one of the, one of the really, one of the things that I learned at Rent the Run the Runway and that I've brought to my team at Two Sigma is that, you know, as I mentioned, I think a little earlier, one of the big things that you have to do to be successful at a startup, particularly like a consumer facing startup like Rent the Runway, is really understand and figure out what your customer is going to want and figure out how to build things

and how to know if the feature or the product feature that you're building is actually something that people want and that sort of product management skill set and knowledge. And even engineers have to have it. So there is a formal role called product manager and exists, you know, most startups and most tech companies and Two Sigma has these folks as well. But, you know, when you're at a startup, even the engineers are kind of expected to understand and sort of have that customer empathy. And that knowledge of kind of knowing how to think about that has actually been really useful for me to bring to Sigma because, you know, we have customers for my team. There are other people at Two Sigma. But they're not, you know, we don't have,

you know, a trading desk telling us to build X, Y, or Z. Right. We've got, you know, hundreds of people that use our software, and they all have slightly different needs. And so it's really important that my team be able to hear lots of different pieces of feedback and sort of generalize that into, okay, where do we actually need to go with the products that we're building so that we're building something that's great for other people to use. It's easy for them to use. It makes them productive. And it kind of anticipates the future needs of this business. So yeah, I mean, that is sort of where I was going to go next. I mean, when you describe figuring out the needs of rent the runway, you're talking about tens of thousands of women around the country and how they might want to search and have an article of clothing shipped to them. Describe a little bit more that process when it's internal, when it's at a financial services company.

what are the types of things that your clients, your customers, your internal customers are looking for what do they need, what kind of problems are they trying to solve? And what are they looking to you specifically to build for them or to help them build so that they can do their job more effectively? Yeah. So, I mean, look, one of the big problems that they're always going to need is just the demand for more, you know, more data, more data and more computational power. And so my team, you know, my team doesn't do the actual like data onboarding, right? So there's a data engineering team that's really responsible for that part of things. But my team owns the storage systems, right? And, you know, recently, right, we were serving, we've been serving like 15 petabytes a day of data.

So just to like contextualize that for your users, if you've got an iPhone with 256 gigs of storage, that's like 60,000 iPhones worth of storage that we're sort of serving in a day. So, you know, we have these really massive amounts of data and there's always demand for, you know, I want more data, I want it faster. I need it, you know, I need to be able to access this data in particular ways because, you know, like I'm looking across a time series of data and trying to, you know, detect changes or what have you. And so, you know, and as we, you know, as new kinds of like machine learning algorithms are adopted, They have different kinds of data requirements and data serving requirements that my team will need to be able to keep up with, right? And, you know, so I think there's always that demand for bigger and faster.

You know, on the, and then on the computational capacity side, right? Like, you know, again, as we get more data, we want to process it faster, you know, we want to run lots and lots and lots of experiments. you know, we have workloads that peak at like half a million cores of processing. So again, that's like, you know, your laptop might have 16 cores if you've got like a really hefty laptop. So, you know, huge, huge volumes of computational processing. And to do that requires pretty complex systems under the covers to actually, you know, coordinate all of that work, you know, enable people to sort of submit work to these systems to run and get results. You know, the way that my team will, you know, will understand this is we really have to work with our partners, both in engineering and in modeling,

to hear about, okay, like, you know, what's coming up next, right? Okay, if we're moving to, you know, if we're moving to doing a lot more deep learning in this area, what is that going to mean for the platform, right? What, okay, you know, what does, what are the real, like, heavyweight requirements? You need access to GPU processors, right? You know, those processors that are great for certain kinds of matrix math. And that's what, you know, okay, deep learning really needs a lot of GPUs. So my systems are going to need to support that. So I think that's one side of it.

And then I think another side of it is just, you know, in the same way that if you're at a business serving external customers where you can't just talk to each customer individually, you want to look actually at the data about how people are using your product and detect trends or opportunity. for improvements, right? So if you're looking at the data about the way people are using your systems, and you see that like a particular very commonly run command is really slow, you can sort of accept that that actually is probably slowing people down and interrupting their flow and their creativity. And that's an opportunity where if we could make that commonly used command faster in

some way, they're going to be more productive. They're going to be, you know, happier because it's just going to be a lot easier for them to get their work done, right? So those are some of the ways that we kind of approach trying to figure out what to build. So presumably making the core systems faster and able to process larger amounts of data, like that is how engineering contributes to a competitive edge for two sigma. First of all, is that correct? And then secondly, if that's true, does that mean that, does that mean as as quant shops kind of get bigger and faster, that scale matters much, much more than it used to? And does that mean that the competitive advantage is always going to lie with the biggest firms with the most resources? Does that make

sense. Yeah. You know, I will, so I do think that a lot of the advantage that engineers bring to companies like 2 Sigma is, is our ability to build platforms, to build platforms that can enable scale and productivity. I do think that's, you know, that and being, you know, and then, and I do think that that engineers also bring, bring a degree of innovation with them, right? There's a reason that, you know, companies do put a premium on really great engineers. And, you know, it's not just because, like, the skill set is rare because more and more people are learning how to write code. And, you know, I think it is becoming, it's not as hard as it once was to write code. But I think the best engineers are not only, you know, capable of writing code, but they are innovators.

And they have, you know, they can see ideas for how to do things that, you know, you will. wouldn't necessarily predict as an outsider, even as an outsider who is an engineer, but not deep in the details of a particular area. I think it's an interesting question as to whether scale is always a competitive advantage for companies like 2 Sigma. I am not an expert in, you know, the quantitative finance hedge fund industry. I've only worked at 2 Sigma when it comes to, hedge funds. And so I don't have a ton of, you know, experience more broadly. I mean, I do think, though, that, you know, you do see scale. I do think scale matters. I think scale matters in a lot of ways in these businesses. I mean, look, I think scale matters in your ability to get good costs

and trading, right, which is, you know, get your costs down in those areas, get your lending costs down. But I do think that scale from a, from a technology point of view, it will matter if the way, you know, if the way to find good, valuable ideas comes from processing larger and larger and larger sets of data. Yes, scale is always going to be a competitive advantage. Now, if you can find ways of getting good ideas that don't require processing massive amounts of data, or, you know, don't require running really large computational experiments to determine, then, you know, scale is not necessarily an advantage. And scale certainly comes with its downsides, right? So I think Two Sigma has really invested heavily in building out platforms, not just in my team, but, you know, even in our, our model

or tools for modelers, right, we try to think about that as building a platform of tools that our modelers can use it all work together. You know, some companies, my impression is that there are companies where like, you know, practically like every desk will have its own sort of engineering team and its own set of tools. And those are two very different approaches and they have pros and cons. I think that the platform approach, you can, you can do bigger things, right? It's sort of like comparing like a cruise ship or a, you know, a big container ship with like a speedboat, right? So like, you know, you can go a lot farther and you can do a lot more and can carry a lot more in a big shipped, but you cannot turn quickly, right? Whereas if you're in a speedboat, you can react

really, really, really, really fast. You just can't, you know, you've got sort of a limited amount that you can actually do with that. And so I do think that, you know, platforms have a lot advantage in this ability to scale and this, you know, investment in being able to scale does give you a lot of advantages in terms of, you know, the scope of things you can do. But it does have downsides in that you have to invest a lot of technology and time and effort into being able to do that in the first place. And that means that changing your approach becomes somewhat more expensive. I'm June Grasso, inviting you to join me for the Bloomberg Law podcast. Every weekday, we help you make sense of the legal stories that shape the nation and the world. Listen for complete analysis

of the biggest court cases, the latest actions from Congress and regulators, and the legal moves driving the markets. from corporate law to constitutional law and from state courts to the Supreme Court. At Bloomberg Law, we go beyond the day's headlines. We speak with top attorneys, judges, scholars, and policy experts to break down what the rulings really mean. We do this every weekday, then bring you the best conversations in our daily podcast. Search for Bloomberg Law on YouTube, Apple, Spotify, or anywhere else you listen.

On the East Coast, listen as you start your day. day and on the West Coast, catch up in the evening. That's the Bloomberg Law podcast with me, June Grasso. Subscribe today wherever you get your podcast. So I'm curious about the evaluation process of new endeavors. So presumably anyone who is, you know, doing, trying to build some sort of machine learning, AI trading system would always like more data and faster access to the data and so forth. But you or the engineers have to evaluate, I presume, like, okay, but what's a worthy investment? And does this really make sense to build out this capacity? And will it really deliver adequate returns? How do you think about those kinds of problems when a team

comes to you with some sort of need or with some sort of when they're bumping up against the limitations of the existing platform or the existing technology evaluating what aspect of capacity is actually worth investing in, because presumably it's a, you know, very, very costly time, money also with uncertain returns. Yeah. So I have sort of two different approaches. So one of them is that, of course, if you see a pattern of people coming to you or you can detect a pattern of requests, you should probably build it.

Because now you're seeing, all right, like I've seen several different people are thinking about problems that if we had a solution that served time series data 10 times faster or whatever, right, we would be killing a lot of birds with that stone. Right. And so definitely part of the job is looking for those patterns and knowing what people are working on and being able to decompose it into, okay, actually, you know, these are very similar things and we need to solve for this pattern. But another approach that I like to do is sometimes you're not sure. You're not sure. sure. And so the best approach is to partner with the team, particularly if it's coming from an engineering team that's requesting something, is to partner with the team and build out

some kind of proof of concepts, you know, where you're investing enough to get something built, but you're not committing to turning it into like a big platform system. And, you know, what you do when you do that is like, first of all, you learn about the problem more and a really more like specific way. And then if you build this sort of proof of concept for a team and nobody else sees it and says, oh, I really want that too, or this is super useful, I can see how I could use something like this in my area. Then you can say, okay, you know what, like this isn't going to be a platform team. We, you know, we partnered with you, but you're going to, this is your thing now. So take it, run with it, you know, use it for your small area,

but we're not going to extend it to be something generalized. But sometimes you build out that proof of concept and you do see people asking for, well, maybe not quite that thing, but something that looks sort of similar and it gives you a much clearer idea of what the actual need is. And again, I think this is very much something that I've taken from startup life, right?

Where it's, you know, how can I learn quickly where I should be going? And sometimes the best way to learn quickly is just to build something that isn't the ideal, you know, big in the system. But that if we launch it with a partner, we'll learn a lot about the area and whether or not it's worth investing in. So I have a slightly weird question, which is, how do financial services firms feel about open source software nowadays? because I remember, I guess, five or six years ago when I was writing about Wall Street, I remember there were one or two banks that were trying to make an open source push because they thought it could make everything more efficient and cut down on costs

and there's a lot of cost pressure at the banks after the financial crisis. But it was sort of an uphill battle for them because most of the banks were pretty competitive and I guess they thought all their technology was very proprietary and they didn't really want to share. Has that changed at all? Is there more cooperation across the financial industry when it comes to software? There's certainly a lot more open source.

Actually, one of the reasons that I left Goldman was that I actually was working in open source there and I felt like it was such an uphill battle to be allowed to work an open source at the time. I think they've changed that process quite a bit in recent years. But, you know, when I was there, it was like, well, we'll let you do this because we like you and we trust you. But it wasn't sort of a generalized process that lots of people could do.

And I do think that's changed dramatically in the last 10 years. So 2 Sigma does a ton of open source. We both contribute to big popular open source projects like pandas. We also open source some of our own software. So I definitely think that you're seeing a lot more. open source in the financial industry. Now, it's still, you know, it's still different, I think, than the tech industry in that, you know, it's still a bit more bureaucratic probably to, to, you know, create open source. There is certainly, you know, concern about IP and what is going to

give our, you know, competitors an advantage if we open source it versus, you know, what helps with our brand in the industry, right? You know, because open source is, you know, because open source is good, partly because it helps you recruit engineers. Engineers tend to like companies that do open source. In my opinion, I think it's just like it shows that you're a good corporate citizen when you contribute to open source and you know, because everyone uses open source and open source is expensive to keep up for the open source maintainers, right? A lot of them are volunteers. And so when you look at a company and you see that they, you know they use open source because every company that does software is using open source, but they absolutely do not contribute back to it.

You think, okay, this company isn't a good corporate citizen in that way. What does that mean for the rest of the way that they think about, you know, engineering? So I do think that, you know, savvy companies realize that preventing their engineers from contributing to open source is actually bad branding in a lot of ways. But there still certainly is that concern of, okay, how do we make sure that engineers are not accidentally leaking something that is in fact really like proprietary and valuable. And I do think, you know, that's going to be a concern probably forever, given that there are, you know, algorithms and pieces of code in finance that really are quite valuable in and of themselves, right? And so, you know, when you can, you can do something significantly faster than your competitor,

because you've thought up this great mathematical algorithmic trick, like you don't really want that getting out there to the wider world, accidentally leaked as a piece of open source software. You know, I'm curious. I mean, at the beginning, you mentioned Two Sigma's reputation as being kind of academic. But I'm thinking, like, from the perspective of an engineer, like, maybe thinking about going to a place like Two Sigma versus going to a place like Google. I mean, like, I don't know if Google still has it, but of course, they used to be famous for, like, the 20% thing and getting to work on your own projects. And they still have all those other side bets, which are just a bunch of businesses that lose money. And I also have to imagine that even in the core Google, there's probably a lot of people working on things that don't make money and are never expected to make money.

And they're just a bunch of people, I don't know, eating the lunches and working on their projects and stuff. But at a fund, at a hedge fund, I can't imagine that there is as much space for that kind of thing where it just sort of like intellectual explorations or long pursuits of things that may never get monetized. or productized and so forth. And so I'm curious about like, is that how much of a difference that is internally at a place like 2Sigma versus a large established tech company like a Google or Facebook or Microsoft? So I think, look, I think that that Tuesdaysina definitely has, I mean, people doing technical research. We have a labs team. and we do try to provide room for people to explore ideas. Because again, as I said, innovation, you know, comes from surprising places in engineering.

And, you know, while Google is not always particularly efficient, probably, in the way it allocates its engineers, at least to an outsider, you know, that it does come from a place of recognition that, like, engineers, when left to their own devices, and but, given clear, you know, ideas, maybe clear problem statements will innovate in surprising ways. And so I do think that at least at 2-Sigma, we try to do a reasonable job of balancing, like being very pragmatic and focused on, we've got to ship things for this business, right? Obviously, you know, we're not a huge company or, you know, 800 some engineers. So it's not like, you know, we have infinite resources to do whatever. but being culturally aligned with that desire of engineers to have a little bit of freedom to explore and innovate and, you know, try new things. I, you know, I do think Two Sigma actually does a pretty good job of that, partly by the fact that we just have like a great learning culture.

So, you know, we really support people learning new things, whether it's going to conferences or doing training or reading academic papers together. You see a lot of that kind of thing at Two Sigma. and, you know, I think we're very eager to take ideas from academia and sort of more cutting-edge ideas from the wider world and figure out how to apply them, which I think is a competitive advantage for us. So, you know, I think that, you know, if you're an engineer deciding between Google and 2-Sigma, you know, there's a lot of different things you're going to be deciding on. I actually would guess that one of the major things you're really deciding on, though, is do you want to work at a giant company or do you want to work at a small company, you know, right? Because if you want to work at a giant company, you know, giant companies have pluses and minuses, right? There's lots of different things you could do, but you are going to be a small fish in a very, very, very, very, very big pond. You know, whereas at 2 Sigma, you can, you know, you can make a difference, you know, even as a college graduate, you know, coming in to the company.

We're not so big that people don't make a big noticeable difference even early in their career if they, you know, find the right problem to solve. So I think that that's really the, that's the bigger difference, you know, than the 20% time concept or any of the rest of it. I'm curious how intense the competition is for engineers at the moment. So, you know, obviously there was a lot written about how. Banks were competing with the big tech firms to get the best talent, particularly around the time that Goldman announced that it was actually a tech firm. And there were all these stories about financial services firms putting in, you know, pool tables or ping pong tables, free lunches or whatever, to try to entice people that would normally go to some campus in Silicon Valley. Is that still the case? or is that starting to perhaps ease off of it?

I mean, I do, my impression is that the competition for engineers is still very hot. You know, people can, you compete with different people. So I don't, you know, we compete with big tech companies and other funds. We don't compete. My impression is not that we compete as much with Goldman. I do think that Goldman can say they're a tech company, but culturally, they are an investment bank. And for good and for bad,

I learned a lot in my time working at Goldman. I think Goldman has some really great aspects of their culture, but you do not spend 100 years as an investment bank and then say you're a tech company and become a tech company. That's just not just foundationally, like not the way it works. Like I actually sort of personally quite strongly believe that the founding culture of a company is very hard to shake. And so if you have a founding culture of engineers,

which Two Sigma does, right? So one of the co-founders of 2 Sigma is, you know, an engineer. I do think you've got a very strong technical culture built in from day zero. If you have a founding culture of bankers, it's going to be a different culture. And you can make it a good place for engineers to work. And there's, you know, lots to do and lots to learn. But it's going to feel different. And I think, you know, engineers are going to recognize and see that.

And so I, but the competition for engineers is definitely still quite hot, you know, between, you know, financial companies and tech companies and, you know, frankly, everything in between, right? Software is eating the world, as it were, and, you know, everybody needs technical talents to get ahead. I have like one more question sort of about the transition from a tech company to Sigma. I mean, obviously, I assume there's many things that are similar, you know, the sort of pure tech aspect of it. But I'm curious, like, and I guess, you know, you had, did have the financial experience at Goldman, but how much did going from tech to a financial services, a firm, or to a fund, require you to sort of learn the language of finance more?

And how challenging was that? I mean, I understand most of your work is working with other engineers, but in terms of, you know, the way people talk about analyzing time series and so forth, how did you approach that and how much of a challenge is that, being able to sort of meld the communication between tech people, engineers, versus the more purely finance side. It is a challenge. You know, I think one of the big challenges, frankly, for me at 2 Sigma is I'm not, I don't have a like huge heavy math background. And so there is, you know, even more than like Goldman, the math at 2 Sigma is intimidating to me, I will say. And, you know, you know, so I think a lot of, a lot of this is just learning the, the language of the company and how to,

how to speak to the language of the company. We like to talk about epilons and omegas. And, you know, it's like, okay, like sort of small steps and like big, you know, big ideas. Okay, I can, I can sort of translate that, right? I guess I find, especially for the role that I'm in now, a lot of what I really need to do, and a lot of what I really need to translate is really getting people to, out of the details of their area, again, whether it's my area details or the details of, you know, the need of some model or some of our engineering team into kind of the higher level problem that they're trying to solve. So helping, helping us all get to kind of the generalized common ground. I don't need to understand the math at a detailed level to understand that you need 10 times the data that you

used to need, right? I don't need to understand the details of, you know, dealing with prime brokers to understand that this team needs to be able to build systems that are going to iterate much faster and, you know, have, you know, have these characteristics because of the way that they need to pull data from the prime brokers. I don't know. Now, now I'm way. Now I'm well. way out of my depth. But, you know, so I think a lot of, a lot of my job, anywhere that it's been in leadership has been, how do I get everyone to speak on, to get to a common ground of, of talking about their problems at a high enough level that each can kind of appreciate it, without forcing everyone to know all of the, know and understand all the details. Because I do think that it's fun to

know the details sometimes. But a lot of times, engineers can get. lost in the details. And, you know, the details aren't the important thing, right? The important thing is kind of the narrative of how is the work that we're doing, making an impact on your day-to-day life, making your job easier, helping this company scale, helping this company grow, you know, get where it needs to go. And I think that's really, that's the most important thing that I do is help, is create and share narratives that almost anyone can understand. because, you know, I may need to talk to, you know, modelers. I may need to talk to people in legal.

I may need to talk to people in, you know, on the corporate side or in HR, right? And all of those folks need to understand the value that my team is bringing to the company. And I need to understand at the high level, their problems so that I can make sure that I'm meeting them. But again, you know, I don't need to necessarily understand all of the details of how they do their jobs to deliver the solutions. for the kinds of software that I need to build. I really enjoy it. I mean, it's such a sort of new area for us, for me and Tracy, and I think for probably most of our listeners.

So really appreciate you taking the time and walking us through your job and your career and the whole landscape, absolutely fascinating stuff. Well, yeah, thank you for having me on. It was fun. Thanks. That was great. Tracy, you know, like I said in the beginning, that was a conversation I've kind of wanted to have for a long time to talk about the sort of nuts and bolts of just how all this

works. And I found that really super interesting. Yeah, absolutely. And I'm trying to think about what to like focus on here because it was such a wide ranging conversation. But I did think the idea about banks sort of like create or financial services firms creating an open source culture and the evolution of that. I thought that was really. really interesting in this idea of being a good corporate citizen when it comes to producing open source software. That's such a, it's such a sea change to the way banks used to operate. And Camille was sort of giving a flavor of that with her description of her work at Goldman. And we're still only on the edges of it. But I'm interested to see how that goes. Because as you have

more financial companies that like to declare that they are, in fact, tech firms. and that our competitive edge also comes from tech, like does that spark a similar culture to what we see on the West Coast in Silicon Valley when it comes to open source? Or does that cause banks to sort of double down on being competitive and keeping their tech as a proprietary thing? Does that make sense? No, it makes a lot of sense.

I like your point that it's like in the end, like a company like Goldman, it's a bank. It's an investment bank. And maybe. Yeah. Maybe an engineering founded firm like 2 Sigma can genuinely have a tech culture. But I have to, I suspect she's right that for all of the protestations, Goldman, a firm like Goldman can never really be a tech firm. That would just be my guess.

Maybe we'll have someone from Goldman on at some point to make the countercase. I think both of us sort of had the thought at the same time of like there are some similarities between going from being an engineer to a manager to going from being a reporter to a journalist. And, you know, I think a lot of what she said really resonated with me, including that last bit about like the sort of the need to create a common language that everyone understands. And I see that all the time, like in a newsroom where you have different teams very focused on one thing. But the best managers within the newsroom are people that are. are very good at sort of essentially describing in plain English to everyone else in the newsroom that doesn't really know about this stuff, why what they're working on is interesting

so that there is some sort of level of, you know, uniform understanding about what the news, what's going on in the newsroom. Yeah. There's also the issue of creating a sort of language around the type of news product that you're offering. Like, because writing, you know, if I say to someone, oh, why don't you just write a quick and short story about this? Quick and short can mean different things to lots of different people. And so even just creating like an artificial term for what that might be, like creating this artificial structure that everyone can eventually recognize and come to understand. Yeah, there are a lot of parallels between engineering and journalism management apparently.

So I didn't expect that. And I feel like I'm going to have to go out and buy Camille's book now and read it and learn more about it. Yeah, no, I want to read it too, even. No, it's probably not for me per se. I mean, it's for tech. It definitely seems like it would be very useful. Or at least to see the same processes replicated elsewhere. I don't know.

I just really enjoyed that a lot. And I feel like I learned a ton in the last hour. Yeah, same. A bit different to the usual odd thoughts fair in a good way. All right. Shall we leave it there? Yeah, let's leave it there. Okay.

This has been another episode of the Odd Thoughts podcast. I'm Tracy Alloway. You can follow me on Twitter at Tracy Alloway. And I'm Joe Wisenthall. You can follow me on Twitter at the stalwart. Follow our guest on Twitter. Camille Fornier, her handle is at Skamele, S-K-A-M-I-L-L-E. And she is the author of The Manager's Path, a guide for tech leaders navigating growth and change, which I'm going to download to my Kindle ASAP. Follow our producer, Laura Carlson. She's at Laura M. Carlson. Follow the Bloomberg head of podcast, Francesca Levy, at Frenchieh, at French. Francesca today and check out all of our podcasts, said Bloomberg, under the handle, at podcasts. Thanks for listening. A lot of short daily news podcasts focus on just one story.

But right now, you probably need more. On Up First from NPR, we bring you three of the world's top headlines every day in under 15 minutes. Because no one's story can capture all that's happening in this big, crazy world of ours on any given morning. Listen now to the Up First podcast. from NPR.