Self-Disclosure, Body Doubling, and Psychological Safety

What happens when your brain loves puzzles… but struggles with where to start? Paige Watson shares how ADHD shapes his work as a developer—and how practices like TDD, mob programming, and discovery trees help him stay focused, move forward, and actually enjoy the ride.

Overview

In this episode of the Agile Mentors Podcast, Brian Milner is joined by Paige Watson, a technical coach, seasoned XP practitioner, and self-proclaimed “code crafter.” Paige shares his firsthand experience navigating ADHD as a software developer, and how practices like Test-Driven Development (TDD), ensemble programming, and visual planning (like Discovery Trees) have helped him find sustainable focus and flow.

Together, Brian and Paige unpack how small, iterative steps and collaborative team dynamics can support not just neurodivergent developers, but everyone on the team. Whether you're navigating ADHD yourself, leading a diverse team, or just want to write better, more maintainable code—this episode is packed with thoughtful insights and practical takeaways.

References and resources mentioned in the show:

Paige Watson
Paige Watson’s ADHD Blog Posts
#76: Navigating Neurodiversity for High-Performing Teams with Susan Fitzell
#123: Unlocking Team Intelligence with Linda Rising
Scrum Foundations
Subscribe to the Agile Mentors Podcast

Want to get involved?

This show is designed for you, and we’d love your input.

• Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one.
• Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com

This episode’s presenters are:

Brian Milner is a Certified Scrum Trainer®, Certified Scrum Professional®, Certified ScrumMaster®, and Certified Scrum Product Owner®, and host of the Agile Mentors Podcast training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Paige Watson is a passionate advocate for “Quality Software as Craft,” known for transforming developers into high-performing, cohesive teams. With deep experience guiding software teams and leading workshops for global companies, he helps build elegant, scalable systems designed for longevity and real-world impact.

Auto-generated Transcript:

Brian Milner (00:00)
Welcome in Agile Mentors. We are back for another episode of the Agile Mentors podcast. I'm with you always Brian Milner. And today I have Mr. Paige Watson with us. Welcome in Paige. Really excited to have Paige here. We kind of crossed paths with Paige because of some posts that he had done.

Paige Watson (00:11)
Thank you.

Brian Milner (00:19)
He is a technical coach and has been in the development community for a long time and is an XP practitioner, right? Did I hear you correctly say that?

Paige Watson (00:27)
Yes, I like to use the term code crafter, but yes, a lot of the things I do are XP centric. Yes.

Brian Milner (00:31)
Nice. I love that, Codecrafter. Then the post that kind of got our attention was a series of posts, actually, that Paige had done about really ADHD and software development. And as people who have listened to this show for a while know, we've done a couple episodes around neurodiversity and neurodiverse traits. and how that bleeds into our work in the software industry. There's plenty of stats showing that there's an unusually large percentage of people in this profession that have some form of neurodiversity. The topics were how he manages ADHD and works. The first one I thought was an interesting title, talked about it being a bug or a feature. So tell us a little bit about what kind of got you started in exploring this.

Paige Watson (01:21)
Yeah. So I go to a three-day open space that we have in the Northwest. I'm in the Seattle area. And one of the sessions that we had was something, I forget the exact title, but it was around neuro-spiciness in the workplace. And the whole idea was let's get a bunch of people who are neuro-spicy. for lack of a better term, and find out what works for you at work. What are things you need? How do you make sure that what you need is being said out loud? how do you make your work better? So this was a great discussion that we had. And I came out of it going, a lot of the things that I do, a lot of the practices and processes that I use, are actually really helpful for me in my ADHD. So then I sat down and thought, well, first I thought this would be a great conference talk. So I wrote that. And then I was like, I bet this would be a great series of blog posts as well. So I wrote those.

Brian Milner (02:24)
Ha ha. Yeah.

Paige Watson (02:32)
It turns out it is a pretty good conference talk, if I say so myself. I get a lot of really good feedback. And honestly, the discussion after I do the presentation is almost better a lot of the time, because you're right. There is a lot of people that, whether they've been diagnosed or they self-identify, whether it's ADHD or autism or anything, there's a lot of that that

Brian Milner (02:37)
Hahaha.

Paige Watson (02:56)
that I think we see existing in our software. you know, area that we don't, I don't want to say it's more, I don't have like a definitive study or anything like that that says it's more people in software, but it seems like it. And I sometimes wonder whether that's just me, you know, seeing people because I'm in the software industry or whether there's a draw towards it.

Brian Milner (03:22)
Yeah, there was a study that I, because I did a conference talk on neurodiversity and software development a while back too, and there was a study that I found out at the University of Texas that basically the only correlation I could find was saying that young people who were entering college and choosing majors were choosing actually it was people on the autism spectrum of some kind were choosing careers in computer science at a rate that was three times essentially that of the general public. So it's not all the neurodivergent traits, but it is one flavor of that. I just don't, maybe there's just not a study on the others, but I... I agree with you. think just from my experience, working in software and managing people in software and developing myself, the people I've kind of been around and worked around, now that I'm more aware of neurodiverse traits, it seems like, yeah, that seems very much like this is going on. That seems like that's going on. And it just starts to make sense a little bit more. Yeah.

Paige Watson (04:24)
Yeah, yeah. And I wonder, you know, I kind of look back and like, I like to play board games a lot. you know, I like, I have a model railroad and I like the aspect of not just watching the trains go around, although there's probably a maim in there somewhere, but I like sort of operating it like a model railroad. How do I get these cars over there to the green elevator in the fewest moves? There's a puzzle solving aspect. And one day I was like, I like to do that in my work too. You know, and is that part of the the neuro spiciness? I don't know. But you know, it's definitely a draw as to why I like development.

Brian Milner (04:56)
Yeah. Yeah. Well, I want to dive into some of the things that you uncover in your talk and in the blog post that you wrote. What were some of the discoveries that you realized as you were looking into this?

Paige Watson (05:17)
So, like, first off, let me preface by saying I'm not a doctor, you know, and if you have, if you think you're, you know, if you think you have ADHD or want to know more about it, please talk to your medical provider. That's really important.

Brian Milner (05:21)
Yeah. Yes.

Paige Watson (05:34)
And I can only really talk for my ADHD because ADHD comes in so many varieties. Yes, there are certain things that happen together, but there's so many sort comorbid aspects to it that I only really want to talk about mine and touch on some other things I've seen maybe, but just that caveat. What was really interesting is that I used to think that I ADHD was about not being able to focus. But it's about not being able to control the focus. Because sometimes I can't focus at all. There's lots of things going on. That whole, squirrel, that sort of thing. And then there are other times when I can hyper-focus. And this is where my talk comes. My talk I call Focus Flow on Co-Coffee.

Brian Milner (06:13)
Yeah.

Paige Watson (06:21)
And the whole idea is that I go and sit down at my desk with a cup of coffee, and I'm ready to go. And I start typing, and I go to take a sip, and the coffee's cold. And I forgot to go to lunch again. So it's not really about not having focus. It's about not being able to fully control where that focus goes. In terms of the way I

Brian Milner (06:32)
You Yeah.

Paige Watson (06:47)
the way I work, there's a lot of things that I found I can get really overwhelmed by big tasks. I can get overwhelmed if I'm not sure where to start. I'll do that thing where I'm like, I have my work. I know my story. I've got all the requirements. I sit down at the IDE, and I start to think about how am I going to write a test. I don't know where to start. I know what I need to do. It's not that. It's picking a place to start. And that's really a tough one for me. And then I can get overwhelmed by that. Or I can get overwhelmed by a large task and not fully understanding all of it. And when I do, I sort of freeze and shut down. And so there's a lot of learning around this that I've found about myself, which has been really nice. Also, having to talk about it to people has been sort of forced me to be a little more circumspect. But there are some really great practices that I found that work really well as well. For me, especially, mainly collaborative programming, mobbing or ensemble work. Pairing works as well, but I find collaborative, like full team programming to be much more effective.

Brian Milner (08:00)
Yeah.

Paige Watson (08:06)
Test driven development. I really like that in because I think about the the Requirements as code so I write one little requirement and then I make that requirement happen and then you know that the test fails because it I haven't written the code and then it passes when I write the code, know, and hooray little dopamine hit when it passes but also I don't have to go back afterwards and remember the code that I wrote and and try and write tests around it. That's a really tough one. I was going to remember to test this one thing, but I forget what it was. Now, if I think of my tests as requirements in code format, even the name, the name isn't should get user. It's that when I pass user ID1 should return user. for ID one type of thing, you it's a very clear or when I pass null should throw exception, you know, like, and they're very small. So again, I don't have to be overwhelmed thinking about this grand architecture and holding on to all the information.

Brian Milner (09:19)
Yeah. What I think is really vital here is to, because I love how you explain the kind of symptom, right? The symptom that we experience and then kind of matching that up to say, but here's a practice that really kind of counteracts that a little bit. I think you're absolutely right. You know, I experienced the same thing with hyper-focus and not being able to focus and There is something about having small little chunks of work that makes that so much easier to digest because it's a constant flow of things. It's not, oh my gosh, now I've got to stay with this for three days straight before I get out of it. No, I'm going to do a little bit and then check it and a little bit and check it. And I agree. That's a big problem, I think, as well for people with ADHD that we kind of... can't always remember what happened yesterday, because so much has kind of come our way. And it's not that we weren't invested in it when it was there. It's just that, our brains are trying to keep up with all the things that are going on. And it just kind of overwhelms our memory processes a little bit.

Paige Watson (10:15)
Yeah. Yeah. Yeah, I talk about it like I have my short term, which is my memory buffer. And then I have my long term, which is my hard drive. And the problem is that the buffer gets flushed really easily. something new, interesting, something that sparks my interest immediately flushes the buffer. And so a lot of things that are important don't get written to the hard drive and save for later. And another issue that I've run into is

Brian Milner (10:35)
Yeah. Right.

Paige Watson (10:55)
there are times I don't really understand what's important. What's important to me is not always what's really important to the team, the work, right, to my wife, you know, all that sort of thing. And so, you know, I'll think like, gosh, I have this chunk of work where I have to add this logging, but if I refactored this into a need-based eventing system, it would be so much better in the long run.

Brian Milner (11:00)
Yeah. Yeah. ⁓

Paige Watson (11:21)
Well, the important thing is that the logging get in there. But I don't think about that. think like, the need-based eventing system is the important that in four years, that's really where we need to be, you know? And so I'll like, I'll get excited about that and I won't focus on that. And I'll, you know, I'll forget about the buffer will flush. And, and so being able to, to do little tiny chunks of work and in, and use use whatever I'm a story or whatever I have in terms of my requirements to drive my tests is super helpful because I can look and say, okay, this happened here because I have a test that says this happened. And I have a test that says it didn't happen to what it should happen, what the response should be or the outcome should be if it doesn't happen. That's really... like TDD is fabulous for that. Collaborative work is fabulous for this because when I'm driving, I don't get overwhelmed if I'm at the keyboard because all I have to do is listen to what other people are telling me and type on the smart input. When I'm navigating or I'm helping write the software, I can get stuck, I can get lost and it's really... It's good because my teammates will say, hey, let's just add this little part. I know you want to refactor this into a need-based eventing system, but let's just add this. In fact, I can hear my buddy's voice in my head saying, can we just write this little part? And the answer is, yeah. OK, great. So there's guardrails on both sides when you work as a collaborative team, which is really excellent.

Brian Milner (12:46)
Ha ha. Yeah, I agree. part of that hyper-focused kind of side effect sometimes is that our brain turns its attention to something. And it's hard to come back from that edge once you've gone over it. And if you're thinking, oh, it's this needs-based event system that we need to move to, my brain is now in that mode. if I don't have that help to say, whoa, hold on, let me pull you back over that cliff edge here. Let's go this direction. I agree that partnering up with someone, pairing with someone, that can be such a vital thing there to kind of help control that a little bit.

Paige Watson (13:31)
Yes. Yeah, yeah, it really and I mean, there's so many other things that the sort of myopic view versus the 10,000 foot view, it can be really easy for me to get really focused on one little thing. The other people will allow you, one, even if that one little thing is what I need to work on, the other people will see how the larger context exists, how the architecture fits together. where I might not be thinking about that. And on the opposite side, when I'm thinking about like, oh, we're going to need this component, we're going to need these five components, we're going to need a database, and again, my buddy, we can just start on this little thing. We can just do this little part. And so again, those guardrails of not having to hyper-focus and not having to sort of scatter and get overwhelmed by the immensity of it all. it really works well.

Brian Milner (14:43)
Yeah, I agree. I want to make sure people listening understand as well, though. If you're hearing this, please don't think, well, if I don't have ADHD, maybe this isn't important to me. Part of the reason we kind of talked about how there's, know, maybe we're seeing it, maybe there's some studies showing it, that there's a prevalence of these kinds of traits in people that we work with. It's important, I think, to know our own teams, to know how to help the people on our teams. And if there's someone in your sphere that you work with that has some of these traits, then they may not be diagnosed in the way you don't have to be. If you just notice this is what's going on, well, just a suggestion. Hey, have we considered doing something like this? Has that ever been anything you've tried? That kind of thing can go a long way, I think, just being helpful.

Paige Watson (15:34)
It will. I would be careful, right? Because it's not my place to say you have this or you're this or whatever. And it's totally up to the person, whether they've been diagnosed or not, to self-disclose, right? The really nice thing about this is this is a great way of working for everybody. ⁓

Brian Milner (15:36)
Yeah. Yes.

Paige Watson (15:56)
Collaborative programming builds a team. It's no longer my code versus your code. It's our code. We built this together. Woody Zuilll likes to talk about the best of my coding ability and the best of your coding goes in. And when I start to write something that's not so great, you go, well, maybe there's a better way. And so that sort of lesser coding skill gets dropped out. So the code quality increases just for having

Brian Milner (16:19)
Yeah.

Paige Watson (16:22)
multiple people with different sets of knowledge in the room. Not only that, but I start to learn. I'm not a UI guy, but if there's someone who's strong in the UI skills and knows the domain from that side, we work together. Now, if I go work in another mob or ensemble somewhere else. I can be like, yeah, I remember hearing about this and we need to watch out for that sort of thing. And maybe we should pull in another person as opposed to being totally in the dark. But you start to have that cross-pollination of knowledge that you don't necessarily get by having just stand-ups or knowledge sharing meetings, which is not really knowledge sharing at all.

Brian Milner (17:06)
Right, right. I appreciate that word of caution, because you're right. I mean, I don't want anyone listening to think, I'm going to go tell someone I work with, hey, it looks like you have ADHD. You know, like that's not appropriate. But if you see, that's the great thing about these things that can help is that they're actually good for many reasons. And you don't have to be doing it for this reason.

Paige Watson (17:23)
Yes.

Brian Milner (17:28)
you get plenty of benefits doing it for other reasons. And it just so happens to also help in these other ways. So that's a really great call out.

Paige Watson (17:33)
Yes. Yes. and certainly, so I've, I oftentimes after I do presentations on this or something, there's that question of like, there's, there's this guy at the office who's, you know, obviously got ADHD, but he doesn't know it or whatever. How do I, how do I help him? And, and my answer is, one, don't, you know, but, but I mean, a better answer is maybe like, instead of saying, look, you have this issue. say like, Hey,

Brian Milner (17:53)
Ha

Paige Watson (18:00)
I have some ideas about how we can work as a team in a better way. Can we try that? And whether or not the person has whatever, like this is a great way to work as a team. Maybe it helps everybody. So.

Brian Milner (18:06)
Yeah. Yeah, I agree. it's not that, you know, it's not our place to put the name on it. And it doesn't really even need that. It's just, it's just kind of recognizing the personality, the traits of the person that you work alongside and saying, you know, we all have strengths and weaknesses. We all have things we do really well and things that we kind of struggle with. And, you know, you do that for anyone else, right? Anyone else on your team, you'd say, Hey, there's, they maybe aren't as good in this area. How can we, you know, help

Paige Watson (18:20)
Yep. Yep.

Brian Milner (18:44)
boost them in that area.

Paige Watson (18:45)
Yeah, yeah. And while we're on that subject, self-disclosing and having been comfortable with that eventually, slowly, but eventually, a lot of it working on a team where I feel very safe, saying what I am, what I need, that sort of thing, has been super powerful. And being able you know, to say, need to do this, or this would be super effective for me if we can do it this way. Could someone else come and sit with me while I do this? There's a great thing called body doubling that people with ADHD have used. And it's not really someone watching over you or making sure you're on task or whatever. It's a person sitting in the room with you. Just having another person there, whether they're working on the same thing or not, it can be super effective for helping me maintain my focus and continue the process that I'm working on as opposed to going down rabbit holes or hyper focusing or whatever. And it's a weird thing that it happens that way. Now, when you work collaboratively, the whole team is doing that, and you're working towards continuing the code forward. But Being able to recognize that and being able to say to someone, hey, could you just pop in, even when we're remote, can I just open up a Zoom room and just so we're together here? I'm just going to work on this and you can work on that. If you can't mob or you don't mob or you're not pairing or whatever, even that's a good start, a good help. But this idea of being able to be on this team that's comfortable with this. allows us, especially when we're mobbing, allows, I have one person I worked with who was very introverted and got, that energy got exhausted pretty regularly, especially in the mob. And this guy was, is amazingly smart and I love working with him. Okay, every once in a while he'd be like, I'll be back. And he'd go sit, you know, in a cushy chair in the corner and, you know, quiet time to himself. Great. Nobody in the mob was like, where's he going? How come he's not working? We were all like, yeah, that's what he needs. We can keep going. We can keep moving the code forward. And then he would recharge. He would come back and we'd keep going with him. And so sometimes, and again, if you can get to that point that you feel comfortable and you're in a comfortable surrounding, it can be immensely helpful and allow. for the team to continue to grow and do the good work in a way that's effective for you as well.

Brian Milner (21:24)
Yeah, I think that's the big kind of paradigm shift that's happened is that, you know, for a lot of my earlier career, the kind of attitude in workplaces was you, the individual adjusts to fit the environment. You had to, you know, change how you worked best and everything else to fit the structure of whatever it was. And now there's much more recognition. And I think very appropriately so to say, no, we're human beings, we're very different and no one little cookie cutter mold is gonna work for everyone. And we don't want it to. It's actually beneficial that it's not that way. know, cause we want people who can be better at spatial reasoning and others who are more creative and like we want the benefits from it. We just, you know, get annoyed sometimes at having to deal with, you know, individual downsides from that as well.

Paige Watson (22:17)
Yes. Yeah. Yeah.

Brian Milner (22:19)
What other kind of tricks have crossed your play? What other things have been really helpful to you in programming with ADHD?

Paige Watson (22:25)
Sure, so I talked about collaborative programming. I talked about TDD. Those are both super effective for me. Another one is we use a thing called Discovery Trees. Discovery Trees is a visual representation of tasks to be done. so yes, it's sort of like a breakdown of work, a tree of work. But the really important part of it is that it's not It's not an upfront design. It's a last responsible moment practice, which means not last possible moment, but last responsible. So it started out with us, we were mobbing and we were like, okay, we got to build this and we're going to do that. Oh, we need to remember to add the connection to the database. When somebody would write that down on a sticky note and put it on the window and you know, it started with a bunch of sticky notes on the window. Then it moved to, OK, what do we need to do next? What's the next most important thing that the application doesn't do right now? And let's focus on that. So let's connect to the database. What do we need to We would sort of put the connect to the at the top and then say, what do we need to do to make this effective? Well, we need the connection string. We need the. the whatever certificate or all this sort of thing, we'd list a couple of things. And then we'd say, OK, of the four things we just listed, is there one we can start on right now? Is there something we can do right now that maybe will take a couple hours to half a day at most? And if the answer is yes, we stop designing the rest of it. We stopped adding sticky notes under it. And we started focusing on that one thing. If the answer is no, then we'd say, of the four things we came up with, what's the most important thing that the application doesn't do right now? Well, OK, it's the connection string. Do we have everything we need for the connection string? We need a username. We need a password, et cetera. We need a table name, whatever. And so can we start on something there right away? Yes. OK, let's start on that. and stop designing the rest. And so it was a very quick way of, again, that just-in-time design. And it's super effective because we would start on something and we'd add a little tick up in the corner. And I've... On my blog, I've got pictures of it, but we've got ticks in the corner of stuff that's in process. And then when it's finished, we cross it out, big slash across it. We can also do this online using whatever whiteboard that you're using for your company. When you look at it and you see like, okay, there's one thing at the top and there's four things underneath that and then underneath each of those has three or four things. The top two things in the first branch are crossed off. And then there's a couple of things from the third branch cross off. And I say to you, what percent are we done with the work that we know? You can say, it's probably more than 50%. You know, maybe it's about 60, but you can visually see it right away. And it's super easy to kind of say, okay, here's the steps we think we need to go through. Here's the things we need to remember. And if at any point we go, we forgot to do that, we write a sticky and we put it on the tree and we say, is this the most important thing that the application doesn't do right now? And if so, we go work on that. not, we wait until it is. And there's some really that law of unintended consequences sort of thing. There's some really exciting things that came out of it. One, we didn't have to do this big upfront design and planning. You should have a roadmap. You should know the direction you're going, obviously. I'm not saying there should be no design, but I'm saying there shouldn't be two days of sitting in a room coming up with all the different stories and designs that you have to do over the next quarter or two quarters or whatever. Because we all know in three months when we get to this work, what's going to happen? We're to look at it go, this isn't anything of like, everything's changed since we got here. We still have to connect to the database, but everything has changed.

Brian Milner (26:38)
Right.

Paige Watson (26:41)
Right? So you need that roadmap, but you don't need to do that design. You can do it at the last responsible moment. ⁓ And the visual aspect, one, it allowed me not to get overwhelmed because I could look at it and say, OK, here's the next thing that I have to do. I don't have to worry about all the rest of that. Two, when we had PM management leadership, anybody walk by,

Brian Milner (26:49)
Yeah.

Paige Watson (27:06)
we could immediately say, we are right there. See how these are crossed off and that isn't, and this one's got ticks in the corner, which says it's in progress. We are right there. And then we added some other visualizations like red dots or whatever for blocked. When we were doing this online, we had blue stickies, which were questions that we wanted to pose to our product people later or whatever. it was super effective at sort of radiating all that information and put that in a place and put the link wherever, where everybody can get to it. And, you know, we didn't really have to, there wasn't a lot of time spent trying to explain what was going on to people outside of the team. So.

Brian Milner (27:51)
Yeah, that's one of the such strong points about making things transparent. Because when you do that, then you get the added bonus of now people don't need updates. Now people don't need to, you we can just point them to that artifact and say, hey, there it is. Go take a look yourself at any time. I love that. And I love also how that kind of deals with the problem we talked about earlier about, we have got this big, huge thing to do. I don't know where to start. Where do I start? There's too many things to do.

Paige Watson (28:09)
Yeah.

Brian Milner (28:20)
Now just systematically we're gonna go step by step through it and it gives you that impetus to just get going, right? Get something started. Yeah, yeah, absolutely.

Paige Watson (28:27)
Yes, the bias towards action. Yeah, and the really nice thing is that there were times when we had a tree and someone would be like, hey, we just finished our work. What are you guys doing? And we'd be like, OK, here's the tree. And they would grab one of the unstarted top level ones and say, well, we're taking this over to our board. And they would start on it. And so it was really easy to sort of split the work as necessary or as people were available to work on other things. And we didn't have to worry about like, how do we assign this story and that story and what.

Brian Milner (29:01)
That's great. These are great tips. like I said, I hope as people listen to this, they're hearing not just the exact thing to do, but more of the approach to it to say, when there's issues like this, you just experiment with different practices. You try them out and you see how they go, which is what we should be naturally doing anyway.

Paige Watson (29:01)
Yeah. Yeah.

Brian Milner (29:21)
Yeah, this is really helpful. And what we'll do here is make sure in our show notes that we've linked to these posts that Paige put together, because they really are fascinating. If this is something that interests you, encourage you to read the whole series, because it's, like you said, there's some really interesting pictures that kind of walk you through the process and how we went through this. So I really appreciate you being willing to do that and to share that kind of information with everyone. It's not always easy to, you know, be able to just say to people, hey, this is kind of what I'm going through. But I appreciate you doing it because I know it's really helpful. It's helpful to me. And I know it's helpful to others as well. So I just thank you for being willing to do that.

Paige Watson (30:03)
You are welcome. It's one of the sort of aspects of being a crafter, calling myself a crafter, is I want to spread great practices. I always like to say I... I don't know the best way to build software, to create software. I know the best way right now. If there's a better way, I love that you were talking about experience because we should all be doing them all the time and finding the better way. And these practices, even mobbing and TDD and all, they all came out of like, how do we find the better way? Whoever it was that started them, How do we find the better way? Discovery trees, I'm hearing people using them all over the world now and they're like, this is great. Like that's good. If it works for you and it's really effective, then do it because we wanna get rid of those things that are holding us back, whether it be processes or practices or sort of ways of working that aren't super comfortable for who we are as people. Let's change that. Let's do it a better way. Yeah.

Brian Milner (31:08)
That's awesome. Well, Paige, I can't thank you enough. Thanks for making the time for this and sharing your insights with us. I really appreciate you coming on.

Paige Watson (31:16)
Yeah, thank you. And I enjoyed this a lot.