Camille Fournier on Building Tech at Two Sigma

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. Yeah, absolutely, And you know, so we talked about theoretically, we talked 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 of data. We've never really liked talked about it from the bottoms up, like the actual process of using computers, using technology to uh to perform all these calculations and too in theory um 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 in stalling particular products or systems. I really have no idea what that looks like nowadays. No, I literally have 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, uh so to speak. But I really 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 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 against the likes of Google and Facebook and other startups and so on. But it raises the question of like, how similar differences and what how the too, how the to 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 Fourgnier. She is the managing director or a managing director head of platform engineering at two Sigma, which is a big financial services company. It has a hedge fund and also does VC stuff. Veryous sort of well known famous firm

in the space. Camille was previously the CTO at rent, the runway, the popular fat and I don't know how you describe it, but I guess you like people rent dresses onto temporary basis or rent clothes on temporary basis. And prior to that, Camille was at Goldman sach so has seen all of this from both sides, the tech hemisphere of all these services. 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, UM, before we get going, why don't you sort of give us the quick summary of your career. How did you get to be? Uh, your path to being the head of platform engineering at two Sigma. Sure, I have something I have. 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. UM went to graduate school at the University of Wisconsin. Um decided I didn't want to get a PhD. 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. UH. You know, went to Goldman UH 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 uh, you know, really massive risk analysis. UM. And then I also worked in similar kind of technology group to the one that I run today UM for a couple of years. UM. And then around two thousand and eleven, 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, UM. Even in New York. There were lots of interesting startups. And UM, I got approached by Rent the Runway and I had also not heard Rent the Runway until I I interviewed there, But of course they were very small, small startup at the time. UM, 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 shart business people. Right. The founders were just incredibly smart, you know, Harvard NBA's um PhDs with

operations to a starch backgrounds on the data side. So it was like they're really smart people in the in the leadership team, and the technology was a complete mess um, 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 the 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. Um. It was significantly more challenging to come in to a startup that's sort of in the growth stage and uh, 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 too. Because that's really a lot of the challenge in a in a startup is how fast can you iterate how fast can

you do new things? UM? 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 UM. You know, 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 it. I had

come to learn a lot. I had come to establish myself a little bit as as a leader in the in the industry. Frankly, I did want to have more of a public career than I was able to have it Goldman. At the time, Golden 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, UM. And then I decided that all right, I wanted to you know, being at the start ups exhausting. So I was like, all right, I'm gonna take a break I'm gonna 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. Was 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 talked to a bunch of company I talked to Google, I talked to a bunch of smaller startups and you know, if I'll be honest, When I was approached by two Sigma, UM, my first reaction was, I don't know. I had actually I know a lot of people who worked at two Sigma already, and my impression was actually that the company was really academic. I wasn't sure how well I would fit in in uh,

in a super academic culture. UM. 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, UM, really kind of getting back to my technical roots as you know, a large systems developer. It's really kind of the technology

area that I'm most interested in personally. UM. And it was a great, you know, great team I got to you know, I'm part of the engineering leadership team at two Stigma UM, and so you know, I took the job and you know, here we are today and it's been, uh, 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 gotta say, like I have used the runway and it's blown up a lot since then and pretty much UM. All of the women that you might ask about this probably no about it. UM. But when you moved from Goldman to Read the Runway, you mentioned that it was

more challenging than you had expected. Can you go into a little bit more detail on on why that was and what was the difference between either the technology that you were actually working on Goldman versus the technology and Rent the Runway, or maybe the differences in in the ways the companies actually operated and did things. There were

a few things. So first of all, like at 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 a sort of combined being very needing to move really really fast, right so needing to build new stuff really quickly. There are areas of Goldmen 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 seven, 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. Um, that

is not the case with consumer technology, right. The the expectation is if you're building a product, you're building you know, 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, two o'clock in the morning on the Sunday, you have

to do 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, open business open on Monday morning, but we've got some time, right, which is often the case in finance. Um, 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 when I came in. So I think that was

a big challenge. UM. And then there's just like a lot of technology pieces that you know, when you're building, um, 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 elements 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 doesn't need to be beautiful. Um. 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 you know, 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 availability, but also on you know, the actual way you decide what to build is really different. Um. And then you know,

look big company to small company. You know, obviously you've got a lot you don't even notice the things that are prepared provided for you in big companies like you O HR and training and i T and all of that stuff that's just kind of there and working and has been established over years and years you you have to establish it yourself at a small company, and that's fun, but it's a lot of work. So you mentioned between Rent the Runway and your current job, which will get

too 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 in your evolved a lot

during this time. My assumption would be that in the beginning, um, you were doing a lot more like hands on technical stuff. By the end, my guests 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 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 uh, managing engineers as opposed to building technology directly. Yeah, you're 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 gonna 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 you're not going to be focused, and then you're gonna 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. Um, you know,

you've got to make sure it actually works. You've got to actually get it running in in you know, two customers. Customers have to be actually using it, um and if it breaks, it has to be fixed. And so when managers who are really managing very large teams right 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 I've been an engineer with managers who have like throwing code at me that way, and it's it's really h 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

like your actual team because they'll probably get mad at you. Actually, um. 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 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 ageist 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 I'm not going to be taken seriously by the people that I'm managing anymore. And you know, that is a very so.

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, um, and you have to kind of get over that and figure out how to feel like you're still staying technically in the loop. UM. Incredible without you know, having you know,

writing code being your your main job. UM. So I think that was that was a huge transition for me, um and a huge transition for a lot of engineers. I think that's that's that's a huge one. And then I think, you know, there are a lot of them like 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 they 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 there, you know, you do want to promote people into management who are technically credible, um and you know, have good judgment, because that is part of your job as an engineering manager is sort of helping your team

make good decisions. But you uh, you definitely need to still be able to help them make those good decisions even as a team it'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 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, uh, you know, or whatever you're you're 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 gonna 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 designs. So how do you do that? Um And I think that is a similar challenge to a lot of people go through, and certainly that I 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 um. 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, um, it's hard to come up

with new ways of judging your performance. But the other thing that tends to happen in journalism is journalists, in 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 with that aspect of it? And and do you think that managers are 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.

I one of my friends and I sometimes refer to ourselves as punk managers because we're kind of both both a little bit punks and in various ways, you know, And I do think absolutely so. 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 um 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 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 gonna, 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 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 um, I don't know, you know, they're definitely not like anti authority necessarily, um,

but you're absolutely right that. For a long time that really, back when I started it round the runway, this was like really very popular, the idea that like managers are a waste. There are you know, again higher st 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 deadweight, 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 required large teams of people to build and maintain and evolve. Um 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 isn't that is a somewhat more modern evolution of software engineering, right, you know, thirty years ago or the early days of software engineering, lone wolves could do more

by themselves. Um, But as systems have grown and grown in complexity and they're more components and 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 for 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 UM 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 groups were 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 you're getting bad results out of that, right. Um. 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. Um. 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, we have too many managers and everyone wants to be a manager, and you know, we're wasting all this overhead on management, you know. So I'm just sort of waiting for that to 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 are just not efficient even small teams that startups, Like, it's really hard to run an efficient it's really hard to like build a multiperson product group effort if you don't have leadership and you know, if you know, you need someone who's willing to to do that. You know, both the good and the bad work though, right, you know, the fund work maybe if 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 that, like it makes their teams happier and more effective. So let's uh skip ahead, or let's skip to your current role.

UM introduced you, Managing director, Head of Platform Engineering at two Sigma. What is the head flaff engineering at Too Sigma? Do? Yeah, So I run the team that builds the software systems that anyone at Too Sigma who writes software themselves will use. So that could be other engineers or modelers. But we build things like our data storage products. Um, you know, you do all of our sort of public cloud work.

Um we build Uh, we build tools for software developers to you know, test their code and and execute their code. UM we build framework. So you know, really it's all of the all of the software that other people who write software use, is you know, foundational software is built by by min How different is an engineer at a financial services firms such as to Sigma to an engineer at a tech company or 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. Um. So, like in my team, we are actually have a lot of people. I mean to Sigma in general has like six of the staff is not from financial background financial company backgrounds, right, So so we definitely you know, to Sigma in general is like a very um diverse in terms of a former employer background

kind of company. Um. And my team is actually very heavily populated by people who have worked in the tech industry before coming to to Sigma because a lot of the products that we build are very much like it's very tech heavy. The team that I run. You would see similar kinds of teams at all kinds of big tech companies, UM, they would be much much larger than the team that I run. But you know, it's very

it's very kind of like UM transferable work. So I think that the some of the differences that i've I've noticed between engineers certainly at startups versus some somewhat larger

UM either tech or finance companies. I do think that you know that as you get larger or you know more that 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 is you're gonna 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 know everything about you know, this kind of deep

technical system or whatever, right, or you know they're they're much this. The skills that startups tend of value are much more about people who could 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 value to 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 we want 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 and Rent the Runway and that I've brought to my team at Sigma Up is that UM.

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 gonna want UM and figure out how to build things and how to know when if the feature or the product feature that you're building is actually something that people want UM. And that sort of product management skill set and acknowledge and even

engineers have to have it. So there is a there is a formal role called product manager exists, you know, most startups in most technopanies, and two Sigma has these folks as well. UM, 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 that knowledge of kind of knowing how to think about that has actually been really useful for me to bring to two Sigma because you know, we have customers for

my team. There are other people at two Sigma, UM, but they're not you know, we don't 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 means, and so it's really important that my team UM 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, I was that's sort of where I was gonna 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

a 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 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 they're always going to need, um, is just the demand for more you know, more data, uh, more data and

more computational power. And so my team, um, you know, my team doesn't do the actual data on boarding, right, So there's 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 fifteen petabytes a day of data.

So just to like contextualize that for your users, if you've got an iPhone with two fifty six gigs of storage, that's like sixty tho iPhones worth of storage that we're sort of serving in a day. UM. 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 machine learning algorithms are adopted, they have different kinds of data requirements UM, and data serving requirements that my team will need to be able

to to keep up with. Right. And you know, so I think there's always that a man for bigger and faster um you know, on the on the and and then on the compute computational capacity side, right Like you know, again, as as we get more data, we want to process it faster. You know, we want to run lots and lots and lots of experiments. Um. You know, we have workloads that peek at like half a million cores of processing.

So again that's like you know, your laptop might have sixteen 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. Um, 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 will understand this is we really have to work with our partners, both in engineering and modeling to hear about Okay, like you know, what's what's coming up next? Right? Okay, if we're moving to uh, 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 heavyweight requirements? You need access to GPU processors, right, you know, those those processors that are great for certain kinds of matrix math, and that's what um you know, okay deep learning really needs on GPUs, So my systems are going to need to support that. So I think that's that's one side of it, and then I think another side of it is just um you know, in the same way that if you're at a 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 um or opportunities 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 and and interrupting their their low 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 gonna 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 um. 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 makes them yeah, you know,

I will so. I do think that a lot of the advantage that engineers bring to companies like to Sigma is just our ability to build platforms, um to build platforms that can enable scale and productivity. I do think that's you know that and and being you know and then and I do think that that engineers also bring bring a degree of innovation with them, right. This is there's a reason that you know, companies do put 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 capable of writing code, but there they are innovators and they have you know, they can see ideas for how to do things that you know, you wouldn't necessarily predict as an 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 to Sigma.

I am not an expert in you know, the quantitative finance hedge fund industry. Um. I've only worked at two Sigma when it comes to you know, hedge funds and 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. Um. I do think scale matters, and 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 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 UM 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 too Sigma has really invested heavily in building out platforms UM. Not just in my team, but you know even in our our model or tools from modelers, right.

We try to think about that is building a platform of tools that are modelers can use, it all work together, you know, some companies of my impression is that there are companies where, like you know, practically like every desk will have its own sort of engineering team in 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 ship, but you cannot turn quickly, right, Whereas if you're in a speedboat you can reactually 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 UM. And so I do think that you know, platforms have a lot of advantage and 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. 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, well, 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, of the existing technology, evaluating what what aspect of capacity is actually worth investing in, because presumably it's a very very costly time money also with uncertain uncertain returns. Yeah, so I have 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 attect 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 ten times faster or whatever, right, Um, 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 to decompose it into Okay, actually, you know these are very similar things, and we need to solve for this pattern. Um. But another approach that I like to do is sometimes you're not 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 a partner of the team, and build out some

kind of proof of concept. You know, where you're you're investing enough to get something built, but you're not committing to turning it into like a big platform system. Um. And you know what you do. When when you do that, it's like, first of all, you learn, uh, you learn about the problem more and 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 gonna be a platform team we've you know, we've partnered with you, but you're gonna this is your 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 that is this is a very much you know, something that I've taken from startup life right where it's you know, how can I how can I learn quickly

where I should be going? And sometimes the best way to learn quickly is so just to build something that isn't the ideal, um, you know, big in system, but that if we launch it with a partner, will 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 we're 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 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 um. Actually, you know, 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, and you know, 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 UM and I do think that's changed dramatically in the last ten years. So two Sigma dos a ton of open source UM. We both contribute to big popular open source projects like pandas UM. We also open source

some of our own software. UM. 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 concern about I P and what is going to give our you know, competitors and advantage if we open source versus you know, what helps helps with our brand in the industry, right, you know, because open source is good partly because it helps you recruit engineers. Engineers tend to like companies that do open source.

You know. 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 you know, because everyone uses open source, and open source is expensive to keep up for the open source maintainers, right, you know, 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 going 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's 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 um. 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 of this great mathematical algorithmic trick, Like you don't really want that getting out there um

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 thing and getting to work on your own projects and I and they still have all those other like 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 I had had a fund that a hedge fund, I can't imagine that there is a 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 product tized and so forth.

And so I'm curious like about like, is that how much of it different that is internally at a place like two Sigma versus a large established tech company like a Google or Facebook or Microsoft. So I think, look, I think that that UM to Sigma definitely has I mean people doing technical research. We have a labs team UM, and we do try to provide room for people to explore ideas, which again, as I said, innovation you know,

comes from surprising places and engineering. And you know, while Google is not always particularly efficient probably in the way it allocates its engineers, at least to an outsider, UM, you know that that it does come 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. UM. And so I do think that at least at Too Sigma, we 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, eight hundred 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. You know, I do think too, Sam 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 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 two 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 and a very very very very very big pond,

you know, whereas at two sigma you can you know, you can make a difference, you know, even as a college graduate, you know, coming into the company. We're not so big that people don't make a big noticeable difference even early in their career, um, if they find the right problem to solved. So I think that that's really the that's the bigger difference, um, you know, than the than the time concept or any any of the rest of it. Um. 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 are all these stories about financial services firms putting in uh, you know, pool tables or ping pong tables and 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 um perhaps ease off of it. I mean, I do. My impression is that that the the competition for engineers is still very hot. You know, people, can you compete with different people? So I don't. I 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 stay there a tech company, but uh, culturally they are an investment bank, um 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 a hundred 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 two Sigma is, you know, an engineer. Um, 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 gonna 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, software is eating the world, as it were, and you know,

everybody needs technical talents to to get ahead. Like one more question sort of about the transition from a tech company to two Sigma. I mean, obviously, I assume there's a many things that are similar, um, you know, the sort of pure tech aspect of it. But I'm curiously and I guess you know, you had did have the financial experience, Ed Goldman, But how much did going from tech to a financial services firm or to a fund require you to sort of learn the language of finance more?

And how challenging was that? I mean, I 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 uh finance side, It is

a challenge. Um, you know, I think one of the big challenges frankly for me at two 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 two Sigma is intimidating to me, I will say. And you know, so I think a lot of a lot of this is just learning the language of the company and how to how to speak to the language of the company. We like to talk about Epsilon's and Omega's 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 some modeler or some of our engineering team into kind of the the

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 necessary. I don't need to understand the math at a detailed level to understand that you need ten times the data that you used to need, right, I don't need to understand, um, the details of you know, dealing with prime brokers to understand that this team needs to be able to build systems are going to iterate much faster and you know, have you know, have these characteristics because of the way that they need to pull

the different prime reverse. I don't know now now I'm way way out of my depth, but you know so, 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 to get to a common ground of of talking about their problems at a high enough level that each can kind of appreciate it um without forcing everyone to know all of the known

I'll understand all the details. So 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. UM. And I think that's that's really that's the most important thing that I do is help is create and and 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 mean need to talk to people in you know, uh, you know, in the on the corporate side or an HR right uh and and all of those folks need to understand the value that

my team is bringing UM to the company. And I need to understand that at the high level of their problems, UM, 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. 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 at really 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 like talk about the sort of nuts and bolts of just how all of this works. And

I found that really super interesting. Yeah. Absolutely, And um, 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 creating or financial services firms creating um an open source culture and the evolution of that. I thought that was 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 with her description of her work at Goldman UM. 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 they're competitive, edge also comes from tech, Like does that 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? Now? It

makes a lot of sense. I like her point. That's like, in the end, like a company like Goldman, it's a bank, it's an investment bank. And maybe maybe UH an engineering founded firm like two Sigma can genuinely have a tech culture. But I have to I suspect she's right that for all of the Protestations Goldman affirm like Goldman can never really be a tech firm. That would just be my guests. Maybe maybe we'll have someone from Goldman on at some

point to make the counter case. 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, um, a lot of what she said really resonated with me, including that last bit about like the sort of the uh 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 very good at sort of essentially describing in plain English to everyone else in the news room that doesn't really know about this stuff, why what they're working on is interesting, so that there's some sort of level of um, you know, uniform understanding about what the news, what's going

on in the news room. 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, um, 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. I want to read it too, even though it's probably not for me per se, I'm for tech. It definitely seems like, um, it will be very useful. It's but or at least to see the same processes

replicated elsbere I 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 All 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 All Thoughts podcast. I'm Tracy Alloway. You can follow me on Twitter at Tracy Alloway and I'm Joe wisn't Thal. You can follow me on Twitter at the Stalwart. Follow our guest on Twitter,

Camille Fournier. Her handle is at scamill 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. UH. Follow our producer Laura Carlson. She's at Laura M. Carlson. Follow the Bloomberg head of podcast, Francesca Levi at Francesca Today, and check out all of our podcast said Bloomberg under the handle ad podcast. Thanks for listening.