In this episode of the Humans+Tech Podcast we're talking to the incredible Camille Fournier, managing director of Two Sigma, and author of the books The Manager's Path and 97 Things Every Engineering Manager Should Know.
Scroll down to read the full transcript of our chat with Camille
In this episode we cover
- The Rent The Runway career ladder [00:01:05]
- Progression.fyi [00:02:29]
- How to build a good career ladder [00:02:58]
- Manager READMEs [00:13:47]
- The Manager's Path [00:19:24]
- Camille's experience of moving into management [00:22:52]
- Managing in startups [00:26:12]
- Building a Peer Network [00:29:06]
- Lara Hogan's Manager Voltron [00:32:16]
- Camille's quickfire questions [00:35:22]
Find out more, and follow Camille
Follow Camille on Twitter
We were discussing Camille's books The Manager's Path, and 97 Things Every Engineering Manager Should Know.
Full transcript
Aaron - Welcome to the Humans+Tech Podcast. I'm Aaron Randall, and this is Amy Phillips
Amy - Hi
Aaron - Today we're talking to the incredible Camille Fournier, managing director of Two Sigma and author of the books The Manager's Path and 97 Things Every Engineering Manager should know. Camille Thanks you so much for taking the time to talk to us today.
Camille - Thank you. Very excited to be here,
Aaron - So I want to start actually, Camille with the serious stuff, um, so it's a Human+Tech tradition for me to draw a doodle of our guest and that goes out when we publish the podcast. So sure, Yeah, this is very serious. So I want to show you the doodle I drew of you and if we could just get your thoughts and feedback, so
Camille - All right. Wow. I like that. I have a necklace. Yeah, and the short hair. I think I think this is pretty good. Very talented
Aaron - you know, I did notice. Actually, you have, like, the best necklace collection Google Photos shows that
Camille - It's true.
Aaron - Okay, Now we've got that stuff out the way let's dive in. So Amy and I first learned about you a few years ago when you were CTO at Rent The Runway and so at Songkick where Amy and I were working at the time, we were busy building a growth framework or an engineering ladder for our tech scene and we found a blog post from Rent The Runway, which you wrote back in 2015. Sharing your teams growth framework. It was a simple spreadsheet, but the core skills, role and structure really influenced what we ended up developing at Songkick. So I guess thank you for doing the hard work. And also thank you for sharing it with the world.
Camille - Absolutely. I mean, I you know, I shared it with the world partly because when I went to do my own, I had several friends in New York City tech companies that slipped me there's kind of under the table and they were like, here's some ideas. And my my husband, actually still works at Google, and he kind of let me look over his shoulder at some of the things that they had done there, and I was like, Okay, great. Now I feel like I have some some baseline and I'm obviously my team also contributed a huge amount to to the product. And, you know, at some point it was like, you know what? like this is a lot of work, and we're all kind of trying to do the same thing. You think I should just share what we've done and make it a little bit easier for people to get started. And so that's that's kind of why I did it
Aaron - Follow up question I had was It seems like now nowadays it's becoming really common for people to do that. And you have a whole websites dedicated to people who've shared their growth frameworks like progression.fyi. You know, your growth frameworks on there and Songkick's is on there and there are tens of them from big companies. But it did feel like, I guess, as we were saying Rent The Runway was ahead of the curve there. And it also stood the test of time. So you mentioned that you built this thing with your team. But my my follow up question was, How do you go about creating such an amazing growth framework?
Camille - Yeah, I mean, like I said so part of it was I did get a lot of people to share information sort of off the record with me about what they had done. Um, and and that was that was useful. I mean, really, what happened was I actually did two versions of the framework. So the first time I tried to do one, we had a very lightweight sort of low detail. Um, you know, not that many levels framework that I rolled out. I can't remember exactly when, but But I rolled out, you know, maybe in 2013 early, 2014 something like that. And, you know, we did it because people have been asking for it and sort of felt like, all right, you know, we had, I don't know, maybe 30 engineers on the team or something at the time as they are. Maybe it's time to put some structure in place. Um, but what I realized after doing it was that we have actually made it. I hadn't added a lot of clarity to things and because I had tried to keep it simple in the interests of making something that people wouldn't debate and try to like, you know, precisely interpret and sort of check a bunch of boxes so that they could insist that they could get promoted like there's a common with among engineering managers that if you keep things somewhat vague, then people won't try to game the system like I've heard many otherwise, you know, pretty, pretty smart managers say that and what I found was by doing that. In fact, the opposite happened so people would interpret these kind of vague pronouncements of levels of seniority in the way that was most favorable to them and say, like, What are you talking about? Like I guess I'm only I'm only six months out of college, but clearly I'm already issued original. Oh, no, that's not That's not, you're a very great person, you know. So they have a bright career ahead of you. But you're not a senior engineer yet. I definitely had conversations somewhat similar to that in the process. And so, you know, I realized that I wasn't doing myself or my team any favors by being so vague and you know, I'm not the only person who discovered that this was a thing that needed to happen. So, you know, as I said, my husband works at Google. He kind of let me look over his shoulder a little bit more at the technical ladder that I see individual contributor ladder and and that was because I think, you know, I have no idea what they're doing these days at Google, I'm sure they change all the time. But Google famously has promotion committees, and and they had, I think, for a long time had a somewhat big ladder, and people were really frustrated on How do I get promoted? And how do I prove to this committee that I'm doing the work of the next level? And, you know, it's a big company. We're all doing different kinds of things. But I'm an engineer on Android. It's very different than a, you know, engineer working an infrastructure. And so you know, someone there. I think actually a group of people there had done a lot of work to try to add some color and detail, and that was just, you know, helpful. I didn't use like, a ton of what they had done directly, but it was helpful to kind of see some of the language around impact and scope and how it applied at a really big company to give me some more specific ideas, but I didn't want it to be, you know, we didn't want it to be like a generic ladder or something that would be appropriate for, like, a really big company like Google. So, you know, try to keep in mind that look, this is a small start up. Everybody here is working really closely on the product with the product team with other partners around the company. There's very few people I got in there really know people who are just able to only work with engineering, right? So try to make sure that whether it was the individual contributor ladder of the manager management ladder, we were still calling out the fact that this is a collaborative partnership around a product of the company that we're all really helping to build and taking the time to articulate some of that and some of our own core values along the way.
Amy - That's really great. How do you get around that like, how do you get to the right level of detail? Because I think like you say it's very easy to kind of think that the generic, very vague framework will be that the easier one to work with, but it's not. But also it can go the other way is where you end up with the framework that ends up being treated like a checkbox exercise, and everybody's trying to tick off every single thing listed on there. Um, what's the right level of detail?
Camille - I mean, I don't know that I have, like, a perfect answer to that, So I do think so. I do think in general, especially above like, very early career ladder levels where, like you can sometimes it be fairly brief because a lot of what you're expecting, like you're just right out of college. A lot of what you expect people to do in their first year or two. It's just like we just wish to see that you're learning and growing and becoming, you know, an independent engineer, you can kind of briefly say that sometimes, but I think you want more than a sentence or two. Um, yeah, but and you want more than, like a couple of facets that you're looking at, right? So So I think the key things that you absolutely have to be careful about is like, all right, First of all, like How are you? How are you defining the facets that you actually break down? This goes along, right? So, um so let me think so. Rent The Runway. I think I think I copied. Actually, this was one thing I stole from FourSquare's, they have been like, uh, you know, like, role playing game attributes, right? Like, you know, strength and wisdom And, uh uh, you know, intelligence. And what's the What's the other one? I forget anyway, you know, So it had these look sort of different, four different facets and we tried to kind of translate them into important areas of, you know, how do you get things done? What are you getting done? Um you know, how do you communicate and work with others? And I do think that thinking about the facets is pretty important because it can actually be really challenging to keep things not too long if you overlap in one bucket, a lot of different concerns. So to try to be a little more specific. I recently did an exercise in my current company that was uh, that was around redoing our management ladders, and I I was really just an adviser. So actually, one of one of my directs and a group of his peers really went around, they interviewed a lot of the senior management about what they thought the different levels of management should look like umm they did a big exercise to work on it. And we had originally had, I wish I could remember exactly the language we originally had four, for a separation of four things. But that was, like, very bunched up. So it was like there was a section on scope. Um, there was a section on that was just on like people. Um, and the, uh, this is gonna be a terrible anecdote because I cannot remember the actually made that just to make a terrible podcast. Uh, wait pause for a second and see if I can actually remember what precisely we did. But the long story short was that we had we had really, like, over over emphasized in one of those areas. Ah, ah. Lot of stuff kind of wrapped into it. And then there was, like, so what? It was just like on selection and recruitment. It was like we had four aspects. So one of this, like, sort of culture which is sort of shared between engineering, management and and individual contributor, so that's so that's no big deal. But then, somehow the manager ladder had, like almost everything in its scope section, and then we had this weirdly very, very bare like recruitment section was basically like, How would I be thinking about, like, recruiting? and building your team? Now that's important for managers. But the idea that it is one of the four important things that you talk about was not right. It was just like it was just like you can understand why it might have been done that way originally because the company was growing really fast. That probably was really top of mind for everyone writing the ladder then. But now it's like actually, I want to be able to put more detail that separates out kind of this size of team and scope of responsibilities of this manager, um, versus the way that they, uh versus the way that they actually, like, work with their peers and, like lead their projects and sort of the the the execution of how they actually execute things versus the way that they think about the people, not just recruiting, but developing people developing leaders on their teams. You know, dealing with high performance, with low performers, all of that kind of stuff. So by just sort of shifting it to be less, um, less bunched up in one of the four facets. We were actually able to keep the ladder relatively brief, like, you know, a few sentences for each of those sections, but still provide enough information for people to see and distinguish the difference between different levels. So I don't have, like, a hard and fast answer. I've seen a lot of people do a lot of different approaches here, Um, and you know, like friends of mine have worked very hard on, especially for individual contributors. I think this comes up a lot more right. I think, for managers. We all sort of intuitively kind of understand that there is something to team size or team team complexity of scope. That part corresponds to different levels of management. It's not that's not the only thing. It tends to be a big part of it for individual contributors. I think it could be a little bit muddier like, how do you tell that someone's having a bigger impact in their day-to-day. And so I definitely know people who have done different exercises to try to say, Okay, here are some core skills that we expect every individual contributor to have and grow along. And then we have different facets of skills that different kinds of individual contributors might be focused on to try to try to separate out and recognize different skill sets. I've never personally done that, but I've seen people try to do that as a as a way of accounting, for we have foundational skills and expect everyone to have. And then we know that like, Okay, you're like a frontend expert or your expertise is really on the product side versus your expertise is really on the infrastructure side. And so we're gonna have things look a little different across those two. Those two ladders, not just ladders but those two facets, I should say
Amy - So one of the, moving on to sort of other other tools and things that people expect around management is Manager READMEs. So it was your more recent book about 97 Things Every Engineering Manager Should Know and you wrote a piece about Manager READMEs. Um, could you share your thoughts on Manager READMEs?
Camille - Sure. So So I'm not a fan. Uh, and I got into a little bit of, ah, Twitter spat. At some point, I want to say it was like last year, maybe 18 months ago. Time flies, on the topic because I finally just, like, couldn't couldn't, you know, hold it back. And I wrote the Medium post on it that was a bit more inflammatory than what I ended up publishing in the book. Just let me tone that down a little bit because, you know, the Medium post was sort of written in a in a very quick you know ah manner. So here's my challenge of Manager READMEs. Um, I'm a manager. READMEs are useful when what they cover is, like, very basic nuts and bolts stuff like this is when I'm available. This is the best way to contact me. Um, you know, these are like some, maybe these are some of the things I'm working on, you know, this is, you know, this is the structure of my day, stuff like that. That's very almost, like fact based stuff that that's useful, right? And I can imagine that if you're in a remote team which we're all figuring out how to do right now as a as we speak probably certainly here in the States. Uh, you know, having that kind of information published somewhere is probably, like, super useful. I find where Manager README really fall down is is when, so there are two things that I don't like about Manager README. The first is that I don't like them as the guide to managing up to me. Um, which is I don't think that's what a lot of people who write them would call them. But that is totally what they're writing, which is basically like, here are my biases. Here is what I hear is what I say that I about myself. Um, so, you know, here are my quirks here, You know, here is what I expect from you to be successful. All that aside, these are all good things to know, maybe even some of these good things to write, but I find it to be a very, very kind of inappropriate way for a person in a position of power to relate to the people that they have power over. And I think that's you know, they're the two foundational things that I find about First of all. Look, I just think that often really ignores the power dynamics between manager and direct reports. Where, like, look, you, you have a lot of power over these folks. And so if you say something in that I have, you know, I believe myself to be very transparent, and I want you to tell me and you know, I love to get feedback. Please give me any feedback that you find, you know, immediately in the moment. That's what I really want. And then you write that you give it to them. They read it, they take it at face value, and then they try to give your feedback. And you react poorly, which look almost everyone does. I do and I try, like I've tried very hard to become a person who's good at taking feedback, but it's terrifying to give your manager feedback. I have the nicest manager in the world right now, and it's terrifying to give him feedback and, like he does not react badly. But it's it's a terrifying thing to do. So when you sort of put that out there for people, and then inevitably someone actually takes you at face value, does the thing you said you wanted and you react poorly. You really undermine your relationship with that person. And I think that the problem that I have is that my I feel like a lot of what people do when they turn it into this, managing up to me, document they because they don't call it that right. They call it a thing to help build trust. But that's not the way you build trust what you built trust by spending time with people you build trust by like working on projects together and going through stuff and talking and just getting to know one another and showing up for one another. So your behavior is what builds trust, not just words that you write in a document, and I worry that a lot of engineering managers are just are looking for an easy out for the work of, you know, building relationships. I just I think that's a really common challenge for people who come from engineering backgrounds where we think look like? If I could just automate it. You know, life would be easier if I could just write a document, a how to deal with me document. Then like everyone will know my inputs and outputs and they'll understand my api and you know it'll be great right? You are not a Turing machine. You know, you're not a predictable, you know you're not a finite state machine with very predictable behavior based on inputs and outputs. Uh, even if you think you are, you're not. Especially if you think you are probably especially not because you're probably not very introspective about that part of yourself. So I think that it's just very easy for these to become a way for managers to, you know, think that they're short cutting building trust, not really short cut that at all, and in fact, possibly erode trust by by not acting true to what they say they wanted to be.
Aaron - Yes, all this is making me think of like I think it's a related point, but just very quickly I want to read a line out of your book, about halfway through there's this is quote that says "the tech industry is filled with people who despise management, thinking it's not as important a job is writing code, but management is a job. It is a necessary and important job" which I think is really powerful, quote. But the other bit there is like it seems like management is seen as an overhead or bad in the tech scene, particularly in the start up world. Do you think that things like Manager READMEs are fueling that? Or do you think it's something else?
Camille - Um, you know, I actually think, here's what I will say I think management is in a much better place in the tech industry than it. Was when I wrote my book, um, and it's certainly than it was 10 years ago when I really started to get a lot more into management myself. Um, there's still a long way to go, I mean, I do think that things like Manager READMEs yes, they are part of that old school management tech management thing. Like who created the most famous manager READMEs that you will never hear about is a very senior person at Google who is still there who I will not name, but like very famously had a manager README long, long ago. And it was from all accounts of people I know who worked somewhat with this person. Probably not immediately for. But, you know, I was very much like a you know, uh, it was very much had it wasn't quite as touchy feely in the problems that it had, as was what I think some manager READMEs nowadays do. But it was definitely an attempt to to get over the like need to talk to people and get to know her and Google kind of famously from management, I think they've gotten better at this overtime, but like, famously for many years, right, they had managers with 50 or 100 direct reports like they were very much like. Management is not useful, management is overhead. And and I do think that, like this manager README, things do come, I don't know that they come exactly from a tech industry that thinks that management isn't necessary, But I think there's a lot of a lot of first time managers who were engineers have this problem that they still can't really see value in things that aren't writing code and you know, and they just they struggle to really feel feel productive if they spend all their time talking to people on things like that, that just there's a little bit of a struggle getting over that hump of like actually, there is value in having meetings. You know, there is value in in writing documents and not just in writing code. And there value thinking about how we work together in the processes that we work in and so forth and so forth. I do think Manager READMEs tend to be adopted by people who are looking for shortcuts. Um and and that's I think probably, you know, I suppose like, you know, the biggest problem I have with it is, I just think they're bad advice for new managers and the kind of thing that new managers will do. And it will actually slow down their progression to becoming good managers because they think that they've gotten this shortcut that will take a while for them to realize that actually, it's not a shortcut, really probably undermining me on, and that's just sort of lost time when they could have just been trying to do the job and build the relationships and build Trust
Amy - Great point. Yeah. So your book, The Manager's Path really does, like, really resonates with people, sort of just moving into being tech leads. Or maybe they've been managing for a little while, but, like definitely a number of people who are in that sort of level come and sort of wave your book around very excitedly, and I think it is because it's very, very practical advice, But also, I think it is that sort of stuff which maybe doesn't, or didn't used to get shared so widely. Like you need to stop coding like it won't be your whole job. It's a different job. What was your experience of, like moving into kind of tech leading and management for the first time?
Camille - I mean, I think it was lucky. My, you know, my first experienced tech, leading and managing was a small team. And I, and I had a great manager helping me do it. Um, so, you know, I got to got to have my first major speculate experience be on a really interesting project with a team of people that I really liked, Um, that I have been working with for a while and a project I was really passionate about. And I was very deeply involved with from the technical side. And then I also got put in put into the management role of that team, and it was a small team so I was managing, like four people. So not not a massive management role on, and the person who was managing me is actually, you know, he, uh, he and I still keep in touch. He's someone that I really you know, love and respect a lot. And he's always been on the like, mostly on the technical track. So he's a man, he's been sort of a tech lead manager several times, and actually he may or may not be managing lots of people now, but for the most part, he's always managed to keep himself in these sort of managing relatively small teams from a very technical perspective. But he takes it very seriously, and so you know, I've got I've got the benefit of having someone who certainly took the like work of really taking a complex technical project with multiple people working on it and making that project go well, he really taught me how to take that very seriously. And even though management was not his like passion, he was the kind of person was like, If I'm gonna do this job when I'm doing this job, I'm going to do the best job that I can of it on. So, you know, I think I was lucky to have my very first experiences be under someone who was very, you know, was really diligent about the way he approached these things and willing to teach me. And so I do think I was lucky that I had a mentor. Well, I'm sure that was like a lot of people get pushed into tech lead roles or even, you know, early management roles, and they don't have any kind of mentoring. They have no training, and it's just sort of like go and often they don't have any good role models. You know, I think I was. I was lucky you know, working for a pretty big company that had an established management process practice and it was not perfect. But you could see professionalism in the approaches to various kinds of management tasks, which again, I don't think you necessarily get access to or exposure to when you're at a start up, you have to kind of figure it all out yourself. And so I was lucky to have some of that exposure to good managers to some enough for mature processes for dealing with things and then have the very first person who mentored me through that. He's someone who was very diligent and thoughtful about the way he approached it, even though management was not necessarily his passion.
Aaron - That's the question that you mentioned that you were lucky enough to have a great mentor in your manager. In this, In this experience of transitioning, into, more management people that role, What do you do if you're in a very small company where you don't have that?
Camille - So my advice to people, at small companies is always like you need to build a peer network outside of your company. You can get coaching. I actually had a coach for a really long time when I was a Rent The Runway, so I definitely, uh, didn't try to go it alone, I actually had two coaches for a while. I had a CTO coach and I had a sort of personal coach, a leadership coach, and that was very, you know, I kind of needed both of them for different things. I also had a huge, peer network. So Rent The Runway I wasn't in the very earliest stages of matter. I had done some of it before, but I have never managed at scale that I was managing. I've never been an executive. I'd never been a manager managers. I had to learn a lot very quickly. And I really relied on a peer network of other people in startups who were maybe going through the same thing or had gone through it a little bit before I did. And so who they could provide some advice to me? As well, as those coaches to give me just different kind of pieces of feedback and information. Um, that was really helpful. You know what? I didn't Actually, I didn't end up getting a lot of peer feedback or advice from people at bigger companies. So for whatever reason. And I don't know, You know, looking back, I'm not sure if this is just the network that I had, but you know what? You will learn different things. Being a leader of a startup, then you might learn being in a big company where there's just there's so much established for you that you don't even know. Uh, you're getting, right. Like, you know, all of this stuff that, like, HR teams do at big companies. You have to do, maybe not all of it yourself but a significant part of it yourself, even as kind of a line manager at a start up right at my current company, Right. We have HR business partners. And if my line managers need help with something, Um, sure, they have their manager. They could talk to me, but they also have a great HR partner who is there to help give them advice on how to deal with tricky situations. And, you know, if it, you know, if we're trying to hire someone, we have a whole recruiting team, right? If we you know, if someone needs to take a leave, we have policies established, right, So there's so much that you don't actually learn. Necessarily when you're working at a more established company that you will learn at a startup that I think you know, you do want a pure network of people who are actually going through similar things because it's not super helpful to have someone you like. Well you just ask HR what the policy is because, like, I know you have to do that. So what should I do.
Aaron - How did you actually go about making those connections with those peers outside your company
Camille - I was lucky, uh, one of my best friends. Part of the reason I moved to New York is actually he moved to New York. And I went great. My friend Harry is in New York now. I have, you know, I have a good friend there, and I have an excuse to move there. Um and so he had started. He was basically the sort of engineering leader at Foursquare, Uh, for very long time. So he built that team from the tech side, and he he had, he's a very good networker. So he had gotten done a bunch of work himself to make connections with other VPs of engineering and CTO type folks outside in the New York City tech scene. And when I ended up in that role, he very happily brought me along, so I was like It's just very lucky, Frankly, to have this friend who himself is an amazing networker an, was willing to introduce me to people and I but I've seen other people do this without that person. And what I see is like, for example, one of my friends is named Juan Pablo. And he's been a VP of engineering and CTO of various companies a lot of like remote. But here in New York as well. And one day he just like, e mailed me and was like, Hey, like, would you like to get coffee? Like I'd like to talk about some things. I was like, You know, I don't know. That's God. He sounds nice. I'll give it a shot. And you know, we we have become friends and kind of built out a network ourselves, you know, so just kind of being willing to reach out to people and sure, plenty people are gonna say no, like, you know, if you reach out to really busy executives at startups like they're busy, they may not say yes, but sometimes just being willing to reach out and ask, you never know who's going to say Yes, And people do like especially in smaller startups scenes, right? So in New York, the scene is not tiny by any means, but it's not like San Francisco, where every person you run into on the streets is already in a start up. And so I think leaders in New York tend to want to cultivate their network a lot because we know that you know, the next person we want a hire or next job might come from someone that we know that we met at that party or that we just had coffee with that one time. So, you know, building on a network is a useful skill for anybody in a leadership position, I think kind of no matter what, especially when you're in a smaller a smaller area for start ups or for your industry. Um, I think the other things you can do, going to conferences that are local to your area that are around like engineering leadership and meeting people can be helpful. Like the LeadDev I know runs some great conferences. They've run some here in New York. They run some in London. So if that happens to be kind of in your geographic area. You could meet people there are a lot of people. There's there's trainings that sometimes the different companies will run. And sometimes you know that's an excuse. To get out there and meet people. So I do think that building a network does require usually requires a bit of work on your part. But it's work that will really pay off in the longevity of your career and probably in your happiness and success in the role.
Aaron - It's true, it's very interesting. I'm I'm thinking now about Lara Hogan's Manager Voltron, very familiar with that amazing tool we actually spoke to her about it, has offered on the idea of building up and actually did it with my engineering management group, and we filled it in together separately, but sharing some interesting like aspects of Oh, actually, this this corner's missing for lots of us on one of the questions was like now what? But that point you made about just reach out to people is I mean, yeah, that method. we use that, we use that this podcast and we've spoken to some, like yourself included some incredible people that I never would've dreamed we have got to talk to, you have written these incredible books and just amazing leaders in technology. And people generally just wanna talk, which is a very interesting learning points a
Amy - It feels to me like as well that it's one of those funny things where your network is almost outside of work. But it seems that actually, so many people are getting better at their jobs or getting the support they need to do their jobs from their network. That it feels like it should actually be something that companies are telling these new tech leads, like you also now need to go and build a network and here's your time. And some guidance on how to get started
Camille - Yeah, no, I mean, here, so in between Rent The Runway and my current job. One of the things I did was actually run a run, uh, like, sort of peer learning management class type thing here in New York with my friend Kellen. And, you know, we would run these sessions with 20 to 30 people that I mean, we did various format, but part of the goal of it was actually to help build networks, so, you know, it was very much focused on the New York City Tech scene, very much focused on, you know, managers, so we would actually limit the number of people from the same company who could attend because we wanted first of all, people to feel able to speak freely on not worry about their peer, like, reporting back, but also for people to meet people from other companies. So you know that that was like a really fun thing. It's hard. It's something that I don't really have time to do a full time job. But, you know, we actually had a ton of success just building out these, like peer learning groups where we, you know, we would either do like, you know, meetings once a week for a few weeks running, or the best ones are. Actually when we do like a day and 1/2 intensive were just bring everyone together and, you know, sort of draw on some common topics that we know most managers want to talk about, also some topics from the group's themselves, and have the group's really splitting out and talking to one another, mostly with us giving some moderation and feedback and setting up the kind of structure for the day, but it was just a really fabulous experience. We got really positive feedback from everyone that attended at night. I think definitely, we helped At least some of the attendees create much stronger local networks for their for their careers here, so.
Amy - Wow, sounds amazing. We need one in London if you want to come to London --- the number one way. Uh, -- so we wrap up every episode of this podcast with three quickfire questions. So number one, what are you reading right now?
Camille - Uh, what am I reading, I'm actually reading. I'm not reading anything. Non fiction. I'm reading a fiction book. I think it's called Spinning Silver, silver is in the name. It's like a sort of fantasy, but it's kind of this, actually, like, kind of interesting. It sort of feels like a like a complex fairy tale. Uh, I'm enjoying it It's very well, written
Amy - Sounds interesting. Um, And what or who is your number one tip for keeping up with the tech industry?
Camille - Keeping up with the tech industry? Um, my look, my number one tip, especially if you are a manager, is to cultivate a strong network of individual contributors that you know and trust um, and be willing to ask them dumb questions on and you know you could like, I also think like, eh, So I'm not a fan of hacker news, which I think is one way that people do it. I find it to be kind of a toxic place to visit, so I don't tend to tend to use that. But, you know, I do think with the right with the right cultivation, you can find people on Twitter that we're talking about interesting things, but certainly as a manager, it's more than just kind of knowing what's going on that's important. It's like knowing who to ask about what is real and what is I kind of like hype or not really ready and so cultivating a pretty wide network of people who are still actively writing code and could give you some got checks on things. That's certainly very important for me and keeping in touch with the reality of things in the tech industry.
Amy - That's really interesting. And then who inspires you?
Camille - Who inspires me? Um oh, gosh, uh, who inspires me? I'm sure there are plenty of people who inspire me. Um, you know, you know, my friend kind of inspires me. And she's like, You know, she's just, like, hilarious and positive and great at friendships and speaking her mind. And, you know, she's done some interesting things in the industry, and is super insightful. And, you know, I'm always and always inspired by people who I just find to be like, you know, really insightful and willing to willing to say, willing to speak openly, but also like not trying to be, like, hurtful about it, right? Just, you know, sort of want wanting to state their opinions, but also being thoughtful about the impact that what they're saying might have on other people. I just think, you know, is unfortunately not as common as perhaps it could be in tech.
Amy - That's very true. So, Camille, where can people find out more about you?
Camille - Where did you find out more about me? I mean, I have various, like, halfway halfway abandoned websites. http://www.camilletalk.com/ is one of them, but I mean, the easiest way is probably following me on Twitter at @skamille I very occasionally blogged in, like one of three different places. Uh, once I wrote a get a gist on GitHub That somehow still like ever, like, went more viral than I expected. I was like, I don't really want to write this as a serious blogpost. So I'm a little all over the place. But mostly, I think if you're you know, if you're interested in keeping up, you can occasionally check my Twitter, which is definitely a mix of a lot of things. It is not any one thing, um, and I do very occasionally blog. But you know, these days it's it's hard with a full time job and two kids and everything else. So
Amy - yeah, fantastic. Thank you so much, Camille. It's been absolutely amazing talking to you. So lovely to hear, like your experiences of moving into management, your thoughts on like, tools and techniques being used out there. Yeah, thank you so much for taking the time.
Aaron - Thanks
Camille - Thanks for having me
Amy - We'll be linking to all of the websites and doodles in the show notes. But make some time to read Camille’s books, The Manager's Path and 97 Things Every Engineering Manager should Know they're both jam-packed with wisdom to help you be an amazing manager.
I'm Amy Phillips. This is Aaron Randall, and you've been listening to the Humans+Tech podcast.
Get the latest posts delivered right to your inbox.