Why faster coding doesn’t mean faster delivery - Distributed.

Intro Statistically, most organisations end to end performance is going to be harmed by AI augmented coding and even if it is harming our performance, our perception is more likely to be that it's improving things. I think it's really important for people to try and just check in on themselves, check in on their teams, check in on what's really happening so that they can make informed, data-driven decisions. Speaker 2 From Tubal, this is distributed where we show how world class engineers and their teams tackle the challenges of remote work. I'm Jack Hanna, your host. In this conversation I talked with Anthony Marcano, the Co founder of River Glide and a 30 year veteran of software development. Anthony's best known for taking teams to the elite benchmark of Dora metrics. And so in this conversation we touched on how he's done that so consistently and what he's seeing the most elite teams do to make the most of AI. Of course, as we did that, we also identified the patterns of teams who are actually adopting AI to their own detriment and talked about what you can do to prevent that from happening. Lastly, we covered return to office and what most teams are getting wrong when pushing folks back to work in person. This conversation was a ton of fun. I hope you enjoy it as much as I did. The four DORA metrics So Anthony, you are one of the only, if not the only person I know who's claimed to get multiple teams to that elite benchmark of the Dora metrics. Dora metrics are widely considered like our industry's best understanding of how to measure a team's effectiveness. And so I want to figure out how you've actually done that. For the folks who don't know, do you mind just giving us a quick overview of what the four key Dura metrics are? And then we can break down how you've managed to get teams to elite benchmarks across these 4 metrics. Speaker 1 Sure. I mean, I suppose we should say what elites means. There's actually a number of categories for achieving different levels of these particular metrics from Google Clouds, DevOps Research and Assessment group. And there's low, medium, high and elite. And elite is basically the the highest performing that you can get according to these metrics. And there's actually 5 metrics now as of September 2025, which was in the Dora States of AI Assisted Coding report. But the four that were there before were leads time to change. So that's the time it takes from committing something to your version control repository to it actually being in production. There's deployment frequency. So how often are you deploying per unit of time? There's failed deployment recovery time. So how long does it take that if a deployment goes wrong for you to recover from it? And then there was change fail rates, which is how often do you get those failures? And in the State of AI assisted coding report, which seems to have superseded the previous state of DevOps reports, because obviously everything's got to be about AI right now, they added a fifth metric, which was rework rates. And that is essentially just the the ratio of deployments that you get where you you have to do some actual rework where you have to fix an instant in production, for example. Speaker 2 Yeah, I can't imagine why they would have added rework that seems odd with with everything going on that's just seems seems strange. We'll we'll probably get to that as we as we go. What elite status means So what does it actually mean to get to the elite standing for each one of these things? Because as you talk through them, it seems obvious that performing well across these four, now 5 categories is desirable. What? What is like the elite status really even mean? Speaker 1 So essentially what that that means is that your lead time for change is usually less than an hour. So that means from that change being committed to version control, not merged into master from a, you know, dev branch actually that first commit to actually being in production. And, and that's less than an hour if you're in the elite category. I mean, they've kind of dropped that now. They've got now 7 clusters, but we'll just work with the 2024 classifications. Then deployment frequency that's, that's classed as on demand, which basically means pretty much continuously. So as soon as something is committed, it can go pretty much. I mean with the teams that I've worked with that varies from 15 to 20 times a day for a team of about 6 to 8 people. So that's, you know, that's how many times they push their changes during the day and that's how many times it goes, gets deployed to production failed deployment recovery time. That's I believe that's less than 5 minutes or less than an hour. I forgot the exact number now and change fail rate less than 5%, the rework rate that wasn't included in the previous category. So I couldn't tell you what that is. But I'm, I'm imagining it will be a very low number, a very, very low number. But I think you know, a lot of the, the, the categories below that, like for example, high, they're kind of looking at deployment frequencies of between one day and one week, for example. That's, that's the scale difference between what's considered elite and what's considered a high performing team. And then when you get into the mediums, you're talking between, you know, once a week and once a month for deployment frequency. I mean, obviously you'd want to do this, right? Why wouldn't you? Well, what I found most interesting is that there's a lot of companies that just don't seem to be interested in it, which, which I find bizarre. And the great thing about these Dora metrics. So you can actually go on to the Dora website, you can just Google for quick check and you can answer a Series, A very brief survey and it will tell you here's here's its estimate of, of where you are in the grand scheme of things. But what is interesting about it is it'll actually show you where you are in your industry based on their survey data. So you can just change the drop down at the top to, you know, a very limited list of, of different industries. And it will show you what the, the median and the standard deviation for the upper and lower end in each of these different bars from where you're at. So for me, I don't think, you know, it's necessarily the case that people would absolutely want to be at the top of the scale because that's when you're at the elite, you're at the top of the scale. Forget the top of the industry, you're just at the top of the scale at that point. But you don't necessarily need to be there. You only need to be at the top of your industry in order to be beating your competition or just ahead of the top of the industry to guarantee your ability to beat your competition. So I think the, the why is interesting because I'm, I'm not, I'm not 100% convinced that there's lots of folks that actually do want it sounds like a great idea, but I don't know how many of them really want it. And there's lots of places I've spoken to and they're like, well, why would you want to do that? It's like, why would you want to be able to ship features in your product faster than your competition? I mean it to me, it's an obvious answer, but, but I don't think it's that obvious to everybody. So I thought I'd just, I'd just mentioned that. Speaker 2 Yeah. Why do you think that is if if I can jump in like, what would be a reasonable argument for why you wouldn't want to be above the competition in these in these categories? Speaker 1 I honestly can't think of 1. I actually did ask this on LinkedIn a little while ago saying that Help me understand, why would you not want this? And a lot of the answers were well if you don't need to be, why would you? And it's like, well, you know, if I was in Formula One, you know, I don't need to win the race. I can finish. That'll do. You know, for me, if you're competing in a market, the keyword there is competing. And if you become complacent and say, yeah, well, we're doing all right, then it's a bit like saying, well, you know, we're doing OK. We're in the middle, middle of the pack. But the trouble with that is over time, if everyone else is trying to move themselves forward, you're slowly falling backwards without falling backwards, if that makes sense. So I'm not entirely sure. Yeah, I, I think, I think some people might look at this and think, oh, well, this is, this is just, you know, tech Bros trying to be, you know, prove how how good they are or how much better they are than other people. But no, there's there's a legitimate competitive advantage if your products can have its different capabilities enhanced more quickly than your competitions because you can respond to customer feedback more quickly. Speaker 2 All right. Well, for the purpose of the conversation, let's take it as an assumption that it's a desirable thing, right? Like being able to respond to the market, to customer requests, to what's going on in the world quickly, safely, repeatedly, consistently over time is like a desirable thing, which I think these like collectively tell the story of being able to do. I mean, we talked about at the beginning how, you know, there there's a, a new, you know, fifth key metric in the Dura metrics and there's so much information online about how individuals are taking advantage of, of AI. What excites Antony about AI But you know, this introduction of this 5th metric is obviously there to help folks understand what is the actual impact of AI on teams performance. And I want to talk about that because I feel like there's an insufficient conversation about how teams could take better advantage of AI and what impact as having on teams productivity, not just not just individuals. And so I guess before we get into that, I am curious like what excites you most in AI for software development right now? And then we can talk a little bit more about this team stuff. Speaker 1 Oh, you know, I mean, you look at all of the different tools and the slightly different approaches of things. We're in a, a massively experimental phase right now, you know, where everyone's trying to figure out what's the best way of, of doing this stuff. I think the thing that excites me the most though, is that if you look at most of the tooling, it's, it's very much, it seems to come from the mindset of an old school way of thinking about software development where I'm building a product rather than evolving and developing a product. It's bizarre how the word software development, the word development never gets used really in the rest of the process. It's, it's a developmental process. It's not a construction process, right. But old waterfall ways of thinking were, well, it's like a construction process. And there were lots of good reasons for that back in the 60s, but they have over time become less and less relevant as a way of thinking about how we create and evolve software products. But a lot of the AI tooling currently is very much about how can you build something quickly. What I'm excited about is how Despite that, there's a lot of smart people trying to almost coerce it into working in the ways that we have since discovered are much better ways of developing software and trying to get AI tooling to actually replicate that process more effectively. So people are creating clawed skills, for example, that have a number of refactoring rules built into them and other skills that have TDD disciplines built built into them, trying to coerce the tools into look, look, stop doing it like that, Just do it like this. And the fact that there's enough, there's a number of people out there passionate enough to try and get the tooling to work in that way, I think is is really exciting. But but it's also a little concerning in a way because at the rate we're going, it seems like I'm going to call them the zealots, the AI zealots, right? Who you can't say anything bad about anything with AI in the sentence about it. And there's a lot of them seem to be pushing back quite hard on on anyone who says anything or suggests that anything to do with AI can can actually be detrimental. This is why I'm I'm actually more concerned than I'm excited at the moment. But nonetheless, I am excited about the potential, the future, but I'm more concerned about the present. What concerns Antony about AI Yeah, let's talk about that concern. What? What? What's that rooted in? Speaker 1 Well, forever we've known that if you have bottlenecks in your process, if you throw more resources at a part upstream of that bottleneck, it just makes it worse. You know, Eli Goldratt taught us that in the goal, you know, if your bottleneck is upstream and you're throwing more resources downstream, well, that makes no difference. But if you're upstream of the bottleneck, it actually piles up the work and actually causes everything to take longer. And this is this is one of the areas of concern. The other is for people who, and this is something that the Dora State of AI assisted coding report found was that if your code quality isn't particularly good at the moment anyway, then it's like that for a reason. And it might be because people didn't know better or they didn't feel like they had the time or to, to, to do it right, or what whatever the reasons were, in some cases even told to leave it as it is, whatever the reasons were, what AI does is it just amplifies that problem. And people don't like people like me saying that, you know, there's a few of us out there who are trying to fight the good fight and, and help people see that actually, if you have to choose where you're going to spend your time and your money and your energy, you've got to look at, OK, what, where's the bottleneck in my process? Because because if coding isn't your bottleneck, then AI augmentation of that element of the process at best might give you the opportunity to shrink the number of developers you've got there. But if your bottleneck is downstream of that, then everything's going to take longer end to end. Now I've got video about it on the River Glide TV YouTube channel and on my LinkedIn page where I actually illustrate this using Little's Law and the theory of constraints and some simple pictures showing traffic that shows that, you know, you keep adding more lanes to cross a single lane bridge. Everything that joins that system is going to take longer to get across the bridge. And the real solution is actually to use the AI augmented coding capacity that you, that you, that you gain and, and just say, well, look, but no, no one should be doing anything more than what they're doing now. No more output, but that spare capacity can then be used to look downstream and say, well, why is that bottleneck there? What can we automate to widen that bottleneck? What can we do to make that bottleneck scalable as we scale out our development? And, and that's the opportunity for a lot of teams that I think and organisations in particular. But at the moment, I think we've got the same problem as ever. You know, when projects or companies or orgs felt like they needed more more software, they would always throw more developers at the problem. Speaker 2 Yeah. Speaker 1 We've seen it time and time again, and throwing AI at your developers is like throwing more developers at the problem. Speaker 2 Yeah, so, so to repeat that back, it's basically like the, the, the video's great. We'll link to it in the show notes to help folks illustrate the, the your, your, your point here and Little's Law. But the the idea that you're communicating now though, is that basically like AI can speed up parts of the process, but if you have a bottleneck, if you're speeding up parts that are upstream of that bottleneck, you're going to slow the whole system down. So instead of having these developers use their added efficiency to produce more things upstream of the bottleneck, use that time, that capacity to devote to identifying the bottlenecks and removing the bottlenecks. Removing delivery bottlenecks And so is that, you know, just to that, that like sounds great in theory. Like in practice, is that practical at most large companies? Because like at a company like Tubal, that's, that's super practical. Like we're a super small team, 10 people. We, we do this already, like everybody's empowered to basically change anything about any part of our, our software development process. But for companies with hundreds of developers, does that work? Speaker 1 Right. Well, that's a really good question because the, the, the most recent teams that I've actually established I could, I could just be open about that's pretty obvious. For my LinkedIn page was with Ford Digital and I was brought in as the head of engineering there to literally build out the initial talent base and teams and established ways of working and so on. And they were working on software that integrated with, in vehicle software, including telling them when to charge and not to charge, interfering with the batteries on, on electric vehicles, which, you know, is not exactly free of risk in a company that had, I think, something like 100,000 people. I think the, the division that, that we were operating in, there was something like 6000 developers. And, and the key difference was, is that going back to your point about empowerment, there's a lot of assumptions that people make inside big companies about what they can and can't do. And one of the things that I would do is work with other teams in, in other parts of, of Ford and, and they'd say, Oh yeah, we can't do that. And I'm like, why? It's the policy. I said, oh cool, show me the policy. Well, I thought it was the policy. Well, let's look it up, shall we? And we'll go and look up the policy. And it's like, no, no, you've got the freedom to do this. And I've seen this with multiple companies, so many different companies that I've worked with over the years. Big companies, people kind of get brought in. They learn how a particular team works and they internalise the way things are as if it is the only way things can be. But actually they're empowered to do way more. So to me, empowerment isn't about me giving people power. It's me helping people see the empowerment they already have and then and then taking advantage of it and questioning it and challenging it so it can be done. No matter how big the company and no matter how much money is on the line and no matter even if, even if the even if you could brick a car and stop it from functioning entirely, you know, even if there's a risk of, you know, blowing up a battery, you know, obviously these things were all very carefully managed. But all of this, these ways of working, they can work in those environments, but people sometimes need a little bit of help to to feel like they can question the status quo. Speaker 2 One thing I wanted to get your take on, it's obviously near and dear to our hearts. AI’s impact on collaboration Your your tuple given the nature of the product that we have is, is how the advancement in these tools and the ways the teams adopt them impact the way that folks work together. Because I, I agree with you that most of the public narrative framing of all these tools is like, it helps you construct software faster, like build new features like go, go from like, you know, 0 to one in a context where or like not really acknowledging the iterative nature of, of how software often is actually built. I'm wondering if you have any observations or just like thoughts about how AI is changing collaboration patterns for, for teams. And yeah, I'd love to get your take on that. Speaker 1 I think again, like going back to the Dora report, you know, one of the things they highlight is that AI augmented or assisted coding amplifies teams performance and and if it's great, it gets better and if it's not great, it gets worse. And I think for the teams that already have collaborative working environments, it, it's really just helping take care of the stuff that would otherwise just be a laborious task. You know, the, the, the term yak shaving comes to mind. You know, if you're working in a pair and this is one of the things all my teams have always done, always pair programmed or done more programming as well, software teaming as some people like to call it as well. So they're already collaborating and, and they're already working together. They're already seeing when it's ideal to work as a pair or as a larger group or sometimes there's just a repetitive tasks needs to be taken care of. Well, now a lot more of that repetitive, the easy stuff can just be taken care of with AI tooling. You know, we used GitHub copilot, for example. It's just us. We need to these conflict changes just done. Just go do that while we carry on pairing on this really more difficult problem, but with, you know, input and guidance from from other AI tooling, for example. So I don't think it changes an already collaborative team. I think what it could do, and I haven't seen this, but it is more of a concern is that in organisations where the leadership might, might want to tell teams how to work like, Oh no, you're not allowed to do pair programming. You know, they might say, well, look, instead of pair programming, you can all work individually now just with AI and, and I think I think there is a time in the future where that might happen. I think I even mentioned to you in a previous conversation that, you know, one of the great things that you know, Tuple might be able to do in the future is, you know, be able to start a call with an, an AI pair programmer. You know, that can be see what's going on on your screen and interact with it and, and be an, an additional pair. Sure, we might be able to get to that point someday, but but I think that the way that it's changing things, I think is more, you know, teams that weren't particularly collaborative are probably just going to be a lot less collaborative because they're just churning out way more code. Risks of relying entirely on AI code What's the risk of that? Because because I, I definitely to, to the extent that you have a predisposition to not want to collaborate because of your social preferences, because of your company's incentive structures, whatever it might be, I do think that AI tools afford a very convenient out for that. And for that like predisposition doesn't matter. Like I, I guess like that, that's the real question is like, what, what do we miss out on to the extent that that's a trap teams fall into? Speaker 1 Yeah, I think again, there are, there are numerous examples out there that people can find where, you know, there's an individual sitting there and they're spawning up multiple parallel agents coding on loads of different things. And I heard an interesting quote from someone today where they said that, you know, they're at the point now where they're, they're only sample checking what the code is doing and, or, or the quality of the code before, before they merge the pull request that they're getting back from these parallel agents. And for me, that's all well and good, but how, how do you, what's policing the, the AI then? Like we've, we've had, there's been a huge, huge thing this week, this last couple of weeks with Claude Bot and, and Mobot, right? And, and people, people are just trusting the AI entirely. And it's just going off and doing stuff like, you know, signing them up to a $2500 coaching course that they thought they might be useful or leaking their credit card details and personal information with other bots. And it's, it's like, I just don't think it's ready to be left unsupervised yet. There will come a time where maybe that will be true. But I think the real danger is that serious security vulnerabilities start to slip through, challenging maintenance issues start to slip through. And and I think it's important that, you know, some people say, oh, well, we won't need humans to maintain the code as long as the AI understands it. That's, that's all that matters. But you can say that, but that is actually a dangerous place to be. Literally just today somebody on LinkedIn posted a screenshot of their anthropic bill. It was $50,000 for the month and it was a huge surprise to them. They were like they were not expecting that. Now, from what I understand, they have not increased their output of value based on the conversation that I followed by $50,000 in that month or by the equivalent of having hired $50,000 worth of engineers, right. So, so at some point you might have to say, you know, this isn't cost effective. We need to actually dial this back a little bit. Well, then you're going to need people to to maintain the code. So it's a very dangerous position to put yourself in. It's like the analogy I can think of is this. So you know, in software architecture you always want to make sure that you abstract your code from anything that you can't control. It's helpful for testing purposes because then you can. Speaker 2 Yeah. Speaker 1 Replace a with a test. Double your interactions with this outside world, whatever it is. But it's also because if you, if you, if you depend on a particular framework and that framework grows its roots throughout all of your code. If there's some breaking change in the future that can grind your entire ability to function to a halt. Or if that software as a service decide we're going to triple our fees right this year. And tough luck on you because you're so reliant on us that you just have to pay you. You've, if you have that abstraction, you've got the ability to say, well, all right, but we can go to this other provider and it'll take us two weeks to swap everything over. Speaker 2 Right. Speaker 1 You know, So what do you want to do about it? Whereas at the moment I, I, I fear that, you know, the pricing of all of these things is going to keep going up and companies are going to ultimately be held to ransom. So right now I'd be maintaining the insurance policy of making sure my code was always maintainable by a human for that reason. However, if it's maintainable by a human, it will be far easier for your another AI LLM platform to comprehend that code if you did need to switch from one to another. So either way, it's a it's a good insurance policy to have. Speaker 2 Yeah, it's interesting there. There's kind of I think there's an underlying assumption or framing of your answer that surprised me. Why collaboration matters in software teams I guess what I'm. It feels like your response is rooted in the assumption that the core value that collaborating offers a team is code quality and. Speaker 1 That is one of. Speaker 2 Them and and and I guess that doesn't, that wasn't what I would have expected you to say. Like what I didn't hear you say is talking about like deciding what to like picking the right things, what would like the prioritization problem, for example, which I do think is like a huge byproduct of effective collaboration. I didn't hear you say anything related to to knowledge sharing, though. I guess you could maybe make the argument that knowledge sharing is between humans is like less important to the extent that you have really good knowledge sharing between humans and and LMS. And so yeah, I just wanted to challenge that. Am I reading that right or, or are there other parts of this that you think are also relevant to the to the conversation? Oh. Speaker 1 100% it's all very relevant, but at the moment AI assisted coding isn't involved in the conversation about knowing what do we work on next. People do collaborate, they do identify the thing to work on next and then they get the AI involved in working on it at the moment. So that's where a lot of the focus is regarding. So yeah, sure. Collaboration 100% is, is important throughout the entire process. Because an analogy that I like to use, say with pair programming as a just as an example, and I suppose it's, it's goes back to a word that you just used, which is challenging, right? You're challenging each other with pair programming. If I'm working on my own, I can very easily say I'm tired, spent so long on this, that's enough. But if you're working in a pair, the other person says, oh, hang on, no, come on, we've got to do this next bit. And then, you know, they might take over and you get to sit back for a second and see, think about what can we do next? And then you can maintain your energy that way. But you also are pushing each other to make sure you're keeping holding each other accountable. If you like for the work. That also happens in conversations about prioritisations, about holding people accountable. I've got a great story about, you know, how a representative from the business kept telling us that we wanted all of these things in, in, in the, in the product. And when I found out that they had to sell a certain number of a particular item by the end of the year, otherwise they'd get fines for regulatory reasons, I said, how does that help us sell another, another one of those things? And I'm like, oh, well, I'm not sure. I said, OK, cool. This is the bottom of the list. Everything at the top of the list is the stuff that helps us sell the thing. So you can then hold the business accountable saying, well, I know you like the idea of this new bell or whistle that you want to put into the product, but how does it? I took this from a book called Business Lessons Learns from Formula One, where Frank Williams, the founder of the Williams F1 team, If people came to me and asked for money for anything, you'd say, how does it make the car go faster? If you can't answer that question, you don't get the money, you know, So someone, I want money for the website. How does it make the cargo faster? Unless they can say, well, by updating the website, we present a more professional image and that makes us more attractive as sponsors. Sponsors will then be more willing to spend more money with us, which allows us to actually create, take that money and make the cargo faster. So, so, so the, the holding people to account piece, I think is key. And, and one thing that we know about most LLMS is that they're very agreeable. They don't like to challenge you too much. Speaker 2 No. And yeah, they're, they're sycophantic in that way. They'll just, and you know, there's work to try and make that better. But yeah, no, that's it's it's, it's a good shout. Yeah. I just wanted to call that out because I think you make a good point that the dialogue is here. You know, the dialogue about this stuff is centered around the actual development of the software. And so that is probably where you need to focus the conversation because it's meeting people where they're at. But yeah, there is this richness that comes from collaborating that adds value in these these these other areas that's important to consider, just not the the centerpiece of the conversation right now. Navigating top-down pressure to adopt AI Yeah. I guess related to this, obviously engineering leaders are getting bombarded with tools to consider pressure from other executives to adopt these tools in one capacity or another, which I think in many ways does lead to some of the problems that you're describing where it's just like there's this downward pressure to behave in a certain way and it causes some of these upstream of bottleneck issues that that we're talking about trying to avoid previously. How should engineering leaders think about some of this pressure that's coming from all angles? Speaker 1 Yes, there's how do you think about it And then there's how do you navigate it? There are there's, there's two sides to it, The two sides to it that are, I think, captured by a piece of advice I got from my first ever manager in in IT back in the 90s. And he said it's about there's a difference between doing a good job and being seen to do a good job. He said sometimes you can be doing a great job and it not be seen sometimes. Sometimes what's seen as a good job is not necessarily a good job. So you've got to strike the balance there. And I'll give you an example. Somebody that was in in a company that I was coaching was being interviewed for a potential promotion. And the question that they were given is like to tell, come back and present what you think the key technologies that will change the future of this company. And they came to me and said, look, I've thought about all of these different ideas. What do you think? I said, I think they're all good ideas. So, OK, if it wasn't an interview and any one of the people that's on this board just came to you one day and sat down and said, hey, let's have a coffee. What do you think is going to have the biggest impact of all these technologies on our future? And they said none of them because they weren't yet fully exploiting the talent that they already had and the technologies they were already using. And, and I think this is this is the trick. So, so, so my suggestion was why don't you give an answer that sounds like you're answering the question with all of these cool technologies, all the latest greatest stuff, Obviously AI was in there. But also then tell them what they really should, what you would really do, and that is focus on upgrading the skills of the people you have. And, and this is, this was well before this Dora report came out where it highlighted the fact that AI is an amplifier. But what is essentially they, they, they found is that if you're in the higher performing teams, AI is boosting your performance. And if you're in the lower performing teams, it's making it worse. So, so I would say the way to think about it is if the people you're reporting to need an AI tick in the box because they need to tell a story to their board or the shareholders that they're leveraging AI because otherwise you'll be left behind, Get the tick in the box you need, but don't overuse it. Focus on understanding the true performance of your team's end to end, not just one part here. And, and look at things like the Dora State of AI coding report, because one of the other things they found in that report is that the out of the seven clusters they've identified, 60% are in the lower performing categories, which are actually having their overall performance harmed by AI. And that's from a self selecting group of people that they surveyed who this institute is aware of and they're aware of because those people are subscribed to it because they're interested in maximising their performance. So they're already going to be doing it. I actually was speaking at a conference being hosted at Cambridge University a couple of months ago. And I actually got did a quick survey at the beginning of my talk with, you know, a raise of hands and there was something like 2 out of around 80 people in the room that were actually operating in this elite category. And I was like, are you in the same team? They went, no, never met before. Like, oh, wow, that's, that's random. So 2 out of 80 people in an agile conference were, were, were operating at that level. So I think it's probably somewhere between, you know, probably somewhere between 40% and and 4%. So let's just split the difference roughly and call it 25% of all teams are actually able to leverage AI, which means that statistically most organisations fall into the group where AI is harming their performance. So I'd say before you start introducing something, find out if it's going to harm your performance 1st. And and and you can just do. You can just do a preliminary check using the quick check check on Dora. Speaker 2 I think recognising where people are coming from is so important in that, right? Like it's like, yeah, somebody needs to take the box, recognize that and allow them to take the box in a way that is most useful for the business actually based on your best understanding what's going on. And so if you know that doing this thing is actually going to make things worse, then find a way to take that box in a way that that that's kind of contained and then kind of address the real underlying issues separately. Why DORA is a good starting point Would you say your best recommendation for how to answer that question is going and assessing where you are against the Dora metrics? Speaker 1 I think I think it's probably one of the easiest ways, just using the quick check. You know, one of the things I do warn against is to not, not not use these metrics as a way of beating teams up. Like you don't, don't use these metrics as a way of saying or setting targets. You know, good hearts law tells us that as soon as you set a target, it becomes meaningless and the metric becomes meaningless because people then just gain the metric and they don't do it on purpose. I mean, some people do, but most people don't. Most people just do it unconsciously. So instead, you know, you've got to, I think the first thing for any leader to do is to try and just get an understanding of where are they in the grand scheme of things. And the way I would do it is I'm, I'm assuming any engineering director, head of engineering has a rough idea of pretty much, you know, how long it takes for their teams to get things to production and roughly how often things go wrong. And, and why not, hey, just ask the question, you know, ask, ask the teams to, to fill out the survey and maybe get them to do it anonymously, you know, so that nobody is, you know, feels under pressure. But most engineering leaders could probably answer this for themselves, answer the questions and then you'll see roughly where you are in the grand scheme of things. And then I think you could then start to think, ah, right. OK, where are we? We're here. OK, what's the research telling us? The research is telling us, well, you need to be in the high performance. So you need to be high and elite more or less in order for AI to be amplifying your performance in a positive direction. How do we get there? And then again, as I said before, if you get back to the teams and say, what do I need to do to help you solve the challenges that getting in the way of you being able to operate at this slightly improved level? And then help them see the value of the metrics so that they then use that as data to to to for themselves. Speaker 2 Yeah. We've been talking about high performance across these different areas, you know, against the Dora metrics generally, obviously with how AI amplifies performance in in kind of either direction. Another vector here is obviously like if folks are working in person versus remote, RTO is having kind of like a a resurgence or working in person, I guess is having a resurgence right now. Return-to-office mandates And while working from home was certainly very in vogue during COVID and after COVID for variety of reasons, a lot has changed, I'd say over the past 12 to 24 months in, in this in this regard. And so I wanted your take on this. What do you feel like most people are getting wrong about the RTO debate? Speaker 1 I think the, the, the big issue is that I think some of the decisions about telling people that they need to come back to the office are being made by people who haven't experienced a highly collaborative remote working team and and they haven't even experienced the tooling. I'll give you an example. One company I was working with, they, they had, you know, a more traditional video conferencing tool. It's the usual kind of thing where it's a, it's a window into the other person's world and that's it. You know, you can look through the window, but you can't reach through it. And, and a lot of the developers were pair programming using these video conferencing tools where only the person who's sharing their screen can actually be doing anything on the code at that moment in time. So they couldn't see how. Collaboration was better if people were pair programming when they were working remotely. But I said, well, but why they use it? That's not that tool isn't designed for that type of collaboration. It's not designed for that purpose. And we actually ended up showing them tuple and, and saying, well, look, imagine if you could just work like this where it's not a window with a pane of glass, but I can reach through the windows open and I can reach through and I can say no. And I can interact with the code on their computer or on their screen at that moment in time. It's actually nicer than pairing. And there's environments that I've worked in where even when we were in person pairing, we just did exactly that, used a direct interactive tool on the local network. We're both on our own computers because I've got things set up the way I like, they've got things set up the way they like. We might be sitting next to each other, but we're still actually operating through our through them sharing their screen to mine and me being able to interact on their screen. So, so in a way, the the advancements, the the lack of latency, the reliability that you get from modern highly collaborative pair programming tools like Tuple, I think changes the game. I think it changes the game considerably. And I think the decision makers who decide that you must be in the office have no experience of that and at none whatsoever. I think the other thing that they're missing is that, and I, and I think this is very much the case in particularly large companies, I think the person making these decisions is often so far away from the coalface that these are just resources. You know, people's lives have adapted into this more remote working world or hybrid world where you only have to come into the office periodically. And what happens is, is that you're, you're basically saying people being in the office is more important than keeping the most talented people. And to me, that doesn't make sense because you're you're going to drive a percentage of people away who can't uproot their lives. Characteristics of elite remote-first teams What are what are some of the patterns or or behaviours of these elite teams who work remotely and are collaborating effectively that separate them from or allow them to operate at that level when the perception is that it's not possible? Speaker 1 I think when you care about what you do, that is the key. You know, this is one of the things that when when I was able to, I think you mentioned it earlier, how do you get a team started in this way? You've got to find people who are actually interested and passionate and, and, and keen to learn and excited to try new things, whatever those things happen to be. And finding people that really genuinely care. I think is, is, is a key element of it. I think people who value collaboration, and it's not something that you have to encode in a policy because it just happens, you know, and it happens in whatever way makes sense for that particular group of people, you know, because it's not always the same. You know, we've worked with people, I've worked with a lot of people who are, you know, classified in various ways as neurodivergent and their way of working and collaborating is different. And finding that balance with a particular combination of people in a particular team, as long as they're producing the results, what difference does it make how they decide to collaborate? What difference does it make if some of them come into the office every day because they like being in the office and they're more extrovert thinkers and they need people around them to interact with in between their, their, their pairing sessions or other people that are more introvert thinkers that actually need a break from people when they end a pair. Well, when they take a break from a pair programming session, This is this is the thing. Everybody's different. And if you want to limit your talent pool to the people that are in a commutable distance, think in a particular way, then your your, your opportunity to get the best talent has been massively reduced. So personally, I value people who are passionate about what they do and care about the results. And you just got to trust people to do the right thing. If you're in a position where you're having to mandate that people come into the office because you don't trust that they're getting anything done from home, whether people are in the office or not is not your problem. You've got a totally different problem. And that problem is either that you've hired the wrong people or that you've got trust issues. Either way, fixing you can't fix that problem by forcing people to come back into the office. One of the things that we had in our teams was an open door policy. Anyone can join any room where pairing is happening or mobbing is happening at any time. Anyone, managers, leaders, other people from other teams, everybody's welcome. And our and our explanation of that was, look, every new person that comes into the room who has a question that will be a naive question could be the one question that we should have been asking ourselves this whole time but hadn't because we were too deep in the weeds. And having that random person come in the room. I think that to me is actually more collaborative than people just being in the office with a fully remote team. The one thing that you don't tend to get is those opportunities just to interact socially, you know, and I think that's where a fully remote team, I think it's important for that that team to find a discipline that they stick to around having social coffee moments. And one of the earlier teams that I was talking about, sometimes there was a little bit of tension. So we said, look, that's because we're not hanging out anymore, so let's just hang out. So we set aside every Wednesday afternoon between 3:00 and and 4:30, there was just a coffee break room online. We just jump into sit there, have a coffee break. Some people brought brought along a beer, some people brought tea, whatever they wanted to bring. And the the whole thing was no shop talk. How are you? What's happening? Oh, where you planning? You know what what happened with that holiday that you had booked that had to be cancelled? You know, just have normal everyday human being talk. So fully remote teams do need to do that. Hybrid teams have the opportunity to have that social interaction over lunch in the office when they have their scheduled times in the office. Speaker 2 Yeah, no, that's a good, good addition. Anthony, this conversation's been been amazing. I do have some rapid fire wrap UPS that I want to want to hit before we before we jump. These are quick questions meant to be answered quickly. No need to sort of embellish or overthink it. You ready for some some quick rapid fire questions? Speaker 1 Almost. There was one thing that you asked about earlier and I, I, I wrote, made a note of it that we've got to talk about it. METR study on AI and perceived productivity So before we go into the rapid fire, I just want to go back to, there's another piece of research that I think is quite important for people to be aware of by a group called Meter. And lots of people would discredit this research because it was a relatively small group and it was early 2025 when AI tooling wasn't as good as it is now. But the key finding of that report was that some of the developers, their performance was improved and some of the developers, it actually slowed them down. But the key thing was that most of the developers perception was that it speed them up, even if it slowed them down. Speaker 2 Right. Speaker 1 So some of them the perception was accurate, it did speed them up. And some of them their perception was inaccurate, it slowed them down, but they thought it speed them up. And I think these two things that we've, we've learned from this research and this, this concept of people, you know, having optimistic perceptions about their performance is not a new idea. That's just that it's been revalidated in the context of using AI tooling is that we all want to think we're in a high performing team, but do we really know? We might feel like we are, we might perceive that we are, but have we measured it with anything other than Yep, winds blowing in the right direction? So I think, I think knowing that statistically most organisations are going to be actually their performance end to end performance is going to be harmed by AI augmented coding and the research that tells us that even if it is harming our performance, our perception is more likely to be that it's improving things. I think it's really important for people to try and just like just check in on themselves, checking on their teams, check in on on what's really happening so that they can make informed data-driven decisions. We always talk about how it's so important for product managers to make data-driven decisions about what new capabilities they want us to implement. But we have to take that advice ourselves as engineers and say, well, we should also be making data-driven decisions. So that's one of the things that I wanted to mention as a key take away from before. Speaker 2 Yeah. No, it's a. It's a really, it's a really important shout out. Everybody sort of thinks that they're above average, but definitionally that can be true, right? Like it's just, it's not how math works. Rapid fire round All right now, Anthony, Are you ready to jump in? Speaker 1 I'm ready. Rapid fire hit me with it. Speaker 2 Good deal what? What is the best piece of advice you can give someone who's just starting their career in software? Speaker 1 Learn the fundamentals about good quality code, how you get there and extreme programming in particular, go right back to the beginning and work your way through all everything you can learn about extreme programming because everything that people talk about today as being agile engineering practices ultimately were birthed in or rebirthed in many cases in extreme programming, you know, people talk about, oh, you know, they're doing Scrum and they're, you know, Scrum gave them user stories. Not true. User stories came from Extreme programming. People talk about continuous deployment. Well, that was discussed very early on in I think the 1999 book of yeah, the first edition of Extreme programming about keeping the the distance between the code on your computer and the code in production as as close as possible. But if you're starting out, I think it's really important to have learned. Learn how do you get to good a good quality products first without the tools. Then learn how to use the tools to get there faster. Speaker 2 Yeah, it's great advice. I, I, I did another interview with a woman by the name of Chelsea Troy, who's a professor at the University of Chicago's master's program in, in computer science and a machine learning engineer at Mozilla. And she's really, really thoughtful about in, in her own curriculum how to like, when to, to, to teach students to use these tools, how to use them, etcetera. And so folks want a deep dive on that particular a bit. There's some really good stuff in that episode too. What's your favorite tool, Anthony, physical, digital or otherwise, for improving your own productivity? Speaker 1 A pairing partner. Speaker 2 I dig it, I dig it. Who's the technologist you've been paying more attention to lately? Speaker 1 I'm not paying any more attention than ever, but I've continued to pay as much attention to. And someone you might want to get on at some point is Jason Gorman. He's one of the key people, I'd say, obviously other people I also pay attention to. He's got a lot of really good things to talk about on AI right now. He's written a whole series of content which I think might end up in a book called the AI Ready Developer. And it it's all about, you know, getting back to the fundamentals, you know, really honing those skills of what how do you get to good quality code and how do you recognise when you've got there so that you can then leverage AI to make that a faster process rather than not having those skills. He's saying a lot of good things there. Obviously people like Dave Farley and Kevlin Henny always paid attention to what they have to say as well. They're doing some great stuff. Recently they've was involved in some research that found, admittedly again for somewhat self selecting group, that's the development elements of the process. They were getting between 30 and 55% increase in, I don't want to call it productivity, but rate of output from the developers and an environment where, you know, leaving your computer and going into the version control system and getting to production is a fully automated process that happens in 15 minutes. Yeah, AI is just going to increase your productivity, but that isn't always the case. And they weren't measuring what happened after that code was committed in in those teams, of course. So but I think that was an interesting data. Kevin's always got lots of really good stuff to say and and is very well read on on the history of a lot of this stuff. Speaker 2 Well, well, those are all great, great suggestions. I'm going to may have to link to some of their work in the show notes for, for for the purpose of this. But Anthony, this conversation's been a pleasure. It's, I really appreciate you in the making the time to, to chat through all these things and I always love connecting and learning from you. So, so thank you, Anthony. Where can folks go to find you or learn more about your work? Speaker 1 I'm spending most of my time on LinkedIn, so I'm sure you'll put a link to my profile in the notes below. If people aren't on LinkedIn, I'm trying to drop in on Blue Sky and give you my profile link for that as well. And occasionally I post a video to Riverglide TV. Speaker 2 Good deal. Well, we'll link to all those places. So thank you again Anthony. Hope to chat again soon. Speaker 1 All right. Thank you. Speaker 2 Thanks for joining us on Distributed. If you want to learn more about what we covered in this episode, or if you want to share your own thoughts, follow Tuple on X or visit Distributed FM.