Speaker 1: Hello, and welcome to another episode of the Odd Lots Podcast.
Speaker 1: I'm Joe Wisn't Thal and I'm Tracy all Away. So, Tracy,
Speaker 1: you know, we've had a number of episodes, um, not
Speaker 1: that many, but certainly a handful of them. One of
Speaker 1: our themes is like quantitative finance quant stuff. We always
Speaker 1: sort of talk about it from a sort of very
Speaker 1: big theoretical level, like what's happening with different factors, alpha decay,
Speaker 1: stuff like that always sort of like tends to be
Speaker 1: at the sort of big picture abstraction level. I would say, yeah,
Speaker 1: I think that's right. We talk a lot about the
Speaker 1: future of quantitative finance. What's most important, I guess when
Speaker 1: it comes to running a successful quant strategy, like whether
Speaker 1: it's the actual formula or program that you're using, or
Speaker 1: whether it's something like the data set that you're using.
Speaker 1: We've discussed all of those. Yeah, absolutely, And you know,
Speaker 1: so we talked about theoretically, we talked about it academically,
Speaker 1: but one thing that we haven't really discussed is you know,
Speaker 1: when you like think about quantitative finance, you think about
Speaker 1: lots of really smart people, mathematicians, people using computers to
Speaker 1: find data, to analyze huge amounts of data. We've never
Speaker 1: really liked talked about it from the bottoms up, like
Speaker 1: the actual process of using computers, using technology to uh
Speaker 1: to perform all these calculations and too in theory um
Speaker 1: beat the market. Yeah, I think that's right. And I'm
Speaker 1: going to go ahead and admit that I don't know
Speaker 1: that much about engineering in the financial industry. We can
Speaker 1: talk a lot about what gives a competitive edge when
Speaker 1: it comes to quant strategies, but a competitive edge when
Speaker 1: it comes to engineering when it comes to in stalling
Speaker 1: particular products or systems. I really have no idea what
Speaker 1: that looks like nowadays. No, I literally have have no idea.
Speaker 1: But it's kind of, you know, it's this huge whole
Speaker 1: component of it, and every financial firm, whether it's a
Speaker 1: major bank, whether it's a fund, want to advertise their
Speaker 1: tech stack, their tech advantage, uh so to speak. But
Speaker 1: I really I don't really know much about the actual
Speaker 1: process of like building that tech and how you build
Speaker 1: a competitive edge from that tech. And Yeah, it's like
Speaker 1: it's a whole sort of facet of this that I
Speaker 1: don't think we've I don't think most people know very
Speaker 1: much about. Yeah, and I'm also interested in knowing whether
Speaker 1: the culture of being an engineer at a financial company
Speaker 1: is different to the culture of being say a trader
Speaker 1: or a banker at a financial company. And I'm definitely
Speaker 1: interested in knowing whether or not the culture of being
Speaker 1: an engineer at a financial company is different to being
Speaker 1: an engineer at say Google or Apple or something like that. Right,
Speaker 1: I'm extremely curious about this as well, because again, it's
Speaker 1: like one of these things where in theory more and
Speaker 1: more financial institutions would like to be competitive for talent
Speaker 1: against the likes of Google and Facebook and other startups
Speaker 1: and so on. But it raises the question of like,
Speaker 1: how similar differences and what how the too, how the
Speaker 1: to compare? Yeah, absolutely, this is going to be a
Speaker 1: fun episode, I can tell. Yeah. I'm super excited about
Speaker 1: this one. This is a conversation I've wanted to have
Speaker 1: for a long time. Today, our guest is Camille Fourgnier.
Speaker 1: She is the managing director or a managing director head
Speaker 1: of platform engineering at two Sigma, which is a big
Speaker 1: financial services company. It has a hedge fund and also
Speaker 1: does VC stuff. Veryous sort of well known famous firm
Speaker 1: in the space. Camille was previously the CTO at rent,
Speaker 1: the runway, the popular fat and I don't know how
Speaker 1: you describe it, but I guess you like people rent
Speaker 1: dresses onto temporary basis or rent clothes on temporary basis.
Speaker 1: And prior to that, Camille was at Goldman sach so
Speaker 1: has seen all of this from both sides, the tech
Speaker 1: hemisphere of all these services. So Camille, thank you very
Speaker 1: much for joining us. Yeah, thank you for having me
Speaker 1: excited to be here. Yeah, I'm really looking forward to this. So, UM,
Speaker 1: before we get going, why don't you sort of give
Speaker 1: us the quick summary of your career. How did you
Speaker 1: get to be? Uh, your path to being the head
Speaker 1: of platform engineering at two Sigma. Sure, I have something
Speaker 1: I have. I guess I have a fairly standard educational background.
Speaker 1: So I have a computer science degree from Carnegie Mellon.
Speaker 1: For my undergraduate degree, I worked at Microsoft for a
Speaker 1: hot second. UM went to graduate school at the University
Speaker 1: of Wisconsin. Um decided I didn't want to get a PhD.
Speaker 1: I did want to live in New York City, and
Speaker 1: so ended up getting a job at this company that
Speaker 1: I had literally never heard of until I interviewed there,
Speaker 1: called Goldman Sachs, which I'm sure will be very amusing
Speaker 1: to your listeners. UH. You know, went to Goldman UH
Speaker 1: and was there for about six and a half years.
Speaker 1: And I worked in risk technology for a long time,
Speaker 1: which was actually like really awesome area to work in,
Speaker 1: building a lot of really big scaled systems to do uh,
Speaker 1: you know, really massive risk analysis. UM. And then I
Speaker 1: also worked in similar kind of technology group to the
Speaker 1: one that I run today UM for a couple of years. UM.
Speaker 1: And then around two thousand and eleven, I decided that,
Speaker 1: you know, I wasn't quite ready to be settled down
Speaker 1: and like making a career at a giant company like Goldman,
Speaker 1: and I wanted to try something new. And the startup
Speaker 1: world was really, you know, getting to be very hot,
Speaker 1: very popular, UM. Even in New York. There were lots
Speaker 1: of interesting startups. And UM, I got approached by Rent
Speaker 1: the Runway and I had also not heard Rent the
Speaker 1: Runway until I I interviewed there, But of course they
Speaker 1: were very small, small startup at the time. UM, and
Speaker 1: I was just so blown away by the product idea.
Speaker 1: It was one of those things where every time I
Speaker 1: described the product to another woman, she immediately understood what
Speaker 1: I was talking about when it comes to consumer facing startups,
Speaker 1: that's really such an important sign of a good idea
Speaker 1: is just how fast your potential customer gets it. So
Speaker 1: I was like, all right, like this company seems like
Speaker 1: it has really shart business people. Right. The founders were
Speaker 1: just incredibly smart, you know, Harvard NBA's um PhDs with
Speaker 1: operations to a starch backgrounds on the data side. So
Speaker 1: it was like they're really smart people in the in
Speaker 1: the leadership team, and the technology was a complete mess um,
Speaker 1: And so I was like, great, I'm a great engineer
Speaker 1: and I want to like, you know, become a leader.
Speaker 1: So this is a great opportunity for me to you know,
Speaker 1: join this company and the fixing the tech will be
Speaker 1: easy and you know this is going to be a
Speaker 1: slam dunk, and of course life never works out that way. Um.
Speaker 1: It was significantly more challenging to come in to a
Speaker 1: startup that's sort of in the growth stage and uh,
Speaker 1: you know, both do a lot of work to really
Speaker 1: turn the technology around and make it really stable and
Speaker 1: scalable and easy to add new stuff too. Because that's
Speaker 1: really a lot of the challenge in a in a
Speaker 1: startup is how fast can you iterate how fast can
Speaker 1: you do new things? UM? And it's also just that
Speaker 1: was a you know, a massively challenging learning experience to
Speaker 1: learn how to become a manager and an executive and
Speaker 1: a leader. But I did that. I did that for
Speaker 1: four years. So I became the CTO UM. You know,
Speaker 1: I was there for about four years, and it was
Speaker 1: a really it was an amazing, amazing learning experience. You know.
Speaker 1: After after four years, I sort of felt like I
Speaker 1: had done what I came to do it. I had
Speaker 1: come to learn a lot. I had come to establish
Speaker 1: myself a little bit as as a leader in the
Speaker 1: in the industry. Frankly, I did want to have more
Speaker 1: of a public career than I was able to have
Speaker 1: it Goldman. At the time, Golden was still very secretive.
Speaker 1: They didn't really want you, you know, out there in
Speaker 1: public talking about your work. And I like talking about
Speaker 1: my work. I like sharing my ideas. You know. I
Speaker 1: learned a lot about being a leader. I grew the team,
Speaker 1: I stabilized the technology, UM. And then I decided that
Speaker 1: all right, I wanted to you know, being at the
Speaker 1: start ups exhausting. So I was like, all right, I'm
Speaker 1: gonna take a break I'm gonna think about starting my
Speaker 1: own company. I actually wrote a book about engineering management
Speaker 1: in the year and a half that I was doing
Speaker 1: various things. Was how I like to describe it. And
Speaker 1: then I was like, all right, you know what I'm
Speaker 1: this me starting a startup by myself is not working
Speaker 1: out because I don't have any great ideas and you know,
Speaker 1: maybe this is not the right thing for me to
Speaker 1: be doing right now. So I was like, Okay, I
Speaker 1: need a job. And I got approached by two Sigma.
Speaker 1: You know, I would talked to a bunch of company
Speaker 1: I talked to Google, I talked to a bunch of
Speaker 1: smaller startups and you know, if I'll be honest, When
Speaker 1: I was approached by two Sigma, UM, my first reaction was,
Speaker 1: I don't know. I had actually I know a lot
Speaker 1: of people who worked at two Sigma already, and my
Speaker 1: impression was actually that the company was really academic. I
Speaker 1: wasn't sure how well I would fit in in uh,
Speaker 1: in a super academic culture. UM. But I went and
Speaker 1: interviewed and I was actually blown away by just how
Speaker 1: smart and nice everyone was, and you know, the role
Speaker 1: that they wanted me to come in to run their
Speaker 1: platform engineering organization was a really interesting role, UM, really
Speaker 1: kind of getting back to my technical roots as you know,
Speaker 1: a large systems developer. It's really kind of the technology
Speaker 1: area that I'm most interested in personally. UM. And it
Speaker 1: was a great, you know, great team I got to
Speaker 1: you know, I'm part of the engineering leadership team at
Speaker 1: two Stigma UM, and so you know, I took the
Speaker 1: job and you know, here we are today and it's been, uh,
Speaker 1: you know, it's been really a great experience so far.
Speaker 1: I've been there for almost four years now. So you
Speaker 1: mentioned when you moved from Goldman to Rent the Runway,
Speaker 1: which was a startup at the time and has really
Speaker 1: I gotta say, like I have used the runway and
Speaker 1: it's blown up a lot since then and pretty much UM.
Speaker 1: All of the women that you might ask about this
Speaker 1: probably no about it. UM. But when you moved from
Speaker 1: Goldman to Read the Runway, you mentioned that it was
Speaker 1: more challenging than you had expected. Can you go into
Speaker 1: a little bit more detail on on why that was
Speaker 1: and what was the difference between either the technology that
Speaker 1: you were actually working on Goldman versus the technology and
Speaker 1: Rent the Runway, or maybe the differences in in the
Speaker 1: ways the companies actually operated and did things. There were
Speaker 1: a few things. So first of all, like at at Goldman,
Speaker 1: certainly at the time, and the areas that I was in,
Speaker 1: I was just not used to working in, So I
Speaker 1: was not used to working in an environment a sort
Speaker 1: of combined being very needing to move really really fast,
Speaker 1: right so needing to build new stuff really quickly. There
Speaker 1: are areas of Goldmen that are like this, but that
Speaker 1: wasn't really where I was working and having really high
Speaker 1: sort of uptime requirements. So I think one of the
Speaker 1: interesting things about the difference between a lot of parts
Speaker 1: of finance and consumer technology is that it is still
Speaker 1: possible in a lot of parts of finance to work
Speaker 1: on systems that actually don't have to be up seven,
Speaker 1: meaning that they don't run on the weekend sometimes right
Speaker 1: like you know, the markets are closed, so the system
Speaker 1: doesn't actually need to be running for example. Um, that
Speaker 1: is not the case with consumer technology, right. The the
Speaker 1: expectation is if you're building a product, you're building you know,
Speaker 1: a website or an app or whatever that you know
Speaker 1: consumers are going to use, then it's going to be
Speaker 1: available when they want to use it. And that is
Speaker 1: actually a really big technical difference because it really does
Speaker 1: mean that you know, if something goes wrong on you know,
Speaker 1: two o'clock in the morning on the Sunday, you have
Speaker 1: to do deal with it. Someone has to deal with it, right.
Speaker 1: It can't just like leave it until, you know sometime
Speaker 1: when you're more wide awake and all right, like we've
Speaker 1: got to get this ready for you know, open business
Speaker 1: open on Monday morning, but we've got some time, right,
Speaker 1: which is often the case in finance. Um, that's really
Speaker 1: not the case in consumer. And so I think that
Speaker 1: is actually a really big different kind of challenge that
Speaker 1: you know, I wasn't totally thinking about, I think when
Speaker 1: I when I came in. So I think that was
Speaker 1: a big challenge. UM. And then there's just like a
Speaker 1: lot of technology pieces that you know, when you're building, um,
Speaker 1: when you're building for consumers, particularly frankly in fashion, where
Speaker 1: things need to look and feel good right in the
Speaker 1: technology there's a you know, there's sort of a spit
Speaker 1: and polish and you know, branding and elements to everything
Speaker 1: that you're building that you know a lot of times
Speaker 1: in finance, you know you're building an interface for you know,
Speaker 1: a trader or you know, a risk analyst or whatever.
Speaker 1: It just needs to work. It doesn't need to be beautiful. Um. So,
Speaker 1: you know, really having to think much much more about
Speaker 1: you know, the customer who isn't sitting you know, in
Speaker 1: the desk next to you telling you exactly what they need.
Speaker 1: You know, because the customer is you know, thousands and
Speaker 1: tens of thousands of women all over the country who
Speaker 1: you know, each has kind of different preferences, right, so
Speaker 1: how do you figure out what to build for them?
Speaker 1: How do you you know, how do you build something
Speaker 1: great without necessarily having you know, the person telling you
Speaker 1: exactly what it is that they want built. Those are
Speaker 1: some of the challenges just on the kind of technical
Speaker 1: side that it was really a very different kind of
Speaker 1: both you know, some of the technical challenges on availability,
Speaker 1: but also on you know, the actual way you decide
Speaker 1: what to build is really different. Um. And then you know,
Speaker 1: look big company to small company. You know, obviously you've
Speaker 1: got a lot you don't even notice the things that
Speaker 1: are prepared provided for you in big companies like you
Speaker 1: O HR and training and i T and all of
Speaker 1: that stuff that's just kind of there and working and
Speaker 1: has been established over years and years you you have
Speaker 1: to establish it yourself at a small company, and that's fun,
Speaker 1: but it's a lot of work. So you mentioned between
Speaker 1: Rent the Runway and your current job, which will get
Speaker 1: too soon. You did write this book, and I meant
Speaker 1: to plug it in the beginning, and I'll plug it
Speaker 1: at the end. But the Manager's Path a guide for
Speaker 1: tech leaders navigating growth and change. And so I have
Speaker 1: to imagine like during that time, like coming to Rent
Speaker 1: the Runway when it was a small startup and then
Speaker 1: leaving when it was this household name. I have to
Speaker 1: imagine that like your role in your evolved a lot
Speaker 1: during this time. My assumption would be that in the beginning, um,
Speaker 1: you were doing a lot more like hands on technical stuff.
Speaker 1: By the end, my guests would be a lot more management.
Speaker 1: And per your book, I imagined that that's a really
Speaker 1: tough progression for a lot of people. And engineering and
Speaker 1: management they're very different jobs. It's kind of like in
Speaker 1: our industry, like being a journalist and being sorry, being
Speaker 1: a reporter and being an editor. They're very different jobs,
Speaker 1: even though a lot of people go on that trajectory. Now,
Speaker 1: I guess this is you know, this is a book
Speaker 1: length topic. But for you like sort of like what
Speaker 1: are the big pain points that people experience or that
Speaker 1: you experienced on that journey to actually sort of uh,
Speaker 1: managing engineers as opposed to building technology directly. Yeah, you're
Speaker 1: you're absolutely right that it is a book length topic.
Speaker 1: But I think some of the highlights are in the
Speaker 1: early days you can still sort of manage and write
Speaker 1: code or you know, be kind of somewhat hands on
Speaker 1: for a while, but as your team grows, you start
Speaker 1: to you have to consciously like ease off and pick
Speaker 1: out what you're going to work on if you're gonna
Speaker 1: be hands on. And then at some point you just
Speaker 1: can't be hands on anymore, right, you can't. You know,
Speaker 1: you cannot really be writing production quality software if you're
Speaker 1: in meetings six to eight hours a day because you're
Speaker 1: you're not going to be focused, and then you're gonna
Speaker 1: be working. You know, maybe you're writing that code at
Speaker 1: night after your day is done. But you know, in
Speaker 1: engineering teams, right, you don't just like write code and
Speaker 1: then it's done. You write code, someone has to review it,
Speaker 1: tell you whether it's good or not. Um, you know,
Speaker 1: you've got to make sure it actually works. You've got
Speaker 1: to actually get it running in in you know, two customers.
Speaker 1: Customers have to be actually using it, um and if
Speaker 1: it breaks, it has to be fixed. And so when
Speaker 1: managers who are really managing very large teams right code,
Speaker 1: they may be able to do the writing part, but
Speaker 1: they often can't do the rest of those parts. And
Speaker 1: that's actually really frustrating as an engineer. I've been I've
Speaker 1: been an engineer with managers who have like throwing code
Speaker 1: at me that way, and it's it's really h it's
Speaker 1: really frustrating to experience that. So, you know, I really
Speaker 1: strongly advise you know, managers, once they get to a
Speaker 1: certain point, to stop doing that. Stop writing code, right,
Speaker 1: that's not really your job. You can do it as
Speaker 1: a hobby on the weekends, but don't do it for
Speaker 1: like your actual team because they'll probably get mad at you. Actually, um.
Speaker 1: But that transition is so painful because as engineers, we're
Speaker 1: taught for years and years and years that our value
Speaker 1: is in the software that we create. That like, that
Speaker 1: is what we are rewarded for, is you know, writing
Speaker 1: good software, building good systems and being clever and fixing
Speaker 1: you know, fixing hard bugs and being being smart about
Speaker 1: that thing, and it really feels very it's very scary
Speaker 1: to stop doing it. Um. You know, also because everyone
Speaker 1: tells you, you know, and there's just kind of you know,
Speaker 1: tech is a very ageist industry, right, and there's this
Speaker 1: great sense of like, if I stop writing code, you know,
Speaker 1: I'm immediately on the path to obsolescence and my technical
Speaker 1: knowledge is going to fade and I'm not going I'm
Speaker 1: not going to be taken seriously by the people that
Speaker 1: I'm managing anymore. And you know, that is a very so.
Speaker 1: So it's like you've got all these cultural messages that
Speaker 1: are like your value is in software, but you can't
Speaker 1: really do your job well if you're writing a lot
Speaker 1: of software as a manager of a large team, um,
Speaker 1: and you have to kind of get over that and
Speaker 1: figure out how to feel like you're still staying technically
Speaker 1: in the loop. UM. Incredible without you know, having you know,
Speaker 1: writing code being your your main job. UM. So I
Speaker 1: think that was that was a huge transition for me,
Speaker 1: um and a huge transition for a lot of engineers.
Speaker 1: I think that's that's that's a huge one. And then
Speaker 1: I think, you know, there are a lot of them
Speaker 1: like as your team gets larger, you also have to
Speaker 1: you have to develop the skill of helping your your
Speaker 1: organization make good technical decisions without knowing every single detail
Speaker 1: of what they're doing. And that's sort of a it's
Speaker 1: sort of a similar challenge but a little bit different. Right,
Speaker 1: So when you're actually again writing the code, reading the code,
Speaker 1: very much in the details of the work you and
Speaker 1: you're probably an expert if you've been you know, you're
Speaker 1: getting into management, you've been doing this for a long time.
Speaker 1: You know, generally speaking, people they get promoted into management
Speaker 1: do tend to be viewed as technically credible by their teams.
Speaker 1: You know, I don't think you should always just promote
Speaker 1: the best engineers as managers because they're the best engineers
Speaker 1: they might actually like writing code. But you know, sometimes
Speaker 1: right like there, you know, you do want to promote
Speaker 1: people into management who are technically credible, um and you know,
Speaker 1: have good judgment, because that is part of your job
Speaker 1: as an engineering manager is sort of helping your team
Speaker 1: make good decisions. But you uh, you definitely need to
Speaker 1: still be able to help them make those good decisions
Speaker 1: even as a team it's larger and larger, and you
Speaker 1: get farther away from the details of the problems, and
Speaker 1: so I think that's the other really challenging transition that
Speaker 1: a lot of managers go through and that I certainly
Speaker 1: went through, which was like, how do you, like, how
Speaker 1: do you get the right information and get sort of
Speaker 1: about what's going on in a team that's maybe you know,
Speaker 1: you don't even you're managing the manager of their manager, uh,
Speaker 1: you know, or whatever you're you're you're like several management
Speaker 1: layers away from it, but you kind of need to know, oh,
Speaker 1: something's going wrong here, because if it goes too wrong,
Speaker 1: it could affect, you know, the ability for your whole
Speaker 1: organization to get stuff done right, or it could affect
Speaker 1: it's gonna make you look bad because something is late
Speaker 1: or it's broken, or you know, it's constantly falling over.
Speaker 1: And so you have to still be able to influence
Speaker 1: their technical decisions, but without actually like looking through their
Speaker 1: code and reading it and actually knowing all the details
Speaker 1: of their systems designs. So how do you do that?
Speaker 1: Um And I think that is a similar challenge to
Speaker 1: a lot of people go through, and certainly that I
Speaker 1: that I went through. And so those are those are
Speaker 1: some of the challenges that I talk about in my book,
Speaker 1: among many others. So I may be projecting here, but
Speaker 1: I see a lot of parallels between the the engineering
Speaker 1: profession and how it um. Sorry, let me rephrase that.
Speaker 1: So I may be projecting a little bit here, but
Speaker 1: I feel like there are quite a few parallels between
Speaker 1: journalists who transition from reporters to editors or some other
Speaker 1: sort of management job in journalism and engineers who do
Speaker 1: something similar. You know, journalists are judged by their output,
Speaker 1: the quality and maybe sometimes the quantity of the stories
Speaker 1: they produce, and once you move into an editing role
Speaker 1: or a management role, um, it's hard to come up
Speaker 1: with new ways of judging your performance. But the other
Speaker 1: thing that tends to happen in journalism is journalists, in particular,
Speaker 1: reporters are competitive people who often have an anti authority streak,
Speaker 1: like they like calling authority up on the decisions that
Speaker 1: they're making, and therefore sometimes they do not make the
Speaker 1: greatest managers. So one thing I'm wondering is in tech
Speaker 1: it's kind of similar, right, you have a lot of
Speaker 1: competitive people who want to move fast and break things.
Speaker 1: And I think there, at least for a long time,
Speaker 1: there was this culture of management being bad and that
Speaker 1: you should have fewer managers, you should just hire good
Speaker 1: people and let them do their own thing. How did
Speaker 1: you deal with with that aspect of it? And and
Speaker 1: do you think that managers are are more widely accepted
Speaker 1: in tech as a lot of the players get bigger. Oh, yes,
Speaker 1: this is a this is a very very interesting area.
Speaker 1: I one of my friends and I sometimes refer to
Speaker 1: ourselves as punk managers because we're kind of both both
Speaker 1: a little bit punks and in various ways, you know,
Speaker 1: And I do think absolutely so. Actually think tech is
Speaker 1: sort of interesting. There are definitely the sort of anti
Speaker 1: authority types of which I'm sort of one in some ways,
Speaker 1: right um where you know, I mean, part of the
Speaker 1: reason that I ended up getting into management is that
Speaker 1: I looked around and I was like, look, I think
Speaker 1: I can make better decisions than other people. I think
Speaker 1: I can, you know, I think I think I make
Speaker 1: good decisions. I think I make better decisions on the whole.
Speaker 1: I think I'm you know, going to do a better
Speaker 1: job of treating people well and you know, creating healthy,
Speaker 1: healthy organizations. But I mean also i think I'm gonna, like,
Speaker 1: you know, I think we're going to be more successful
Speaker 1: under me because I've you know, I've got what it takes, right.
Speaker 1: I do think there is some of that, But there
Speaker 1: are actually plenty of people in tech who are you know,
Speaker 1: very rule abiding thoughtful. I mean, look, tech, part of
Speaker 1: part of being an engineer, being a really good engineer,
Speaker 1: is actually like learning the rules of the systems really well. Right.
Speaker 1: You're you're sort of writing very very very precise rules
Speaker 1: into you know, into software as you write software, right,
Speaker 1: And so there are actually plenty of people in tech
Speaker 1: who I think are are you know, our rule abiding
Speaker 1: and quite quite willing to kind of um, I don't know,
Speaker 1: you know, they're definitely not like anti authority necessarily, um,
Speaker 1: but you're absolutely right that. For a long time that really,
Speaker 1: back when I started it round the runway, this was
Speaker 1: like really very popular, the idea that like managers are
Speaker 1: a waste. There are you know, again higher st front
Speaker 1: people and get out of their way and let them,
Speaker 1: you know, and they'll just figure it out. And you know,
Speaker 1: managers are deadweight, right. Both engineers and like vcs would
Speaker 1: say this, right. Frankly, part of the reason I started
Speaker 1: blogging about management and ended up writing the book was that.
Speaker 1: I just thought that was so so ridiculous because it's
Speaker 1: so obvious to me that, look, modern engineering is is
Speaker 1: building very complex systems that required large teams of people
Speaker 1: to build and maintain and evolve. Um it is a
Speaker 1: team sport, is what a lot of people say, right,
Speaker 1: And I think that's true. I don't think that you know,
Speaker 1: that isn't that is a somewhat more modern evolution of
Speaker 1: software engineering, right, you know, thirty years ago or the
Speaker 1: early days of software engineering, lone wolves could do more
Speaker 1: by themselves. Um, But as systems have grown and grown
Speaker 1: in complexity and they're more components and more things that
Speaker 1: need to be done, it's just much harder to build
Speaker 1: you know, a really interesting and compelling product, as you know,
Speaker 1: a lone wolf for as a team of like sort
Speaker 1: of individuals just working on their own stuff. And so
Speaker 1: I do think that when you need that really like
Speaker 1: team based coordination UM to go really well, you do
Speaker 1: need capable management to help with that. You know, you
Speaker 1: need the coach, You need the person who is you know,
Speaker 1: observing everything that's happening and making sure that you're covering
Speaker 1: all the pieces that need to be covered, making sure
Speaker 1: that the groups were well together, because you know, when
Speaker 1: the group isn't working well together, they're not as productive,
Speaker 1: they're not as happy. You know, you get a lot
Speaker 1: of conflict, you get a lot of you know, you're
Speaker 1: just you're you're getting bad results out of that, right. Um.
Speaker 1: You're not going to get the greatest creativity out of
Speaker 1: the overall group when they're you know, when they're not
Speaker 1: collaborating well. Right. Um. And so I do think that
Speaker 1: you know that there was I just, in my opinion, frankly,
Speaker 1: like kind of a you know, legacy attitude about management
Speaker 1: that I think, for the most part, has gone away,
Speaker 1: although I'm always waiting for the backlash to happen. You know, inevitably,
Speaker 1: there will be a backlash and people will be like,
Speaker 1: oh my god, we have too many managers and everyone
Speaker 1: wants to be a manager, and you know, we're wasting
Speaker 1: all this overhead on management, you know. So I'm just
Speaker 1: sort of waiting for that to to drop personally. But
Speaker 1: I do like, I think that management. I do think
Speaker 1: that management became more accepted even at startups in tech
Speaker 1: because a lot of people were suffering from the lack
Speaker 1: of it. A lot of teams are just not efficient
Speaker 1: even small teams that startups, Like, it's really hard to
Speaker 1: run an efficient it's really hard to like build a
Speaker 1: multiperson product group effort if you don't have leadership and
Speaker 1: you know, if you know, you need someone who's willing
Speaker 1: to to do that. You know, both the good and
Speaker 1: the bad work though, right, you know, the fund work
Speaker 1: maybe if sometimes you get to you know, you get
Speaker 1: to be the final decision maker on some stuff, maybe, right.
Speaker 1: But the grunt work of like, actually you have to
Speaker 1: kind of influence a lot of people, and you know,
Speaker 1: you have to deal with a lot of conflict, and
Speaker 1: you have to you know, have hard conversations, and so
Speaker 1: you know, I do think that management has become more
Speaker 1: popular in tech, not just because the big tech companies
Speaker 1: have grown up, but actually because everyone has just realized that,
Speaker 1: like it makes their teams happier and more effective. So
Speaker 1: let's uh skip ahead, or let's skip to your current role.
Speaker 1: UM introduced you, Managing director, Head of Platform Engineering at
Speaker 1: two Sigma. What is the head flaff engineering at Too Sigma? Do? Yeah,
Speaker 1: So I run the team that builds the software systems
Speaker 1: that anyone at Too Sigma who writes software themselves will use.
Speaker 1: So that could be other engineers or modelers. But we
Speaker 1: build things like our data storage products. Um, you know,
Speaker 1: you do all of our sort of public cloud work.
Speaker 1: Um we build Uh, we build tools for software developers
Speaker 1: to you know, test their code and and execute their code.
Speaker 1: UM we build framework. So you know, really it's all
Speaker 1: of the all of the software that other people who
Speaker 1: write software use, is you know, foundational software is built
Speaker 1: by by min How different is an engineer at a
Speaker 1: financial services firms such as to Sigma to an engineer
Speaker 1: at a tech company or or some sort of startup,
Speaker 1: Like does it take a different skill set or does
Speaker 1: it take a different personality? I think that depends a
Speaker 1: little bit. Um. So, like in my team, we are
Speaker 1: actually have a lot of people. I mean to Sigma
Speaker 1: in general has like six of the staff is not
Speaker 1: from financial background financial company backgrounds, right, So so we
Speaker 1: definitely you know, to Sigma in general is like a
Speaker 1: very um diverse in terms of a former employer background
Speaker 1: kind of company. Um. And my team is actually very
Speaker 1: heavily populated by people who have worked in the tech
Speaker 1: industry before coming to to Sigma because a lot of
Speaker 1: the products that we build are very much like it's
Speaker 1: very tech heavy. The team that I run. You would
Speaker 1: see similar kinds of teams at all kinds of big
Speaker 1: tech companies, UM, they would be much much larger than
Speaker 1: the team that I run. But you know, it's very
Speaker 1: it's very kind of like UM transferable work. So I
Speaker 1: think that the some of the differences that i've I've
Speaker 1: noticed between engineers certainly at startups versus some somewhat larger
Speaker 1: UM either tech or finance companies. I do think that
Speaker 1: you know that as you get larger or you know
Speaker 1: more that you can you can hire more specialists and
Speaker 1: more depth experts, and so I do think that what
Speaker 1: you'll see if you look at a startup is you're
Speaker 1: gonna see a lot more generalists, and you'll see engineers
Speaker 1: who are not necessarily the best engineer in terms of
Speaker 1: like real like sort of deep expertise and you know
Speaker 1: they know everything about you know, this kind of deep
Speaker 1: technical system or whatever, right, or you know they're they're
Speaker 1: much this. The skills that startups tend of value are
Speaker 1: much more about people who could just be like, all right,
Speaker 1: like how quickly can I get through this problem and
Speaker 1: onto the next thing? And that is not that is
Speaker 1: value to UM at big companies to some extent, but
Speaker 1: I think big companies tend to have more time to
Speaker 1: spend on solving problems, and so they'd rather spend the
Speaker 1: time to solve a problem right or more right than
Speaker 1: to just get it, you know, get something out there,
Speaker 1: and we want to the next thing. So I think
Speaker 1: that's that is a difference. I also actually think one
Speaker 1: of the one of the really one of the things
Speaker 1: that I learned and Rent the Runway and that I've
Speaker 1: brought to my team at Sigma Up is that UM.
Speaker 1: You know, as I mentioned I think a little earlier,
Speaker 1: one of the big things that you have to do
Speaker 1: to be successful at a startup, particularly like a consumer
Speaker 1: facing startup like Rent the Runway is really understand and
Speaker 1: figure out what your customer is gonna want UM and
Speaker 1: figure out how to build things and how to know
Speaker 1: when if the feature or the product feature that you're
Speaker 1: building is actually something that people want UM. And that
Speaker 1: sort of product management skill set and acknowledge and even
Speaker 1: engineers have to have it. So there is a there
Speaker 1: is a formal role called product manager exists, you know,
Speaker 1: most startups in most technopanies, and two Sigma has these
Speaker 1: folks as well. UM, But you know, when you're at
Speaker 1: a startup, even the engineers are kind of expected to
Speaker 1: understand and sort of have that customer empathy and that
Speaker 1: that knowledge of kind of knowing how to think about
Speaker 1: that has actually been really useful for me to bring
Speaker 1: to two Sigma because you know, we have customers for
Speaker 1: my team. There are other people at two Sigma, UM,
Speaker 1: but they're not you know, we don't we don't have
Speaker 1: you know, a trading desk telling us to build X,
Speaker 1: Y or Z. Right, We've got you know, hundreds of
Speaker 1: people that use our software and they all have slightly
Speaker 1: different means, and so it's really important that my team
Speaker 1: UM be able to hear lots of different pieces of
Speaker 1: feedback and sort of generalize that into Okay, where do
Speaker 1: we actually need to go with the products that we're building,
Speaker 1: so that we're building something that's great for other people
Speaker 1: to use, it's easy for them to use, it makes
Speaker 1: them productive, and it kind of anticipates the future needs
Speaker 1: of this business. So yeah, I mean, I was that's
Speaker 1: sort of where I was gonna go next. I mean,
Speaker 1: when you describe figuring out the needs of rent the runway,
Speaker 1: you're talking about tens of thousands of women around the
Speaker 1: country and how they might want to search and have
Speaker 1: a article of clothing shipped to them. Describe a little
Speaker 1: bit more that process when it's internal, when it's at
Speaker 1: a financial services company. What are the types of things
Speaker 1: that your your clients, your customers, your internal customers are
Speaker 1: looking for. What do they need, what kind of problems
Speaker 1: are they trying to solve, and what are they looking
Speaker 1: to you specifically to build for them or to help
Speaker 1: them build so that they can do their job more effectively. Yeah, So,
Speaker 1: I mean, look, one of the big problems that they
Speaker 1: they're always going to need, um, is just the demand
Speaker 1: for more you know, more data, uh, more data and
Speaker 1: more computational power. And so my team, um, you know,
Speaker 1: my team doesn't do the actual data on boarding, right,
Speaker 1: So there's there's a data engineering team that's really responsible
Speaker 1: for that part of things, but my team owns the
Speaker 1: storage systems, right and you know, recently, right we were
Speaker 1: serving we've been serving like fifteen petabytes a day of data.
Speaker 1: So just to like contextualize that for your users, if
Speaker 1: you've got an iPhone with two fifty six gigs of storage,
Speaker 1: that's like sixty tho iPhones worth of storage that we're
Speaker 1: sort of serving in a day. UM. So you know,
Speaker 1: we have these really massive amounts of data and there's
Speaker 1: always demand for you know, I want more data, I
Speaker 1: want it faster, I need it. You know, I need
Speaker 1: to be able to access this data in particular ways
Speaker 1: because you know, like I'm looking across a time series
Speaker 1: of data and trying to you know, detect changes or
Speaker 1: what have you. And so you know, and as we
Speaker 1: you know, as new kinds of machine learning algorithms are adopted,
Speaker 1: they have different kinds of data requirements UM, and data
Speaker 1: serving requirements that my team will need to be able
Speaker 1: to to keep up with. Right. And you know, so
Speaker 1: I think there's always that a man for bigger and
Speaker 1: faster um you know, on the on the and and
Speaker 1: then on the compute computational capacity side, right Like you know, again,
Speaker 1: as as we get more data, we want to process
Speaker 1: it faster. You know, we want to run lots and
Speaker 1: lots and lots of experiments. Um. You know, we have
Speaker 1: workloads that peek at like half a million cores of processing.
Speaker 1: So again that's like you know, your laptop might have
Speaker 1: sixteen cores if you've got like a really hefty laptop,
Speaker 1: so you know, huge huge volumes of computational processing, and
Speaker 1: to do that requires pretty complex systems under the covers
Speaker 1: to actually you know, coordinate all of that work. Um,
Speaker 1: you know, enable people to sort of submit work to
Speaker 1: these systems to run and get results. You know. The
Speaker 1: way that my team will will understand this is we
Speaker 1: really have to work with our partners, both in engineering
Speaker 1: and modeling to hear about Okay, like you know, what's
Speaker 1: what's coming up next? Right? Okay, if we're moving to uh,
Speaker 1: you know, if we're moving to doing a lot more
Speaker 1: deep learning in this area, what is that going to
Speaker 1: mean for the platform? Right? What? Okay? You know, what
Speaker 1: does what are the real heavyweight requirements? You need access
Speaker 1: to GPU processors, right, you know, those those processors that
Speaker 1: are great for certain kinds of matrix math, and that's
Speaker 1: what um you know, okay deep learning really needs on GPUs,
Speaker 1: So my systems are going to need to support that.
Speaker 1: So I think that's that's one side of it, and
Speaker 1: then I think another side of it is just um
Speaker 1: you know, in the same way that if you're at
Speaker 1: a at a business serving external customers where you can't
Speaker 1: just talk to each customer individually. You want to look
Speaker 1: actually at the data about how people are using your
Speaker 1: product and detect trends um or opportunities for improvements. Right, So,
Speaker 1: if you're looking at the data about the way people
Speaker 1: are using your systems and you see that like a
Speaker 1: particular very commonly run command is really slow, you can
Speaker 1: sort of accept that that actually is probably slowing people
Speaker 1: down and and and interrupting their their low and their creativity.
Speaker 1: And that's an opportunity where if we could make that
Speaker 1: commonly used command faster in some way, they're going to
Speaker 1: be more productive. They're going to be you know, happier
Speaker 1: because it's just gonna be a lot easier for them
Speaker 1: to get their work done. Right. So, those are some
Speaker 1: of the ways that we kind of approach trying to
Speaker 1: figure out what to build. So presumably making the core
Speaker 1: systems faster and able to process larger amounts of data
Speaker 1: like that is how engineering contributes to a competitive edge
Speaker 1: for two sigma um. First of all, is that correct?
Speaker 1: And then secondly, if that's true, does that mean that
Speaker 1: does that mean as as quant shops kind of get
Speaker 1: bigger and faster, that scale matters much much more than
Speaker 1: it used to, and does that mean that the competitive
Speaker 1: advantage is always going to lie with the biggest firms
Speaker 1: with the most resources. Does that makes them yeah, you know,
Speaker 1: I will so. I do think that a lot of
Speaker 1: the advantage that engineers bring to companies like to Sigma
Speaker 1: is just our ability to build platforms, um to build
Speaker 1: platforms that can enable scale and productivity. I do think
Speaker 1: that's you know that and and being you know and
Speaker 1: then and I do think that that engineers also bring
Speaker 1: bring a degree of innovation with them, right. This is
Speaker 1: there's a reason that you know, companies do put put
Speaker 1: a premium on really great engineers. And you know, it's
Speaker 1: not just because like the skill set is rare, because
Speaker 1: more and more people are learning how to write code,
Speaker 1: and you know, I think it is becoming it's not
Speaker 1: as hard as it once was to write code. But
Speaker 1: I think the best engineers are not only capable of
Speaker 1: writing code, but there they are innovators and they have
Speaker 1: you know, they can see ideas for how to do
Speaker 1: things that you know, you wouldn't necessarily predict as an
Speaker 1: as an outsider, even as an outsider who is an
Speaker 1: engineer but not deep in the details of a particular area,
Speaker 1: I think It's an interesting question as to whether scale
Speaker 1: is always a competitive advantage for companies like to Sigma.
Speaker 1: I am not an expert in you know, the quantitative
Speaker 1: finance hedge fund industry. Um. I've only worked at two
Speaker 1: Sigma when it comes to you know, hedge funds and
Speaker 1: and so I don't have a ton of you know, experience.
Speaker 1: More broadly, I mean, I do think though that you know,
Speaker 1: you do see scale. Um. I do think scale matters,
Speaker 1: and scale matters in a lot of ways in these businesses.
Speaker 1: I mean, look, I think scale matters in your ability
Speaker 1: to get good costs and trading right, which is, you know,
Speaker 1: get get your costs down in those areas, get your
Speaker 1: lending costs down. But I do think that scale from
Speaker 1: a from a technology point of view, it will matter
Speaker 1: if the way, you know, if the way to find
Speaker 1: good valuable ideas comes from processing larger and larger and
Speaker 1: larger sets of data. Yes, scale is always going to
Speaker 1: be a competitive advantage. Now, if you can find ways
Speaker 1: of getting good ideas that don't require processing massive amounts
Speaker 1: of data UM or you know, don't require running really
Speaker 1: large computational experiments to determine, then you know, scale is
Speaker 1: not necessarily an advantage, and scale certainly comes with its downsides, right,
Speaker 1: So I think too Sigma has really invested heavily in
Speaker 1: building out platforms UM. Not just in my team, but
Speaker 1: you know even in our our model or tools from modelers, right.
Speaker 1: We try to think about that is building a platform
Speaker 1: of tools that are modelers can use, it all work together,
Speaker 1: you know, some companies of my impression is that there
Speaker 1: are companies where, like you know, practically like every desk
Speaker 1: will have its own sort of engineering team in its
Speaker 1: own set of tools. And those are two very different approaches,
Speaker 1: and they have pros and cons. I think that the
Speaker 1: platform approach, you can you can do bigger things, right.
Speaker 1: It's sort of like comparing like a cruise ship or
Speaker 1: a you know, a big container ship with like a speedboat. Right,
Speaker 1: so like you know, you can go a lot farther
Speaker 1: and you can do a lot more and can carry
Speaker 1: a lot more in a big ship, but you cannot
Speaker 1: turn quickly, right, Whereas if you're in a speedboat you
Speaker 1: can reactually really really really fast. You just can't. You know,
Speaker 1: you've got sort of a limited amount that you can
Speaker 1: actually do with that UM. And so I do think
Speaker 1: that you know, platforms have a lot of advantage and
Speaker 1: this ability to scale and this you know, investment in
Speaker 1: being able to scale does give you a lot of
Speaker 1: advantages in terms of, you know, the scope of things
Speaker 1: you can do, but it does have downsides in that
Speaker 1: you have to invest a lot of technology and time
Speaker 1: and effort into being able to do that in the
Speaker 1: first place, and that means that changing your approach becomes
Speaker 1: somewhat more expensive. So I'm curious about the evaluation process
Speaker 1: of new endeavors. So presumably anyone who is you know,
Speaker 1: doing trying to build some sort of machine learning AI
Speaker 1: trading system would always like more data and faster access
Speaker 1: to the data and so forth. But you or the
Speaker 1: engineers have to evaluate, I presume like, okay, well, what's
Speaker 1: a worthy investment and does this really make sense to
Speaker 1: build out this capacity and will it really deliver adequate returns?
Speaker 1: How do you think about those kinds of problems when
Speaker 1: a team comes to you with some sort of need
Speaker 1: or with some sort of when they're bumping up against
Speaker 1: the limitations of the existing platform, of the existing technology,
Speaker 1: evaluating what what aspect of capacity is actually worth investing in,
Speaker 1: because presumably it's a very very costly time money also
Speaker 1: with uncertain uncertain returns. Yeah, so I have have sort
Speaker 1: of two different approaches. So one of them is that,
Speaker 1: of course, if you see a pattern of people coming
Speaker 1: to you, or you can attect a pattern of requests,
Speaker 1: you should probably build it. Because now you're seeing, all right,
Speaker 1: like I've seen several different people are thinking about problems
Speaker 1: that if we had a solution that served time series
Speaker 1: data ten times faster or whatever, right, Um, we would
Speaker 1: be killing a lot of birds with that stone, right.
Speaker 1: And so definitely part of the job is looking for
Speaker 1: those patterns and knowing what people are working on and
Speaker 1: being able to to decompose it into Okay, actually, you
Speaker 1: know these are very similar things, and we need to
Speaker 1: solve for this pattern. Um. But another approach that I
Speaker 1: like to do is sometimes you're not sure, and so
Speaker 1: the best approach is to partner with the team, particularly
Speaker 1: if it's coming from an engineering team that's requesting something.
Speaker 1: Is a partner of the team, and build out some
Speaker 1: kind of proof of concept. You know, where you're you're
Speaker 1: investing enough to get something built, but you're not committing
Speaker 1: to turning it into like a big platform system. Um.
Speaker 1: And you know what you do. When when you do that,
Speaker 1: it's like, first of all, you learn, uh, you learn
Speaker 1: about the problem more and more and a really more
Speaker 1: like specific way. And then if you build this sort
Speaker 1: of proof of concept for a team and nobody else
Speaker 1: sees it and says, oh, I really want that too,
Speaker 1: or this is super useful. I can see how I
Speaker 1: could use something like this in my area. Then you
Speaker 1: can say, okay, you know what like this isn't gonna
Speaker 1: be a platform team we've you know, we've partnered with you,
Speaker 1: but you're gonna this is your your thing now, so
Speaker 1: take it, run with it, you know, use it for
Speaker 1: your small area, but we're not going to extend it
Speaker 1: to be something generalized. But sometimes you build out that
Speaker 1: proof of concept and you do see people asking for
Speaker 1: well maybe not quite that thing, but something that looks
Speaker 1: sort of similar, and it gives you a much clearer
Speaker 1: idea of what the actual need is. And again I
Speaker 1: think that is this is a very much you know,
Speaker 1: something that I've taken from startup life right where it's
Speaker 1: you know, how can I how can I learn quickly
Speaker 1: where I should be going? And sometimes the best way
Speaker 1: to learn quickly is so just to build something that
Speaker 1: isn't the ideal, um, you know, big in system, but
Speaker 1: that if we launch it with a partner, will learn
Speaker 1: a lot about the area and whether or not it's
Speaker 1: worth investing in. So I have a slightly weird question,
Speaker 1: which is how do financial services firms feel about open
Speaker 1: source software nowadays? Because I remember, I guess five or
Speaker 1: six years ago when I was writing about Wall Street,
Speaker 1: I remember there were one or two banks that we're
Speaker 1: trying to make an open source push because they thought
Speaker 1: it could make everything more efficient and cut down on costs.
Speaker 1: And there's a lot of cost pressure at the banks
Speaker 1: after the financial crisis. But it was sort of an
Speaker 1: uphill battle for them because most of the banks were
Speaker 1: pretty competitive, and I guess they thought all their technology
Speaker 1: was very proprietary and they didn't really want to share.
Speaker 1: Has has that changed at all? Is there more cooperation
Speaker 1: across the financial industry when it comes to software. There's
Speaker 1: certainly a lot more open source um. Actually, you know,
Speaker 1: one of the reasons that I left Goldman was that
Speaker 1: I actually was working in open source there and I
Speaker 1: felt like it was such an uphill battle to be
Speaker 1: allowed to work an open source at the time. I
Speaker 1: think they've changed that process quite a bit, and you know,
Speaker 1: in recent years. But you know, when I was there,
Speaker 1: it was like, well, we'll let you do this because
Speaker 1: we like you and we trust you. But it wasn't
Speaker 1: sort of a generalized process that lots of people could
Speaker 1: do UM and I do think that's changed dramatically in
Speaker 1: the last ten years. So two Sigma dos a ton
Speaker 1: of open source UM. We both contribute to big popular
Speaker 1: open source projects like pandas UM. We also open source
Speaker 1: some of our own software. UM. So I definitely think
Speaker 1: that you're seeing a lot more open source in the
Speaker 1: financial industry now, it's still you know, it's still different,
Speaker 1: I think than the tech industry in that you know,
Speaker 1: it's still a bit more bureaucratic probably to to you know,
Speaker 1: create open source. There is certainly concern about I P
Speaker 1: and what is going to give our you know, competitors
Speaker 1: and advantage if we open source versus you know, what
Speaker 1: helps helps with our brand in the industry, right, you know,
Speaker 1: because open source is good partly because it helps you
Speaker 1: recruit engineers. Engineers tend to like companies that do open source.
Speaker 1: You know. In my opinion, I think it's just like
Speaker 1: it shows that you're a good corporate citizen when you
Speaker 1: contribute to open source, and you you know, because everyone
Speaker 1: uses open source, and open source is expensive to keep
Speaker 1: up for the open source maintainers, right, you know, a
Speaker 1: lot of them are volunteers. And so when you look
Speaker 1: at a company and you see that they you know,
Speaker 1: they use open source, because every company that does software
Speaker 1: is using open source, but they absolutely do not contribute
Speaker 1: back to it, you think, Okay, this company isn't going
Speaker 1: corporate citizen in that way. What does that mean for
Speaker 1: the rest of the way that they think about, you know, engineering?
Speaker 1: So I do think that you know, savvy companies realize
Speaker 1: that preventing their engineers from contributing to open source is
Speaker 1: actually bad branding in a lot of ways. But there's
Speaker 1: still certainly is that concern of Okay, how do we
Speaker 1: make sure that engineers are not accidentally leaking something that
Speaker 1: is in fact really like proprietary and valuable um. And
Speaker 1: I do think, you know, that's going to be a
Speaker 1: concern probably forever, given that there are you know, algorithms
Speaker 1: and pieces of code in finance that really are quite
Speaker 1: valuable in and of themselves, right, And so you know,
Speaker 1: when you can you can do something significantly faster than
Speaker 1: your competitor because you've thought of this great mathematical algorithmic trick,
Speaker 1: Like you don't really want that getting out there um
Speaker 1: to the wider world accidentally leaked as a piece of
Speaker 1: open source software. You know, I'm curious. I mean, at
Speaker 1: the beginning you mentioned two Sigma's reputation as being kind
Speaker 1: of academic. But I'm thinking, like from the perspective of
Speaker 1: an engineer, like maybe thinking about going to a place
Speaker 1: like two Sigma versus going to a place like Google.
Speaker 1: I mean, like I don't know if Google still has it,
Speaker 1: but of course they used to be famous for like
Speaker 1: the thing and getting to work on your own projects
Speaker 1: and I and they still have all those other like
Speaker 1: side bets, which are just a bunch of businesses that
Speaker 1: lose money. And I also have to imagine that even
Speaker 1: in the core Google, there's probably a lot of people
Speaker 1: working on things that don't make money and are never
Speaker 1: expected to make money. And they're just a bunch of people,
Speaker 1: I don't know, eating the lunches and working on their
Speaker 1: projects and stuff. But I had had a fund that
Speaker 1: a hedge fund, I can't imagine that there is a
Speaker 1: much space for that kind of thing where it just
Speaker 1: sort of like intellectual explorations or long pursuits of things
Speaker 1: that may never get monetized or product tized and so forth.
Speaker 1: And so I'm curious like about like, is that how
Speaker 1: much of it different that is internally at a place
Speaker 1: like two Sigma versus a large established tech company like
Speaker 1: a Google or Facebook or Microsoft. So I think, look,
Speaker 1: I think that that UM to Sigma definitely has I
Speaker 1: mean people doing technical research. We have a labs team UM,
Speaker 1: and we do try to provide room for people to
Speaker 1: explore ideas, which again, as I said, innovation you know,
Speaker 1: comes from surprising places and engineering. And you know, while
Speaker 1: Google is not always particularly efficient probably in the way
Speaker 1: it allocates its engineers, at least to an outsider, UM,
Speaker 1: you know that that it does come a place of
Speaker 1: recognition that like engineers, when left to their own devices
Speaker 1: and but given clear you know, ideas, maybe clear problem statements,
Speaker 1: will innovate in surprising ways. UM. And so I do
Speaker 1: think that at least at Too Sigma, we we try
Speaker 1: to do a reasonable job of balancing, like being very
Speaker 1: pragmatic and focused on we've got to ship things for
Speaker 1: this business, right Obviously, you know, we're not a huge
Speaker 1: company or you know, eight hundred some engineers, so it's
Speaker 1: not like, you know, we have infinite resources to do whatever,
Speaker 1: but being culturally aligned with that desire of engineers to
Speaker 1: have a little bit of freedom to explore and innovate
Speaker 1: and you know, try new things. You know, I do
Speaker 1: think too, Sam actually does a pretty good job of that,
Speaker 1: partly by the fact that we just have like a
Speaker 1: great learning culture, so you know, we really support people
Speaker 1: learning new things, whether it's going to conferences or doing
Speaker 1: training or reading academic papers together. You see a lot
Speaker 1: of that kind of thing at two Sigma, and I
Speaker 1: think we're very eager to take ideas from academia and
Speaker 1: sort of more cutting edge ideas from the wider world
Speaker 1: and figure out how to apply them, which I think
Speaker 1: is a competitive advantage for us. So, you know, I
Speaker 1: think that you know, if you're an engineer deciding between
Speaker 1: Google and two Sigma, you know, there's a lot of
Speaker 1: different things you're going to be deciding on. I actually
Speaker 1: would guess that one of the major things you're really
Speaker 1: deciding on, though, is do you want to work at
Speaker 1: a giant company or do you want to work at
Speaker 1: a small company, you know, right, because if you want
Speaker 1: to work at a giant company, you know, giant companies
Speaker 1: have pluses and minuses, right, There's lots of different things
Speaker 1: you could do, but you are going to be a
Speaker 1: small fish and a very very very very very big pond,
Speaker 1: you know, whereas at two sigma you can you know,
Speaker 1: you can make a difference, you know, even as a
Speaker 1: college graduate, you know, coming into the company. We're not
Speaker 1: so big that people don't make a big noticeable difference
Speaker 1: even early in their career, um, if they find the
Speaker 1: right problem to solved. So I think that that's really
Speaker 1: the that's the bigger difference, um, you know, than the
Speaker 1: than the time concept or any any of the rest
Speaker 1: of it. Um. I'm curious how intense the competition is
Speaker 1: for engineers at the moment. So, you know, obviously there
Speaker 1: was a lot written about how banks were competing with
Speaker 1: the big tech firms to get the best talent, particularly
Speaker 1: around the time that Goldman announced that it was actually
Speaker 1: a tech firm. And there are all these stories about
Speaker 1: financial services firms putting in uh, you know, pool tables
Speaker 1: or ping pong tables and free lunches or whatever to
Speaker 1: try to entice people that would normally go to some
Speaker 1: campus in Silicon Valley. Is that still the case or
Speaker 1: is that starting to um perhaps ease off of it.
Speaker 1: I mean, I do. My impression is that that the
Speaker 1: the competition for engineers is still very hot. You know, people,
Speaker 1: can you compete with different people? So I don't. I
Speaker 1: you know, we compete with big tech companies and other funds.
Speaker 1: We don't compete. My impression is not that we compete
Speaker 1: as much with Goldman. I do think that Goldman can
Speaker 1: stay there a tech company, but uh, culturally they are
Speaker 1: an investment bank, um and for good and for bad.
Speaker 1: I learned a lot in my time working at Goldman.
Speaker 1: I think Goldman has some really great aspects of their culture.
Speaker 1: But you do not spend a hundred years as an
Speaker 1: investment bank and then say you're a tech company and
Speaker 1: become a tech company. That's just not just foundationally, like,
Speaker 1: not the way it works like. I actually sort of personally,
Speaker 1: quite strongly believe that the founding culture of a company
Speaker 1: is very hard to shake. And so if you have
Speaker 1: a founding culture of engineers, which two Sigma does, right.
Speaker 1: So one of the co founders of two Sigma is,
Speaker 1: you know, an engineer. Um, I do think you've got
Speaker 1: a very strong technical culture built in from day zero.
Speaker 1: If you have a founding culture of bankers, it's going
Speaker 1: to be a different culture. And you can make it
Speaker 1: a good place for engineers to work. And there's you know,
Speaker 1: lots to do and lots to learn, but it's going
Speaker 1: to feel different. And I think you know, engineers are
Speaker 1: gonna are going to recognize and see that, and so
Speaker 1: I but the competition for engineers is definitely still quite hot,
Speaker 1: you know, between you know, financial companies and tech companies
Speaker 1: and you know, frankly everything in between. Right software, software
Speaker 1: is eating the world, as it were, and you know,
Speaker 1: everybody needs technical talents to to get ahead. Like one
Speaker 1: more question sort of about the transition from a tech
Speaker 1: company to two Sigma. I mean, obviously, I assume there's
Speaker 1: a many things that are similar, um, you know, the
Speaker 1: sort of pure tech aspect of it. But I'm curiously
Speaker 1: and I guess you know, you had did have the
Speaker 1: financial experience, Ed Goldman, But how much did going from
Speaker 1: tech to a financial services firm or to a fund
Speaker 1: require you to sort of learn the language of finance more?
Speaker 1: And how challenging was that? I mean, I I understand
Speaker 1: most of your work is working with other engineers, but
Speaker 1: in terms of you know, the way people talk about
Speaker 1: analyzing time series and so forth, how did you approach
Speaker 1: that And how much of a challenge is that Being
Speaker 1: able to sort of meld the communication between tech people
Speaker 1: engineers versus the more purely uh finance side, It is
Speaker 1: a challenge. Um, you know, I think one of the
Speaker 1: big challenges frankly for me at two Sigma is I'm
Speaker 1: not I don't have a like huge heavy math background,
Speaker 1: and so there is you know, even more than like Goldman,
Speaker 1: the math at two Sigma is intimidating to me, I
Speaker 1: will say. And you know, so I think a lot
Speaker 1: of a lot of this is just learning the language
Speaker 1: of the company and how to how to speak to
Speaker 1: the language of the company. We like to talk about
Speaker 1: Epsilon's and Omega's and you know it's like, okay, like
Speaker 1: sort of small steps and like big you know, big ideas. Okay,
Speaker 1: I can I can sort of translate that, right, I
Speaker 1: guess I find, especially for the role that I'm in now,
Speaker 1: a lot of what I really need to do and
Speaker 1: a lot of what I really need to translate is
Speaker 1: really getting people to out of the details of their
Speaker 1: area again, whether it's my area details or the details
Speaker 1: of you know, the need of some some modeler or
Speaker 1: some of our engineering team into kind of the the
Speaker 1: the higher level problem that they're trying to solve. So
Speaker 1: helping helping us all get to kind of the generalized
Speaker 1: common ground. I don't necessary. I don't need to understand
Speaker 1: the math at a detailed level to understand that you
Speaker 1: need ten times the data that you used to need, right,
Speaker 1: I don't need to understand, um, the details of you know,
Speaker 1: dealing with prime brokers to understand that this team needs
Speaker 1: to be able to build systems are going to iterate
Speaker 1: much faster and you know, have you know, have these
Speaker 1: characteristics because of the way that they need to pull
Speaker 1: the different prime reverse. I don't know now now I'm
Speaker 1: way way out of my depth, but you know so,
Speaker 1: so I think a lot of a lot of my
Speaker 1: job anywhere that it's been in leadership, has been how
Speaker 1: do I get everyone to speak to get to a
Speaker 1: common ground of of talking about their problems at a
Speaker 1: high enough level that each can kind of appreciate it
Speaker 1: um without forcing everyone to know all of the known
Speaker 1: I'll understand all the details. So I do think that
Speaker 1: it's fun to know the details sometimes, but a lot
Speaker 1: of times engineers can get lost in the details, and
Speaker 1: you know, the details aren't the important thing, right, The
Speaker 1: important thing is kind of the narrative of how is
Speaker 1: the work that we're doing making an impact on your
Speaker 1: day to day life, making your job easier, helping this
Speaker 1: company scale, helping this company grow, you know, get where
Speaker 1: it needs to go. UM. And I think that's that's
Speaker 1: really that's the most important thing that I do is
Speaker 1: help is create and and and share narratives that almost
Speaker 1: anyone can understand, because you know, I may need to
Speaker 1: talk to you know, modelers, I may need to talk
Speaker 1: to people in legal I mean need to talk to
Speaker 1: people in you know, uh, you know, in the on
Speaker 1: the corporate side or an HR right uh and and
Speaker 1: all of those folks need to understand the value that
Speaker 1: my team is bringing UM to the company. And I
Speaker 1: need to understand that at the high level of their problems, UM,
Speaker 1: so that I can make sure that I'm meeting them.
Speaker 1: But again, you know, I don't need to necessarily understand
Speaker 1: all of the details of how they do their jobs
Speaker 1: to deliver the solutions for the kinds of software that
Speaker 1: I need to build. I really enjoy. I mean, it's
Speaker 1: such a sort of new area for us, for me
Speaker 1: and Tracy, and I think for probably most of our listeners.
Speaker 1: So really appreciate you taking the time and walking us
Speaker 1: through your job and your career and the whole landscape
Speaker 1: at really absolutely fascinating stuff. Well, yeah, thank you for
Speaker 1: having me on. It was fun. Thanks, that was great, Tracy.
Speaker 1: You know, like I said in the beginning, that was
Speaker 1: a conversation I've kind of wanted to have for a
Speaker 1: long time to like talk about the sort of nuts
Speaker 1: and bolts of just how all of this works. And
Speaker 1: I found that really super interesting. Yeah. Absolutely, And um,
Speaker 1: I'm trying to think about what to like focus on
Speaker 1: here because it was such a wide ranging conversation. But
Speaker 1: I did think the idea about banks sort of like
Speaker 1: creating or financial services firms creating um an open source
Speaker 1: culture and the evolution of that. I thought that was
Speaker 1: really interesting. In this idea of being a good corporate
Speaker 1: citizen when it comes to producing open source software, that's
Speaker 1: such a it's such a sea change to the way
Speaker 1: banks used to operate. And Camille was sort of giving
Speaker 1: a flavor of that with with her description of her
Speaker 1: work at Goldman UM. And we're still only on the
Speaker 1: edges of it. But I'm interested to see how that goes,
Speaker 1: because as you have more financial companies that like to
Speaker 1: declare that they are in fact tech firms and that
Speaker 1: they're competitive, edge also comes from tech, Like does that
Speaker 1: does that spark a similar culture to what we see
Speaker 1: on the West Coast in Silicon Valley when it comes
Speaker 1: to open source or does that cause banks to sort
Speaker 1: of double down on being competitive and keeping their tech
Speaker 1: as a proprietary thing. Does that make sense? Now? It
Speaker 1: makes a lot of sense. I like her point. That's like,
Speaker 1: in the end, like a company like Goldman, it's a bank,
Speaker 1: it's an investment bank. And maybe maybe UH an engineering
Speaker 1: founded firm like two Sigma can genuinely have a tech culture.
Speaker 1: But I have to I suspect she's right that for
Speaker 1: all of the Protestations Goldman affirm like Goldman can never
Speaker 1: really be a tech firm. That would just be my guests.
Speaker 1: Maybe maybe we'll have someone from Goldman on at some
Speaker 1: point to make the counter case. I think both of
Speaker 1: us sort of had the thought at the same time
Speaker 1: of like there are some similarities between going from being
Speaker 1: an engineer to a manager to going from being a
Speaker 1: reporter to a journalist. And you know, I think, um,
Speaker 1: a lot of what she said really resonated with me,
Speaker 1: including that last bit about like the sort of the
Speaker 1: uh the need to create a common language that everyone understands.
Speaker 1: And I see that all the time, like in a
Speaker 1: newsroom where you have different teams very focused on one thing,
Speaker 1: but the best managers within the newsroom are people that
Speaker 1: are very good at sort of essentially describing in plain
Speaker 1: English to everyone else in the news room that doesn't
Speaker 1: really know about this stuff, why what they're working on
Speaker 1: is interesting, so that there's some sort of level of um,
Speaker 1: you know, uniform understanding about what the news, what's going
Speaker 1: on in the news room. Yeah, there's also the issue
Speaker 1: of creating a sort of language around the type of
Speaker 1: news product that you're offering, like because writing, you know,
Speaker 1: if I say to someone, oh, why don't you just
Speaker 1: write a quick and short story about this, quick and
Speaker 1: short can mean different things to lots of different people,
Speaker 1: and so even just creating like an artificial term for
Speaker 1: what that might be, like creating this artificial structure that
Speaker 1: everyone can eventually recognize and come to understand. Yeah, there
Speaker 1: are a lot of parallels between engineering and journalism management apparently, so, um,
Speaker 1: I didn't expect that. And I feel like I'm going
Speaker 1: to have to go out and buy Camille's book now
Speaker 1: and read it and learn more about it. Yeah. No,
Speaker 1: I want to. I want to read it too, even
Speaker 1: though it's probably not for me per se, I'm for tech.
Speaker 1: It definitely seems like, um, it will be very useful.
Speaker 1: It's but or at least to see the same processes
Speaker 1: replicated elsbere I know. I just really enjoyed that a lot,
Speaker 1: and I feel like I learned a ton in the
Speaker 1: last hour. Yeah. Same, A bit different to the usual
Speaker 1: All thoughts fair in a good way. All right. Shall
Speaker 1: we leave it there? Yeah, let's leave it there. Okay.
Speaker 1: This has been another episode of the All Thoughts podcast.
Speaker 1: I'm Tracy Alloway. You can follow me on Twitter at
Speaker 1: Tracy Alloway and I'm Joe wisn't Thal. You can follow
Speaker 1: me on Twitter at the Stalwart. Follow our guest on Twitter,
Speaker 1: Camille Fournier. Her handle is at scamill s K A
Speaker 1: M I L L E. And she is the author
Speaker 1: of the Manager's Path, a guide for tech leaders navigating
Speaker 1: growth and change, which I'm going to download to my
Speaker 1: Kindle asap. UH. Follow our producer Laura Carlson. She's at
Speaker 1: Laura M. Carlson. Follow the Bloomberg head of podcast, Francesca
Speaker 1: Levi at Francesca Today, and check out all of our
Speaker 1: podcast said Bloomberg under the handle ad podcast. Thanks for listening.