The Platform Engineering Pitfall You Aren’t Looking For (Yet)

David Sandilands [0:19] Welcome to today's episode of the Pulling the Strings podcast, as always, powered by Puppet. My name is David Sandilands. I'm a product manager here at Puppet and active in our community, David Sandilands, or unfortunately, on Twitter as DNSandilands since I was beaten by a driving instructor in Glasgow. Today we're talking with Justin Reock, who is the field CTO and chief evangelist at Gradle, Inc. We will be covering a lot of topics today, including platform engineering, the general evolution of the hype cycle and its impact on our lives working in tech and how we can really find things that progress us against just yet another VC buzzword. So welcome to the show, Justin.

Justin Reock [0:58] Thanks, David. Really nice to be here.

David Sandilands [1:00] So do you want to just tell us a little bit about your background and maybe just a non-work fun fact?

Justin Reock [1:05] Sure. Let's see. So my background is primarily in software development. I put in my 10,000 hours coding for a little ISP called EarthLink. It was actually a company called MindSpring that started out of Atlanta and then was purchased. For the longest time it was the biggest private ISP in the country. I think it's like a holdings company now or something like that. But I went on to do more enterprise architecture, really was drawn towards a lot of open-source work, which actually would take me to a little company called OpenLogic that was purchased by Rogue Wave and ultimately purchased by your parent company, by Perforce. So I spent some time within those walls as well and had a lot of great opportunities to work with a lot of great partners and other people in the industry. Now I focus primarily on developer productivity initiatives. Gradle has a emerging practice that we call developer productivity engineering, which we're seeing from a microeconomic level be the next phase of maturity that businesses will take towards refining their focus on developer productivity and developer experience. So that's a lot of what I talk about now. A fun fact, we are selling our house in Florida and we closed on our RV a couple of weeks ago, and we're going to live on the road for at least a year.

David Sandilands [2:21] Oh, wow. That's awesome.

Justin Reock [2:22] Yeah.

David Sandilands [2:24] My son would be very jealous. He's obsessed with motor homes.

Justin Reock [2:28] I have to say they're very cool. It was my wife's idea, and I grudgingly was like, "Okay, well, we'll do it." But now having clothes on the thing and working on the thing, it really appeals to my engineering sense I think because everything is so accessible. You have all the systems that you would find in a house, everything, but it's all minified and accessible. So whereas I might spend two hours demoing a wall to get to something I want to work at in a real house, I can literally just rip the panel off of this RV and get to whatever I need to. So it's interesting from an engineering perspective for sure.

David Sandilands [3:04] So today we're here to talk about platform engineering with a emphasis on whether it's an uphill trend or a downhill trend. What's your take, Justin?

Justin Reock [3:15] Yeah, so first of all, I think it's an excellent practice. I'm really pleased to see this industry attention on developer experience and creating a more productive environment for our developers to work in. It's obviously a subject that means a lot to me, but it's a subject that should mean a lot to everybody because as of 2022, and I'm still waiting on IDC's report for 2023, over 65% of the global GDP has now been digitalized, which is staggering. That is a tremendous amount of code and a huge workforce that has to produce that code. So anything that we can do to improve the overall happiness and ultimately productivity of this workforce I think is a very good thing. Platform engineering, I think it's seeing a rise in popularity largely because of the work that's been done by Spotify. They have an excellent platform called Backstage, which is an open-source platform for designing... It's like a platform for platform engineering effectively, and it allows you to design various platforms and deploy them at scale. It's been getting a ton of attention, but I think that there's a lot of indicators throughout the whole market that this is becoming front and center for a lot of people. Part of what I do for Gradle is I help to manage analyst relations, and so I spend a lot of time knee-deep in Gartner research and that kind of thing. Their CEO surveys are always pretty enlightening. They're very simple to understand, ask CEOs a number of questions, what's top of mind for them? What are they thinking about? The 2020 CEO Gartner Survey indicated a single digit concern at the C-suite level for developer experience, so it was barely on their radar. But you fast-forward just two years to the 2022 survey, that number's in the 70s, so this acute attention all of a sudden at the C-level to developer experience. Now I think you can partially attribute that to COVID and having to take everything remote and hybrid, but however you cut it, there's more attention in the industry now towards building a good experience for our developers, so I do think that it's here, it's here to stay. Then I think you have to look at the demographics of various companies and not even necessarily their demographic as much as maybe their culture, the way they operate internally and their level of maturity towards thinking about developer productivity. But you'll see companies that are, they've been doing a great job with this. They have scalable platforms that they roll out. They have dedicated platform engineering teams. Then you see folks that are just starting to dabble in it, and then you see folks that are well past it. So you take a company like LinkedIn, Twitter, I was not supposed to talk about Twitter right now, but Facebook, Uber, Square, these are all companies who I would say within the last 10 years have created, scaled and matured platform engineering teams and have now moved to this next level, which we're really seeing is this practice of developer productivity engineering. The microeconomic being, if you look at, for instance, LinkedIn has a whole department that's just developer productivity engineers, that's their title, end developer productivity engineers. But if you look at a lot of their career paths, a lot of them were DevOps, SRE 10 years ago, and then they became platform engineers and then they became productivity engineers. So I think you've got this great practice that's eliminating a lot of friction and toil for developers, but I also don't think it's the end state. I think it's actually a mid-step between going from a DevOps metrics-oriented, data-oriented mindset to going full bore productivity engineering.

David Sandilands [7:01] Yeah, that was something interesting we saw in the data DevOps report, which was focused on platform engineering was, although many of the tech companies you talk about there, they often become the focus because they're cutting edge. There's still a large majority of companies who are similar to my background in terms of I worked for BSkyB, a large cable company, and Royal Bank of Scotland, which is now NatWest Bank who tend to evolve slightly behind big ships, hard to make big cultural changes. I think what we saw in that report was a lot of the platforms were still under five years old, and I think the majority were. So I guess it's going to be interesting to see if they stick to it because I think when we first saw DevOps come to bigger companies and more traditional firms, I think there was a mix of people who really engaged with it and the others who got up the DevOps banners and pens and marketing, but then actually really embrace it for the long term beyond some spending to look up-to-date. So when we're coming into platform engineering with that and we can see the success these technology firms have had, how do you see the best way for the bigger, more traditional firms who always struggle with this to succeed?

Justin Reock [8:30] That’s a great question, because it's one that ends up, you see this story over and over again. You have the big company that reads about Agile and then they want to become Agile, and then they decide, "Well, we're just going to be a little bit agile," which is not agile. You tend to see that. You see it with DevOps too. "We're going to do a couple of DevOps things, maybe we'll do CI/CD or something like that, but not necessarily drink all of the Kool-Aid. Maybe we'll do auto deployment, auto testing, CI/CD, but we're not doing continuous feedback or anything like that." The one thing that all of these successful productivity practices have had in common, if you'll forgive me, I'm going to draw on the ancient business wisdom of the 1970s and the 1980s, which I'd like to talk about a lot when we talk about productivity specifically, I'll talk about the book The Goal, Eli Goldratt's The Goal, which introduced the theory of constraints to manufacturing businesses at the time. For those of you who have read The Goal or if you read The Phoenix Project, which is a direct homage to The Goal, it's basically the same story except told through the protagonist who's a software VP of engineering as opposed to a VP of manufacturing. But one of the most important lessons that comes out of the theory of constraints is that for any system to be improved, you have to do two things. You have to decrease that system's cost and you have to simultaneously increase that system's throughput, and you can't really do one or the other. So the theory of constraints loves to call out, for instance, the fallacy of layoffs, like corporate layoffs that, "Okay, we have a problem with cost, we're going to control the cost by calling down resources." But the companies who do that without a plan to maintain or even improve their overall throughput, the layoff's just a Band-Aid. It doesn't fix the endemic problems. So what of these all had in common, though? They've all simultaneously, when practice at scale, they've decreased the cost of an organization while increasing their organization's throughput. I think that's why Lean, Six Sigma, why Agile, why DevOps, why now platform engineering and ultimately developer productivity engineering are all successful is because they have the potential in every case to make these sorts of improvements for a business. Now, for those large companies that are very difficult in terms of changing culture and in terms of rolling out new practice, you're going to run into a lot of the same pitfalls that any of these companies would've run into trying to adopt Agile at scale or trying to adopt DevOps at scale. You're going to end up with resistance. You're going to end up coming across systems that don't appear or processes that don't appear compatible, and so we end up sacrificing part of that process. So I would give the same advice that I've given in the past about practices like Agile and DevOps, and that is, if you're going to adopt them, let them do what they're supposed to do holistically. What I mean by that is instead of being a business that's trying to adapt agile and saying, "Okay, well we can't do this because it doesn't fit with this," well, the process is proven time and time again. If you are altering the process, then what's really happening is you're ignoring an extent problem in your business that needs to be fixed. People don't approach it that way. They have said, "Okay, well we're just going to call down the Agile thing." "No, no, no, go find the incompatible process in your business 'cause I guarantee you it's causing damage and fix that incompatible process and then adopt it by the book." So I would say I would make the same appeal for platform engineering. I would say don't just assign one person in the organization to create some zip file with an IDE in it and some basic configuration and send it around and consider that to be platform engineering. Do the whole thing. A large, I would say, theory behind platform engineering and then certainly developer productivity engineering is to adopt a mindset where you're treating the development environment as if it were a production environment in which developers are writing code because that's actually what it is. It may not be that the code running on that laptop is running in your production, but that laptop is a production machine that a developer is using to create code. So don't just spin out the platform, monitor the platform. Collect feedback on the platform, improve the platform, and have a dedicated team, not just one person or a couple of people who were senior developers spending a couple of hours a week on the platform. You really want to make this a center of excellence. I make that appeal fully realizing that most businesses are in the other camp. Most businesses are, "Oh, we're going to try Agile. Oh, we had to change this part and then it didn't work, so we ditched it." But it's like, "No, you did it wrong. You should have used this opportunity to find problems in your business.”

David Sandilands [13:33] I couldn't agree more, 'cause I can tell you the story of early on when I saw Agile being adopted and they went into the classic mode to which you describe, which is they fix Agile on to the processes they already have. I can still remember being ordered that each sprint had to add up to, and I can't remember how many points it is, it doesn't matter. We had this certain scale and we came to two points out, and we're having to go back through complicated mathematics just to make sure the points add up to what we want rather than catering it to what we're working on. I think there's all sorts of hurt that happens like that because they're adopting the hype, not the actual practices. I think one of the most important exercise I see done is getting people together cross team and get in front of a whiteboard and try and put the technology to the side and actually working at how people actually need to work.

Justin Reock [14:35] You know what? So right about, there's a book that I really like called Organizational Physics by an author named Lex Sisney. You can tell there may be a pattern here. I really enjoy these perspectives on business when we try to apply the laws of physics to them. When we treat a business like a complex piece of machinery, well, it's really useful because you can't break the laws of physics. So if you start thinking about it in terms of that sort of model, you can make these really nice predictions about how a business is going to behave or operate. Anyway, long story short, Lex Sisney calls out in Organizational Physics. These four different forces is what he calls them, but really they're personalities, and that's a producer, a stabilizer, an innovator, and a unifier. Most people are one of these things naturally. All of us, if we've been around the block enough, we can put on one of those hats. But in terms of if we've got our eyes closed and we're not really thinking about things, we tend to fall into one of those categories just most naturally in terms of the least energy expenditure to be one of those four personalities. The thing is that in this industry, we seem to have a great deal of producers and innovators, and I think that that is just part of the engineering personality makeup right now. A producer is somebody who feels most comfortable when they have 15 years worth of work in front of them, and they just can heads down, do their work, produce, produce, produce. That's where they feel good, that's where they feel comfortable. Innovators are innovators. They're coming up with a new idea, and then if you ask them about that idea they had two weeks ago, they're like, "I don't know. What are you talking about? I'm thinking about this new idea now." You don't see a lot of unifier, which are the people who can make all these folks work together really effectively, and you see even less stabilizers. The folks who are, they want a spreadsheet, they want a process, they want data, they want metrics. Oftentimes, you see these personality conflicts, you'll get somebody who's an innovator who feels very slowed down by a stabilizer. But vice versa, you get a stabilizer who's just ripping their hair out because they're working with this innovator that they can't just seem to pin down on anything. So it doesn't always come naturally, I think, for those of us who are in this industry to do what you just said, to be able to actually put down rubber meets the road, let's get on a whiteboard, let's align our priorities, let's make sure that we're being thoughtful about the work that we're doing. But of course, the businesses who go through that exercise tend to see a lot more success because it's great to innovate and it's great to produce, but you can't just do things. There needs to be some direction to it.

David Sandilands [17:11] I can remember a very tragic project where joining as the support person of the time and hearing about, I think it might have been an OpenShift project, it's not too important, but I asked a simple question about how to integrate with our change management processes, and the response was, "Those processes will just have to change." So you can imagine which way that went.

Justin Reock [17:34] Right.

David Sandilands [17:36] Of course, that's not saying these processes can't change, but you've got to have done that work upfront and have it agreed.

Justin Reock [17:44] So I would say going back to this original question, how can businesses that are, I wouldn't say intentionally resistant to change, they've just become so large and so complicated that there's a lot of stakeholders and a lot of people that have to be dragged along. I would start, and I know how cliche this is, and I will never forget being 20 something years old, working as a programmer, hearing about these business-y, cheesy things and thinking that was so lame and it would never matter. But having a charter for the project, which people skip that step, they just go right into it. They're like, "Oh, the charter is we're going to become Agile." "No, what do you think becoming Agile is going to do for your business? What are you going to be doing in terms of outcomes?" Then once you have a charter, "This is why we exist, and this is what we're moving towards." When you are faced with a difficult decision or when someone in the business feels misaligned, as long as you are doing things according to the charter, you can always look to the charter, so it makes things way less fragile. Like, "I'm about to make this decision right now. Does this decision serve the purpose of the charter, or does it take away from it?" Then it should be a pretty easy decision after that. So make sure that you not only understand why you're undertaking a platform engineering or a productivity engineering project, but understand what you want success to look like. What is the outcome? What is the big picture outcome from all of this? That's going to help you inform all the difficult decisions and details along the way. Then the next thing is to really make this a focus for an individual or set of individuals. So as opposed to saying, "Hey, I've got this little side project for you, senior developer person, I want you to start looking into platform engineering." Now, it needs to be a full-time focus. Don't make somebody context switch between trying to do this new strategic thing for the company and going to have to go about their day-to-day stuff. Even if it means hiring somebody, get somebody who's focused on this or a group of people who are focused on it. Then finally, I would say, especially for a larger business, there's no reason for you to do this yourself anymore, Backstage is totally free, it's open-source. I'm sure that Spotify is thinking of ways it can monetize it, but it's not really doing that right now. By starting with something off the shelf that's already proven, that already works really well, it takes so much of the guesswork out of how you're going to actually have to do this implementation. Then the last thing I would say is go to conferences, go to DevOps Days events, specifically. The DevOps Days shows are fantastic. As far as we know, those events are where the term was coined. Patrick Debois started the DevOps Days event in Gantt, Belgium in 2009. There's some argument over whether he had used the term once or twice before that, but certainly up in headlines, that was the first time that the term had ever been coined. You can learn so much talking to the people who go to these shows. They're not heavy sponsored events. There's not a lot of fluff there, and they're cheap. They're like 100 bucks, and it's centralized to devopsdays.org. So this is a non-profit organization that's just there to educate and advocate about DevOps, and there's a lot of platform engineering discussion going on in that bit of the universe right now. So yeah, to summarize, start with a clear direction, know why you're doing what you're doing. To your point, David, earlier about getting caught up in the hype or the buzz, if you don't know why you're trying to create scalable platforms for your developers, if you don't know how that's going to assist in their onboarding and how that's going to reduce the maintenance required to keep their environments stable and performant and reliable and consistent, if these aren't the outcomes that you're clear on, you're setting yourself up for failure. So make sure you have a clear charter and know what you're doing while you're doing it. Then make sure that you've got dedicated resources with real focus on this. Use an off-the-shelf platform if possible, as opposed to doing all this stuff yourself and then get involved. Get involved in the communities that are incubating all of this new way of thinking.

David Sandilands [22:05] I guess as maybe move towards final points, I think what can be interesting there is what you're highlighting to me is companies who are investing in the people and making sure that they have a charter and they have a clear way for people to understand how to work to, and they're going to conferences and being invested in, there's almost this tragic way of getting it wrong of when you get it right, it's really great for the employees. But if you get it wrong, you end up creating a burden on the day job and you actually end up ironically making things worse for them. But as you highlighted, people who end up still doing the original job, but being handed a whole bunch of extra responsibilities to, I guess, go through the agile motions without actually meaning it.

Justin Reock [22:56] Yeah, I think you're spot on there. I think that the success of these things, I think, always hinges on being able to observe the outcomes. So I would say then the way that you deal with that, that's why the metrics are so important. Understand what key dimensions are we hoping to improve? What changes are we trying to make? So here's an example. You might be familiar with the SPACE framework, if not the SPACE framework. You definitely, I'm sure I'm familiar with DORA Metrics. These are both invented basically by the same person, Dr. Nicole Forsgren, she started DORA, sold it to Google and is now investing heavily in a company called DX, which you can find at getdx.com. I think the work they're doing is just stellar. The SPACE framework is a way of thinking about organizational productivity through what I find to be a much more comprehensive lens than some of the traditional metrics that are used to measure productivity, things like team velocity, meeting deadlines and whatnot. So SPACE consists of five overall metrics, S for satisfaction, P for performance, which means, are we meeting deadlines? Are we getting vulnerabilities patched on time? That sort of thing. Activity, which is just raw activity, cranking out code, running bills, that kind of thing. Then collaboration, communication, which is what it sounds like, and finally, efficiency and flow. Then the way that you gauge these things, there's no prescriptive way to gather the data, it's a normalization framework. So for instance, you could just send an email out to all your employees and say, "How do you think about productivity? How do you think about your productivity?" Then when they write back in short form or whatever, you classify each of those sentences into one of those five dimensions. "Okay, this sentence was about collaboration. This sentence was about activity. This sentence was about performance. This sentence was about satisfaction." There's all kinds of compelling data out there. One of them being that we seem to be very masochistic as an industry. Typically, when you run these studies, the satisfaction component is in the single digits and it's like all about activity and performance, but really, it should be balanced. Really what you want is an even spread across all five of those dimensions because they're equally important. But I say all this to say, adopt something first. Say, "Okay, we ran a SPACE inquiry around our developers and we got this stuff back and we found out that developers don't think that we're doing things very efficiently. We're in that 5%, 10% category on the E dimension, and they're not very happy. There's not a lot of job satisfaction. So we want to implement whatever, develop our productivity engineering, platform engineering to improve these two metrics." Now we have a clear goal. So now what are we going to do? "Well, let's see, our build times suck, they're 20 minutes long and the tests are flaky and it fails half the time. So we're going to put some acceleration technologies in place to speed up those builds, speed up the cycle times. We're going to put flaky test detection in place, and we're going to start taking action on flaky tests and eliminate them." Then six months later, after you put those things in place, go run your SPACE survey again and see if you move the needle. Those metrics, again, it's the oldest adage into the world. It's a 3000-year-old saying, "What gets measured gets improved," but that's just as true now as it was 3000 years ago.

David Sandilands [26:31] No, absolutely. I think if we pull a few things together there, if you have no benchmark and no understanding where you're coming from, you can't really have any clue where you want to get to. I think a lot of these systems, when you see the places that are suffering from a hype cycle, whatever they're chasing, often they just go out and they buy the book and they copy things exactly as it says. Where I find things like Safe can be quite problematic is that a lot of organizations just want the copy, they want the handbook that tells them exactly what to do without thinking about why they're doing it or what they're trying to achieve from it.

Justin Reock [27:16] I couldn't agree with you more about Safe. In fact, I was just having this conversation, almost identical conversation at the UberConf show last week in Denver, talking about the promise of some of these things but that... and again, I don't want to detract from what I said before. I do believe that Agile is prescriptive, and I do believe that it's very black and white, that you're either doing Agile or you're not. If you claim to be doing a little Agile, then guess what? You're not doing Agile. So I stick with that. By the same token though, I think you're exactly right that when you have a framework that's just like, "Okay, but just here's your prescription and one-size-fits-all," and you don't have to be thoughtful about how you're going to make these processes work for your business, then it just becomes untenable. It is just hype at that point.

David Sandilands [28:04] I guess just one thought actually, is in terms of these cycles we've seen and we talked about in terms of Agile, DevOps, platform engineering and developer productivity engineering – do you feel like one of those has had a lot more impact than the other, or do you feel it's all been on the shoulders of giants?

Justin Reock [28:25] Oh, that's another excellent question too. I think a lot of it is how commoditized the practice has become. I think we can go back even further in time. We can look at business process re-engineering from the '80s and early 90s and Lean and all of these. Business process re-engineering would inform Lean and Lean would inform Agile and Agile would inform DevOps, and DevOps informs platform engineering. Platform engineering absolutely is informing and helping to execute on developer productivity engineering strategies. I think it's just a matter of what's been around the longest and has had the time to make the most impact, and they're solving different problems. So an example, platform engineering is really great for onboarding, quickly rolling out in a repeatable, scalable way developer environments and platforms for them to do their work, and then also enforcing and standardizing configuration across all those platforms. So what bottlenecks does it help with? It helps with operational bottlenecks in terms of developer rollout. It makes it easier to maintain these environments. So for people who have to administer these systems, their overall toil goes down. Then conceivably, because we're controlling the platform, because we're scaling the platform, hopefully, the platform engineers are also optimizing the platform. So the developer experience gets better and better. Now, at Gradle we don't see a difference between developer happiness, joy, and developer productivity. For us, it's actually one and the same. It's because the act of writing software for someone who loves to do it is a joyful activity. It's also very interesting what goes on in the brain when someone is writing code. This isn't just pseudoscience, the brain has actually been mapped while developers are writing code as part of various research. What's interesting is that there's this soup of left and right brain activity happening at the same time. On the one hand, you're in this state of creative flow, absolutely, where you're thinking about a problem, you're visualizing that problem in your head. You're coming up with a data structure or a logic structure or something that would solve that problem, so now you're doing something very creative. But then we do do something else. We turn around and now do something scientific. We write a bit of code and we ask the build tool chain, the platform, we ask the platform for feedback about our work. Did we do the right thing? Now here is where from a developer productivity standpoint, all of these practices rubber meets the road. If at this point when the developer is asking for feedback about their build, if the platform has been engineered and has had developer productivity engineering principles applied to it and is now optimal for feedback cycles and has a very trustworthy, consistent and reliable test set, then the experience is great for the developer. They get a feedback immediately that's useful. They don't have to wait 15 minutes for something to complete and go context switch and go off and do something else or doom scroll on their phone or whatever, and then switch back into what they're doing later when that build finishes; or if the build is faulty, now I'm waiting 10 minutes and the build is just failing; or I can't rely on the tests because they're a flaky test set. All of these are things that can pull a developer out of that joyous state of creative flow and into a state of frustration and toil and friction. What happens neurologically is so interesting. Context switching we've learned over the last 10 years is first of all, impossible. We know the executive function in our brain doesn't really work that way. We can't really multitask. We give ourselves the illusion that we can, but what we're finding that's even more disturbing over the last couple of years is that context switching itself, the act of trying to multitask is associated with an increased level of glutamate in the prefrontal cortex of the brain, which is directly associated with cognitive fatigue. Cognitive fatigue leads to an inability for a business to innovate. It's super slippery because you can take somebody... We've all been there, we've all been fatigued and still had to do our jobs, and we can, if we've been doing this long enough, we can do basic tasks and complete our work, but it's really hard to elevate the work. It's really hard to innovate past what we're doing when we're in that state of cognitive fatigue. So going back to the original question, what's had the most impact? Well, I think that DevOps has done a great job in terms of challenges to taking our code inventory and creating throughput (i.e., money) with as little impediment as possible. We're delivering software faster, we're scanning for security vulnerabilities. We're making our code higher quality. So I think that's really helpful for our time to market initiatives and even can get interesting when we're delivering that quickly how much faster we can resolve issues and stuff like that, so MTTR metrics and commit to deploy metrics. All these things that you would find typically in DevOps, I think, are very impactful, but I think that they've helped more in terms of operational deployment. Then platform engineering I think has started to get to a more human level where we're definitely focused now on joy and on making sure that developers have what they need quickly without a lot of waiting, so we're getting there. I'm a little biased, of course, but the reason that I'm at Gradle was when I saw this emerging practice and I thought about its potential, I decided that this is really where I want to be spending my time right now. Because I think, and again, I am biased, but I think it's making the most impact because it's directly addressing the sources of friction and toil and fatigue that developers experience day to day. It is more than any other practice, it is most closely linked to solving the problems that impact developers' mood and impact their ability to be productive. So that's why I'm here because I think that this has in a 65% global digitally transformed GDP knowing that every single unit that makes up that GDP is coming out of the prefrontal cortex of some developer somewhere, I think focusing on their health and their productivity and their happiness will in the long run have the greatest impact.

David Sandilands [35:04] No, absolutely. I couldn't agree more, and I think we used to refer to some when we had issues as restoring family time when things just worked and people didn't have to be called out. I think in the same way, just day-to-day work being joyful, and obviously we're all paid to go to work and we don't expect everything to be perfect, but I think not having to deal with as much frustration and being able to focus on work is such an important experience.

Justin Reock [35:38] I couldn't agree more. We have all this fear over AI and ChatGPT, but what is it really doing? It's, again, reducing our toil. It's allowing us to think about the higher level thing.

David Sandilands [35:50] Well, I think that's us for today, Justin. Thanks very much for all these points. I'm sure we're going to have a lot of links and I'm definitely going to get myself a copy of Organizational Physics.

Justin Reock [35:59] Wonderful.

David Sandilands [36:01] So thanks for being here today on Pulling the Strings podcast powered by Puppet. 

Justin Reock [36:06] Thanks, David.