Feature Management: The Not-So-Secret Weapon for CI/CD with Michael Gillet

(Joel Beasley at 00:00:04) Hello, my friends. Today we're talking to Michael, head of development at Win Technologies, a proud member of the Betway Group. And we discuss several unconventional use cases for feature management, why Michael chooses LaunchDarkly for his feature management purposes, and tips for having successful one-on-ones with your direct reports. All of this right here, right now on the Modern CTO podcast. Here we go.

(Intro Narrator at 00:00:34) This is the Modern CTO podcast.

(Michael at 00:00:46) So I've always been interested in technology. My dad designed microchips, so kind of from a young age, I've always been interested in technology. I thought, well, you know what? I enjoy it. And that's what I ended up going to university to study—electrical and electronic engineering. But there was a module within that which was actually programming, and I found programming much more interesting and kind of rewarding to me as something to, you've got a problem, write some code, execute it, it runs, it solves your problem. That was to me more rewarding than doing Fourier transforms and figuring out resistance and capacitance of components within a physical thing. And then, yeah, moved into software from there, really, and started off on the front end. Got a job at Win Technologies, which is a member of the Betway Group, which is the company that I'm still at. That was kind of seven and a half years ago, and then moved on to a leadership role after 18 months or so on a team more focused on the back end. So kind of upskilled in the back end tech. And since then, I've kind of been involved in the full stack of web development and have progressed through a number of roles through architecture into head of development, which is the role I now have.

(Joel Beasley at 00:02:08) That's really cool. Yeah, I totally get how you can see more value in the software engineering than like physical electrical engineering. There is this guy at a company called Qwake Technologies I interviewed a while back. No, Joel interviewed him. But anyway, they're making really cool stuff. They're making AR for firefighters that like outlines the room that they're in through the smoke, so it helps them see what they're doing in low-visibility scenarios. But yeah, he was talking about how it's so challenging on the hardware engineering side of things because when you're producing a physical product, it's like $100,000 if you want to move a button to the other side of the thing. So you really have to get that right. Whereas in software, you can just run it. Oh, that didn't work. Let me change something, run it again.

(Michael at 00:03:00) Yeah, absolutely. And I think there's an element of that which I really enjoy. I'm not so hands-on software now as I used to be, but in my personal time, I am. And it's great in that way that software, we can play around with as a hobby where you're kind of investing time rather than actually spending, as you say, kind of hundreds of thousands on moving something around, which in software, the idea of being able to move something around or rearchitecting something, rerouting stuff, it's not free, but equally you're not having to pay for a resource to do that in the same way that you are with hardware, which is great for figuring out what actually is the best way to, what is the best option for customers and the best design for a system.

(Joel Beasley at 00:03:46) Yeah, absolutely. So what kind of stuff are you building in your free time?

(Michael at 00:03:51) So I run a wallpaper website. What I like about being able to do that is because I'm not hands-on and actually because I was more experienced in .NET, because of when I moved to kind of back end teams rather than front end, more experienced in .NET rather than some of the more modern front end frameworks that have come about over the past few years. We were using Angular for a while at work, so I have experience with that. But what I wasn't getting at work because of the role I've got to was experience with something like Vue or React. And so I thought, you know what? I do want to actually learn these front end technologies. So I actually, there is a framework out there, React.NET, which allows you to do server-side rendering of a React front end but from a .NET server, which is unusual, I know. But it was a good way for me to at least take my experience with .NET and bring in modern web front end technology. My next plan would actually be to move to Next.js and probably use Vercel and that kind of technology, which is what our front end teams at work are using. It's just not something I've got much hands-on experience with. So yeah, the wallpaper website is kind of an opportunity for me to keep up to date with the latest tech that in the day-to-day job, I'm very aware of but don't really get to play with.

(Joel Beasley at 00:05:06) Yeah, that's really cool. And I mean, I'm sure that helps you interact with your engineers on a more personal basis too.

(Michael at 00:05:13) Yeah, definitely.

(Joel Beasley at 00:05:15) So I did lurk your LinkedIn a little bit prior to this interview, and I saw that in the early 2010s you were a news reporter. Can you tell me about that?

(Michael at 00:05:27) Yeah. So as we were chatting earlier on, I've always been interested in tech. And when I was at university, I was very passionate about kind of what is out there in terms of new tech. And so I started writing my experience with the technologies that I liked and used, and felt like I actually could contribute in some way to a community. So I started writing about Windows because that's what I was using, some of the products that Microsoft were releasing at the time. That got picked up by a few of the kind of Microsoft-centric blog sites, and then I ended up being asked to actually write for some of them. So for a period of time, I was writing about technology, which I found really quite an interesting place to be and a job to be doing. Well, I think I felt though was it can be a little bit of an echo chamber at times. I always wanted to be able to contribute something new, have a new angle on something rather than just kind of regurgitating the same news headlines, which is really valuable to be doing, but I didn't find it as rewarding. So I ended up looking for other things that I could do within that space. So I ended up partnering with Microsoft, and it was SkyDrive at the time. It's now OneDrive. And I actually partnered with the team at Microsoft Corp and did some kind of exercises with readers of some of the sites that I was writing for and gathered feedback around what the customer experience is like and what the pain points were and what would they do if they could have some new features, so kind of partnered with Microsoft on that. And it's because of that that I was then awarded MVP status by Microsoft, which I've retained since 2012. So almost a decade now of having that, which is cool.

(Joel Beasley at 00:07:15) That's really cool. So do you have to do anything to maintain and upkeep that? You got to contribute something yearly?

(Michael at 00:07:21) Yeah, there's a lot of contribution back to the community, and my title now is on the Windows Insider side. So it's kind of trialing like Windows 11 and all of the new things that have come with that, which is really cool. So trialing that, feeding back about that, but what I do a lot of is the wallpaper site itself is actually geared towards kind of Windows 11 and Microsoft-specific wallpapers. But I also organize meetups, usually in London, but I have done a couple for like Microsoft Build and things which have been in Seattle in previous years when we physically went to conferences. So I've organized meetups and things for attendees of conferences and usually again, they're quite Microsoft-centric, which have been really great to actually meet people and kind of just discover what passions people have and why are they interested in a particular technology, why they're interested in Microsoft, why are they attending the conference. So it's a fascinating opportunity to talk to people, which I think a lot of the virtual conferences, it's very hard to do networking in the same manner.

(Joel Beasley at 00:08:22) Yeah, absolutely. It's kind of hard to like, what do you private message someone in the Zoom channel? Hey, you want to go into a breakout room? Chat about this further?

(Michael at 00:08:34) There's been a couple of ones that I've done where they kind of almost have like a speed dating network thing. So it constantly cycles. I think you get three minutes, no more than three minutes, and you just kind of meet people who are there, which is interesting. And then obviously if you've kind of got something that you're really interested in and want to talk more on, then you go off and then actually have a longer chat, which in a virtual way is a good way of perhaps trying to do some of the networking stuff that is much harder to do when you're not in person.

(Joel Beasley at 00:09:02) Yeah. I mean, it definitely still works. It just requires a lot more intentionality on the side of the organizers to make sure that that time is set aside and doing that. But I do want to talk a little bit about LaunchDarkly because we've had John Kodumal on the podcast and Edith, their CEO also. And I think they're a super cool company. And I know that you recently wrote like a feature management book with them or about them. Can you tell me a little bit about that?

(Michael at 00:09:37) Yeah. So over the past few years, it's probably worth explaining how I've even come to use LaunchDarkly and then how I've got to write the book.

(Joel Beasley at 00:09:47) And let's also touch on what it is.

(Michael at 00:09:51) That's fine. So, you know, it was probably five years ago, I would guess. It's a few years anyway. The company was looking to do some AB testing on the front end of our website. So we were exploring ways of doing AB testing, and feature management is the broad topic, I guess, for AB testing. And it was given to the tech department to evaluate what would be the best way of us being able to run AB tests. And there were a number of options available. LaunchDarkly was ultimately selected because we found it very kind of unopinionated about the technology that can be used, and it wasn't only about running AB tests. It was literally a very, very simple concept of effectively having an if statement with a distributed evaluation of whether you're going to get a true or false variable back. Now it sounds very simple, and in reality, it kind of is that simple. The magic that happens with feature management and in particular LaunchDarkly is how do you target that true or false, or if you're doing multivariate testing, how do you target which instance of a variation you want a single user or a single session to receive? That's the magic of feature management. Anyway, we selected LaunchDarkly at the time to do that AB testing because we saw so much potential in that simple concept. And since then, we've gone and used feature management in all of its various forms, and I can talk about many of them. We've used it in various ways across front end systems, back end systems, against migrations, against authentication systems. Different teams have different approaches to it. We've changed the way in which we follow kind of a Git flow model. We've become trunk-based very, very much in some teams. So there's an absolutely huge way that we've, as a business, we have changed because of feature management. And the book that I got to write comes about because I started working quite closely with LaunchDarkly. I started doing conference talks, and I wrote a few blog posts. And that actually got me, a publisher reached out to me because of that and said that they were looking for a book on the topics of feature management and LaunchDarkly, and would I be interested in writing that book? Now as it happens, that was kind of January of this year, and the UK was in lockdown at that point. And I thought, well, might as well spend lockdown and write a book. So yeah, I did that, and it came out in October. So yeah, it's really cool. And actually, you mentioned John Kodumal, and he's written a foreword for the book. So the book is not a LaunchDarkly book as in it's not by them. It does have their kind of approval and an endorsement. So it's really cool, and they've been great. LaunchDarkly, as you say, they're a cool company, and they've been really, really supportive with the book. And I ran a draft past them before we went to the publishers with it, so it's technically correct. There's nothing in the book that LaunchDarkly would dispute. But it's full of examples and kind of tips and tricks and things that I've learned and things that are, that I've learned from the hands-on experience with LaunchDarkly and the way that we've used it in the real world, but also many other scenarios that we have thought about, questioned the pros and cons, which didn't work for us maybe, but it could work for other companies, other scenarios, other products and teams. So yeah, there's lots in there about different ways to use feature management, and it's a topic I could talk about for a long time.

(Joel Beasley at 00:13:26) That's really cool. Well, so what are some of those, what are some of those examples that you've used feature management for over the years?

(Michael at 00:13:34) Yes. I think the, so many different use cases for it. The simplest is kind of what I would deem the switch statement, which is literally you're going to turn something on or off. Often that could be called like a safety valve or kill switch. And the common use case for that is where you've got some functionality within a product which is not mission-critical, but is useful to have. And if there was degradation of your service, then you could turn that expensive feature off. It's not ideal, but you know what? You would rather have that turned off and your customers can still use the product. So turn it off. So that's the kill switch model. And that's nice. It's a simple use, and it generally is either on or off for everyone. And the implementation is relatively simple as well in that you're probably encapsulating your kind of optional implementation in that toggle. And then in the if and else block, you've probably got nothing there because you want to turn it off. There is an inverse pattern to this, which I don't have a good name for, but the idea being that you could have something that is generally turned off and actually, you can conditionally turn it on when there's a need to do it. So one interesting example would be, let's say we wanted to, a customer is complaining about an issue, and we wanted to get more verbose logs for that customer to understand what is the journey that they're doing and where is this issue coming about. We could actually turn on more verbose logging for that one customer and gather that extra telemetry on their journey and their experience. We have also played around with serving unminified JavaScript files for that customer as well in the same switch, so we can get more human-readable aspects of the JavaScript code that's running, which again can be quite useful to us. Is it an issue with the journey? Is it an issue with our code? What's the problem that this customer is facing? So in a specific manner, we can turn something on for a customer, which is not about experimenting or anything like that, which we can get to in a minute, but it's an inverse kill switch, I guess. I think what's crucial with what I've just spoken there, and what I touched on slightly earlier, was the magic of feature management is all about being able to target your true or false, your variation, to a specific customer or a segment of your users. And that really requires an understanding of the kinds of data that you will care about within your application and the needs of when would you want a feature turned on or off. And in this scenario, perhaps it would just be simply the username of the customer.

(Michael at 00:16:20) They call up the call center. They say, "Got a problem." "Okay. What's your username?" Cool. We can turn that thing on. Let's get some more information.

But there are many more complex reasons why feature management is very useful and why you want lots of information about that customer to come through to LaunchDarkly. So if we now kind of move to running experiments, which I think is an extremely important way to deliver software. Yeah. It's often something that is a little bit harder perhaps sometimes to convince senior management to do because it can be wasteful at times, but it's not wasteful in the sense that you're squandering resource.

(Michael at 00:17:01) It's that you might build something, find it doesn't work, and you need to be comfortable that you're gonna get rid of that implementation. It's not wasted work. So it's wasteful in that sense, which is why it can be difficult to get senior management to buy into that. But what it does is it ensures that every step that you take is the most valuable for your customers, the tech you've got, and therefore, the bottom line of the business. And when you're running experiments, there are so many ways in which you might wanna segment that customer base.

(Michael at 00:17:31) The simplest is just to do a kind of a percentage rollout. You really don't care too much about who the customers are. You just wanna roll out to 5%, 10% of your customers. See how that goes down, get the telemetry. If that's looking good, maybe roll out to 50%. And as long as you've not degraded anything and you can see that the feature that you've got is working, then great. And at that point of being at a 50% rollout, you're in a true A/B testing scenario, fifty-fifty split. That's kind of the sweet spot for it. You might not wanna jump there, which is what I'm saying—do 5%, 10%—because you kind of technically want to prove that your new feature works in a safe, controlled manner. So to do that, you don't necessarily need too much information about the customer.

(Michael at 00:18:15) But let's say you wanted to go down a segmentation route and say, "We know that we've got a really valuable group of customers, and then there are several groups of customers that are less and less valuable to us." Now you've got some options with this. How have you determined value? Is it about the amount of money they've deposited over their lifetime, or is it about how much screen time they spend on your app? Or there's a whole range of different ways that you would deem your valuable users and customers.

(Michael at 00:18:41) But if you've got a feature that you really wouldn't want to negatively impact valuable customers, then you'd probably first roll this out with your lowest-value segment of customers. Whereas, if you've got something that is a new feature that you're very confident with, that it works and is actually designed to really get the most value out of your valuable customers, then you might wanna put that experiment in front of your most valuable segment of users. So there are options available to prove how a feature is gonna perform with your users. There are many other ways the customer base can be sliced up to run experiments. It could be that you wanna trial something on a particular device, could be Android versus iOS in the web or maybe a native app.

(Michael at 00:19:26) In that case, you're probably not gonna use it in quite the same way. But it could even be country. You might wanna split the traffic for an experiment per country. And so there are absolutely—well, it's kind of a limitless thing. Now, out of the box, LaunchDarkly has some attributes there, but they have the ability to do custom attributes. You can have many, many of your own custom attributes, which are gonna be quite business-specific or product-specific. With that, you've got the magic there. That's where it comes in is that ability to target who's getting what variation based on a whole load of targeting rules that will get set up in LaunchDarkly.

(Joel Beasley at 00:20:09) So what's the process like of actually using LaunchDarkly in development? Is it like a plugin in your IDE that you're able to just start coding specific LaunchDarkly things in your code, or is there like a LaunchDarkly dashboard that you're working with, or both? What does it practically look like?

(Michael at 00:20:32) Yeah. So to use it, there's an SDK, and they've got many SDKs for most frameworks and technologies and languages. So there's an SDK that does some really clever stuff. If there isn't the SDK for the particular setup that someone wants to use, there is a full API as well that you can use. I would always recommend the SDK over using the API directly because the SDK does some clever client-side... And I say client, not front-end browser client, but like, in the server that is running on. There's some clever stuff there. So I'd always recommend using the SDK.

So you install that, and that really gives you the ability just to create a LaunchDarkly client in your app, an instance of LaunchDarkly to connect to the service. And then what you're doing is kind of on every request, you would have a user object.

(Michael at 00:21:22) Now the user object is the bit where the magic sauce happens, where you put in all of the attributes about that user. I, at times, question the use of the word "user" because if you're dealing with a front-end application where you've got an actual user, it makes a lot of sense. But you could also be using LaunchDarkly on backend systems where you're probably more dealing with requests or sessions rather than users. But the concept's the same. So you've got a user object.

(Michael at 00:21:47) You spin that up and fill it up with the attributes you need. And then the next thing you would be doing is creating or evaluating a flag. Now the flag just needs a string and then the user object to be passed to it. The string is the key of the flag, which is when—as you say, is there a LaunchDarkly dashboard? Yes. And so the string is where you would create the feature flag itself in LaunchDarkly, and you would create it with the key that you wanna use within your application. And it's within the dashboard that you actually set up the targeting rules for that feature flag.

Now I would say the best pattern to follow is that when the feature flag is returning false, that is the default scenario within your application, so kind of the fallback scenario. It's always worth bearing in mind that LaunchDarkly, it is a distributed service. It could go down.

(Michael at 00:22:41) It hasn't really gone down for us, thankfully, touch wood, but it could. And so my gut feeling on this is always your fallback position should be your known state with your current implementation. You should always be happy that if all else fails, what you're serving in your application is the known good state. And it is within the true—where only when LaunchDarkly is returning true would you have your new implementation, your untested, untried code. Untested—I don't mean it's never gone through QA, but it's not in front of every customer. Yeah.

(Michael at 00:23:13) Yeah. And then in the LaunchDarkly dashboard, that's where you would also probably set up the default rule will be to return false and only return true when the particular criteria are met of a user or a percentage of users. Then they get the true variation being served back to your application. So yeah, most of the time dealing with LaunchDarkly is really spent in the dashboard itself, the website itself, rather than in the using it within your application. Once you've got your feature flag in your code base, then you're writing your own code, and you almost don't think about it too much. But it changes the way that you think about writing code, delivering code, deploying it, and then releasing a feature.

(Michael at 00:24:02) And when I say this, what I see is LaunchDarkly—or feature management doesn't have to be LaunchDarkly necessarily—but feature management in general allows us to decouple the deployment of software with the release of a feature. So we could be deploying all of the time, and some of our teams do. We will deploy all of the time, potentially broken code. But the broken code, as I say, is encapsulated within the feature flag in the true value of that feature flag, which we know is not what our customers are seeing. It's only gonna be true if I've turned it on for myself.

(Michael at 00:24:39) So if I can deploy that, then great. Once it's all good from a developer perspective, then maybe I'm getting the testers, the QAs to have a look at it. Does that work? Great. Maybe we give it to a performance testing team. Let's run it through them. Are they happy with it? Great. Let's give it to stakeholders. Let's get it signed off. It's all in our production environment. So the beauty here is we're not going through multiple steps of doing testing on a test environment and then getting to production. Obviously, that can work. In many places, that works very, very well.

But it can be quite cost-ineffective to run something through a test environment and then to production because either everything—if test and production are alike, then you've potentially got an unnecessary step.

(Michael at 00:25:19) If everything's good, you're updating that on test, then getting it to production. Okay, that was an unnecessary step. Or you might have a mismatch between test and production. So you're actually getting a false positive with the test results from your test environment. You get it to production, and then it doesn't work.

Where we've got feature management and where we're gonna purposely deploy unfinished code to production, we have to be certain that we're not gonna break production with that, which means it's relatively safe for us to do that because that's what we've always designed as our thought process. And it means that when someone's signing it off, they're signing it off on the real environment, that is the best environment to sign things off on, which is a huge cost saving effectively and time saving.

So it's a really interesting way to think differently about how we would deliver software than the traditional "put it through lots and lots of testing sign-off phases." It doesn't work for every team, won't work for every product either.

(Michael at 00:26:19) Some areas of tech that I would say that feature management and LaunchDarkly don't work so well would be on databases where you might have schema changes and you need to kind of significantly change the structure of a database. Very difficult to do multiple versions of a database and flip between your A and your B. That's not really gonna work.

(Joel Beasley at 00:26:40) You can just spin up another one. That's...

(Michael at 00:26:44) Lots of money. Yeah. Exactly. You could do that. And that's an interesting thing because then that touches on another use case of feature management, which would be the migration of services or hardware and doing that via feature management. So I guess let's take that example. I think it's a good example. You've got a new system. You've got a new database you want to be running, and you wanna cut over from your old one to your new one. If you've got your application that's currently calling that old system, you would encapsulate the call, the request to the old system in a feature flag, and put your new endpoint in the true state of the feature flag. And then it's easy to turn that on for yourself again.

(Michael at 00:27:27) Let's just check that it works. Does the new system work as needed? And if it was that you have to do a kind of a big bang release with this, you couldn't do a 5% rollout because sometimes migrations need it—all or nothing on the old to new tech. You can't be piecemeal.

But again, you've got a little bit of a safety net, and you can test that for yourself, and you know that you're potentially gonna have some side effects that you would need to remedy, but that's fine. You can live with that because it's just yourself or your testing team or whatever. But for the customer base, you can cut them all over, which is a really good way of doing it. There was also one thing that we did when we actually swapped our authentication system from a very old way of doing authentication to a nice, shiny new token-based way of doing authentication.

(Michael at 00:28:14) We actually turned that on per country, which was a really good way for us to be able to do that because a lot of our stuff is kind of domain-specific. So, obviously, writing cookies against the domain is actually nice to go, "Well, here's country A. Turn it on to this one country. Does it all look good in that one country, maybe a small country, maybe a lower-value country?" Yes, it does. Cool. Then move it over and turn it on in kind of the increasing value, increasing size markets. So yeah, there's really cool ways of using it.

(Joel Beasley at 00:28:46) So what does your day-to-day look like, man? How much time are you spending thinking about this kind of stuff? What are you mainly working on at your job?

(Michael at 00:28:57) So it's quite broad. I've recently also taken over the remit of head of product and UI and UX as well. So it keeps me very busy. So there's a good degree of—and I've always enjoyed being very, having a very product mindset anyway, even as head of development. Because, ultimately, what we're working on as engineers or software developers has to work for our customers and has to work for the business.

(Michael at 00:29:24) And so that does need a good product mindset. When we think about feature management and breaking a deployment from a feature release, that's improving the product in terms of we're probably making it more reliable to do so. So the product's better, the customer experience is better. In terms of how my day-to-day looks, there's a lot of—I'm very, I'm always very focused on the people. I always try and be very empathetic.

(Michael at 00:29:50) I think that's crucial in kind of leadership and managing people. And so a lot of my time is spent in one-to-ones or understanding the needs of teams and what are the challenges and how can we address this. Now is it about prioritization of work? Is it about empowerment of people? Is it about, yes, we care about the customer experience, but are we doing the right things from a developer experience as well?

(Michael at 00:30:20) Are we making sure that the technology that we're building, yes, it serves the business very well, and we can move faster because of it. But are we doing that at the expense of our staff and people and degrading the developer experience, or are we doing that in tandem with improving the developer experience? And that's kind of crucial. Now, obviously, that moves beyond developer experience as well into any of the remits that someone might look after. It's all about what's the experience like for the people who we are looking after, because it's all very good to have the best shiny tech, but you want people to really be passionate about what it is they're building.

(Michael at 00:31:00) And that comes with pushing the boundary on tech, but making sure that people buy into what we're doing and why we're doing it. And that's generally, I see it as the best way to kind of work with people and lead a team.

(Joel Beasley at 00:31:17) Yeah. I mean, focusing on improving your employee experience is only gonna do good things for the customer experience at the end of the day.

(Michael at 00:31:26) Absolutely. And there's been some interesting things with that actually. There was—when we've been doing a lot of our experiments, what we found was there was often kind of a lot of misunderstandings or assumptions being made by people that we would run an experiment. We'd put it out in front of the customers. We'd gather the data. We'd do the analysis. We'd present it back, and someone would go, "That's not what I thought we were experimenting with." And that's quite frustrating. It's quite demoralizing actually for everyone involved because everyone's like, "Oh, well, I thought we were doing a good job, but actually, we've missed the mark on this."

And so what we ended up doing was thinking about what is it we're trying to do when we're running an experiment, and we chatted to a lot of people.

(Michael at 00:32:06) And the outcome of that was we put together what we were calling a hypothesis specification, which acts like a Microsoft form, and is available to anyone in the business to submit a hypothesis to say, "Hey, I've got this idea for one of our products. Why don't we trial this?" But within it, we're asking, "Well, what's the problem we think we've got here, and in what way would this hypothesis help? What would a success metric of this hypothesis look like?"

(Michael at 00:32:36) And what would be the sample dataset that we would look to run this experiment on? And then at the end of it, we get a lovely little kind of report out of it that clearly shows to everyone involved, this is what the hypothesis is. And suddenly, you've got something that's workable for the business stakeholder who looks after that product, for the person who came up with the idea in the first place, for our product management, for our devs, QAs, testers. Everyone can be on the same page with that. And then that's so much better, and it removes these moments of frustration and maybe disappointment, but it's certainly a better way to go.

(Michael at 00:33:13) So we use that quite a lot now.

(Joel Beasley at 00:33:16) Yeah. I mean, setting proper expectations upfront. That's you gotta do that in everything you do in business, sales or management. Yeah, that's pretty universal and super useful.

(Joel Beasley at 00:33:29) But you mentioned you spend a lot of time in one-on-ones. Do you have any tips for having a successful and productive one-on-one and avoiding wasting any time with those?

(Michael at 00:33:44) So what I normally set depends. So sometimes people want weekly ones, sometimes it's fortnightly. But what I always say to the people kind of in the very first one-on-one is this is your time, and we'll use it however you want to use your time. There might be some things that we need to do from a management perspective. The company requires certain things to be communicated and things, and that's fine.

(Michael at 00:34:10) But on the whole, it's up to the individual to kind of guide that conversation. And if it's an update on how they are personally inside or outside of work perhaps, then we'll have a conversation about that. If it's about their team, concerns about the team, then we'll have a conversation about that. Sometimes it's about the product and cool technology and how can we incorporate this into what we do. So it's, and we try and keep it kind of a mix of all of these things.

(Michael at 00:34:38) I would never want it to only be one type of thing that we're talking about. It should be a mix, but to me, I can go to my team whenever to kind of articulate what we need to be doing to meet the goals and needs of the company. That one-on-one time is a crucial bit of time in a week or a fortnight, whatever, where that isn't the agenda of the meeting. It's not about what are we trying to do as a company? What are the goals?

(Michael at 00:35:07) It's how are we doing as people? How are your team doing? What do you want to do? What are your areas of progression that you want to do? Whether it's tech, whether it's personal, as I say.

(Michael at 00:35:18) And so that to me is what a good one-on-one is like. A bit of mentoring, bit of coaching, bit of guidance, and then just being able to have that rapport that's built up over time that there's a good relationship there. It doesn't need to necessarily be a friendship, and I think that can be crucial as well. Not everyone needs to be your friend, but it needs to be a good relationship at least so that you can have those honest conversations when they're needed. Either way, it needs to be a safe space for that to happen.

(Joel Beasley at 00:35:57) That's really solid. I really like how you started by saying it's their time to do what they want with it and also putting it in their hands of how often they want it to happen. I mean, yeah, I think that's very key for making sure it's actually productive and good for your employee, a good use of their time.

(Michael at 00:36:20) Absolutely. And I think there's one other thing that I will always endeavor to do. Sometimes it's very difficult, but I will nearly always try and keep the one-on-ones booked in when they are. I don't really like moving one-on-ones, and I really don't like canceling one-on-ones. Sometimes, as I say, that has to happen, but arguably, the one-on-one's the most important meeting of the week.

(Michael at 00:36:41) So I always try and keep them as locked in as possible.

(Joel Beasley at 00:36:46) So I want to ask—

(Michael at 00:36:48) Oh, just on that subject, what I have found fascinating with returning to the office over the past few months is I think we've all got very used to working from home. Every call, every meeting is a confidential one, generally, especially in a one-on-one scenario. You're only dealing with the other person. What happens with returning to the office is you might not both be in the office, you might not both be working from home on that day. So where I say I don't like moving one-on-ones, the only exception I have to that rule is if I've identified that we're actually not going to be in the same setup at the same time, I will move the one-on-one to, well, either I can find a meeting room in the office, but that's not always that easy, or it's a case of, well, look, I'm going to be working from home on this day. I know you are as well, so I'll move our one-on-one to that day so it remains a confidential call. Because what I wouldn't want to be is at my desk, making it difficult for the other person to raise some of the concerns because they don't want my response to be overheard by other people in the office and are being mindful of the—you don't know what the person's going to want to say or chat about on the one-on-one, so being mindful that they can talk about anything. And so if it can't be a confidential call, then that needs to be managed accordingly.

(Joel Beasley at 00:38:04) Yeah. That's a really interesting challenge that I hadn't thought of. The confidentiality as a benefit of work from home that we lose by returning to the office. But yeah, we always talk about how we lost the water cooler conversations and encounters of the office moving to home. But that's an interesting take there. But I want to ask you a question that we got a really great answer for on a recent episode.

(Michael at 00:38:36) No pressure then.

(Joel Beasley at 00:38:38) So we were talking to the CTO of Zscaler recently, which they're a huge cybersecurity company that, um, huge proponents of zero trust. And they actually, side note, they have built so much infrastructure, in terms of like 150 data centers globally to help speed up your data going around the world. Instead of going around the world, it can just go to their data center nearby in a secure manner. And they've really thought about security from the ground up. Cool company. But their CTO, Amit, was an excellent leader and a big believer in the power of marginal improvements. He talked about how if you improve at something by 1% every day, it's a huge amount over the course of a year. So that's been on my mind.

(Joel Beasley at 00:39:29) And I'm curious, how do you carve out time for self-improvement, and where are you looking to improve yourself?

(Michael at 00:39:38) Yeah. I think that's a very good question. It can be very difficult to make sure that time is kind of there for us to reflect, to understand what it is that we should be improving on. And then once identified, actually, finding the right resource and mechanism by which to develop. Kind of some of the things that I have tried to do, certainly over the pandemic, has been to be very mindful of the fact that we could lose ourselves with the distinction of work and home life blurring hugely.

(Michael at 00:40:15) So I've tried to keep quite rigid working hours. That doesn't always work, but tried to start kind of 8:30, try and finish no later than six. One of the things that I found interesting early on was I don't think I missed the commute per se. Going on the Tube to get to the office isn't enjoyable. However, there was an element of there being a time when you've left your home and you're gearing up for getting to the office and working. So you're kind of getting into a mindset that's a bit different from your home life.

(Michael at 00:40:47) And then you've had your day and then you commute back and you kind of perhaps do the reverse and reflect on your day at work and organize your thoughts, and then you start thinking about what you're going to do in the evening. So I actually haven't done it so much recently, but I have been doing a lot of my own commutes in the morning, which is actually just taking a 20-minute walk before starting work and then doing a 20-minute walk after work to almost mimic those things, and that might be listening to podcasts, it might be listening to audiobooks whilst out on that walk. But I found that quite a useful way of making sure I still have time to review the day, reflect on the day, plan out what I would be doing. And then, yeah, if it's listening to audiobooks or podcasts, it's still an opportunity to have some thought-provoking things going on quite outside of my day-to-day, which I find they're always good for development as well. And in terms of perhaps identifying areas for improvement, I do really enjoy listening to podcasts and audiobooks because I do find them to be quite—I think they're filling a thing that I always enjoyed with conferences, which, as I say, I'm not finding the virtual conferences. I find much harder to engage with than the in-person ones.

(Michael at 00:41:56) But it's that idea of hearing people who are talking within a tech industry, but of technology or the industry that the company is in or the experience that person has is quite outside of my own experience. So they're talking about things that I could relate to, but I haven't perhaps thought about or experienced myself. Then I kind of identify areas of why that's a fascinating take on that. That's something that I should be more aware of within the way I work and the way I interact with stakeholders or my teams or whatever it is.

(Michael at 00:42:37) So that's kind of what I quite like doing, which is very much on the soft skill side of things rather than the actual skill set of technology, which is its own challenge to keep up with the latest technology because there's always so much happening all of the time. But in that regard, I would deem myself to not necessarily ever be the expert in the room on a particular technology, but know that within my teams, we do have the experts on particular areas of technology. So if we've got a need for discussing, okay, we've got this project, this objective, we need to deliver this outcome, then it's about getting those experts in a room and discussing and relying on their expertise to do that. Although, as I said earlier on, I do enjoy working with current technology in my free time, which is about as much as I can do to keep up with tech.

(Joel Beasley at 00:43:35) That's awesome, man. Yeah. I set you up with a high pressure question, and you delivered. Good. But alright. So before we wrap up, is there anything that we didn't get to touch on today that you want to make sure we get out to the world? Any extra shout-out you want to make at the end here?

(Michael at 00:43:53) Not that I can think of off the top of my head. I think, as you can probably tell, I do enjoy talking about feature management. So we've probably done that one to death. And to me, how I am as a leader is a big deal for me and making sure that people feel empowered within the team. So being able to talk about that was crucial for me.

(Michael at 00:44:15) So, yeah, I think it's been a really, really good chat. I mean, it would probably be remiss of me not to say that the book is available on Amazon to buy right now, and it's called Feature Management but Launched Darkly. But yeah, it's been really good.

(Intro Narrator at 00:44:34) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.