Episode 83 – How a Brave Founder Scaled his Software Development Firm by Confronting his Blind Spots – Member Case with Alan Haefele

Acquirers want to understand your methodologies, how often they are updated, and what changes are coming in the future. On this episode, we interview Alan Haefele, Owner & Managing Director of Haefele Software, to understand how to integrate continuous improvement as part of a company’s culture and DNA.  

TRANSCRIPT

Greg Alexander [00:00:15] Welcome to the Boutique with Collective 54, a podcast for founders and leaders of boutique professional services firms. For those that aren’t familiar with us, Collective 54 is the first mastermind community to help you grow, scale and exit your firm bigger and faster. My name is Greg Alexander. I’m the founder and I’ll be your host today. And on this episode we’re going to discuss continuous improvement. Now, why are we going to talk about continuous improvement? Well. Many times, clients and prospects have a mentality that says, What have you done for me lately? Buyers of boutique professional services very often are purchasing what you’re going to become, not necessarily who you are today. I wouldn’t go so far as to say that yesterday was worthless. But, you know, if your business depends on generating recurring revenue, expansion, revenue from existing clients, it’s very important that you continue to evolve. And one of the ways to do that is through continuous improvement. And it keeps you on the leading edge. It makes your services and your people interesting. It makes you attractive to prospects, talent, maybe even a potential acquirer at one point. So we have a role model for us today. His name is Alan Haefele, and Alan is, we believe, an expert on this subject. And his firm follows a continuous improvement methodology, so to speak. And I’ve asked Alan to come on the call here and talk to us about that today. But before we jump into the details, Alan, if it’s okay, would you mind giving a proper introduction? 

Alan Haefele [00:02:04] Yes. Thanks for having me, Greg. Yeah, slight pronunciation on the name, but Alan Haefele.

Greg Alexander [00:02:12] Oh, I’m sorry. I apologize. 

Alan Haefele [00:02:14] No problem. I ran a boutique, hopefully software. It’s a software consulting firm with a team in London and largely in South Africa, in Cape Town, where I am today. We are about 55 of us and we are specialists in the net. So Microsoft ecosystem and largely specialists in B-to-B, a lot of logistics, financial services and banking kind of clients. And yeah, we’re on this journey to become more and more of a wisdom firm and collective of course is helping us on that. But yeah, that’s us. 

Greg Alexander [00:02:47] Okay. Well, very good. So the team tells me that this concept of continuous improvement is literally part of the DNA of your firm, and it’s very methodical and very structured and disciplined. So maybe as a way to kick this off, if we could maybe start at 30,000 feet and give the audience a feel by providing an outline as to what it is that you do in this area. 

Alan Haefele [00:03:11] Sure. I think by definition in this, it’s hard to be an expert in it because you kind of are always continuously improving. So it’s always hard to say that you’ve done it. But I think, yeah, the the what stood out for me on this topic was actually how we started. It became a value almost. This people over process was almost one of our first kind of catch phrases when we were four or five, six people. And to be honest, I think it was born out of a vulnerability on my side. I actually have no idea what I’m doing. So let me not put let me put draft at the end of everything and let me put version of version number at the end of everything, whether it was our hiring process or our interview process or our initial sales messaging, everything became a version 1.1 or a version 1.6. And out of that, the people of the process became our kind of mantra, and that any process was completely up for grabs to be torn up and redone almost at any time. And that, I think, infused a lot into our culture today, where people are the process is still a very big part of what we do. It obviously manifests differently now 50 to 60 people, but there is this inherent understanding that every process you see is one phone call away. One team’s message to me from being overhauled into version 2.1 or fully overhauled from a version two to a version three. So we’ve got a couple bigger ones. So like our, our career progression is currently on a version four and our sales team is currently on a version three and we kind of each understand what that means. And if you’ve been around long enough, you will know what version two was and you would know what version one was, and we’ll sort of what the features of it that made that version fail or why it became a version two. And yeah, it kind of started with the adage of every feature on an airplane is the result of some tragedy. Right? And it’s almost always having a spirit of, well, the reason airplanes have a fuselage in that position is because some plane caught on flames and killed a whole lot of people. And that’s now why the fuselage is in a different place. So, yeah, we kind of have that mantra kind of baked into a lot of what we do. 

Greg Alexander [00:05:33] Yeah, that’s a great overview and that’s a horrifying example of the fuselage catching, catching fire. But it is a great way to think about it for sure. And sometimes these things are born out of necessity. You know, you talked about version three and version four and version one and how different functions within the company in different people are on different versions, which I find very interesting because, you know, our membership is, is made up of boutiques, which means they’re on their journey. They’re not well-established, mature organizations. They’re rapidly iterating as they move through their lifecycle, grow, scale and exit. And you’re clearly doing that for sure. Sometimes the rate of change can be unsettling for folks and they say, hey, you know, we we just got the new process. Let us run that for a while before we update it. Update it yet again. Have you run into that? And if so, how have you dealt with it? 

Alan Haefele [00:06:34] Yeah, we have run into it. I think doing the iterative approach is more freeing than binding because almost everything is just an iteration, so it doesn’t really matter if you get something wrong in this iteration. So the art is more around, Well, are we changing enough in this iteration that’s worth doing? Okay, cool. Now we’re going to call it version three, and then we normally allocate some kind of a time limit on it. We’ve gotten better at this more recently because sometimes we would let an iteration run for too long because you now move on to another part of the business, and then you don’t look at how that iteration has gone, but we’ve sold it by just being more conscious per area as to how long in iteration is. We’ve kind of learned this a bit from the software industry itself, which is obviously our game in understanding the Agile principles and understanding Scrum and how you build software for a client. And then just retrofitting that mindset onto the other parts of the business, whether it be delivery, technical, finance, marketing and a key part of that Scrum Agile methodology is this concept of a sprint. So how long is the iteration in a software setting? The shorter, the better. It might be a fortnight, but in other parts of the business, a sprint might be more like six months. We might be more like six months. So we’ll, we’ll just get a little bit clearer that, okay, this iteration of this experiment or this initiative that we’re going to do, we’re going to put a time limit on it of about six months. I think that’s fair. Or another one, you might go, look, we’re going to know whether this is going to work within a month. So let’s make this sprint for that classification a month. Whereas in marketing you might go, look, marketing is a bit, you know, if you’re trying something new there, it’s not going to change overnight. You better give it 6 to 9 months. Okay, let’s make that a nine month sprint before we decide if this is a baby in this bathwater, that we need to throw it all out or reassess where we’re at. Hmm. 

Greg Alexander [00:08:29] That’s an interesting answer. I love the fact that you’re having the conversation about, you know, is this really large enough to be an iteration or a version, I should say, and then your time stamping it, you know, I think that’s a great way to to think about this in kind of version control, if you will. What advice would you give members who are wondering how to measure this? So, for example, oftentimes I’m on the phone with members and their profit margins are not expanding. They’re flat, and they think that their profit margins are acceptable because that’s the data that they have and that’s the way it’s always been. But I’m in a luxurious position and that I talk to lots of members and I see profit margins across lots of firms. And sometimes I can see just on this example that there there’s an opportunity for them to expand their margins. But they they’re not doing it because they’re not aware of that. Which begs the question in the context of today’s call regarding continuous improvement, is, is how do you know it’s working, you know, across all the things, everything from how it’s impacting the clients to our impact in the employees to how it’s impacting the firm in the aggregate. How do you measure? You know, after the fact, I guess, the effect of whatever improvement that was made. 

Alan Haefele [00:09:53] You know, it is a lot harder our current iteration and on this I don’t think it is complete. We have it as as part of our sort of okay rhythm that we are assessing which initiatives were previously in play. And we do that as a leadership team or extended leadership team so that you are getting the full spectrum from each angle so that our lead and delivery and head of operations and head of finance and head of marketing and sales are all collectively around the table once a month, sort of assessing the experiments that are at play. So I suppose you could make that into a regular cadence would be monthly with the leadership team or as part of the okay hours. I’ve baked some of this into the okay hours because you make a good point around. A large part of continuous improvement is complacency because you think it’s good enough, it’s fine. And you don’t realize actually no, there is improvement there. And so part of that of baked into the okay where I sort of like a two parter every quarter for every lead, they need to find something on the outside world and internalize it. So in other words, have to try something from the outside, which means they have to go and find that book, read that, listen to that podcast, connect with some kind of external medium in their field and internalize one thing and to try one thing. And then the second is to actually improve something. So that might be something that’s already in the company, but that’s annoying them. So it makes them stop and think about what’s annoying them and then isolate it. And then the next quarter they need to try something and improve something and that improving something is not something that already exists and trying something, they have to go out and find it. So interestingly, collective 54 was my okay, ask me to find something and bring it in because everybody can kind of find this thing. But what is the what is the found to do in this area? And so my one thing for my quarter a couple of quarters ago was, okay, I’m going to sign up for a for another group, see if I can learn something. Yeah. 

Greg Alexander [00:12:01] Well, we’re glad you’re here for sure. And for those that aren’t familiar with OK Arc could you tell everybody what that is? 

Alan Haefele [00:12:09] Yeah. Objective key results. So it’s a sort of a framework of goal setting in a way which helps you outline a set of objectives that you want to achieve. And then as minimalist as you can identify the key results that would indicate that you’re on track for that objective. So it takes some takes some rigor. I would say we’re on across version four at the moment in how it’s defined and how it was used. Our first iteration was far too verbose and far too admin heavy. Now we’ve started right back to a simpler piece instead of objectives for the next quarter per region. And these are the things that these are the key results that would stack up to that objective. 

Greg Alexander [00:12:53] Okay, very good. And Alan, one of the things that drew me to you for this subject was I understand that you do a companywide kind of retrospective every three months. I’d love to hear more about that. 

Alan Haefele [00:13:07] Yeah, a retrospective is a something that we’ve retrofitted from Scrum and Agile, which is at the end of every sprint of built software, a healthy team will have a healthy retro. And a healthy retro is where you are expecting the team to reflect on the last sprint on the last week or two weeks. And you’re mean to get brutal and you mean to say what worked and what didn’t worked and how you can find improvement in the next sprint. So it kind of like bakes in a bit of. Poking and criticism and then finding actions and identifying something that you’re going to change in the next spring. So we’re going to borrowed that and put it to a number of places in the company. So we’ve actually got a a team retro. So how the team as a whole is working for a particular client. So that isn’t necessarily how the client’s output has gone because that’s what way the client is involved. And they’re listening to the to how the sprint is gone. We’ll do a team retro just to understand how the team is feeling generally about that client and the value that we’re adding. And if we are still a match for that client and trying to improve areas of our delivery for a particular client, we will occasion do a client retro, which is probably every six months where we look at all the clients on the roster and we classify them by a bunch of attributes in trying to work out if they are still the right fit for us. In all we are, we performing a wisdom role or we performing a method role just to determine if this client is on the path to being fired or is this the client that’s on the right path? We occasionally do more of like a resignation retro, although I do those more myself, which is sort of like an upgrade from a from an exit interview because I kind of view most resignations as those plane crashes. Right. There’s a resignation that is that is of consequence. That’s not just somebody you know, it’s not it’s a resignation that was avoidable. Then that to me normally highlights a broken process or a broken client selection or a broken something. And then there’s normally some kind of iteration that needs to come out of that. But then you and your point of a company retro are either every 3 to 6 months, depending on how active we are. On the other retros, we have a sort of a company wide survey which just touches on ten sort of high level questions. And then we have the entire company breaks for half a day to a day into groups of ten and we basically run almost a software retro without the leadership team. So it’s very much for the team by the team facilitated by our business analysts as if they were doing analysis with the client, but just on ourselves. And they facilitate a retrospective, which is basically to tease out all kinds of positive feedback, negative feedback, no holds barred, say what you like, criticize what you like. It’s done in a way with sort of sticky notes or digital sticky notes in mirror. We used to do it obviously face to face, which is a lot more fun. And out of the sticky notes you accumulate the sticky notes into themes. So the facilitator will then see there’s a lot of themes around, you know, the staff being unhappy about, you know, meeting more benefits or missing these kind of benefits or pay bans or not thinking our client mixes. Right. Or and you can start to see the outliers like one or two individuals complaining about something that’s new or yeah. So you sort of identify these themes and then the facilitator breaks something to positive and negative. So there’s also a time for positive reflection. So what parts company have you really enjoyed in the last three months or six months? And out of that, loads of feedback. It’s sometimes daunting because sometimes you get feedback you don’t want to hear, I guess. And but in a way it’s about the blind spot. I guess they’re highlighting the blind spot from the team’s perspective or from the lead’s perspective. And we have a. Our latest iteration for the last couple of years, we ask a key question, which is the same question that it’s almost been in since our inception as part of that DNA is. If you had Alans job. In other words, if you ran this company, what would you fix first? So it’s like if paraphrasing other ways along the way, as if Allen gave you the keys to the kingdom for six months. What would you fix first? And it’s a way to get everybody to. Not just criticize because it’s very easy to criticize how the company could be run better or if there’s an issue in some part of the company is too great, like, okay, well, if you if if you have a better idea, it’s not just tell me what your latest gripe is. It’s more if you had my job, what would you fix first? And that’s that’s been really interesting. A lot of times then nobody knows what to say, but occasionally you get a lot of cool blind spot feedback. 

Greg Alexander [00:18:06] Yeah, for sure. Well, listen, you’re clearly an expert in this area and we’re button up on our time window here. But I look forward to the member session where the members can ask you questions. But on behalf of the membership, I just wanted to thank you for your time today. I learned a lot, you know, courageous and asking that type of feedback and being that open to discovering blind spots, including your own up and down the organization. So really inspirational. Thanks for being here now. 

Alan Haefele [00:18:36] Thank you. Yeah, thanks for the time. 

Greg Alexander [00:18:38] Okay. And for those that are interested in this topic and others like it, you can pick up a copy of our book, The Boutique How to Start School and Sell a Professional Services Firm. And for those that are interested in meaning, leaders of professional services firms like Alan, consider joining our mastermind community and you can find it at collective54.com. Thanks again. Take care.