On the podcast this week Charles Humble talks to Camille Fournier about running a platform team, how her current role differs from the CTO role she had a Rent the Runway, the skills developers need to acquire as they move from engineering to management positions, trends like Holacracy, and her book "The Manager's Path".
Key Takeaways
- When looking for platform engineers Camille looks for people who understand what it takes to build and run distributed systems - network, availability, data - and customer empathy.
- The team needs to be focussed on taking the time do build robust software for operational excellence.
- The technical skills were different at Rent the Runway - these would tend to be more full-stack engineers who worked in a more iterative way.
- Much of what we do at work is really about human relationships. One thing about relationships is that they tend to be better when you have one on one conversations with people on our regular basis. A lot of the value of one on one meeting is that you are reenforcing the social connection you have with the other person.
- One of the most important things we do as engineering managers is stay abreast of how to make teams effective in the context of delivering software.
Subscribe on:
Show Notes
Can you describe what platform engineering is at Two Sigma?
- 00:45 Platform engineering is the new term for infrastructure.
- 00:55 It is the software side of platform infrastructure.
- 01:00 My team is largely software engineers.
- 01:05 We build software systems that build the technical platforms that we use at Two Sigma at the lowest level.
- 01:15 A lot of things we do you’d find at any tech company - I run the team that is responsible for our public cloud integration and automation.
- 01:25 We have a private cloud as well, and we run Kubernetes internally - that team reports up to me.
- 01:35 We have some bespoke storage platforms that we have built here - that team is part of my org as well.
- 01:45 We also own the developer tools, code review.
What do you look for when hiring platform engineers?
- 02:00 For more experienced hires, I want to know if you understand distributed systems.
- 02:05 Not everyone really has a deep understanding of distributed systems.
- 02:15 Many of the systems that we build are either distributed systems or have distributed systems components.
- 02:20 One of the things I want to know is whether those engineers have some understanding of building, debug and operate distributed systems.
- 02:40 That’s one of the distinguishing characteristics.
- 02:50 The other thing I look for in my team is customer empathy - a change I introduced into the organisation when I joined.
- 03:00 Two Sigma is a financial company in New York City, and we’re building platforms for other developers at two sigma.
- 03:10 It’s very easy when you’re building tools for your own company to enforce the usage of that tool, so you don’t think about usability.
- 03:25 Sometimes you can get into a combative relationship with other people where it feels like you are fielding requests from them instead of building this cool thing.
- 03:35 I want to make sure that people joining my organisation have some degree of empathy for the people they are building the tools for.
- 03:45 They need to be able to have conversations and think through what people might want, and they’ll be able to provide responsive support when people have questions.
- 04:00 They won’t just build tools for themselves but they’ll take into account all of the people who are going to use them.
How do those developers differ from others at Rent the Runway?
- 04:15 The customer empathy is true for both of those.
- 04:20 Rent the Runway is a customer-facing business that rents designer dresses and accessories.
- 04:30 We built with a product team thinking of the non-technical end user, or the warehouse staff, or for our customer service team.
- 04:45 We were thinking about non-technical end users.
- 04:50 Having a good relationship with the product management team, and caring about the business and software that you were building meant caring about your customers.
- 05:05 The value of hiring and looking for people who cared about building products for is important.
- 05:20 As a customer-focussed business, rather than a deep infrastructure company, the technical skills I was looking for was a little different.
- 05:30 We had many distributed systems engineers – we had a services architecture and we needed people that understood that.
- 05:40 We also needed a lot of good UI and who knew how to build mobile apps, as well as full stack developers.
- 06:00 At Two Sigma We had the need and the luxury to think about how to design robust distributed systems.
Do you need to have an interest in the business itself?
- 06:25 It doesn’t hurt - but it depends on where you are.
- 06:30 At Two Sigma, we are in finance, but a lot of the people who work on the team are not that interested in finance.
- 06:40 Some are, some aren’t - I will admit to being not personally but totally passionate about finance.
- 06:50 There are interesting technical challenges in the finance industry - and I learned a lot about them in the process of working at Two Sigma - but I’m not one of those people who loves finance.
- 07:10 We’re still able to do our job, because the technical problems are interesting and we’re able to translate that into our day to day work being fulfilling.
- 07:20 At Rent the Runway there were definitely people who loved fashion - I enjoy wearing nice clothing, but I’m not a fashion obsessor personally.
- 07:35 There are people who are more open minded about fashion - but we had plenty of stereotypical nerds who liked dressing in jeans and hoodies.
- 07:50 They were still interested and engaged in the product and the business.
- 08:00 It’s nice if you can be passionate about the industry you’re in - for some people, it’s very important but it doesn’t have to be a make or break for your career.
Have you had a situation where people on your team would fit better in a different team?
- 08:35 A lot of that about the culture of your team.
- 08:40 At my current organisation, we really do have to care about operational excellence of the software that we’re building.
- 08:50 We’re building big foundational systems, and a lot of people rely on them - therefore, if they break, they have a big impact across the company.
- 09:00 That’s very different than if you are building a script by yourself to do some data analysis that no-one else depends on.
- 09:15 You need different skills to do those two things - if you are not really that interested in building robust software, you’re probably not going to enjoy the time to build great platform software.
- 09:35 If you are trying to build something scrappy and learn if something works and iterate to be happy, you’d be pretty unhappy if that was your day job.
- 09:50 I do think that most companies have different teams with different values in the work that they’re doing - and that’s the most important thing to align on.
- 10:50 At the end of day, a lot of work is about human relationships - there are some people who have a hard time with good working relationships.
- 11:00 That doesn’t have much to do with whether they like each other as people; sometimes it does, but some of the people I have liked the most as people have driven me the craziest in terms of working relationship.
- 11:15 I love the fact they are intellectually curious and we can have really deep discussions about interesting topics, but at work they do things that make me insane.
- 11:30 I have worked with plenty of people who I wouldn’t be close friends with outside of work, but some of the best work that I have done is because we get along and have complementary skills.
- 11:55 There are times when I see a manager who has to move people between teams a lot because those aren’t getting along with the manager is a little bit of a red flag.
- 12:10 If it happens once in a while there’s nothing wrong with that - but if it happens a lot, the problem may be that the manager is not being flexible enough or needs to resolve.
- 12:25 The kind of person who is going to be a great manager for a UI team is not necessarily going to be a great manager for a QA team.
- 12:35 There’s also a question of whether that manager is going to be able to work well with and lead effectively.
When you wrote The Manager’s Path did you feel there was a missing need for it?
- 13:35 I’m a pragmatic person, and I had been blogging on and off since I started managing a lot.
- 13:50 I felt what people were enjoying about my blogs were really the pragmatic aspects of management.
- 14:05 If you’re in a situation and you haven’t been there before, what do I do?
- 14:15 One of the things I’m pretty good at is categorising and finding patterns.
- 14:25 I wanted to give people some ideas of things to try.
- 14:35 The first time you manage and someone’s unhappy and wanting to quit, or you have to do a one-on-one, or you have to run a re-org - and you haven’t done that before - how do you even begin?
- 14:45 Even if some of the suggestions that I make in the book about situations don’t end up being what you do, I think there’s something valuable in giving starting points.
- 15:00 That was my goal - I wanted it to be in the style of the useful O’Reilly books - how do I end up doing XYZ?
- 15:20 I didn’t want to write about handwavy be a leader and communicate well.
- 15:30 I enjoy reading those kind of books, but they can be inspirational without being useful in your day-to-day.
Can you talk a little about what one-on-ones are?
- 16:20 So much of our job at work is about human relationships.
- 16:25 When you’re an engineer writing code, you tend to forget about that a bit.
- 16:30 I don’t tend to write a lot of code any more - but there are occasions when I’ll pick something up.
- 16:45 You can get into a focussed zone thinking about the software thinking about bits and bytes and characters on a screen.
- 17:00 When you transition to management, you’re not thinking about bits and bytes any more, you’re thinking about people and relationships.
- 17:15 One thing about relationships (in my experience) is that they tend to be better when you have conversations on a regular basis.
- 17:30 I prefer weekly one-on-ones - a meeting with someone (if they’re remote, by video conference or phone).
- 17:40 You’re having a focussed interaction on various topics.
- 17:45 Part of the value is you are reinforcing the social connection with the other person.
- 18:10 For me, I also have observed over time, is that I get stressed out with people who I have a close working relationship whom I don’t have a one-on-one with.
- 18:20 If there’s any kind of conflict I get paranoid about whether if the person is mad with me or what are they thinking of.
- 18:40 Regular one on one conversations can ease that fear about their managers or other people they work with.
- 18:50 Fundamentally the most important things about one on ones is that they are a relationship management thing.
- 19:00 If you’re married, you want to spend some time with your spouse - whether you do date nights, or for five minutes before you go to sleep at night - the checking in is important in a relationship.
- 19:20 If you are a new manager, who often juggle management and some individual contribution responsibility.
- 19:30 New managers are often expected to write code and do some hands-on work.
- 19:35 That’s OK - juggling things can be painful for context switching, and it’s important to hammer home that it may not be fun or you may not be in the mood for the one on ones - but the worst thing you can do is neglect them.
- 20:00 When you neglect them, you miss things about people on the team, you miss building that relationship, you miss things you would actually catch earlier.
- 20:10 The most important thing about holding one on ones is that you hold them regularly, ideally at least every other week.
- 20:15 It’s very hard to go longer than that and maintain a good relationship - especially if it’s someone you’ve not been working with for a long time.
What led you to publish the engineering ladder [http://dresscode.renttherunway.com/blog/ladder]?
- 20:50 I published it because the way I wrote it was from backchannel help from friends.
- 21:05 I had feedback from friends who are CTOs at other companies and I took advantage of my network to help me create this ladder, along with my team at Rent the Runway.
- 21:25 After we created it, I realised that if you were a new leader who had never done this before, you maybe don’t have a strong HR team, and your team has a set of levels, where do you start?
- 21:55 I love to look at other people’s source code to get started - one of the great things about software is how much people share their work.
- 22:05 Taking someone else’s work and remixing it to make it work for your use case - or reading the code and getting ideas from it and doing your own thing.
- 22:20 There wasn’t anything out there for this essential piece of organisational work.
- 22:30 As an engineer (who is a big proponent of open source) I wanted to just publish this to give them a starting point.
- 22:35 We did a pretty good job, but it’s not perfect, but we thought about it and is the result of a couple of iterations.
- 22:45 If nothing else, it will give people a starting point and then a bunch of other people published their work.
- 22:55 Some of it are evolutions of the Rent the Runway ladder - and now if you’re starting out, and you want a career ladder for your engineering team, you have a lot of examples out there to learn from.
- 23:15 I think that’s a great thing for our industry.
What do you think of the case for the need for management?
- 24:40 It’s cyclical - the trend (of not needing managers but then swinging by to need them) has gone away.
- 24:50 Part of the reason why I wrote this book is that I thought there was a lack of appreciation of the value and challenges for managers.
- 25:00 I thought if I wrote about it, and made it clear what the manager’s job is, that it would help people the value that a good manager would bring to a team.
- 25:20 I think there’s an idealistic notion that you can put a bunch of smart people together that stuff will happen and they’ll do the right thing.
- 25:30 If leadership is needed then someone will step up for a while and lead, and then they’ll step down and another will step up without needing things to be formal.
- 25:50 One of the things I cite in the book is “the tyranny of structurelessness and what worked and what didn’t.
- 26:10 What she found was that the organisations tried to be egalitarian - they wanted everyone to be the same, and didn’t want to have official leaders - they were trying to be idealistic.
- 26:20 What she observed was that when the organisations were fairly small and had really specific things to do and the tasks were clear to everyone then it didn’t really matter.
- 26:35 In some ways thats what you see very often in early stage start-ups - they are scrambling to survive, as there’s so much obvious work to be done.
- 26:45 You all probably know each other well and it’s a fairly good group of people - there’s probably not as much need for structure.
- 26:55 As you grow, to longer timeframes of work, and have more competing interests - how do you decide what to do?
- 27:05 If projects take weeks to months to complete, someone has to decide where to spend your time and resources as a group.
- 27:15 If you don’t have an official structure, what happens is that you’ll have an unofficial structure.
- 27:30 You see this at start-ups, right before they give in and implement more official structures.
- 27:35 You might think you are a flat organisation and that we don’t need managers - except the founders have a lot more say than anyone else.
- 27:45 The people who joined earlier tend to have more say than the people who joined later.
- 27:50 The loudest person in the room maybe has more to say than the quietest.
- 27:55 It has nothing to do with who has the best ideas or the most experience or anything else - it has to do with these social undercurrents that happen.
- 28:05 Sometimes they can be good - the founders should have more say, for example - they took the risk in founding the company - but should the loudest drown out the quietest?
- 28:25 I think that management and structure are useful for putting light on the reality in the situation, which is that people are making the decisions.
- 28:35 When you have a tie, somebody has to be the tie breaker.
- 28:45 Most of us don’t have the luxury of building consensus ad infinitum around decisions - we have to get things done.
- 29:00 At some point, you need to put people in those positions of authority to be able to make those decisions.
Are there other managerial books you would recommend for engineers?
- 29:30 I really like “Turn the ship around” - it speaks to engineers, from a military perspective.
- 29:45 If you’re in a messy situation, how do you turn it around and clean it up.
- 29:50 “Thanks for the feedback” is one that I read recently - it’s a classic in giving and receiving feedback.
- 30:05 Whether you’re a manager or not, you might read this for both giving feedback and learning how to take feedback.
- 30:25 “High output management” is a favourite among engineering leaders - it has things I like and things I don’t but it’s a classic for good reason.
- 30:40 One thing I recommend to engineering managers is to stay abreast how to make teams effective in terms of delivering software.
- 31:00 That changes - one of the things I recommend is to follow how the trends of software development change, so your teams can be as effective as possible.
- 31:20 A book that came out recently “Accelerate” is all the research that she and her team has done on what makes development teams effective.
- 31:40 It covers things from how you do continuous deployment to how to structure change control, how do you do idea sharing on the team.
- 31:50 It is very useful to keep abreast of things that are going on in the cloud, because that changed how people wrote and deployed software, so if you don’t know about it then you may not be aware of the best practices of the day in making teams most effective.
