ºÚÁÏÃÅ

Episode transcript

Ìý

Ken Mugrage: Hello, everyone, and thank you for joining the ºÚÁÏÃÅ Technology Podcast. I am one of your regular hosts, Ken Mugrage. I'm joined today by Dr. Rebecca Parsons.

Ìý

Dr. Rebecca Parsons: Hello, everyone. I'm Rebecca Parsons, another one of your recurring hosts and CTO emerita here at ºÚÁÏÃÅ.

Ìý

Ken: Today, we have a pretty cool topic. We recently published something we call our Sensible Defaults on our website. We wanted to talk to a couple of our community leaders about what that means. First off, let me introduce Brandon Cook.

Ìý

Brandon Cook: Hello, I'm Brandon Cook. I'm the Global Community of Practice Lead for Software Development.

Ìý

Ken: Welcome. And Kief Morris.

Ìý

Kief Morris: Hi, there. I'm Kief. I'm the Global Community of Practice Lead for Infrastructure Engineering.

Ìý

Ken: First off, let's start with just a definition, I guess either one of you. I know we don't tend to use the words best practice for multiple reasons. What is a sensible default?

Ìý

Kief: A sensible default is basically something that we think is generally a good idea, barring some reason why your particular situation, it might not be right. It's like, by default, for example, we think it's a good idea to pair program. Unless there's some reason why that's not feasible, we would just go ahead and do that.

Ìý

Ken: What does it not mean?

Ìý

Kief: It's not something that you must do, you're going to be punished for not doing. It doesn't mean you're doing it wrong if you don't. It's basically-- You mentioned the best practice, it's the contrast to best practices that, at least the way that the phrase is often used, best practice is that this is the best way to do it, no matter what, you should always do it this way. Whereas a sensible default is just a usually good idea.

Ìý

Ken: That makes sense.

Ìý

Rebecca: I think one of the things that distinguishes the sensible defaults is that there is more of an expectation that you understand the why. If you're going to choose not to do it, you want to explain why it is that it doesn't fit in your situation, not just, "I don't like that." Also, how you are going to compensate for the goodness that you got with the default.

Ìý

You really do have to understand it. Whereas, as Kief pointed out, with the best practice, there's this, "If you don't do this, you're bad, but let's not talk about what the goodness is that comes from it or why people say it's this best practice." I think that's an important part of keeping it from being the commandments that have come down from on high that thou shalt.

Ìý

It doesn't have that feel to it because it should be much more of an informed conversation about why you were choosing not to do it and what are the circumstances. That helps others also learn about what situations might be different than the ones they've encountered in the past.

Ìý

Brandon: Yes. Another thing there as well with sensible defaults is that there's going to be different nuances and different flavors of it at different organizations as well. That's where we want to really avoid being super dogmatic that you have to do it this exact way. We think that these sort of defaults should be things where every team should start off saying, "How can we put this into place on our teams in this organization?" Really understanding the fundamentals and really understanding the why and the how these things could be done to improve the whole experience for development and the team overall.

Ìý

Kief: It's an interesting point that every organization is not going to use the same necessarily practices or have the same sensible defaults. I think the thing about when we selected our sensible default practices, when we went through that process of working out, well, what do we think they are, what do we want to document as our sensible defaults, part of it is that they're not obvious.

Ìý

We didn't want to have these generic platitudes like, "Well, write good quality software." Because nobody's going to say, "No, I don't think I should write good quality software actually." It's not even things that are taken for granted in the industry. One thing we consider it is use a source code control system to store your source code. Some years ago, maybe that would be a thing that you would need to point out. These days, you can take that for granted. We chose ours as ones that we think are maybe not obvious and not necessarily the defaults for the industry, but are ones that we particularly find effective and think are effective.

Ìý

Ken: Lead me into the defining of these. You both introduced yourselves as leaders of different communities of practice. I know that's who owns sensitive defaults in ºÚÁÏÃÅ. Our listeners don't. Just briefly, what is a community of practice lead at ºÚÁÏÃÅ? Who are the people that develop these sensible defaults? Actually, I will start with Brandon because Brandon is relatively new to the role.

Ìý

Brandon: Yes, I was going to try to let Kief take that, but I'll try to give it a go since I just stepped into the role. From my understanding, it's we are just trying to connect all the dots between the regions and how these sensible defaults are emerging across our organization globally and make sure that there's alignment across the regions that these are the expectations that we're setting because there will be different nuances and different leanings in the various regions.

Ìý

We were looking to really just have alignment, especially in this distributed environment where there'll be teams working across different regions and that in that way. That's where the community of practice comes into play globally—working with all the different regions to get that common understanding and that common practice so that when these teams form, there's a common understanding between everyone.

Ìý

Ken: Yes, I think it's important because, in a lot of places, the how you should work comes down from on high, if you will. At ºÚÁÏÃÅ, our community of practices truly are communities. Kief, you've been part of that community for quite a while. The sensible defaults, how have they evolved over the last year or two, again, in using and leveraging that community as opposed to being a "Rebecca, CTO, America, what are we supposed to do here?"

Ìý

Kief: Yes, so it's interesting. I actually go back to how we first came up with them, which was-- it wasn't that we sat down and said, "What do we think would be good practices to use?" It wasn't aspirational. It was really looking at, what do we use? What has historically been the things that when you joined-- I joined ºÚÁÏÃÅ about a bit more than 14 years ago now, and I was familiar with agile ways of working and extreme programming and those kind of things.

Ìý

It was really coming into a project team and working with people that I really got by that experience of working with the people and seeing what the practices, how they normally would do things, like how would they, I don't know, structure a story wall to put stories? How would they how would they write up stories? Those kind of things.

Ìý

I think it's interesting because what I would call them is norms that have evolved. They weren't necessarily written down, but they were in people's heads and they were also often things that we would have to explain to people, whether it's to new Thoughtworkers or in client situations where, basically, we say, "Okay, we think it's a good way to work like this." Pair programming is a great example because, for a lot of people, that's a new thing.

Ìý

These were things that we maybe had to do that, make that extra effort to explain why do we think they're effective and for people to get used to doing. When we first decided to document these practices, we drew on how we worked and those things that we noticed. It wasn't an inventing from scratch. Then over the past year or two, we're getting feedback from people, from people out there on projects, from new joiners and so on, to see how they land and how well they work, and the way that we put them together. We've gone through and had to do some updates and refreshes and improvements on how we express those.

Ìý

Ken: I'm going to ask Rebecca. She was the CTO at the time when these really became to the forefront. In a large organization, how did that happen? What made it to where, "Well, we need to agree on some of these things"?

Ìý

Rebecca: It actually started in Australia and we had a head of engineering in Australia at the time. His name is Evan Bottcher, and unfortunately, he's no longer with ºÚÁÏÃÅ. He was looking around projects, and feeling the need to actually document what our way of working was. He is actually the person who originally coined this term "Sensible default." He was very focused on what would now be in Brandon's scope, almost exclusively, which is the software delivery practices, the things like pair programming.

Ìý

It did go a little bit into some of the other things around project planning. Do you have a risk register? As Kief pointed out, this is as much the how do you make one of these happen in a way that is supportive of the development process? It's not that startling to think you should have a risk register, but a risk register is not this list of risks that people write down and ignore. There's a process around things like that. It's the, how do you manifest some of these things that are also important?

Ìý

As I said, originally, it was primarily around software delivery practices. We didn't have formal communities of practice at the time. This was something that was initially just used in Australia, and then started to expand out globally through the heads of technology in these various countries. When we actually formalized global communities of practice, which we didn't have a formal mechanism-- We've always had a very strong software development community, but we hadn't formalized it as part of our organization with particular responsibilities.

Ìý

When we did that, one of the things that we thought, "Ah, now we have a Kief and a Brandon, and a Kate for experience design..." What we did was thought this was something that can bring the community together globally by saying, "Let's build upon what Evan has already done, but let's expand it out to include what are the sensible defaults for product? What are the sensible defaults for infrastructure engineering? What are the sensible defaults for program management?"

Ìý

What we have developed, over the past couple of years, and have now recently published, it shows the entire coverage of our various craft communities, these communities of practice. These sensible defaults have developed as a result of the work that these people are doing across the globe on our various client projects. This isn't, "Oh, I'm sitting, as a professor, in a lab, and saying this is a wonderful thing for you to do," but this is sourced from people who are doing the work day in and day out.

Ìý

Ken: As Kief mentioned, some of these aren't obvious. Some of them might be, but this might be even some of our secret sauce. Why are we publishing this? I guess either Kief or Brandon, why are we telling the world about this?

Ìý

Brandon: Yes, I think that there's a difference between just publishing what we think are like the sensible defaults, and then actually putting them into practice. There's one next level on top of just sharing those, "Oh, here are the sensible defaults that we think you should be following." Then two, actually implementing them and actually doing them in the best way suited for that organization.

Ìý

That's where it's like just sharing our differentiation that these are some of our core sensible defaults that we think can accelerate, help provide better experiences for your teams, better outcomes for your business. Then if you want to actually probably do these in the most efficient manner with very experienced practitioners in these areas, then working with us is probably a good choice because we can actually have those folks who've done this on several projects and evolved numbers of organizations to adopt some of these sensible defaults and have seen great success. I think that's the key differentiator between giving away the secret sauce and just sharing what the sauce is.

Ìý

Kief: I think it's always been a part of our ethos to share and contribute to the industry. We've never been the organization where it's we're going to come up with a secret special way to do things and then we're going to keep it to ourselves and you have to come to us if you want to do it. We've always been about, like, we come up with ideas, we want to share them, we want the rest of the industry to adopt them if it makes sense for them. We want to drive and help everyone do better.

Ìý

I think that the other thing, then going to it, it's like, again, people can see if they're going to work with ºÚÁÏÃÅ, they can see, this is what we do, this is how we work. It's not going to be shocking. You know what you're in for when you can look at those practices. I think that's a good thing. I think, if for some reason, you really, really don't think that our ways of working are right for you, then that's probably for the best as well that you know that before coming in.

Ìý

Brandon: Another thing to add there is, I think, it's just like the sharing of knowledge, like Kief just said, is definitely a core part of our culture. I guess we're always willing to have a vibrant conversation. If you take a sensible default, like TDD, there was a vibrant conversation that we had around is TDD dead, several years ago. Pair programming always has a vibrant conversation with clients.

Ìý

A lot of these practices, a lot of these sensible defaults are just having great discussions and evolving and being challenged. That makes them even somewhat even more bulletproof because we really have to think about the why, and we have to demonstrate the outcomes of these as well with our clients.

Ìý

Ken: Given the fact that there's—I love that word vibrant—discussions around these, I'm going to ask Kief, because I know you've been in this a little bit longer than Brandon. What's the process like? I know it differs community to community and there's not a defined process from ºÚÁÏÃÅ, but inside the infrastructure community, what's the process look like as something going from a, "Oh, that might be a good idea," to, "Oh, this is our sensible default."

Ìý

Kief: The way we did it was we started with a mural board, a virtual sticky board where we put stuff up, and we decided to do it. We had some sessions where people could join in on Zoom and had these conversations, but we also wanted to make sure we had an asynchronous ability for people to contribute. We basically made the board and we started putting things in there and getting people to put things in there and putting in comments.

Ìý

We had discussions in our internal forums and the chat rooms and mailing lists, as well as at a few calls where we could have that more interactive conversation. It was a real process like that. They also participated-- I worked closely with Evan because the infrastructure and software development practices are quite closely related. We worked together actually pretty closely.

Ìý

On the software ones, we actually had a document that people could add comments to. There were like some really long conversations about some of the practices about like, "Oh, is this really the right thing or is it old hat?" We had a lot of discussions around the trunk-based development, continuous integration, and whether that was now obsolete, the pull requests were the way to go.

Ìý

That was quite an interesting and vibrant thing. At the end of the day, we just had to go with the consensus, I guess. We're never going to get a unanimous agreement, but we had to go with this. This really does seem like the consensus overall among the community and among folks in the conversation, and just put it and go forward basically.

Ìý

Brandon: Yes, the good example from the one that Kief just mentioned around trunk-based development, we were really looking at what are the core fundamentals of trunk-based development that we really want to get out? Does that mean that you can't do PRs or you can't effectively continuously and frequently integrate your code? We wanted to really highlight the core fundamentals that we wanted to seek out.

Ìý

That's where the phrasing and the framing and the wording of the sensible defaults comes into play, so that we can then go to an organization and work with them and get them on like a maturity roadmap to start adopting this practice and improving their software delivery overall.

Ìý

Kief: I think that's also a good example because it goes to show-- part of the conversation we had around that in the last round was-- There's a couple of phrases that are obvious. Continuous integration is a well-known phrase. Trunk-based development is a fairly well-known phrase. We actually opted not to use those as the names for those practices because we felt like there was a little bit of that, as Martin puts, the semantic diffusion of continuous integration, to a lot of people, has come to mean, "Well, I run a build server on my branches."

Ìý

We did that step back and say like Brandon, like what you just said was, like, "Okay, what's the important things about this?" and to make sure to get that and we use the phrases integrate frequently and continuously. It's like, "You can use pull requests, you can use branches, but as long as you're integrating very frequently, very continuously, you're still doing the thing that we find to be effective."

Ìý

Ken: One of the things that is great about ºÚÁÏÃÅ is the ability to disagree, but still get the work done, and be heard, and be able to talk about these things. How do you promote that culture inside the organization where the sensible default is to do trunk-based development, for example, but because of concerns that our client or whatever it is, how do you promote that culture where people can say, "I get that's a sensible default, but I can't do it here because--" Like Brandon said early on, not just because they just don't like it. How do you get that to where people are, like, "I understand it's a sensible default and I need to do this, but I can't in this case. I feel safe not to."

Ìý

Kief: I guess it's just about the conversations, how you handle those conversations. When you get somebody saying, "Well, don't want to use this particular way of working," you always assume good intent. You assume, "You don't want to do that. Do you understand why?" maybe you might ask. I think it's having those respectful conversations, I guess, and trying to-- We, and other people who've been in the company for a while, I think hopefully provide that leadership and provide that example for newer folks that, it's not just-- you don't just pile onto somebody and tell them they're doing wrong, but it's like you try to have a constructive conversation around it.

Ìý

Brandon: Yes, I would say it's definitely a challenge at this in this new landscape where everything is remote. I think a lot of the sensible defaults arose at ºÚÁÏÃÅ out of a strong co-located experience where you just got to sit down with very experienced Thoughtworkers and you learn these practices because you were just working next to them every day, particularly like pairing. You just learned the nuances of pairing when you're sitting right next to someone a lot easier versus where now everything is remote.

Ìý

Trying to be, like, get someone who's like interested in pushing for these practices and then they get any resistance from the client, they're like, "Oh no, I don't know what to do now, but I really want to try this out." I've never had an experience where folks aren't wanting to push for these, but any form of resistance is where they really see the blocker and maybe on their team, they don't have the experienced Thoughtworker who's been through that conversation before.

Ìý

Right now, we're working on working through some of those challenges to enable a lot of folks in this regard so that then they can have those conversations with the client, they can have those conversations with their team, and they can effectively drive the adoption of the practice going forward.

Ìý

Ken: I can see a listener seeing this and go, "Oh, I'm going to run out to ºÚÁÏÃÅ.com and look at the sensible defaults because all this AI stuff is new and I-- oh my gosh, there's no--" Why don't we have any AI sensible defaults? Anybody want to tackle that one?

Ìý

Rebecca: Because as I said earlier, this comes out of our experience, and we're still learning. We're still experimenting. Everybody is still learning and experimenting with what are the ways that you can use these various AI-enabled practices to get a better outcome. It's a sensible default because, in the majority of cases, this is how something works, and we haven't got that yet.

Ìý

The potential impact of AI across this software delivery lifecycle is such that it's going to impact all of our different communities and some of them have more tools available to them today, some of those communities don't have them really available right now, or there's still a lot of innovation going on. In a landscape that is as volatile as the AI landscape is at the moment, I think it would be premature for us to say, "This is the way to do something that's only been out for a couple of years."

Ìý

Brandon: I see right now, with the Gen AI stuff particularly and coding assistants and things like that as major augmenters of the practices that we already are sharing with folks. If you take like TDD or pairing and you're, like, "Oh, I'm going to leverage a coding assistant with my pair, or I'm going to leverage a coding assistants to reframe the sort of TDD red, green refactor loop, so that maybe I'm accelerating a lot faster."

Ìý

I see those as like augmentations of practices that we have. Sure, maybe there'll be new practices that arise, but just like Rebecca just said, we're very much in the experimentation phase, folks are still experimenting with how to leverage a lot of these things effectively. It's still a wait until we see like strong outcomes and strong acceleration from leveraging these tools.

Ìý

Kief: These practices are really-- they are things that we usually do. They're not aspirational because I have some aspirational things around infrastructure because I feel like this is one of my things when I give talks or whatever. I'm always complaining about the current state of infrastructure as code and the way that I feel that we have a ways to go. I think we should be moving towards doing things in a different way.

Ìý

I'm not going to say that, "Well, those should be the NBR default practices," because people aren't working that way yet. We don't have the tools out there to work that way yet. Our sensible default practices aren't aspiration. These are real, which is, I guess, another thing that maybe people should understand. I think sometimes you run into people who are, like, "Oh, all of these things around pairing and test-driven development, they're great ideas that people write about and talk about, but don't really work that way." It's like, no, we do. These are the real things we do.

Ìý

Ken: I'll stick a plug-in here because Kief won't—if you want to learn more about infrastructure as code, Kief wrote a book called Infrastructure as Code that you can find in major book seller close to you. Another thing that, and this is going to be the former military in me creeping out, I must admit. Often when a choice is made on a way of executing a plan, when there's debate about it-- As we mentioned, some of these are not necessarily obvious. Some of the sensible defaults are not obvious. Folks don't necessarily, "Well, that's not how I would have done it." "Okay, fine. I'll try," but they don't really do it.

Ìý

Kief, we were chatting the other day and you mentioned the phrase "disagree and commit." Brandon, I'm going to look to you because you're relatively new to this role, you've been on teams. How do you handle that? Whether it be sensible defaults or otherwise, when you're on a team and you're really not in 100% agreement on how to do something, it's a new AI tool, whatever it is, how do you get a team to not necessarily be in 100% agreement, but still commit and give it their best shot so that you know that it was the idea that worked or did not work and not the team?

Ìý

Brandon: These are probably the major challenges that most teams face from a day-to-day experience. I find the most effective way is just leading with empathy and trying to hear what thoughts most folks have to say, but then at the end of the day, we don't all have to exactly agree, but we can come to an agreement that we want to go in one direction and test that out for a certain period of time and see what the outcome is.

Ìý

If we find out that idea didn't work out, then maybe we can change course to another direction. It's really just making sure that you're having those conversations with your team, listening to their concerns, and then also addressing those concerns in some capacity. At the end of the day, you still need to make a decision going forward if we don't all come to an agreement so that you can start driving towards some type of outcome that can lead you in a better direction later on.

Ìý

Kief: I think often when people are unsure about certain practices, it's because they haven't used them and seen them in action. You get used to a different way of working. That's what you know, and it can be strange to-- a different way just seems wrong. "It's not what I was taught. It's not how I'm used to working. I don't know necessarily how to do it effectively."

Ìý

I think there's really no substitute for doing it with a group of people, with a team of people who are familiar with it. That was the thing for me, again, when I joined my first ºÚÁÏÃÅ team, and some of these practices that I'd read about and played around with, like say test-driven development, like, though I tried, it was hard. I couldn't really make it work. I wasn't sure about it.

Ìý

Then working on a team where they were using it, there's a lot of nuances to how they made it work. It was really mind-opening. Once you start-- I think it's about also asking people, just give it a chance. Let's work with it. Let's go with it, see how it works. Then once you've been doing it for a while, you have a little bit better, I guess, experience, of seeing what it is, then we can talk about whether you still think maybe it's not the best.

Ìý

I think another thing as well, is a lot of these practices are complementary to each other. Things like pairing and TDD, and the continuous merging and integrating and testing of code, all that works together very effectively. Sometimes if you decide, "I don't want to do one of them or another," they all come apart and it doesn't necessarily work as well. I think it is important that we give it a real go.

Ìý

Brandon: I think Kief has a great point there. It's almost a combination multiplier of some of these practices together where we see a lot of huge outcomes from. It's not just the combination of practices within one of our communities. It's the combination of practices across our communities as well, that we get the huge multiplier as well. Oh, if we're just going to focus in just on one, that may not be the best strategy, because then now you're just over-optimizing for maybe this one practice. Maybe it's just take a step back and look holistically at how you want to approach your delivery overall. How do you want those different roles to collaborate? How do you want them to work together? I think that's where the true unlock happens for most teams.

Ìý

Ken: Yes, thank you for mentioning that. I guess I want to ask Rebecca because I know you're the executive sponsor for a couple of the other communities. It's easy to think of software development in TDD, "That's a sensible default." What about other non-- I don't want to say non-technical, because they are very, very technical. What about the design-type communities and those types of communities? What does sensible defaults look like for them?

Ìý

Rebecca: One of the things that you'll see that's now on the website and published is that there are actually two different kinds of sensible defaults. We've spent a lot of time talking about the more practice-based sensible defaults. Some of these are more principles. When we look at the design community, it's less about what is the process that you're going to use to create a design, and more about, what should that particular process look like?

Ìý

It might, as an example, involve some kind of user research. You can't just say, "Do user research," because, what if your users are remote? You might have a different process. What if your users are intermediaries, which we try to avoid whenever possible, because we want to talk about the real users. Many times, for example, with customer service applications, they won't let you talk to somebody who's actually on the phone or online doing customer service. They want you to talk to the supervisor.

Ìý

The only thing you're going to hear from the supervisor is how the supervisor thinks it should work, not what the day-to-day experience is. There are principles there that are less like practices just simply because there is perhaps a broader scope to them. It was interesting in stepping back and looking at this is what the design sensible defaults look like versus the infrastructure and QA and analysis. You can see that there's the common thread of this is based on how we actually work on things.

Ìý

What constitutes a sensible default in infrastructure is a different kind of thing than what constitutes a sensible default in product. That's why I think it's so important that it's the individual communities of practice that are responsible for their area, rather than saying, "We're going to designate one person to come up with all of them across all of the crafts," because they're very different things, they require different competencies. Yet, they're all targeted at the same goal, which is we want to deliver products and services and technology that delights our customers. We want to do it as quickly as possible, we want the whole fast feedback and visibility, that's an underlying enabler for many of the practices across all of the different crafts.

Ìý

I think it was important to allow the individual communities to focus on the things that mattered most to them, because they do look, in some ways, very different from each other. Then, in some ways, as well, you can see that they are all of a piece. As Brandon pointed out, all of those things have to work together.

Ìý

Kief: Yes, I think that's really important. They have to work together. Especially when you look at those things like the fast feedback, and you look across-- certainly, we've worked with people in organizations where it wasn't everybody involved in the overall process on the same page about things. You might have somebody trying to do all we're going to do fast feedback, we're going to do frequent deployments, continuous delivery.

Ìý

Maybe the design wasn't working that way, the design was, like, "We're going to produce a final design and hand it over, and then it's going to be implemented," or vice versa, where you have product people who want to get continuous feedback from their users. Having the way that we're doing the software delivery, and the project management and everything all aligned to make that happen. That's what I think makes the magic. It's not just like different pocket seats doing things the way they think is best. We do have that, as you say, the common, the thing that underlies all of it.

Ìý

Ken: Then for the final question, Brandon, I'm going to address this to you because you had mentioned, when we talked about why publish the secret sauce, it's like, well, it's one thing to read it, it's another thing to do it. For our listeners, are these all just for elite teams and practitioners or can they go to the website and get some things that they can put into practice tomorrow?

Ìý

Brandon: No, I think there's plenty of practices that you can start implementing on your teams today. If you wanted to start pairing, I know there's a lot of perceived friction against that, but you could start pairing your devs tomorrow, and they can start working on cards. Obviously, you'll have to figure out what best works effectively for that team and different nuances in there.

Ìý

These are type of practices that you could try to start introducing into your teams as soon as possible. There may be somewhere there's a little more organizational friction that you'll need to push against and work towards-against, but you'll have to figure that out as you go through each of the practices. I would say there are some things that we're thinking about as a community of practice around like maturity models in each of the practices, and things of that nature, so that we can start meeting organizations where they are and bring them further and further along in terms of starting adopting some of these practices and thinking about how they implement them within their organization.

Ìý

Kief: I've had people tell me that these practices aren't realistic for your average developer, that ºÚÁÏÃÅ, you hire the best people and so they can do these extra special things. It's true to a certain extent that it's hard. Some of these things, if you don't know how to do it, it's like exercising or something, if you don't do it often, then it's going to be hard to do, when you do it a lot, it gets easier.

Ìý

The thing I always say is, we don't use these practices because we're special and able to use them. If we are more effective than maybe some other teams, it's because we use these practices. By using these practices, you can-- anybody can use these practices and become good. I think that's a really important thing to understand.

Ìý

Ken: Great. With that, I'll say thank you very much for your help. For the listeners, don't hesitate to check out them on the website and a little bit of insider information. Other things to follow, I'm sure, other content around our sensible default practices. Thank you, Kief.

Ìý

Kief: Thank you.

Ìý

Ken: Thank you, Brandon. Thank you, Rebecca.

Ìý

Brandon: Thank you.

Ìý

Rebecca: Thanks, everybody.