Christian McCarrick  

This is simple leadership. Welcome.

 

Thank you to our sponsor, Auth0 for helping make the internet a safer place by offering identity as a service and supporting this podcast.

 

We’re here to learn from New and seasoned technology leaders who all share a passion for improving the craft of technology management. Let’s take a deep dive into management and leadership challenges and best practices specific to Software Engineering and Technology teams. Do you want more engineering management leadership tactics and information? Subscribe at SimpleLeadership.io to receive the latest updates from this podcast. 

 

Hi, I’m your host Christian mckarrick. This is the Simple Leadership podcast. Welcome back. Today’s guest is Loïc Houssier. Loïc started his career as a security researcher in France and has a background in mathematics and cryptography. His career evolved to more management roles in software engineering, focusing on critical infrastructure of European administration’s working for Orange, Thales, and Naval group. He eventually decided to join a startup, OpenTrust, to help with growth and organize the teams and eventually became the CTO there. Luke joined DocuSign via the acquisition of OpenTrust four years ago and is today a VP based in San Francisco leading DocuSign’s efforts on mobile, eCommerce, and billing systems. On today’s show, we discuss mergers and acquisitions along with engineering team efficiency. Good afternoon, Loïc. Welcome to the show.

 

Loïc Houssier  

Well, welcome for having me. 

 

Christian McCarrick  

Absolutely. And look, I had the pleasure of having dinner with you a few months ago at a Plato event. I greatly enjoyed our conversation at that time. So I’m super excited to kind of continue the conversation and to have you on the podcast today. So thank you very much for joining.

 

Loïc Houssier  

Of course. And I’ve listened to your podcast more than a couple of times and I feel I was a failure or not to be a part of the people that you haven’t interviewed so far. So thank you for having me again. 

 

Christian McCarrick  

Oh, absolutely. Thank you. My pleasure. Also, Loïc, where are you calling in from today?

 

Loïc Houssier  

From San Francisco, so from the DocuSign office downtown San Francisco. 

 

Christian McCarrick  

Excellent, excellent, very close to me. I’m actually working from my home today in the East Bay, we’re pretty close to each other at least in the same time zone and in the same city. One thing I do want to point out to my listeners, I also apologize, I haven’t recorded an episode in almost six months. As some of you other engineering managers and leaders know, I’ve been running engineering for a super fast growing unicorn. And that’s pretty challenging. And it’s taking up most of my time. The good news is that I’ve been able to get some help on this podcast and will be returning to a more consistent schedule in the coming months. So definitely appreciate everyone’s patience  and thank you for all the listeners out there who have been pretty dedicated to the show, and have been inquiring when the new episode is coming out. And I can say, you know, when this launches, that’ll be a good New Year’s resolution to keep the show going. Like I asked all my guests, if you could just kind of give me a little bit of a brief background, kind of what you did to get to where you are today. You know what might be interesting to my listeners?

 

Loïc Houssier  

Yeah, so I’m now in San Francisco. I basically started my career in France, studied math, most of my time and ended up doing cryptography as my specialization of math. I started my career as a research engineer in the security field. I did that for something like three years and a half. In a big telco company, Orange, for people who are mostly in Europe. It’s a pretty big company, hundred thousand people, and that company is a pretty big structure. I’ve been working there for like three, three years and a half, I was saying, I moved in another big company like 60,000 employee called Thales, which was and still is working in the defense industry. And I was basically working on the security of critical infrastructure and mostly focusing on government’s *inaudible*. And I was there some kind of a half a security expert as you can be after 4 years of experience, but they call it expert anyway. But I was also basically managing the development of a platform that We were basically providing to, to our customers a woman’s. After that I had a nice opportunity to basically go outside of the software industry. So after seven, seven years in my career, basically inside a Thales group, there was a subsidiary called another group. And their focus is basically building submarines and frigate for the French marine. And basically, I took this opportunity to be outside of the software industry just to understand how the heavy industry is working. So I was there to help from an organization perspective with some kind of a program management background. And I was basically trying to apply what I’ve learned in that area, which was basically just amazing for my the rest of my career. So it was only two years outside of the software industry. That gave me the opportunity to basically help people that were way more senior than me, were more knowledgeable but as you could have field because I was basically newborn on this area and not knowing anything about what is a torpedo, well, what is a radar, but I still had to basically influence the way they work by providing some processes or tools, basically around their work. And that was one of the best experiences I had, which I could reuse as my job as a manager. So basically how to influence people where you don’t have the technical legitimacy anymore, which the more you, you climb the ladder, the less you can be really technical. So that was just an amazing experience. But it was still a big company. So after these two years outside of the software industry, I wanted to come back to my first love which was security and an engineering. So I had an opportunity in the tiny company of 60 people and they were looking for basically kind of a program manager with a security hat and working for the government. so I had kind of the perfect profile for them. And then they were 60. So I was so happy to have an opportunity to understand what is a startup. How this is working because I was mostly working on big companies with a highly processed and a lot of people supporting you. And I just discovered a world where you have to do everything by yourself, which has some downside. But the good side is, if you are able to do some impact there, the impact at this scale is huge for the company. So in that startup, starting to be like, some kind of a big Program Manager, and you know, having a dedicated software team because for my biggest basic customer, I needed to basically make some dedicated release with some specific modification for governments. And it was working pretty fine. And at some point, they moved in on the engineering side totally without any more customer relationship, and just helping teams to be more efficient. And I basically ended up being the CTO of that small company. And we move from 60 to 120 through an acquisition, and which was interesting because we called it a merge and not an acquisition. So it was basically two companies. As you can number one and number two in France in our area, and so ended up being 120. And that company has been acquired by DocuSign, four years ago. So managing, again, a merge of this time, it was a real acquisition. So we have been acquired. And I had to basically manage that. And I basically ended up going in San Francisco two years ago, who basically took on a bigger a bigger scope. And now I manage mobile, the eCommerce side to sort of self service side of the design. And I have some team in Brazil too. So this is what I’m doing right now. 

 

Christian McCarrick  

Okay, excellent. I love hearing how people kind of got to the positions they are today because they they really are varied. And it really shows there isn’t necessarily one path, which I think sometimes people think that there’s only one path to become, you know, software leader and the more people I talked to, the more I realized, and I hope my my guests realize that there is no true path. You know, I’ve often found in talking with some of my other guests on the show too that they’ve found that whether it’s in software companies themselves doing roles that are not necessarily technical, and or going outside of software engineering, I think it is those types of opportunities and experiences. I think everyone is pretty much said really helps them when it when they do become a software or an engineering manager. And those skills, like you mentioned before, helping you along the way on that path of becoming a better leader and a better manager.

 

Loïc Houssier  

Oh, yeah. When I started, so I was a security researcher. And basically, I was, so I was coming from a, it was an average University in France and the lab I was working at it was people from a school called Polytechnique in France, which is kind of the MIT in the US to give you a sense. So it’s as if I was coming from community college, or let’s say, definitely Bootcamp, and I was mostly working with people from the MIT. So that was just amazing for me, like the opportunity to basically ramp up and have all those brains that were basically running so fast compared to me when I just joined. And after three years I was, let’s say on par, I just I had this feeling so basically my ego was just too big. So basically when I moved to Thatles, in my first management role, my technical legitimacy was probably the first asset I was using to influence people. And then when I moved out of the software industry, I didn’t have that technical legitimacy anymore. So I had to put my my ego in my pocket and try to find other ways to have people listen to me. And that was honestly the best experience I ever had. So it’s just the understanding that you don’t have to be the best technical person in the room in order to make a decision or two, to make sure that people follow the same path and and listen to you was, was just amazing for me. That was eye opening. And I’m not sure that if I, let’s say let’s assume that I would have just continued the same road on the software industry. I may have become a jerk, honestly. I could’ve become someone with a big ego and just trying to be there. Just like “I know, I know I’m the best. I know what I’m talking about. So guys, you just have to follow me”, I could have become that person, honestly. But that experience, the fact that you’re talking to people that are just in a totally different field, you have to find the ways you have basically have to learn to listen. Because if you want to help them solving problems, you have to listen and understand what they do, and not assume from the beginning. So yes, that was that one of the suggestions I can give to people is try something that’s totally different. The experience that you will get there will be tremendous.

 

Christian McCarrick  

Sure. And I think the higher you go in software engineering, leadership and management, the more that you actually have to rely on those skills, not just downwards to your team. But as you’re talking with the executive team, you’re talking with people in other departments sales and marketing and you have to talk to board members. You have to rely on those non-technical skills to be able to translate as you mentioned, to have the influence, to have the proper communication, to get what you need to get done in a way that’s not relying just on your technical chops. 

 

Loïc Houssier  

Definitely, definitely. So as part of those two years, so one was working on submarine…the other year, I was working on nuclear plants. And I was kind of a deputy director of the operation. So I basically was a kind of a young guy. So walking aside, the really senior person on that area that was basically managing contracts with the French. I was a four wheel supply main contractor. And I was basically working with him and he was explaining to me how to manage the different contract, how to do claims on some contracts in order to achieve some goals strategically on other areas, because of the levels we can have between the different contractors. So trying to also understand all the businesses side and not only the technical side, trying to understand how they think and how they look at the problem was just tremendous. And now when I’m basically managing Europe and trying to understand what is important for my boss or  marketing or product commerce side, and it’s really helping me a lot to figure out and try to understand how they think. And not only being good at managing technical people on all my directors, so it’s definitely a big asset.

 

Christian McCarrick  

And something I asked all my guests is any mistakes you’ve made that you can publicly talk about, maybe protect the innocent or whatnot. I know. We all have probably a whole litany of them. But part of I think what so my listeners get out of this show is understanding that none of us are really perfect. And we’ve all had our mistakes along the way. Any ones that come to mind for you that you can share?

 

Loïc Houssier  

Yeah, basically, I will talk about two. So the first one was on my very first experience, so I had the team that I was assigned to for a government project. And basically I was stupidly assuming other people that will efficient well look at me, so I was like “They should be outspoken. They should speak loud, they should be always jumping on to new opportunities, they should provide value pretty fast in mostly working on a quick and dirty and not slowly losing time” and stuff like that. And I had that guy on my team. He was so slow. He was really slow. I just requested a small document for the particular customer to explain how we do things from basically organization perspective. And he was a guy that was on the team for quite a long time. And I said, “Yeah, I need that document pretty fast and it’s fine. basically give me a two pager and this is just what we need”. And after a week, he came back to me and said, “Yeah, just a couple of more days”, so “Okay, that’s fine”. And then like midweek after that come back to “Are you OK, are you good with the document? Can you provide it to me?” “No, no, a couple of tweaking again”. So basically, it took like something like three or four weeks to provide me with the document and I was totally going crazy because if I were me, I would have done like two pages in one day, it would have been good enough. So I went to my boss and I said, “Damn, I cannot work with that guy, that guy in my team. It’s not possible, took a month to provide that document”. And he basically clapped, looking at me and saying, “Congratulation”. So what’s up? “Why are you saying congratulations?”. He said “No, you just made your first management mistake”. I was kind of curious about it and pretty defensive. And he said, “So describe to me the guy”. I said, “Well, he’s too much on the detail and is always taking the time to be sure that what is written is right, and is not able to do some shortcut”. Okay? So basically, you know, the guy you know that this is the way you behave in What did you ask him by to provide me with a two pager like a quick and dirty. So basically, your mistake is that you assigned a guy to the wrong task. This is your fault. And that was the very first time that I basically looked at it in a different way and the way my manager was direct with me, so there’s a lot of learnings from that. So basically, my manager was a great mentor, and was fairly direct with me. So he was not trying to say, you know, everyone is different. He was really blunt and told me you made a mistake, and this is the mistake. I’ll try to think about the say it in a different way right now. So that was first thing that I learned from that is being direct is probably the best way to help people to improve. And as a manager basically is like it’s my role not to change people, but to understand how people are efficient in their own way and basically give them the work where they will be successful. So which is basically the way we did it after that the guy was working and we just curious about what it would be. I was happy to work on and willing, it would be feeling efficient and happy to work and basically manage all the configuration management of the project, which in the defense industry is something that is pretty huge. And you know he did amazing work, amazing work. I was really quick on judging that person just because he was different than me. And basically I learned that I was the guy basically world In that story, so I was lucky that I had a good manager calling me wrong on this. And that was early in my career. That was one of the best things that I’ve said the best mistake that I’ve done in my career. 

 

And I have a second one. So this one was pretty early in my career. This is usually what I tell to my folks is like, you don’t have to make all the mistakes early in your career, you have to learn from them, whether you are in your 20s or you’re in your 40s. And so I can talk about this one. So it was like kind of eye opening for me. Discussion again, with my manager, I read a lot about management and how you can manage your priorities and how to set them up and the difference between urgent and important. I used to talk about this, that that story and the way to look at management as someone that is juggling with eight balls, and you’ll see he has 8 balls and is not able to basically manage more than eight balls. Balls being project being initiative, this is only what he can do. And if a ninth one, he’s coming on to another one, he’s coming on top of it, he needs to drop one, I would say the least important of that and delegate that one to the people that are below. And each one in the basic organization. Is able to manage, let’s say, between six and eight balls. So basically, if everyone is dropping the least important balls that they are managing, at the end of the day that people that are like really working, they will stop doing the things that are less important for the company. I love this idea of way to manage the real priorities because there’s kind of a funnel where you know that the things that are the least important won’t be worked on. But I will say there’s a difference between understanding the concept and being able to apply that in day to day life. And coming back to my background, so I was kind of a program manager. So I used to do a lot of dashboards with a lot of KPIs and for quite a long time and I was always trying for each of my teams to understand all those KPIs. So I wanted to know anything, everything. So whether it is the throughput of the projects, the number of … and what are the SLAs on top of it. I wanted to have all those information. Even if I knew my priorities, and what will my priorities, I had the feeling that and this fear of missing out something. So I wanted to receive all those KPIs. And I was basically putting a framework for the semi boss team in order to for him to have those the information that I thought were crucial to drive your business or your teams. And you look at me say how much time do you spend on this? Yeah, I don’t know. But it’s, it’s obviously building the framework is pretty long and everything. He said, this is not where you need to spend your time. What are your priorities? So this my priority and say, “Okay, so how much time you spend on that?” “See, I don’t know maybe like, in my day, in my week, maybe a 15 to 20%”. He said, “Forget about those KPIs and spend 60% on those priorities, this is what I need”. And basically, that’s all it comes down to the what is your limit in terms of workforce, what you’re able to achieve, and it was always hard for me to let go and not see them, obviously, every single detail, but there’s so much only so much you can do. There’s only so much that you can look at. And I was basically at the time where I need to let go, I need to let go. And just basically, you know, so I won’t look at those KPIs. Just my guys will look at it. I need those teams to look at that and I just need to trust them. And they will inform me if there’s an issue on that so that I can just look at the right KPIs that make sense for me, and they were the ones that are really important. And so even if I’m in my 40s, and I’m a VP now, I was still struggling with that. And it was like two weeks ago, and that discussion was eye opening for me. So just you know, for the people that are listening to that maybe the takeaway is like, you don’t have to make all the mistakes early in your career. Even if you are pretty advanced in your career, it’s totally fine, to accept that you’re making some mistakes, and you can change the way you look at things. Two big mistakes, I would say that I can disclose. 

 

Christian McCarrick  

Absolutely. And I think it’s true. I think we do make mistakes every day. And as you point out, the the most important thing is being open to learning from them. Some of those learnings can come from not only your manager, but they can also come from your peers. And they can also come from some of the people you manage as well. So be open for learning all up and down and sideways as well. You know, you’ve mentioned a couple things, you’ve been a part of a couple of mergers and potential acquisition. And I think this is something that almost all managers will have to deal with at some point in their careers, right, especially fast growing companies. You know, it could be called a reorganization. And that really could be something that is pushed down to you or to something that is initiated by you yourself as a manager. It could be large, it could be small. There’s other types where you talked about two and you’re actually combining two different entities and what we’ll chat about that in a second, but let’s walk through some of these kind of scenarios. As a manager of teams, if you’re looking at your teams and you’re looking at again, as a efficiency are the things, what are some of the reasons that would kind of make you as a manager, look to want to potentially want to merge teams?

 

Loïc Houssier  

That’s a good question. I would say merge that I took my experience from was basically a business merge. So we decided to merge two different companies in which you basically don’t have the choice. And you just have to make sure that the merge is working well, and you’re trying to mix the culture, where that is basically a working product company. And then from that perspective, maybe a couple of thoughts, one mistake again, that has been done at the time. We called it a merge, but it was an acquisition. And when you have basically two different cultures, two different set of stacks and you have two teams that you need to work together as a one team, but they work totally differently. You need to be clear in the early beginning, basically what would be the set of cultural practices that will keep. In terms of merger was basically to say, in fact, it’s not a mergers it’s an acquisition. And I’m sorry, guys, maybe you’re not really happy with that. But you will have to convert within this set of practices or this set of stacks or the set of to set because for efficiency reason, we cannot have like, I don’t know, two CICD  processes, or so many stacks. So you will have to change. And this is one thing that we didn’t do very well in the beginning, is clearly set the expectations. So people were like, yeah, it’s a merge, but we want to keep our stacks. It’s another team. We don’t have projects together. So nothing was really clear. And that was probably one of the key learning that I have right now. It’s if and when we do acquisition, it’s to be clear on setting the expectation.

 

Christian McCarrick  

sure, from the very beginning, making it clear if there’s going to be a technology change or an acquisition, like you said, being clear about which one is going to be, I don’t say winning out right, but which one is going to be the ultimate path you’re going to kind of merge towards right or transition to

 

Loïc Houssier  

Yeah, and exactly what you said, you said, choosing the one that is winning out. But this is the feeling of the people that are already working, when you have to change your… your stacks to the the one that the other team is using, you feel like you’ve lost something. So there’s a feeling that you have to manage. But if you don’t do it, so if you don’t set the expectation in the beginning, people will always have this kind of fear. What I mean is, there’s a need for clarity, if you don’t have the clarity, people will always assume or they go on the path that is not the one you want to have. So it’s better to set the path in the beginning, even if there are some consequences to that. Some people may decide to quit because they don’t like the new set of stacks of your new set of practices or the culture. But if it’s clear in beginning, at least you can manage the consequences. If it’s not clear, it will lead to friction between the teams and a lack of efficiency.

 

Christian McCarrick  

Okay, and do you any tips that you would recommend for any, any managers that are leading teams right now that might be, you know, they’re getting acquired their recently acquired or you know, it might be something in the future? What are some of the top things you’ve learned? Maybe not as a, as a leader at an executive level, but more if you’re, you know, a line manager, maybe managing one team or senior manager. Any recommendations you have for how they can help their teams get through a transition like that?

 

Loïc Houssier  

Yeah, I guess the worst is the the uncertainty. Trying to be as transparent, seeking information. At first, I would say that the early beginning on the why. Why are we being acquired? What are the reasonings? Let’s say you’re part of the company being acquired, you need to understand why that your company is acquired. Is it acquired because they are looking for the tech stack or the piece of software that is fairly well complementing the offering. Are they mosty interested in it as a marketing asset, or is it they don’t really look down at looking at the stacks or the product you’ve built, but they look at the team itself. As a manager, you need to understand the reason for the acquisition to basically tell your team because uncertainty is the worst. And as the acquisition is moving, so during the due diligence, so after the deal is closed, basically explaining and trying to understand what would be the impact for the team and be clear. And in the beginning not trying to protect the team was as long as you can to protect the the identity or whatever trying to understand what is the overall goal of the acquisition. And if there’s a chance, let’s say I don’t know you’re part of an acquisition and they want to change the way you hosted. So you were in a Ws and they want you to move to GCP. Or you were using some monitoring system and they totally want you to change that how you will make it even the stacks. They want to change the language of your of your software and wants you to rewrite about of it, I think this is the kind of information that needs to be clear from the outset as soon as the as possible, because no matter what you will have to manage the transition will say sooner or later. And the sooner you know, the better you will be prepared and the better you and the people you manage, will be able to provide you the feedback. Some people will say, “You know what, if you’re changing that, I will quit”. So then you know, so you will be able to be prepared for that and to to manage that. If you don’t also seek those information and share that with your team. Basically, that would be way harder to manage. 

 

Christian McCarrick  

Okay, sure. Anything post acquisition—so you’re a manager the first 90 day. Is there anything important that they should look to do or try to manage through that transition? Because I know as you said, there’s going to be some uncertainty. It’s a little bit of unease, anything that a manager post the acquisition/closing should focus on?

 

Loïc Houssier  

Try to follow the change and not be reluctant to the change but with an acquisition you will go through change no matter what. Whatever it is, maybe you were using title when you will be using JIRA. Maybe it’s a downgrade, that’s fine. Maybe you were using, I don’t know get lab that you need to get her or maybe you were using Slack, you need to, to use Microsoft Teams or whatever. I would say even though it’s usually the the silly stuff. So for someone moving from the one that I would say instant messaging to one another, in the big scheme, it’s kind of silly, not really important. But this is the kind of stuff that basically will annoy most your team. So you need to be aware of the change and have the change to move as fast as you can. That is really important. The second aspect is making sure that your team has a mission, it needs to be clear from the beginning. Let’s say in the first 90 days, there will be a lot of work for the integration. Integrating the systems, integrating the product, maybe you’re doing some change in the stacks. But in the long run, what will be the mission of your team? And that is really important especially if the acquisition of the merge make you some kind of a satellite site. So I will give you an Example: DocuSign has two main offices, one in Seattle and one in San Francisco. But we have offices in Paris, in Tel Aviv, in Warrenville, in Chicago, and South Paulo. When 70% of your workforce is in basically the two main city sites in the US, you have to make sure that these, let’s call them satellites have a real mission. Because if they don’t have a real mission, it would be really hard for them to exist. So it’s, if you’re part of those small teams that have been acquired by your big thing, you need to be really clear and understand what is the mission so that you people understand that they belong to something that is bigger. And it’s, and it’s really important.

 

Christian McCarrick  

Absolutely. And that certainly helps with motivation as well. And I think one last thing to add on this is, as I’ve gone through some of these myself, there’s an urge, either by yourself or by some of your teams to maybe make a rash decision. You know, something that they might make emotionally, when, as you said, it might be something silly like, like an instant messaging tool, and they might be willing to change jobs over that. Well, I think in some cases, too, it’s give it a little time wait and see how things are so you’re better able to make a more sort of impartial decision instead of just a pure emotional one.

 

Loïc Houssier  

Yeah, I would also add, it’s important to understand because I’ve heard that so many times “Ahh they want us to change to their tool, but it’s not the best one”. And trying to first understand as a manager of that, the best solution for your team is maybe not the best solution for the company. That is something that is hard. So for example, I don’t know—the database. Maybe your solution is way better and more efficient for your product. But at scale, adding your centralized DBA team that are really specialized and able to choose one stack or one version of the database is probably better for the company, in terms of SLA in terms of performances. So maybe for you it’s not optimal, but it would be for the overall company. And that is one of the hardest thing to do is accept for the good of the company, that the your team is downgrading some of the aspects that they were doing. So that is one of the hardest thing to do. Because you have to be convinced yourself, which is hard. But you have to convince your team then this is not easy. 

 

Christian McCarrick  

Absolutely. I think that segues to into kind of the second part of this the conversation of what I want to get into around, especially as growing teams and companies grow that concept of what’s the most optimized thing for a team might not be the most optimized thing for the organization. And especially as you’re trying to build a engineering team that is operating as efficiently as it can and especially at scale. At some point, adding people linearly just doesn’t work. it incurs an increasing management cost. And of course, payroll is one of the largest expenses at a company. So what are the things that you have learned about scaling engineering teams and scaling them you know, as efficiently as possible throughout your career?

 

Loïc Houssier  

It’s a matter of prioritization. So when you want to grow and grow fast, my learning is focusing on hiring the right people is the number one priority. So you want your job to do, you want your job to do you have your, basically your release to, to go through the door, but if you want to, to scale, you have to hire other people that can make you scale. So when when we hire we try to surprise over here, we always try to find the people that have the network so that they can bring more people so that you reduce basically the kind of the lead time between the job offering and the people that come in. That’s one thing, talking about the tech stack. That’s one thing too, the more you bring out a new stack, the more maintenance it will need. So trying to reduce or converge into a standard in a company. It’s always good. And it’s kind of interesting and it comes down to the the way I do personally trying to manage things. There’s, we try to I don’t know if you read that book “The Zone to Win” by Geoffrey Moore. So it’s a different world basically world the famous one than “Cross the Chasm”, which is about product lifecycle and how to to reach your market. But he wrote the second one that he basically, I think he wrote it when he was working with Microsoft and Salesforce, basically (now I’m not trying to spoil it for people that want to read the book). He basically explained that there’s a way to look at innovation, try to be simplifying, there’s one side that is disruptive innovation, disruptive from your customer perspective, and something that is more like sustaining innovation or continuous innovation. So you have your current product offering and you add features on top of it. But those will say continuous innovation happens on the product or service that is already working, which is basically the bread and butter of your business. Here you cannot be too disruptive. So you cannot probably bring on new stacks or a new way to host, or a new way to deploy. You need work through incremental, small increment to make sure that you’re not disruptive. Because this is your business. So you cannot disrupt it. But on the other side on the positive, but you want to bring up a new service to the market on top of the portfolio you have, you can, you don’t have much customer yet. So you can be really agile there. And you can basically test new ways to host new ways to, to deploy. And so for example, talking about infrastructure, whether you want to be like your bare metal, have to do your managed communities on Google or Amazon. There’s a wide range of solutions. At DocuSign, for everything that is the core business, there’s one way basically to deploy the product which is on prem on our own data center as a new fairly, let’s say not cutting edge way. Because what we want to achieve is basically five nines and this is what we will achieve in terms of SLA, because our customers do not want us to basically mess with the, the desolace because of contract and when you sign a contract is is highly time sensitive. On the other side of the spectrum, we are providing innovation to our customer on some stuff that are kind of before and after the medical doctors signing a contract, preparing the contract or acting on the after the signature. And this is more using cutting edge technology. So we can have some stuff that are maybe, let’s say, are not yet mature terms of operations, or in terms of even on wage or, and but that’s okay, that’s okay, because we want to get fast. And we optimize for velocity, or compared to optimizing for stability, just trying to be on the growth side of things. So it’s, there’s two ways to look at the growth. So there’s a slow growth production business because you cannot just be like disruptive and the disruptive growth where we trying to adapt and to add more solutions to your current portfolio.

 

Christian McCarrick  

Yeah, absolutely. You know, I was just going to mention to even at Auth0, we have our core login flow is something that is absolutely mission critical and you know, that has to be met with the highest level of SLAs. But innovating around things like the dashboard or reporting or other types of things that providing gives us a little more flexibility to be able to innovate on that. Because even if that’s down for five or 10 minutes, it doesn’t have a huge impact. Now, we don’t want that anyway for lots of other reasons for perception of whatnot. But it, like you said, it does allow you to, to kind of innovate on the different areas of your product, depending upon how poor they are or not.

 

Loïc Houssier  

Yeah, maybe three, nine, it’s perfectly fine for this dashboard, compared to your very own audition mechanism where it should be at four or five nines because it’s so much critical. So yeah. 

 

Christian McCarrick  

Absolutely. One thing I want to talk about too, because this sometimes becomes a controversial topic is measurement and metrics. As an engineering manager, I have sometimes found teams skeptical and sometimes hostile to any type of sort of measurement and you know, talk about before wanting to measure everything with with some of your background, how do you recommend a manager to have conversations with teams about introducing metrics? And how they can be important and helpful.

 

Loïc Houssier  

I went a long way, as I basically talked before, I’m a data person and I love dashboards with like hundreds of KPIs that I can try to see and detect patterns to better understand how basically my teams are going. But eventually, now I can say it, I think it was, if not a waste of time, it was probably a waste of focus. So now, I would argue that, and this is what we are trying to do with my team is to focus the team on one or two KPI that makes sense. And so we did I did my offsites kickoff for FY 21 with my teams. And we spend basically that it’s all basically based on the company priorities and everything trying to define what is the definition of success for us. And our definition of success is probably not the velocity of the scrum teams. It’s probably not this level of details. We basically said okay, we need to release this by that time, and we need to change that architectural design. In a couple of, let’s say, two main milestone, basically team, so that this was the definition of their success. And we will all align that we need to optimize for that. And I’ve been clear that, of course, you want to be reactive on p ones on. But I would say being clear on what is the, the one big thing or the two big things that matters helps with the prioritization. Because when you’re trying to look at too many pieces of data or too many metrics. And again, and talking about the velocity of the scrum teams, based on the story point and everything Sure, obviously, on the paper is really good. It’s nice to see over time that your VC is trending down because the new employee are no more efficient and everything. So sorry, not the velocity 20 down, the trending up would be better. You get what I mean, right? It’s satisfying. It’s satisfying. At the end of the day, the energy you spend trying to put in business metrics. I’m not sure what types of business. I’m now in a position and I can say it. That is for me and my team that it’s probably better to focus on the one or two KPI that matters the most for the business, and making sure that those are good. And basically, the success will be there. And that’s all part of the discussion I had with my boss when I was trying to put that framework to have all this visibility and everything told me what about those small projects, if you when we say those big two, and all of those are basically are not very successful with dealing with that be a good year for you. So yeah, that would be a great year. If I fail to see I’m successful on those ones. So focus on those ones. I don’t care about the others. I will say it’s not I don’t care obviously about it. It was a word who said focus on those ones. So going down to the metrics now I’m trying to be as scientific as I can with my my lead. So that we are all aligned on what is the most important and the rest difficult without teams. They will have their own metrics. Maybe they will be a bit more detailed than I am. But at the end of the day, I’m fine. And I trust them perfectly to manage their… Yeah, I’m more like that now, it was a late change. So if I had to restart my mercury again, I think I will have less scrutiny on all those KPIs. And maybe be less picky when also working with my teams. 

 

Christian McCarrick  

Sure. No, excellent focus on what matters. And by doing that, you know, and if you measure what matters, then that’s the thing that the team again in a circle the teams will focus on. And then you’ll hopefully try to improve and make sure that they align to the business because ultimately, that’s the most important thing.

 

Loïc Houssier  

Yeah, and it’s, it’s funny, you mentioned “Measure what Matters”, which is a great book, and talking about rkR and stuff, and even if you look at those books, they provide a way to be aligned, but they don’t provide the granularity. And this is probably where I struggle. I won’t say struggle. I’m pretty okay with my career, but this is probably where I struggle with all those frameworks. It’s hard to adapt them or implement them in your ecosystem within your company and trying to find the right granularity. What shouldn’t be, what should it be those results that you put on the objectives, how many should be what what is exactly what you need? And it can depend, I think there’s no one size fits all. But, I more and more like, you need one objective and maybe one or two week period, that should be enough for your team, they should understand what is the definition of success with that little information.

 

Christian McCarrick  

Perfect. And as we kind of wrap up this episode a little bit. We’ve mentioned a couple of books here already. But are there any other resources that you have that you might recommend for a book, podcast, blog you like to read or anything that that either has helped you in the past that you recommend or something that you might have might have read recently?

 

Loïc Houssier  

Yeah. I would start with the one that I just finished basically, on Wednesday, when I was in Seattle, another snow which is the “Bad Blood” sort of story of theranos. And it is up at times. So I think this is that was a good book. Because for one time we were talking about a failure. And not about…on that will be more so maybe you are one of my two cents. But it’s when we listen to people that are like outspoken and successful in their career. It’s very impressive and I was looking up to those person that were like, you know, Steve Jobs but not only older, those guy like Elon Musk and everything and we focus on those successful people. You look at the gap between them and you and say “Damn, I won’t be able to, to achieve anything like that in the end”. That can be depressing, honestly. And again, you’re trying to understand what makes them successful, but you have this survival bias. So you’re looking at the other people that succeed, but what about the others—why people are failing? and I find that this book is for once looking at someone that was  brilliant, so being able to start that business at 22. And so she was basically uniformly recognized as a brilliant person. But still the company failed. And it was basically because of the poor management. There was some technical issues. But the poor management was one of the reasons. I found this book really interesting because for once we were looking at what management can play in your business. Even if you have a lot of money, you have raised a lot of money, basically end up losing your business because of your poor management. So that one was really interesting. And another one that I will mention is “Creativity, Inc.” I don’t know if you read this one, written by Ed Catmull. He was the CEO of Pixar. And he went also through an acquisition by Disney. And the book is about how to foster creativity in your teams. And there’s a lot of learnings for obviously engineering leaders because it tells how those guys were open to any comment on the other movies they were building. So from anyone in a company, everyone was able to raise their hand and say, “I don’t know, this piece this moment. I don’t like it because it’s whatever”. And they’re forced to have this energy where everyone felt totally allowed to, to express their concern about the piece of a movie.

 

Christian McCarrick  

Their legendary screenings that they used to do inside, right? 

 

Loïc Houssier  

Yeah, yeah. And that was just amazing. Of course, it’s obviously for people making movies, but you can definitely adapt for your own teams and try to foster that. I will say that kind of true, because it’s really easy for and I look at my key ones in my teams and they feel p ones being. Sorry, my young engineers so that I people that just joined a company straight out of college. In the beginning they can be shy and how can you during design reviews or during meetings—how can you give them the feeling that they are totally entitled to, to say what they don’t understand, or they want to challenge an architecture? So it gives you a lot of, obviously tips and stuff that you can apply. So I really love that. 

 

Christian McCarrick  

Excellent. Excellent. Well, couple of definitely good book recommendations that I haven’t read the theranos one, too, I actually have it, it’s on my book list to read. I do want to read that because I’ve got that recommendation from a couple of people now. What would be the best way for people to contact you? Whether it’s Twitter or LinkedIn or anything if someone had a question or or wanted to reach out to you about something on the show? What would be the best way?

 

Loïc Houssier  

Well, definitely LinkedIn. I guess it’s the easiest. I have a Twitter handle, but I’m probably mostly tweeting.  I’m not really I was really good at that. But definitely LinkedIn. So I think I’m Louic. L-O-I-C. There’s not a lot in in the day. So at DocuSign especially. So definitely the easiest way. 

 

Christian McCarrick  

Sure. And for those listening to the episode, I always post my show notes on simpleleadership.io so any links to the books we mentioned and contact information for Loic, I will certainly post on there too if you weren’t able to write it down during the show. So had a great conversation today. Always great to talk with you. I really appreciate your time. And so thank you very much.

 

Loïc Houssier  

Thank you for having me, Christian.

 

Christian McCarrick  

Absolutely. Have a good weekend. 

 

Thank you for listening to this episode of the Simple Leadership podcast hosted by me, Christian McCarrick. If you’ve enjoyed the show, please subscribe and don’t forget to leave a review in iTunes. Full show notes and additional information can be found on simpleleadership.io. If you knew someone who would be a great guest for the show, or you want to share your own experiences, please drop me a line. We’ll see you back next week for more technology leadership tips and advice as I interview more top software engineering leaders