S01E03 · A definition of the tech leader

0:03 Parole de Tech Leaders, le podcast Tech.Rocks qui donne la parole aux Tech Leaders. Tech.Rocks, la communauté qui rassemble, connecte et valorise les tech leaders d'aujourd'hui et de demain. Exceptionnellement aujourd'hui, ce podcast est en anglais, puisque nous avons une invitée de marque qui ne parle qu'anglais. Today, it's Guillaume Postaire, Media Factory Director of France Télévisions, and I am with Beth Lebeau, Director of Engineering at Sqreen. Hi, so I am Beth Lebeau. I am Director of Engineering at Sqreen. I moved to Paris about three months ago to take on the new role. So how do you come to arrive at Sqreen and especially in France? So I moved to Paris about three months ago from Google in Seattle, where I had previously been managing SRE teams there. I found that to be a really wonderful technology to be part of. Google is a great company, but just due to the nature of management and leadership at companies tends to be kind of hierarchical and trying to find a path upward where I can continue to grow as a leader, continue to grow in technology.

1:07 Was a little bit difficult. So I started looking elsewhere within Google, primarily with an SRE, but then a little bit outside of SRE, and kind of realized, hey, maybe I should be looking outside of Google as well. So when I started looking at that, I kind of had been working closely with teams in Europe, And it seemed like a really good opportunity to maybe make a shift from the United States. to Europe to kind of experience that. When I did that, I kind of started looking at companies outside of Google and Sqreen contacted me. For me, that was a really big deal. It was very interesting because the day that I got the email, I remember I had just come back from this women's conference called Grace Hopper. And in my inbox, there were two emails. One was for an a company that I had spoken to when I was there that I was looking at possibility of joining and it was for a software engineering internship. And then there was another one directly above it to take on a role leading engineering at a startup in Paris. And initially I kind of saw that both were absurd to me.

2:09 Like I was been 20 years experience, I'm not going to be a software intern. And where I was, the idea of kind of taking on a leadership role at a startup was a little bit far-fetched as well. But I continued to do a little bit more research into it. And I kind of saw that maybe there was actually a fit there. So I actually responded to the email from Sqreen. I talked to them quite a bit. And I learned that I really, really was interested in both the product because Sqreen is a security company. Previously to Google, I had been working at Amazon in payments. And in payments, obviously, security is tremendously important. In fact, I worked with the teams that... Had access to the credit card numbers and charged basically every transaction that Amazon does worldwide and distributes all the money for vendors and sellers. And so I had a I'd already developed an interest in security to some degree. And then I kind of looked at the fact that Sqreen and the product were super exciting to me. It was a position where I knew that one point or another, I would end up being a customer of Sqreen.

3:18 And the idea of working on a product that was compelling to me as an engineer and a developer was a huge deal. So I went through the process of interviewing with them and got really excited when I had the opportunity to join the company. Great. It's not current to come from SRE to be CTO. Not exactly CTO, but I have a CTO. Engineering director and managing development teams. No, yeah. So I really enjoy managing development teams. I started actually as an engineer. So Google was the first place that I did SRE. Prior to that, I had been working, again, as I mentioned, as a software engineering manager at Amazon. And prior to that, I was a software engineer at Amazon. Even before that, I was more involved in startups. So I kind of took a path where I started at startups. Started my own at one point, doing some home theater audio systems. It was kind of fun. It was a friend of mine. We lasted about three or four years, and then the company kind of failed, and we had to go someplace else.

4:23 During that time, trying to save the company, I took on a little bit of debt. And so in order to kind of recover from that, I joined a big company like Amazon. I expected it was only going to be for a couple of years because I wanted to get back in startups, but I actually really liked a lot of what I did at Amazon. I really liked the people. I liked the technology. I liked the challenges. From a point of view of just like an engineering world, You know, the big companies do give you the opportunity to solve problems at a scale that you might not see at a small company. I like to look at the fact that when you're when you're. You're dealing with a million transactions a second. You know, that one in a billion chance happens, you know, a couple times an hour. And so you have to build these reliable systems that are able to scale. And people are depending on your systems to make their lives better. Like at Amazon, like in payments, like people will notice if you accidentally have a bug that double charges you. It doesn't matter what it is because it potentially can directly impact them.

5:26 When I was there, you know, just the customer-centric sense of Amazon leads you to kind of talk to customers and sit in on customer calls, and you actually get to hear the impact that your software has. Like if you double charge someone, they may not be able to pay their rent the next month. And that's a real problem that you have to face. Okay. So you spoke about your startup, Google. So it's very different pattern of company. What's your best souvenir or your best meetings that you had in your career? So I think actually one of the ones that really was important to me was at Google. There was a manager there that I had for most of the time I was at Google. And she was the one that kind of actually helped me realize that I could do more than what I was doing. At Google, you know, the path to promotion is very self-driven. You nominate yourself for promotion and, you know, you...

6:30 If you succeed, you continue to move up. It's really hard sometimes to take that step to realize that maybe you are able to do a lot more than you're currently doing. And so she really encouraged me to just kind of stretch myself in a lot of different ways. She helped me even when I was going to go for promotion. I actually withdrew one of my applications for promotion. She pushed it forward, even though I didn't necessarily think I wanted it. I really wanted it. You know, she put me into positions where I could start growing beyond just like managing and leading a single team to managing a slightly larger organization. And it was really inspiring to have somebody actually have confidence in you like that, to see you. In a way that you didn't necessarily see yourself yet. And that for me kind of changed the way I looked at myself. Ironically, it's probably also one of the reasons I left Google was the fact that, you know, she had that faith in me that I could do more than what I was doing. And she tried to set me up for success.

7:33 And I had to actually look a little bit elsewhere for that. You know, I'm super grateful that I got to have her as a manager. She was probably one of the best managers I have ever had. And I actually take a lot of that that I learned from her managing me to how I lead and how I manage people. It's very much a personal thing. It's very much not about telling people what to do, but actually seeing what the potential is in the people that you lead and actually try to lift them up. try to get them to realize that they are more than what they may think they are, because I think there's a huge amount of potential in a lot of people. And the idea that there's this imposter syndrome, I think, is really very real. It hits everyone. And even if you think that you're alone feeling this way, almost everyone is like that. And I think a good manager, a good leader looks past that and actually can see what that potential is and get people over that hump to actually start taking those risks to have that support.

8:33 Because having that support from a leader, from a manager is a huge deal. And it really changed the way I acted, the way I managed, the way I led. And it really helped establish just who I am, I think, as a manager. Okay, so she was really a mentor for you? She was really a mentor for me, yeah. Is she today a mentor? Yeah, she is. Yeah, I still have contact with her. I think she's an amazing person. And I probably would not have been able to move to Europe and take on the role at Sqreen without her support. It was kind of funny when I announced that I was leaving, her reaction was, oh, that's so great for you. It was, you know, she was sad to see me leave, but she saw the opportunity. And I think that says a lot of who she was, who she is, I guess, as a person, as a manager. She, you know, obviously wanted to keep me at Google, but she was just happy for me to take this really big step, this stretch of myself to see what I could do. could do. And, you know, I have her support. She's made herself available when I've had questions about, you know, the sorts of problems that you face when you maybe are leading a larger organization.

9:42 Because at Google, I had a couple small teams, but now at Sqreen, you know, it's the entire organization is mine. So I have to work through that and she has some more experience in those areas than I do. So yeah, she still is very much a mentor to me. You manage how much person at Google? At Google, I had about 18 reports at one point. Yeah, which is a great team, in fact. It's a great team, yeah. Well, it was two teams, and one of the teams was managed by another manager. So you have the two roles, you manage people and you manage a manager. Yes, I had both those roles, yeah. Okay. And how do you feel different to manage a manager and manage people? So I think manage a manager is a lot more coaching versus helping direct feedback all the time. I think, you know, when you're looking at managing a manager, you're very much trying to help them grow to grow other people. And so to do that, you know, you have to give them the chance to. Have their space, have their leadership area.

10:43 You don't want to basically be telling them how to do that job, even if you used to do that job. I think that's a really big thing is that you kind of are there to support them, help them take those steps and be there to catch them when they maybe, when they maybe not fall, but when they stumble a little bit. I find that Managing engineers directly, you know, there's a little bit more of the kind of deep dive into what they're currently doing, how you can support them directly versus kind of indirectly. In general, it's a slightly different way of managing people, but I think it's an important difference. So today you are at Sqreen. How big is your team? To the culture? So at Sqreen, we have about 15 or 16 engineers at the moment. The culture is kind of a fun environment. I like the fact that we are very security focused.

11:44 We are a security company. And I think a lot of what we do that makes us a fun place to be kind of derives out of that. You know, security is a really challenging field. And we have a blend of people who are really strong security people along with more traditional software engineers. And we've been trying to build this kind of culture where we all are taking part in that security world. In the culture, is it, I assume you're not micromanaging. Oh, no, no. Yeah, no, I don't believe in micromanaging. One of the things I took from Google that I think is a really powerful thing is kind of the role of leadership and the role of management is kind of focusing in on consensus building. I don't like being overly top-down. I think that that is very constraining for people, for engineers, and it reduces the joy and ability to perform and to succeed if everything is being micromanaged from the top down from a manager.

12:49 One of the things that I really do love doing is that consensus building. Spending a lot of time listening to my team, listening to the engineers, seeing what they feel should be done. working with the product managers to find that. And basically then hoping the team realize that they are the ones that have a lot of the great ideas. They're the ones in the code. They're the ones that actually see what needs to be done, how the system needs to improve, and then working to get them to understand what to do next. I think a successful team needs to have that kind of combination of, yes, there has to be some top-down because the idea of the vision of the product, the vision of what the company is going to do is always going to be in the hands of a few people on the product side, the CEO, the head of product, that sort of thing. But on the engineering side. You still need to have a very strong technical culture, a very strong systems background, engineering background to build the system that will enable that product.

13:50 And so the combination of that kind of comes from like me, the CTO, other people with senior experience that understand how to build reliable systems. However, the engineers are there in the code. They know where the fragile points are right now, and they need to be encouraged to help propose some of those changes themselves. Because I think one of the things that engineers, in my experience, thrive in is when they are owning the project from conception to delivery. I think there's a huge deal of rewarding feeling when an engineer kind of comes up with an idea, produces a design doc, implements the code, pushes it to production, and they see that change that they drove from start to finish. impact customers, impact the system. To take the full responsibility. Yeah, I do. I think there's a huge deal of, you know, like Amazon, Google, they call it technical leadership. Things like ownership, dealing with ambiguity, you know, kind of focusing in on the customer, things like that. You know, I don't think the role of an engineer is not to just do what they're told from above, from a manager, from a product manager.

14:56 But I think they have to help drive themselves. and drive the product themselves, take that ownership. Because their job is not to just deliver code, it's to help produce a great product for customers. And that's partially on them to figure out what that means, mostly on the technical side. But, you know, occasionally they may have great product ideas. They should feel very empowered to talk about those, to talk to the product managers, to see if they belong on the roadmap. You know, it is a thing where everybody who is at Sqreen is a stakeholder in the product, is in the company. Yeah, they are empowered by the vision and the... Yeah, I think that's one of the things that really I loved about Sqreen from the moment I started talking to them was how detailed and how deep the product focus was of the company. When I was at Google, we were really far behind the stack. We were way, way down on the back end. And so it was very difficult for me and the engineers on my team to see the direct impact of what we did on end customers.

15:59 But at Sqreen, it is a customer-facing product. And so everything we do has a direct impact on customers and their businesses. And in security, it's hugely important. And so what I really love is the fact that we all feel tied to that, that we all feel empowered to make the product better and move it forward. What's the stack at Sqreen? Because I assume you have a SaaS part and plugins for security. Yeah, so the stack... is really interesting. So there's two major components to Sqreen. The SaaS part is pretty standard. It is a standard Python backend service. It exists primarily to take data and process it and identify where there might be risks. The other side that lives on the customer products, we call the agents, is a really fascinating thing. Basically, what we do is we produce these plugins, essentially, that customers can install into their software that provide details about...

17:07 The things that are happening, whether it's a case where they look for SQL injections or cross-site scripting vulnerabilities. Basically, they observe what's happening in there, report it back, or report details about it. It doesn't actually send any data across. It's all sanitized metadata. Basically enables the system to react to problems. So that even if you have vulnerabilities in your code, the agents that live on your side combined with the backend will enable the systems to react to that, to block potential SQL injections, block cross-site vulnerabilities. Shell injection, anything like that. I think it's a really fascinating set of technologies because what it does is it enables both people who don't have a huge security background to get really strong security right out of the box. Teams that do have some security experts can benefit a lot from the information that having these agents can provide. We call it application security monitoring.

18:09 And so there's all of these signals that we can produce and make available to security teams so that they can make really great decisions about how to direct security in their own companies. So your team is split in two? So yeah, there are two major parts. We just kind of did a reorganization that kind of emphasizes that at this moment. So we do have the backends or the service side team. It's not really backend because we do have a dashboard component as well. Basically provides the infrastructure that the agents send data to. We do some stream processing, digestion of the data, store it, make it available for the customers to look at and see, as well as provide the information back about what potential threats there are. For example, if... A company is using like the account takeover protection that Sqreen provides. If we notice that there's a large number of failed logins across the fleet from a certain IP, you know, the backend will detect that, send a note that, hey, this IP is causing problems, you should block it, and then Sqreen will block it on their side.

19:16 Or if we start seeing suspicious queries with SQL coming in, we'll be able to block those as well. I imagine you use a cloud a lot. Yes, we're on the Amazon cloud. So basically we are running. in the elastic container service. So we kind of have our system kind of auto-scaling on the cloud at this point. We make use of things like Amazon Kinesis to do our stream processing, which I think is a really fascinating technology. It's been really useful for us. We use various other pieces of SaaS to help monitor and understand what's going on with our system. Not afraid of being only on Amazon and not Google or the provider? At this point, the SRE in me is, yes, I am nervous about this. But the reality is that, you know, at our size, we kind of have to make certain decisions right now, both from a technical point of view, but also a financial point of view. At some point, yeah, I would love to get to the point where we have a multi-cloud, that we have more redundancy.

20:18 Than we have right now. You know, coming from SRE, the model of SRE at Google is hope is not a strategy. I can't just hope that Amazon is going to be fine. But realistically, you have to pick your battles, understand where to go forward at given times from a technical strategy. And right now, yeah, we're just on Amazon. Yeah, it's more easy when you are 20,000 than when you're 16. Exactly. Yeah, I mean, at Google, you know, you can have it hugely diverse across the world, lots of different data centers, lots of different technologies. When you have 15 engineers and, you know, several hundred customers. You have to kind of focus in on what matters. And a lot of that is ensuring that we are focusing on building the product out, ensuring that we have really good solutions versus necessarily adding a huge deal of redundancy that, yes, will help get us higher availability, but may not actually make a big difference in what we serve for the customers. What is a tech leader for you?

21:21 So I think a tech leader is very much a kind of a service position. You know, it's very much about meeting a need of the... teams that you lead. You know, I think the core parts that a tech leader needs to provide is to some degree a vision, a North Star to help the team find, understand what they're working towards. You know, I think it's too easy to kind of look at the work that comes through, especially when you have like an agile process with sprints, you go from sprint to sprint to sprint with a backlog and tasks. I think one of the big things that a tech leader can do and should be doing is providing the context for those steps, those work, because there's a lot more meaning in delivering things that are for a larger goal that you believe in, than just checking off that, you know, you delivered this feature or that feature. There needs to be a coherent story. And I think a tech leader embodies that, is responsible for providing that to their team.

22:22 But I also think there's a second part, you know, on the service side for a tech leader, and that's really the kind of inner focus on their teams and the individuals. Like, as I mentioned from... Earlier, I think getting them to believe in themselves and see how they can grow is a huge deal. I think a tech leader needs to listen to the people around them, help them understand that they have great ideas, and encourage them to actually act on those ideas. You know, any leader needs to be there to help people take those steps, go a little bit, take those risks that they may not be comfortable doing. And be there to provide support if it doesn't work out for them. But I think It's an important thing for a leader to encourage, but also protect to some degree and help learn from it. Right. So when there is a stumble, you know, like, again, I'll go back to the SRE part, the postmortem. The postmortem is a huge part of SRE culture because you can learn more from failure than success. If you go and you're successful, it might be luck.

23:23 If you fail and stumble that first time, there is a chance that you can take a look back and understand maybe where those problems were and use that to grow. There's nothing worse than stumbling and falling and failing and then not learning. And I think a tech leader needs to be aware of that, you know, and help people to learn from those mistakes, to take those chances. And if they are successful, to help them realize what made them successful. Because again, we... Make assumptions that everything went right, how much of that was luck, how much of that was, you know, deliberate choices. And we need to make sure that people kind of see those things and are able to learn from that as well. So you open an embrace failure only if there is learning? I think so, yeah. I mean, again, if people don't learn, they will continue to make those problems, and that is a problem. You know, I think you have to take risks to do anything great, and you need to give room for people to take those risks, and hopefully you'll be in a position to identify if they go too far off the path to keep them.

24:30 maximize their chances of success because you obviously don't want to go yes go do this and then come back and then go well why did it fail when you knew like right at the beginning that they did something wrong you know it is encouragement but it is guidance as well because hopefully you know through your experience you have seen how certain things fail how certain things can go wrong And so you can provide that kind of coaching, that kind of guidance early on. But still, you have to allow people to take those risks. And I think that's an important. And how do you manage to be sure they keep the pace? I mean, so it's all about communication, right? I'm a big fan of constant one-on-ones with my engineers to understand, you know, to talk to them about what's going on, you know, what challenges they're facing, what they're worried about. They hopefully will be honest to me when that's there. If not, you know, I'm a big fan of just listening to what's happening in the office. You know, I don't always talk, but like I'm always listening to what the conversations are.

25:32 I'm always listening to, always looking for reactions, the way people are feeling things out. I think it's important to just be observant, to listen to people, to talk to people, to keep track on things. Status meetings are a thing, but I think the personal conversations you can get a lot out of and understand what they're doing and how things are progressing. Are you still coding? Yes and no. At Sqreen, I have not written any code yet. And it's a yet. I intend to. I still very much like to be technical. I think it's a really important thing for a technical leader to understand how their system works to some degree. Like I will never... Impose myself or inject myself into a major feature that needs to happen, needs to be delivered. Because one, my engineers are really great and they're probably better than I am at this point. But two, it's You know, being in my role, I can get pulled away at any moment, any critical path on the technical side.

26:36 I can't be there. However, you know, I do think it's important to understand how your system works so that you can use it to inform some of the general technical strategy. And so I would very much like to get to the point where I am, you know, doing a few things here and there to kind of seeing what some of those pains are. Like, I believe that the developer experience is a very important thing for productivity. I think it's very easy for engineers who are doing the coding every day, working with the tools every day, to just kind of accept that this is how things should be. I would love to get to the point where I can start to see how things are working, you know, from a developer day-to-day point of view and see if there are things that should be changed, could be improved. You know, I've been lucky enough to work with some really great development systems at Google and Amazon. You know, there may be parts from that experience that I can take back and help improve the Prove-It Sqreen. But yeah, in general, I do like technology. I think it's one of the most fun parts of the job. It's a fun part, but you insist on the fact that it's important.

27:37 What do you feel? Why do you feel that's important? I think it's important because we work with engineers every day. Seeing what their challenges are makes it much easier to help them out, I think. You know, to see what their pain is, to see what their challenges that they face are. You know, you can do that potentially without being involved in the coding side. But I think having those conversations with them so that they can open up and talk about the challenges that they're facing with somebody who actually understands what's going on in the stack is very valuable. You know, you don't necessarily have to code all the time. Maybe it's just on the design reviews or... Or other parts of the technical stack. But I think being technical is an important part of being a tech leader, whether or not it's writing code. Are there anything that you want to do, but you can't do to time constraint?

28:39 So, again, I think right now at the moment it has been a little bit on the coding side. One of the things that I really am looking forward to doing is to talk a little bit more with the teams about some of my experiences, especially on the differences between technical leadership and management. I think a lot of the people that I've spoken to so far at Sqreen don't necessarily see that, you know, there is, there should be and must be like a path to develop as a technical leader without taking on people management skills. And so I would really like to. Kind of spend a little bit more time kind of going over my history about why I moved from engineering to management and why I don't think that that's necessarily the right path or the only path for advancement for everyone. I strongly believe that there are two different skills between technical leadership and people management, and they're not always the same people that have both. And it is important to let people know that it's fine to be a technical leader who is not managing people.

29:45 In fact, the company really thrives on those kind of brains and that kind of talent and that kind of skill. Like I can't do what I do unless I have really strong technical people that I can trust, that I know that understand the problems that can... can dive deep into it and provide a high level view of it so that I can kind of make other decisions that I can focus in on strategy and business related stuff and then use that to inform what they do. What's keeping you awake right now? Other than my cat. It's probably the balance between the product and the technology. We have a great product, as I've mentioned, and there's a really strong roadmap going ahead for it. And I think as engineers, when they are working on the product, they are really happy because they start seeing the features get delivered to their customers and start to see what impact that can have. On the technical side, I am an SRE.

30:47 I know that the system that we built may not be capable of sustaining us as we continue to get more customers, as we continue to get more features. And so trying to figure out the right balance between building new features and building out on the infrastructure so that those features can be delivered in a successful way is a really challenging task. And also ensuring that when we are focusing in on those technical tasks, that they are just as rewarding to the engineers. Like we have a very, very talented team and they are very capable of delivering all of these things. But again, I have to make sure that there is a message that ensures that. both tracks are rewarding, that they're not just going to be fixing bugs, that these bugs serve a purpose. And, you know, especially if you look at the likelihood that some of these bugs are customer impacting, that makes them even more important, even more valuable. And so it is a case where you have to find that right balance to keep them engaged, to keep them happy, to keep them really joyful about the product.

31:54 No matter what tasks they're working on. Okay, great. And if you had a magic wand? If I had a magic wand right now, what I think I would do is kind of find the right people to fill in some of the gaps in the organization. We've just recently taken on a slight reorganization where we have revolved the teams around squads, basically, so that each squad has essentially everything that they need to do to deliver great software. At this point, we don't necessarily have all the people to fill all those roles. And so there are a number of cases where people are wearing multiple hats. So like our head of product is also acting as like a product manager for the squads. I'm director of engineering, focusing in on some of these big, you know, strategic technical side, but I'm also, you know, day-to-day managing all of the engineers. You know, we have a, we're going to need an engineering project manager to help facilitate the communication and and the processes that the teams use.

33:02 We're going to need to have people filling in that gap for time to time. So if I could have a magic wand, all those gaps would be filled and we would be able to see how the organization runs when it's fully staffed and fully capable of delivering. Is it a funding issue or a recruiting process? It's the recruiting process. It's not funding or anything like that. It's just finding the right people, especially when some of these, the things that I have seen from the United States, they are not necessarily common. Tasks or common roles that I've seen here in Europe or in Paris. So like the idea of like a technical project manager or an engineering project manager, I haven't seen a lot of profiles, people who have done that before. And so finding the people that I can believe will succeed in that role and do what we need, you know, is a little bit tougher, especially since if we're bringing in the first person to do this organization, we want to make sure that it's successful. And so, you know, it's a little bit more care on that right now. So it's, you don't cross, um, passive people that do that, but we haven't crossed many.

34:04 Um, so we've talked to some and just, just, again, it's just finding the right person at the right time. And again, we, we try to have a very high bar. And so we very much want to bring people on who are going to succeed. And so we don't necessarily immediately, you know, just take somebody to fill a gap for the sake of filling that gap. We want to bring in the right person that will solve that problem that we can believe will succeed. The iBuy is from Google. Habits or you had it before? I think it's not just Google and Amazon. Like when I was at some of the smaller companies, I saw a lot of cases where, you know, the bias to fill gaps and fill holes ended up backfiring. That, you know, if you bring in the wrong person, the problem so that that can cause often outweigh the benefits of or the cost of saying no to somebody who may have actually been able to do that. You know, yes, you have to take risks. And you have to be able to, you know, get somebody that you believe can grow into that role.

35:06 But if you're very wrong, it can be very devastating to an organization because it doesn't just impact that one person. It impacts all the people around them. And so a really bad hire can actually impact an entire team and set them back and actually maybe even drive some of them out who really don't want to lose. Do you have tips to assess people for a certain position? It's very tough. I think one of the things that I do like is a lot of the discussion about just like past behavioral things. I think maybe this does come out of my background with Amazon. Amazon is very big on, they have these leadership principles. They're not perfect. But they do help you focus in on certain things that may enable people to succeed outside of just the pure technical. I think you can judge the technical side through coding and other kind of technical questions. But understanding like how they react in certain situations, you know, give them, you know, ask them for a time that something happened or, you know, ask them, you know, to talk a little bit about their interactions with customers, things like that.

36:11 You can get an idea of how they have worked in the past. And I think that's a very good way to kind of project forward about how they will go in the future. Okay, great. Could you share us three tips for our tech leaders before closing this conversation for others like you, manage platform or tech? Nicole, teams. So I think the first big tip is actually, you know, to just listen. I think, you know, it's very easy to go into a situation and think that you have the answers. You know, every situation is different. People are different. You know, organizations are about people. You need to actually talk and communicate with the people to find out what their problems are. A lot of the benefit that a leader can bring is kind of through subtle communications, subtle prodding in one direction or another. I think teams work best when they all are moving together. They're not going in a direction because you say you must go this way. You have gotten to a point where listening to their problems, you have provided them enough evidence that moving forward in this direction is the right direction.

37:23 Another tip, I guess, would be to kind of just value your people as people. One of the tools that I use a lot is the scheduled send on Gmail. I have a schedule just because of my day-to-day life where sometimes I'm looking at email and responding at midnight or one in the morning. I don't ever want anyone to think that that should be what they do, that just because I'm looking at email at one in the morning, they should be ready to answer an email at one in the morning. So I specifically, you know, if it's after hours and it's, you know, not like a fire, you know, I always make sure that I send my emails. to go out like nine in the morning or something because I'm intending them to wait. So why send it while they're, you know, should be sleeping. So I think that's an important thing. And I guess the other big one is, you know, just to understand that, you know, your systems are fallible and that they will fail and that the people who are supporting it will stress about that.

38:24 And your job is to make sure that when things go wrong, that they're in a position to learn from those things. You know, the post-mortem culture of SRE works both technology, but also processes, I think. Okay, so debriefing is? Debriefing is tremendously important, yes. You told us about your one-on-one, but what are your most essential tools or routines in your daily life? So I kind of went over a few of those. I think, you know, I'm a big fan of communication. So I guess just the tool of listening to people is a big deal. Talking. You know, whether it's in Slack or any other medium that people are using to communicate, to just be listening and observing all of that. Again, I mentioned the schedule send for Gmail. I think that's a huge thing. I use that, you know, all of the time as well. Okay. It's very strange because you... You spoke about listening communication a lot.

39:27 And for Europeans, We think that American culture at work is more about doing and not talking. I think it depends on the people. There is a lot of that. I have been parts of organizations, especially at Amazon, where it is about management is there to tell people what to do and to get them to work towards a vision that is coming from above. When I actually joined Google. The person that was an SRE, one of the SRE people talked to me, really talked about a big part of Google's culture comes from the fact that it was a partnership, that it was two people. And from the very beginning, you needed to have consensus between the two founders in order to be successful. I really think that that's kind of that shaped the way that I looked at things. It is about doing, but I think to do, you have to listen, you have to understand, you know, there has to be some sort of meaning in what you're doing.

40:35 Nobody's actually going to get a lot of joy out of just, you know, submitting code for the sake of submitting code. There needs to be an understanding of what that motivation is and why they're actually doing it. And unless you're listening and communicating, you're not going to get that in place. And you will lose people. I mean, losing a person, losing an engineer because they don't like what they're doing, you know, is horrible. They say that, you know, people don't leave jobs, they leave managers. And I think a lot of that is because, you know, managers, if you're not listening, you're going to just be treating the people as if they're there to do what you want. If a manager needs to be successful, if a leader needs to be successful, they need the people to believe what they're doing is important. And you can't do that without communication. You have books or presentations that mark your career? I don't know so much. Like, I want to... One of the ones that I don't know if it's a great book anymore, but it impacted me early on was Sheryl Sandberg's Lean In.

41:40 You know, there's a lot of criticisms about the book and how it, you know, it does necessarily evoke some sort of privilege. But I think it was the first book that I read that I actually identified with a lot of the problems, you know, just self-confidence, questioning about, you know, what I should be doing, the imposter syndrome related stuff. It got me to actually kind of rethink how I interact with people, how I can actually be more effective, you know, not being afraid to speak out, things like that. I think that was a big one. It's not necessarily marking my career, but there's a former, well, I mean, it does kind of explain why I moved to management to some degree, is there is a presentation from an ex-Google SRE. Her name is Tanya Riley about being glue. In which being glue is this role that a lot of people take where you're being more effective, but you're making your team more effective by filling in gaps.

42:46 And the problem is like a lot of people who are not senior kind of fall into that and they don't necessarily get recognized for that. When I moved into management, I kind of realized that a lot of what I had been doing in the past were beneficial for me as a manager, but as a software engineer, I wasn't necessarily being seen as being effective for doing those sort of things. Despite the fact that if I were more senior, I probably would be. And so it's that weird blend of like, if you do things that senior people do without being senior, you're not necessarily getting credit for it. But yet those are the things that senior people need to do. And so it's kind of this interesting balance there. So great. Thanks, Bess, for this discussion. It was really great for me. We'll get together very soon for a podcast, Tech Leaders Words by Tech.Rocks. And don't forget the Tech.Rocks Summit on the 4th of December at Station F in Paris. We will have a great talk from Alison, the head of people of Sqreen.

43:51 Et n'oubliez pas, le 4 décembre, le Tech.Rocks Summit à Station F à Paris.