Optimizing Your Team with Bart den Haak, author of Moving the Needle

(Intro Narrator at 00:00:03) Hello, my friends. Today, Joel is talking to Bart, author of Moving the Needle, and they discuss how to effectively implement OKRs to move your business forward, why solving a strategy execution problem starts with changing the behavior of individuals on your team, and how to optimize the speed of learning in your organization. All of this right here, right now, on the Modern CTO Podcast.

(Bart at 00:00:29) Here we go.

(Joel Beasley at 00:00:30) This is the Modern CTO Podcast. Alright, so is your book called Moving the Needle?

(Bart at 00:00:43) It's called Moving the Needle with Lean OKRs, but the focus is on lean OKRs. Yeah.

(Joel Beasley at 00:00:47) What's a lean OKR versus a not lean OKR?

(Bart at 00:00:51) Yeah, so I've been using OKRs for the past ten years or so, and it's almost like a hype ever since John Doerr came up with the Measure What Matters book and everybody's jumping on the OKR bandwagon. And the problem is that in companies, there are a lot of goals and a lot of measurements, targets, KPIs, whatever. And they all get converted into OKRs. And, hooray, we're doing OKRs. And, you know, that's not the point with OKRs. So lean OKRs is actually my attempt to say, okay, it's not about converting all those goals into the OKR template. There's more to that. And if you work like this, how it was intended to be, it opened up a lot of possibilities for engineering organizations to help engineers escape their feature factories, et cetera. So lean OKR is actually a full version or actually the correct version on how I believe OKR should work.

(Joel Beasley at 00:01:46) And then why the name Moving the Needle?

(Bart at 00:01:48) Yeah, that's a great question. Because when you're working with OKRs or goal setting in general, you always want to go from point A to B. So you always want to improve the condition. You always want to improve your business. You want to grow your business. You want to improve innovation, et cetera. So in that sense, yeah, you're moving the needle. If you implement OKRs correctly, you get this exponential growth. So that's how I see that you moved the needle for your organization.

(Joel Beasley at 00:02:14) That was one of the things I liked about you, because there's a lot of consultants out there and there's a lot of books, but you chose the phrase moving the needle and you connected it back to objectives and key results. And for me, that's interesting because your business model is your consultant. Right? So you get people that are stressed out because the needle's not moving. Right? So it's pretty intelligent to write a book called Moving the Needle, because when I'm experiencing the reason why I would need your service, right, I am looking for solutions, and then I see that book and it's an aha moment. It's very exciting to find that book and then you read through it. And in that book, do you just give out like the best, most valuable information, or is it lighter and salesier and fluffier?

(Bart at 00:02:56) No, it's a very practical book. So because I got a lot of clients or people that I work with like, hey, Bart, how's this OKR thing, right? You know, how does it work? And this was actually my attempt to collect all the information that I knew about OKRs, did a lot of research about the topic also based on experience that I have with clients, and I put it all in a book. So it is very practical. So it's not fluffy, but it's also not a business novel. So it's a really hands-on book to implement OKRs.

(Joel Beasley at 00:03:26) Can you walk me through an example of like how you've worked with a client? Like they had some problem. They brought you in. Can you give me a real world example?

(Bart at 00:03:35) Yeah. So most of the clients, they call me in because they have a strategy execution problem. They want to move the needle. So then I say, okay, from all the things that you tried, it's not going to work. So you need to have a better strategy to make sure that you move the needle. And in the book I call out a very important strategy for that and that's behavior change. And if you think about that, it all makes sense. Right? So if you change the behavior, maybe of your employees or your customers, it'll result into new habits. Those new habits will result in better results, which will then result in better outcomes. And because I have a technology background, like in technology and in software engineering, you can think about, okay, we want to do this digital transformation or we want to do this DevOps transformation. What does it mean? Why doesn't it work? And I strongly believe that you need to change behaviors of, for example, engineers in order to get there. Right? And then OKRs could be a very powerful framework to change the habits, to change the behavior of people. This is one way to use it. The other way to use it is to actually change customer behavior, which is way more difficult. But the focus on changing customer behaviors, changing customer outcomes, that will hopefully result in this exponential curve, which will lead to strategy execution that you want.

(Joel Beasley at 00:04:57) So how do you actually change the behavior? I'm assuming you don't just like yell at people.

(Bart at 00:05:02) No. It starts with insights. So I think in any transformation it starts with, do we have a problem at all? Or can we just turn the lights on? And I think a great way to do that is to use metrics. Metrics that actually measure something useful, not some kind of vanity metrics. And I think that's the first start to create some awareness of the problem that we're having. I think most listeners, you know, are familiar within the tech domain or software development domain. And they think, okay, we want to increase lead time or one of the DORA metrics. Right? This is a great start to thinking about, oh, we want to increase deployment frequency. What is our deployment frequency right now? Right? And just the fact that you start measuring that, it creates a lot of awareness. Oh, we're not doing great. And also maybe compared to high performers in the market, we're not doing so great. Okay. Then the next step is, okay, what will be our target? What will be our vision? Like, where do we want to be with our company in the next year or so? And if you establish that target, then you can define some smaller steps. And breaking it down basically to move towards that longer term vision that you have, for example, for deployment frequency or mean time to failure or any kind of these deployment metrics. But the same principle applies for if you want to reduce customer churn, for example. You break it down. You first make the insight like what's our customer churn right now? And then you set the target like where do we want to be three months from now, one year from now? Then you break it down and you start with small steps, basically, and you try to experiment and see if you're heading in the right direction.

(Joel Beasley at 00:06:37) That seems pretty simple. Why is it so hard? Why isn't everybody doing it?

(Bart at 00:06:42) I don't know. No, no, it's really hard. Yeah. Yeah. It's really hard. And I think the book is called Lean OKRs because there are a lot of lean principles behind it. And if you go back to the auto factory, right, and then asking why can't American companies or European companies not adopt that model? It's the same with this question. And I think it all comes down to mindset. Right? You need to have the right mindset in order to adopt this scientific thinking mindset, which is really hard, especially for engineers, because they want to focus on solutions the whole time. Solution delivery, delivery, delivery. Instead of, oh, let's do one step back. Think about, okay, what can we explore more in our domain? What are all the obstacles that we're encountering? And adopting this mindset is, I think, key to, and basically, this problem-solving mindset is key to change the behavior. And in order to do that, you need to have strong technical leaders that can actually coach people on how to do this. And what I see now, a lot of, for example, engineering managers, they became manager, but they only became people manager. They're doing their one-on-one conversations. But they're not doing technical coaching anymore or coaching their people. And I think that's wrong. We have agile coaches maybe walking around adopting, you know, the agile mindset. But, you know, technical coaching, how are you going to deploy rapidly to production so that we can run 10 experiments per week, for example? How are you going to do that technically? And somebody need to teach that. And I think that's largely missing in many organizations, this teaching management style.

(Joel Beasley at 00:08:24) So in your engagements, do you ever have like a leader will obviously make the decision to bring you in, and then you're gonna analyze, understand the problem, get to know the team, provide different results for them, different paths that they could possibly take. How often do you get resistant teams? Like people that don't want to do the change? Because change is hard. There's a lot of people that don't like change.

(Bart at 00:08:47) Yeah. Yeah. So this is my favorite. And of course, I'm biased, but this is my favorite game, for example. It's called the Edge of Fluency Game. I'm not sure if you heard about it. It's from, it's created by James Shore and Diana Larsen. It's actually a real physical board game. And in that game, you learn how to create a startup or how to create a company, basically, and how to deal with all the technical and agile practices that come along with that, including business experiments, et cetera, in relationship to OKRs. And especially with management, when playing this game with senior management, they think like, yeah, agile, yeah, that's easy. We will play this game. And then the goal of the game is to have the maximum high score in terms of money. Like you need to make money. And almost all leaders they fail. Right? They miserably fail. Their startup dies. When I play this game with engineers most of the time they win the game. And this is really interesting. Right? They understand how it works. But by playing this game, it creates a lot of awareness about how they need to change. Like they understand, okay, there's some things that we don't do correctly right now or there's a lot of things that we can improve to get there. So you get a lot of people getting enthusiastic about this idea. Okay. This is how it can work. And then after we play this game, we can do a diagnostic. So we can look at what are the current behaviors now in a, for example, in the software development team or product team. And after we've done this, I typically engage with coaching. So actually doing coaching, technical coaching, business coaching, and I prefer just to do this in a more programming style.

(Joel Beasley at 00:10:27) How do I get that game?

(Bart at 00:10:29) You can't get it. I'm a licensed facilitator or licensed trainer so that you can get the game.

(Joel Beasley at 00:10:35) Who invented it?

(Bart at 00:10:35) But you need to—

(Joel Beasley at 00:10:37) I'll just call him. Who invented the game?

(Bart at 00:10:39) James Shore and Diana Larsen, they created the game from the edgeoffluencyproject.org. So if you go to edgeoffluency.org, there are a lot of events. I think also a lot of events in the United States where you can actually subscribe to play the game. And if you played it once, then you can buy your own copy and you can play it with other teams.

(Joel Beasley at 00:10:57) Oh, I want to play it on the show. It'll be a fun episode. Who knows? It might end up horrible or it might end up—

(Bart at 00:11:03) Oh, that would be great. Yeah. That would be amazing. But you need to do it physically. And then with, I think at least three players, that would be great.

(Joel Beasley at 00:11:09) Are you in the States?

(Bart at 00:11:10) No. I'm not. I'm in, close to Amsterdam in the Netherlands. So I'm in Europe.

(Joel Beasley at 00:11:16) Next time you're in the States, send us a message, and maybe we can figure out how to connect up and do that game and do an episode.

(Bart at 00:11:22) Yeah. And it's really fun, and it's really insightful.

(Joel Beasley at 00:11:25) I'm curious how well I would do as an entrepreneur.

(Bart at 00:11:28) Well, most entrepreneurs, when I'm playing this game with also executive teams, they all lose. So, yeah. They have no clue about how to become real agile. And not because they don't understand the concepts, but most of the time, they don't understand the technical practices that come along with that. Like, how do you build a high performing team that can deploy, you know, many times per day to production? How do you build T-shaped engineers? All these kind of things. That's something that you learn from the game. And a lot of engineers, they love it. So they are willing to change like, oh, when can we start? When can we start changing? Yeah.

(Joel Beasley at 00:12:04) Right? That's the purpose of the game is to allow them to come to this conclusion that they understand how to see the business this way and that if they make these changes, they can have better results. Right?

(Bart at 00:12:17) Yeah. Definitely. So, yeah. But you can also do it without the game, of course, by focusing on the metrics and doing a team self diagnosis on their behaviors and see how they behave and then compare it to market behaviors and then compare notes. And, yeah. Then they can decide if they want to improve or not. But what really got me frustrated and still is frustrating me is that we have like highly educated engineers. Most of them have university degrees and they're actually taking orders from product managers, product owners, like here are the requirements, please implement. And I think they're really smart brains and you should try to involve them into discovery sessions and into actually solving customer problems instead of, you know, here's the requirements, just coding and let me know when it's done. And I think you get the innovation from these moments. Right? The innovation comes from your engineers and not from product managers. Right? Because the engineers are the closest to technology. They know what's possible. They know all the latest developments. So if you just invite them to the room when you're doing discovery sessions, for example, you know, magic will happen. And I think that's the beauty of OKRs. You get a group of mixed people around a hard problem to solve, not only engineers, but also product people, marketing people, salespeople. They're all getting involved around a common problem that you're trying to solve as a company or as a product team. And then great innovations start to happen.

(Joel Beasley at 00:13:47) Yeah. Part of our onboarding process is we have people sit with the sales team during sales calls. Whether you're an engineer or whatever you may be, you'll sit with the sales team. You'll understand what we do for our sales calls so that you can have an idea of like, what are we selling our people? You know, because I call it the magical paycheck or the mythical paycheck. There's no paycheck fairy. The way an economy works is we do something useful for somebody. In exchange, they give us money, and we allocate that money. And part of that allocation is your pay to do a function that in turns creates value as part of the value that they're receiving. And if you don't understand where you fit in inside of that value stream or that value cycle, then you're flying blind as far as wanting to grow your career or improve in business.

(Bart at 00:14:38) Exactly. Yeah. And a lot of times, what I try to do with companies is building this value creation tree or something like that, a value creation structure. And most of the time this is absent. Right? How are you building value for your customers? Who are your customers and what's the value you're providing them? Right? Cheaper services, for example. Yeah. The customers don't care about cheaper services. Maybe they do, but, you know, so how are you different than your competitors? And because nobody's going to work and say as an engineer, yay, I'm going to work to make it cheaper for our customers.

(Bart at 00:15:11) We don't care. So I think every company should build this value creation model or some sort so that everybody understands how everything is connected to each other. And I think it helps with creating purpose for people and making sure that people stay longer with your company. If you have such a model, which is not focused on financials at all, but it's focusing on the real customer problems you're trying to solve and the real customer value you bring. The internship idea that you suggested, like, you know, going through sales and marketing, I think that's really powerful.

(Bart at 00:15:44) I see a lot of organizations do similar things like, you know, go to customer support, go work there for one week, see what you learn, and then go back as an engineer. And, you know, you are going to program differently. I'm sure about that.

(Joel Beasley at 00:15:56) Oh, yeah. And I'm always surprised because I have a bias because we research people, try to have some of the best people in the world on the show, so I get this situation where I'm always talking to really great people. And I try to pick up on the patterns that they have and the habits that they have, and we make notes and we research them pretty in-depth. And one of the things that I found was that these great leaders constantly are mixing their people, their teams. They try to pull people out. You don't want anybody off in a dark corner.

(Joel Beasley at 00:16:30) You want to always make sure that these people understand how the company is operating. And I've noticed that at different sizes too, and it looks different at different sizes. Right? Like, at some of the way larger companies, they have these internal systems where you can apply and go do things in different departments. At smaller companies, it's often on you to raise your hand and say, I'm curious.

(Joel Beasley at 00:16:52) To be honest with you, that was one of the patterns that I identified talking to so many leaders was that the people who were curious about what was happening in other parts of the business and, like, maybe left engineering to go actually work in customer service and then left that, worked in sales, and then did, like, a sales engineering mix or whatever it may be, working in different parts of the business, they usually end up running the business. And I thought that was fascinating.

(Bart at 00:17:15) Yeah, I think so too. And I think it started also in a revolution in Japan, I think. There was a story, I don't remember the company name, but there was like this food processing company. And if you want to start as a manager, you first needed to work two years in the meat processing factory, you know, just as a regular employee next to everybody else. And then after this two years, then you became a manager.

(Bart at 00:17:39) I think we can learn a lot of things from that in the software space.

(Joel Beasley at 00:17:44) So you said when we first started talking that people do a lot of things that don't work when they're trying to solve these problems or move the needle before they find out, like, a formula or meet with you and figure out how to get systems in place correctly. What are some of the things that they're trying that aren't working?

(Bart at 00:18:02) Yeah. I think most managers or most leaders, they don't think about behavior change strategies at all. Like, and I think that's the problem. Like, you know, they're adding to the mix. Now are we going to buy this tool or we're going to implement a new process or we're going to invest more in more features of our product.

(Bart at 00:18:19) But I never think about behavior change strategies. Like, what kind of strategy can we develop to change behaviors of our employees or to change behaviors of our customers? And I think that's really important because, again, if you think about it, if you change the behaviors, you change the habits of people or habits of customers, and this will lead to different results. And in most organizations this model is just absent.

(Bart at 00:18:47) It's not there. So there's no framework or no governance process that is helping with this change. And I think if you're in the software space, you need to constantly change. Right? You need to constantly adapt and change because you can do a digital transformation and after the digital transformation you're done, but it doesn't work like that.

(Bart at 00:19:06) You should continue developing, continue to change. So you need to build up this memory muscle to continuously change and, this continuous change mindset that needs to grow in people. You need to change your culture first. And I think a large part of culture, like culture is what is it? Right?

(Bart at 00:19:24) And I think a big part of culture is behavior, how we behave in a company. And we can define core values of a company, but they're too vague. Like nobody— instead, like, we want to be, you know, everybody should be an entrepreneur. Like, what does it even mean for us? Right?

(Bart at 00:19:39) But I think if you translate it back into, okay, what are the norms that we should live by? And if you can then translate these norms into, okay, what behaviors do we then expect in a company? Or what behaviors do we require from engineers? Or what behaviors do we expect from marketing managers? If you can then document that and you can put it in their functions, then you can evaluate people on that.

(Bart at 00:20:01) You can do performance reviews based on behavior, which I think is not based on, you know, that you make the results yes or no. Right? I think you should really reward and incentivize people on how they behave, but it's almost never quantified. And I think that's what was largely missing in action. And OKRs could help with that.

(Bart at 00:20:22) Right? It's what again, it is an addition to what should already be there.

(Joel Beasley at 00:20:27) When you're doing these projects, is it typically with smaller companies or larger companies?

(Bart at 00:20:33) It varies a bit. So I help some startups as well. I invested in some startups as well. But typically, I help a little bit larger organizations. So from, I think, like 30 to 50 product teams, something like that, until like Fortune 500 companies like ING in The Netherlands or Nike.

(Bart at 00:20:55) So it really depends. But my sweet spot is actually, because I have this software engineering background, to help like SaaS companies or FinTech companies. That's my sweet spot because then I have some knowledge in that area. So I prefer to engage with these companies.

(Joel Beasley at 00:21:12) Cool. And I want to give a shout out before I forget. You have a podcast. What's the name of your podcast?

(Bart at 00:21:18) Yeah. We just started it, and the podcast name is just very fresh. It's the, the Phils and Bart's Software Adventures. I started that podcast with a good friend of mine, Philip Bender. And he's the CPO, CTO of Lieutenesta, which is a small company in The Netherlands as well.

(Bart at 00:21:36) And we're just geeks around the software delivery method, which is called extreme programming. It's really old. It's developed by Kent Beck around 2000. And we're obsessed by this technique. And I think there's a lot of harmony with OKRs and extreme programming.

(Bart at 00:21:51) And I try to unify these models as much as I can together because I think the principles behind and the values behind extreme programming really match. So in this podcast, we try to explore this concept and how that applies to modern software development.

(Joel Beasley at 00:22:05) I've heard of Kent Beck. I've read some of his stuff, but I hadn't, like, actually gone into extreme programming. When we were in our prep meeting doing review, we thought that it would be something, like, competitive style, something of that nature, but it's more of a framework.

(Bart at 00:22:22) Yeah. So that's the funny thing. Like, it was considered extreme in 2000, where you had, like, you know, software development cycles of one year or half a year cycles or something like that. Right? It really took ages to get some piece of software out.

(Bart at 00:22:38) And there was a lot of waterfall. A lot of waterfall. And, you know, I think it was even before the Agile manifesto came out. And then Kent Beck, he wrote this book and he was calling it extreme programming. But today, it shouldn't be extreme at all. It should be just regular software development. And it's the only software development method out there.

(Bart at 00:22:59) Right? Things like Scrum. These are not software development methods at all. They're just work systems. So this is the real software development method.

(Bart at 00:23:09) The only software development method out there that's documented and tested in time. But it isn't extreme anymore. So these days, but you would be surprised how many engineering teams don't work or don't look at these values and principles to become high performing teams. I think if they should, then a lot of organizations will reduce a lot of waste in their organizations. But, however, there are some extreme things that are still there.

(Bart at 00:23:34) For example, OKRs or lean OKRs is still an extreme thing because not a lot of organizations can do this.

(Joel Beasley at 00:23:40) Well, why can't organizations do OKRs?

(Bart at 00:23:43) Because it requires a lot of prerequisites for them in order to do that. So for starters, they need to become a product team. Like, you know, they should have, like, cross functional teams. Well, in many organizations, that's still not the case. Right?

(Bart at 00:23:56) They're still— well, we only have like engineers and then we have different QA departments and we have different departments that's defining the requirements for us and you just throw things over the fence. We have a different ops department that's doing the ops. So it makes it really hard to do OKRs. So just imagine that you need to run— if you're a startup, then it's easy. Right?

(Bart at 00:24:14) You can run a couple of experiments per week. But if you're a little bit larger, like 500 people or so in size, then running five or 10 experiments per week in production is sometimes crazy, let alone for larger established companies. Like, they can't even make a software release every month, let alone that you can release experiments six to 10 times per week. So you need to build up these technical capabilities, so you can actually do these experiments.

(Bart at 00:24:47) And you can experiment fast and fail fast. And you get these feedback loops in place. But in a lot of organizations, these feedback loops, they don't exist, or they're too slow to get some decent feedback. And then, you know, OKRs don't work because with OKRs, you try to do weekly check ins and see if some metrics are moving up or down. And based on these results, you take appropriate actions. But if you need to wait for one month or two months to see a metric go up and down, yeah, then you're too late.

(Bart at 00:25:12) So that's, I think, what's often missing in many organizations. Of course, if you're just, you know, two guys in the garage, then things are different. But, yeah, maybe a little bit larger, then— and I think that sweet spot already starts at 30 people, something like that, then things are already going down.

(Joel Beasley at 00:25:27) I did an interview with GoDaddy, the CTO of GoDaddy, and I was fascinated by how well they run experiments across the company, and they've built their own software to manage the experiments. I hadn't seen a company of such scale do it as such a large part of their culture.

(Bart at 00:25:46) Yeah. We have a company here in The Netherlands. It's called Booking.com.

(Joel Beasley at 00:25:49) Booking.com?

(Bart at 00:25:50) Yeah. Yeah. They do similar patterns. Like, they have, like, tons of experiments running in production. It's just crazy. Yeah. But exactly, they built the whole framework for that, to run all these experimentations and to see the results.

(Joel Beasley at 00:26:03) So for a CTO or tech leader, let's give some context. Let's say they have 30 people in engineering, and they're growing. Right? They're a growing company. They have 30 people in engineering.

(Joel Beasley at 00:26:18) It started out the CTO as, you know, just cofounder, them and someone else, and they're so happy to be where they are, but they want some insight or some advice, like one thing that they should be thinking about or they could be doing to improve. What would you tell them?

(Bart at 00:26:35) Improve the speed of learning in a company. One of the big bottlenecks that we see in organizations, especially when they're growing, is how fast the information is reaching down to the branches or reaching the engineers. And when a company grows that ability goes away or, you know, there's a lot of top down management happening and then the information that is needed for engineers is not coming to them. Right? Or they have some Wiki page and they can't find the information that they want or other things.

(Bart at 00:27:06) So I think if you optimize for speed of learning, just from the very start, feedback loops, how to do documentation, coaching, training, et cetera, I think this is one of the biggest things they should master.

(Joel Beasley at 00:27:20) Thank you. Thank you. That's good. I haven't heard that one said like that before. I did learn a lot when I started a, like, a learning company, specifically, because you were selling into learning and development teams.

(Joel Beasley at 00:27:35) And so you had to start learning all of their words and all of that. And one of the things that I learned is behavior change. They talk about behavior change constantly. There are scales. They measure it.

(Joel Beasley at 00:27:47) They try different things. People dedicate their whole lives to researching this. And when I started to go over there, I was like, wow. When you learn how people learn, it's pretty powerful.

(Bart at 00:27:58) Yeah. And I think a lot of managers should master this skill. And I always do the thought experiment with engineers. So just think about your last biggest project.

(Joel Beasley at 00:28:08) Okay.

(Bart at 00:28:08) And then think about how long it took you to finish that project. And probably most people say, well, you know, three months, something like that. Six months, maybe large projects. Took me three months, six months to develop. And I say, okay.

(Bart at 00:28:22) What if you need to do this project again with all the knowledge that you now have? How much time does it take you now? And they say, whoa, yeah, one week. Right? Yeah.

(Bart at 00:28:31) Or those kind of crazy numbers. So then I say like, okay, what's the bottleneck now? Is the bottleneck really how fast you can implement your requirements or how fast you can type? Or so what's the bottleneck? Well, the bottleneck is always, you know, knowledge.

(Bart at 00:28:46) So when you're thinking about optimizing that, when you're thinking about lean, I think it's all, you know, knowledge that is stacked, is queued up. And that needs to be processed and it's not going fast enough. So if you optimize how fast people can learn, then you nailed it, I think. And I think a lot of engineers, engineering managers, et cetera, CTOs, they forget about this. And that's one of the things that I, you know, in my book also tell, you know, is that you should go away from, you know, this passive management style, but you should actually start coaching people way more actively.

(Bart at 00:29:17) Coaching, teaching, so they become you. Or not you, but they master the same skills. So I think that's really powerful. So speed of learning is everything in both teaching and but also in feedback loops that you get from customers and et cetera, which will ultimately then change behaviors. Because you can't change your behavior if you don't know how to act or react or something like that.

(Joel Beasley at 00:29:41) Why should I listen to you? What's, like, what's your experience historically? Have you operated as a software engineer?

(Bart at 00:29:48) Yeah. So I have a strong background in software engineering. I started when I was 18 years old. You know, I always did my studies next to work. So it was a special program.

(Bart at 00:29:58) So four days a week and one day I went to university. So I already started like really, really young. So that was in the middle of the dot-com hype. So it was, you know, crazy times. It was amazing.

(Bart at 00:30:09) So I have this education in— and then, you know, I've studied in software engineering and organizational design, et cetera. So my ultimate goal was I want to work for a space agency. Right? European Space Agency to be exact. Well, NASA will be great, but, you know, I live in Europe. So, no, second best thing.

(Bart at 00:30:30) European Space Agency.

(Joel Beasley at 00:30:31) Don't say that. Europe is a great first choice.

(Bart at 00:30:35) But now you're a space expert. Anyway, yeah. So that was my dream to work there. So and I did. So I worked there helping on innovative solutions for the Galileo project, which is a constellation of, no, 35 satellites.

(Bart at 00:30:50) Basically, we want to get rid of GPS as Europe. We develop our own navigation system, which is better, which is called Galileo. So I worked there to experiment with a lot of innovation projects there. Then the lead time of these changes—the lead time of the changes, I didn't like, because the changes that we implemented still need to be launched into orbit. So, yeah, there's a lead time of ten years or something like that.

(Bart at 00:31:15) So, you know, waterfall, all that. So I wanted to—you know, I thought that it was all, you know, software engineering in space is cool, right? You know, robots and marshlanders, et cetera. But it's really boring. So I decided to quit and join the commercial software development industry.

(Bart at 00:31:32) And I started in a lot of companies, like primarily into fintech. And I started working in a company that grew from nine people in a basement to now today, like 2,000 people. So really rapid curve with OKRs implemented. And I've been working in various functions. So from software engineer myself into platform architect, interim CTO, all these kind of roles I did.

(Bart at 00:31:58) But I'm really happy now to be part of this journey to help people implement OKRs because I think a lot of engineers can benefit from working in this way. And I think for a lot of organizations, I think you owe it to your people to work with this technique, or not necessarily OKRs, but, you know, working in an outcome-driven way so people get more engaged and have more purpose in their work.

(Joel Beasley at 00:32:23) And how do you get started with that?

(Bart at 00:32:25) Well, I think how you get started? I think you should, of course, buy and read the book. I think that's the easiest one. Yeah, that's probably the best one.

(Joel Beasley at 00:32:33) Yeah. Call you.

(Bart at 00:32:34) Call me. No, no. I think the most easiest one—there's, if you go to my website, movingtheneedle.com, there's a free email course where you can just sign up and you get, like, 13 lessons for free. Then you get just the basics of OKRs and you can, you know, make an assessment call if it's something for you or not. Maybe your organization is ready for it. Maybe your team is ready for it or not. And then you can take it from there. And then you can buy the book or ask me for help or something. But I think that's the easiest way.

(Bart at 00:33:00) But like I said before, I think you should also check on your culture first. Like, are we ready for this experimentation and this rapid growth? Because it can be very challenging for engineers to work in this way, right? It's not that it's very stressful, but if you're going to be asked to improve business outcomes or customer outcomes, it's not entirely in your control anymore. Right? And you need to come up with—you always need to think about solutions and think about innovative ideas. And sometimes that can be challenging for people. And there's a lot of teamwork involved in that. And maybe if you don't like teamwork, you don't want to work in this kind of context.

(Bart at 00:33:38) So, yeah. But I think for most engineers, they love fixing hard problems, right? So I think it's a perfect match if you want to solve bigger problems than only, you know, the requirements of today. Then I think it makes a lot of sense to start using it or experiment with it. Just try it out for one quarter, see if it works, if it changes anything in your company.

(Joel Beasley at 00:34:03) I think it's easier now more than ever. When I started programming, I mean, the first several years of my career were just me and, like, a manual. And then I found out, like, people wrote books about it. And then I started following people that wrote these different books, and I realized that then they had conferences. And then, I mean, this is over the course of a decade, like, the first journey.

(Joel Beasley at 00:34:25) And then once I realized that there's books and there's conferences, and then there's thoughts, like, different patterns of thoughts within, like, the software industry as a whole, and you get to the point where you find out what everybody agrees on, and then you find out what the experts—the details the experts argue over. So now if I were to go into, like, another industry, the first thing I would do is, who's the top authors, what are the conferences, what are the talks that they're giving at the conferences, what do they agree on, what don't they agree on, because then you can speed up your learnings, like, significantly.

(Bart at 00:34:58) Yeah, for sure. Yeah. Yeah, I also remember that I still have them on my shelf, all my C++ books.

(Joel Beasley at 00:35:03) Oh, yeah. Well, buy the book Moving the Needle. Yeah, give Bart a call if you want to move the needle. And then is there anything that we didn't cover that you want to touch on?

(Bart at 00:35:15) No, I think we touched on a lot of topics.

(Joel Beasley at 00:35:18) Well, we nailed it, man. Thank you so much. We made a podcast. How do you feel?

(Bart at 00:35:21) Yeah. Nice conversation. Yeah, good questions.

(Joel Beasley at 00:35:25) 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.