Episode 137 – How a Fast Growth Service Firm Formalized Goal Setting to Get Focused – Member Case by Jason Mills

A strategy defines who you serve, what you do, how you do it, and how you do it differently. And a strategy begins with a clear set of goals. In this session, learn how a boutique adopted a formal goal setting methodology, called OKRs, to get focused on what matters most.

TRANSCRIPT

Greg Alexander [00:00:10] Welcome to the Pro Serv podcast, a podcast for leaders of thriving boutique professional services firms. For those that aren’t familiar with us, Collective 54 is the first mastermind community focused entirely on the unique needs of the boutique processor firm. My name is Greg Alexander. I’m the founder and today I’ll be your host. And in this episode we’re going to talk about a popular management methodology, goal setting methodology called Okay Hours. And the reason why I’m going to talk about this is several of our members are attempting to implement them and we’re learning a lot and we want to share some of those learnings. And if you’re not using OKRs, you might be using something similar, such as the boutique framework from collective 54 or iOS or scaling up. There’s a lot of kind of techniques out there and it’s important to have one. Today we’re going to talk about OKRs and we’ve got a role model with us. It’s a member of Collective 54 from a company called Tribal Scale. His name is Jason Mills. Jason, it’s good to see you. Thanks for being here. And please introduce yourself and your firm. 

Jason Mills [00:01:25] Thanks, Greg. My name is Jason Mills. I had engineering a tribal scale. We’re a boutique services firm specializing in platform and software development, using extreme programing, which is essentially test driven development coupled with peer programing. We also use this to provide a unique approach to digital transformation. 

Greg Alexander [00:01:45] Very good. So let’s start with the basics. What is your definition of OKRs? 

Jason Mills [00:01:53] So Oscars are basically, I guess, essentially company goals. The acronym ACRONYM stands for Objectives and key results. The objective portion be more of a loosely defined company goal and the key results, more of the how to get there. So yeah, but it’s kind of like a quick overview. 

Greg Alexander [00:02:15] Yeah. And for those that might be interested, they really became famous when John Daw introduced them to Google back in the late nineties. And many in the tech world, such as tribal scale, you know, have embraced them as a result and to much great success. So, Jason, now we understand what they are. Let me ask you, why did you and your firm start using them? 

Jason Mills [00:02:40] So we’ve we’ve done goal setting exercises for several years to drive personal growth and company initiatives. But in the past, it was really just the manager collaborating with the with a report. And we came to the realization that, yeah, it’s great if someone wants to get a certification to support their growth, but what if that doesn’t align with the company’s goals? So what can we do to eliminate this gap? And as we as we look to really align the company vision in the organization, OKRs became the model to try out for us. 

Greg Alexander [00:03:15] Okay, great. And when did you begin your. Okay, our implementation. 

Jason Mills [00:03:21] So we started end of last year really trying to get the framework in place and for preparation to really launch this in Q1 of this year. So we are about two quarters in almost at the end of the second quarter right now and definitely iterated a little bit on the process. But that’s that’s where we are at this point. 

Greg Alexander [00:03:43] Which is great. I mean, we caught you at exactly the right time. If you already had everything fully baked, the the conversation wouldn’t be as fruitful because I think there’s many that are in the middle of an implementation. So to hear your your story is going to be helpful to them. So tell us a little bit about, you know, what the journey has been so far. You know, how are you using them, What’s gone well, what hasn’t gone well, etc.? 

Jason Mills [00:04:06] Yeah, sure. So we’ve gone ahead and we created for essentially for company OKRs to help line the teams. The first one was lined with white glove service. That was like an example of one of the ones we use trying to provide that ten X value to our clients. The second was service offerings kind of like complements the first OKRs, and the third was thought leadership in the form of content generation through blogs. Speaking of speaking out on podcasts or attending meetups, and the fourth one was meaningful bench work. So we were in a situation last year where a lot of times people were on bench and we wanted to make sure that it aligned with its valuable time. We wanted to make sure aligned with like with what would benefit our clients and our business the best. So those were some of the the OKRs we choose to use. And then each department really gets their own. They can add a couple of extra OKRs if they like, based on what the department needs might be. 

Greg Alexander [00:05:13] Okay, so let’s double click into into one of them and I’m going to choose meaningful bench work because I think that’s a rich topic for our audience. You know, most of our members, sometimes they’re a little lumpy in their businesses and they can find, you know, talented people on the bench for a period of time. And then unfortunately, sometimes it goes the other way your 120% capacity and everyone’s burning the midnight oil. So so what is some examples of meaningful bench work? 

Jason Mills [00:05:42] So a lot of times like the default for us just was like, okay, we’re gonna we’re going to certification certifications always help our, you know, our company in regards to Azure or things like that. But we took it a step further and we we said, you know, whatever we’re working on, it should benefit either a client that we’re going to have in the future or a client that we have currently. And we took it a step further and said, you know, how do we know we’re succeeding in this? So we put together like a metric saying that, you know, we want to we want to use whatever knowledge they’ve gained within two months of of learning it. And that’s how we know if we succeeded with that. So so that’s an example. 

Greg Alexander [00:06:27] That is a great example. So you want to use whatever you learned within two months. I can’t help myself. Two months is a very precise number. How did you pick that? 

Jason Mills [00:06:39] Oh, I it’s like it felt right. Okay. It seems like, you know, when you’re when there’s a little bit of leeway before the next client starts up, it seems like a good amount of time to prep before you actually get deep into the project. So that’s just landed there. 

Greg Alexander [00:06:58] Yeah. Okay. Well, that makes sense. All right. And you know, at the top, I mentioned that OKRs is there’s other similar systems. A lot of our members use iOS. Some use scaling up, some use the boutique. I mean, there’s a lot of them out there. And I advocate for everyone. To me, there’s not a ton of difference between them. The important thing is to have one and be committed to it and implement it. Right? So. So was there any reason why you picked OKRs over the alternatives? 

Jason Mills [00:07:27] Well, they you know, they were naturally a good starting place if you haven’t done organizational goals before. There they were from what we the research we did, they were loose, flexible to change, interpreted in different ways which which, you know, some might think that’s not you you want to make sure they’re not interpreting the phrase, but it actually allows to generate some creativity among the teams to solve different problems. And they’re not tied to compensation, which alleviate some of the pressure as well. So they were basically very forgiving if we screw this up, which we were going to screw it up. Yeah. So anyway, U.S. has its value, too, but I know that’s more of an operating system. And now that we’re two quarters in, we’re actually experimenting a bit, but laying us on top of that to kind of like help us drive and execute a lot of the a lot of the things we want to do. 

Greg Alexander [00:08:19] So that’s fantastic. So the reasons why you chose it, one of the reasons anyways, was the flexibility. And since this was the first attempt at this, that was obviously valuable, I also, I did not know that OKRs were divorced from compensation. So that’s a valuable add right there and I can see the benefits of that. Some might argue against that, but I can see if you’re early in this process that that might make it more, I guess, less stress in getting it implemented and maybe less of a shock to the system. So that’s interesting. Okay. And then in terms of the six months that you’ve been at it, you know, if you were to do it over again right now, if you had a clean sheet of paper, is there any any gotchas, any failures that happened along the way that you wish you would have known? 

Jason Mills [00:09:06] I think overall it went pretty well. We implemented this using just basic spreadsheets. Seems I think you can kind of run the world on spreadsheets and and just set up the spreadsheets, you know, kind of like doing weekly check ins, whether our our OKRs were on track, off track, or if they were done. Kind of provides that simple, simple implementation as we get into it. I think one of the challenges for the engineering team in a lot of times engineering is that one of the larger sizes is that multiple parking levels. So not having that visibility into, you know, what are the managers, the managers, you know, kind of trying to deliver. So are we all in one bucket of thought leadership and no one’s putting any any knowledge into or any time into white glove service. So that was a challenge that, you know, we are kind of working through and evolving on. Hmm. 

Greg Alexander [00:10:03] And what what are your early hypotheses as to how you might overcome that challenge? 

Jason Mills [00:10:09] So we had, I would say like long term, maybe just finding like a tool that can kind of work through and manage it and provide that hierarchal visibility. When I was working at a former Life, I built performance management systems and, you know, clients created goals from very simple to very complicated scorecards, you know, tracking metrics on time and dollar delivery. But end of the day, they all wanted to see a one page dashboard with visibility all the way down the line. So right now we are using a tool that actually integrates with our Google calendar and allows us to kind of tag each meeting that everyone has with an Oscar. And that month we can see how much time was spent across the organization and on the on the specific. Okay. So it kind of provides that visibility to Head Start, right? 

Greg Alexander [00:11:04] Yeah, very cool. Any other, you know, tools that you all leveraged or, you know, quick hacks that people might take advantage of when you got going on this? 

Jason Mills [00:11:15] And we’re we’re piloting a couple of different things, like from the iOS standpoint. There’s there’s a couple different tools that just manage that whole process. So it’s like we’re using 90 right now, which is something that we’re that we’re trying out, which is a good. 

Greg Alexander [00:11:33] Thing about like learning tools around OKRs. Were there any books that you read, any videos you watched, anything like that that you can recall that jump to mind that were particularly helpful? 

Jason Mills [00:11:43] Yeah, there were some there’s a lot of great information on some websites. Definitely read the book Traction, which was a good one on iOS, trying to think of some other ones that come to mind, but those are kind of amazing. 

Greg Alexander [00:11:57] Okay, Got it. And then my last question before we wrap up is, you know, the implementation of OKRs. Is there one person who kind of owns the the whole thing or is it distributed? You know, who’s in charge on it? 

Jason Mills [00:12:11] Yeah. So the for us we have the our chief of staff and she owns the process, kind of like owns the master spreadsheet. And then we have the department leads that kind of like manage the okay for each department, everything kind of rolls up, and that’s kind of a bogey structure. 

Greg Alexander [00:12:28] Got it. Very good. Okay, Well, so for the listeners that are members, let me draw your attention to making sure you accept the meeting invite that will come out here shortly with Jason Mill’s name on it from tribal school. And if you attend that member only private Q&A session on Friday, which is when we have a role model sessions, you can double click on any of these items and ask your questions directly of Jason. So I encourage you to do that. If you’re not a member and you think you might want to consider it, go to collective 54 dot com. You can fill out a form and one of our reps will get in contact with you. And if you want to read about other things that we do or the topics we cover. In addition to this, I pointed towards the book The Boutique How to Start the Scale and Sell a professional services firm in a video is your thing on YouTube. We have a channel called Profiting in Professional Services and you can see some videos on that. But Jason, I appreciate you accepting my invitation when I reached out to you and sharing your journey so far. And congratulations on the progress that you’ve made and we learned a lot from you today. So thanks for being here. 

Jason Mills [00:13:35] Great. Thank you, Greg. 

Greg Alexander [00:13:36] All right. Okay. And for the rest of us, you know, I wish you the best of luck as you try to grow, scale and exit your firm in the future. We’ll talk to you on the next episode.

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.