 In this next talk, Zack Nickens provides a great reminder of the value of some of the core DevOps principles by applying them to a non-software related project that's family. This talk will show you why DevOps matters, but also so much more. Enjoy. Everybody, welcome to DevOps and Autism Care Teams. My name is Zack Nickens. I'm an SRE team captain at OutSystems. You can find me on GitLab at Zack.Nickens. You can find me on Twitter at the underscore Nickens. What I'm talking about today is embracing DevOps for non-technical teams. What that really boils down to and it's most essential is building your team culture. What's important about that is that as you build your team culture, it's critical to your happiness and to your success to make sure that you are building a team where people are empowered and people are safe. Before we really get into it, we need to read the man pages. There are a few really, really important caveats that really need to be at the beginning of this talk. This story is about our care teams adoption of DevOps culture. It's not a story about a specific therapy or a care plan. This story is really tightly scoped to my children. Autistic people are not a monolith and it's important that we include them in discussions about their lives, about their care, and about their rights. It's also really important to understand that this story is not about eliminating toil. This story is not about making my life easier. It's about making sure that my children build the necessary skills, and they have a team around them that allow them to build the skills so they can live independent, happy, and fulfilled lives as they grow up. Let's meet the boys. This is Aiden James. He's five years old. He's a non-speaking person. He loves to play in the water. He really, really loves to jump and run around. He absolutely adores Nemo and Dory and his favorite food is pizza. I think he's pretty cool. This is Aiden's little brother, Henry Scott. Henry is three years old. He's also non-speaking. He loves to take walks through the neighborhood. He loves any kind of music and his favorite food is Chick-fil-A. And so what challenges does our team face? So Aiden and Henry are both non-speaking. That means they don't rely on spoken language as their primary method of communication. And both of the boys have sensory processing disorder. That means that they physically experience stimuli in different ways from most people. And they face challenges in building important skills and in coping with situations which are discomforting or difficult for them to understand. And to meet these challenges, my wife and I have built a care team. And that care team has adopted the core tenets of DevOps and reliability engineering. We leveraged small change sets, active observability, continuous improvement, and blamelessness. And I think what our experience shows is the strength and importance of the human elements in DevOps culture. Not just for our work teams and orgs, but for how we approach challenges in all aspects of life. Our life illustrates that really high performing and happy teams really do exhibit empathy and respect for each other and for their work. My sons are really happy, healthy kids. Aiden and Henry are a lot like neurotypical little boys in a lot of ways. They love to play, they love to watch cartoons, they love to just be loud and run around. We do live a very different life, however, and that's okay. So the first tenet of reliability in DevOps that we've adopted is small changes. And so instead of a code base, think about a daily set of routines and patterns. My kiddos experience life as a set of patterns. And when there are big changes to that pattern, it's discomforting. And so small changes greatly reduce the impact of failures in a system where the impact of change can't be fully predicted. And this is true of both software and humans. And it's okay to accept that there will be some failed changes. Fail changes normal and expected. The key is to minimize interruption. Remembering our ultimate goal is to have a happy day. And we just keep trying to have a happy day. Incremental building for the win. Our care teams, our parents, therapists, family members, friends, we've all learned that introducing these small changes in small batches with very high velocity actually leads to less disruption and stronger skill-building. And that's really what we're engineering for. We're engineering for skill-building. And so introducing a new skill tree to our routine such as self-feeding, we try small changes and we really listen to their response and their feedback to determine if that change set is working. And so as you can see, Aiden really had a ton of fun self-feeding this glazed donut. And so another key thing that we do is that we don't over engineer. We pay very close attention to our sons and their environments. But we have to make sure that we don't over engineer their environments. And so what that means is that we want to make them comfortable, but we don't want to make them so comfortable that change is not getting introduced because change is how we build skills. And so we want to introduce changes safely while maintaining high velocity. And critically, we need to maintain easy rollback for when things don't go well. This is a sample space that we have built for our children. And so you can see that there are sensory toys on the floor. There are a couple beanbags and a tent to play in when they kind of need some quiet time and there are some toys there, but not too many toys, right? We don't want to overwhelm them with stimuli. We want to make sure that only their preferred things are there and that we can introduce new toys or new tools to make sure that they can handle it and that it gets noticed. So interruptions happen, right? Whether you're running a software team, operating software or raising little kids, sometimes people are things are going to get upset. And so Aiden and Henry are going to be uncomfortable sometimes. And success in skill building comes from actually interbracing disruption and then rolling back when we need to. And most importantly, we keep trying. And sometimes when you're having a rough time or you're having a rough day, you just need to play in the bouncy house. I mean, bouncy houses are pretty cool, always for the children. And so through our monitoring and observability patterns, we've recognized patterns and we collect data about what works for Aiden and Henry. And so you'll notice the AAC device here. Recently, Aiden has started using an AAC device while Henry still mainly relies on sign and physical directive communication. And so we accept that we can't treat environments and activities and skill sets as monoliths and we embrace small chunks of continuous improvement to ensure that we do achieve that happy, healthy life. CICD for happiness, right? Everyone on our team is empowered to try new methods and adaptations in small doses because we all know and trust our team. Our team members come and go. We might get new therapists. We might get new speech therapists. Some therapists may cycle out of our team and it doesn't affect us because our team is more important than any one person. The team always remains focused on our team goal. And that's happy kids. And so you can see, you know, sometimes our family is just one tin away from being a full blown circus, but we're all pretty happy. Everybody on our team is empowered, empowered to try and achieve our goal. And that's what makes us a high performance team. So testing in production. We don't have a dev or test environment. So we test in production. Small interruptions are better than major outages. And so accepting that things are going to be disrupted. Just as any large distributed system is also going to always be a little bit disrupted. We've built our culture and our care system around the ability to try these small changes. And then if they don't meet our success criteria, we can easily roll back. And we have to try that in real production. And so sometimes the picture that you wanted to take doesn't come out the way you wanted it to come out, but it's still a great picture. It's still a great memory. So I want everybody to say it with me when this comes across the screen. Teams should be blameless. Blameless. No, really, say it again. Teams should be blameless. When we experience interruptions and disruptions in our life. We can't hold each other to blame, right? When things get sideways, we do have a totally blameless culture. That doesn't mean that we don't get frustrated, that we don't need a moment to catch our breath. It just means that we don't pin any blame on anybody on the team. If we have a hard day, we just had a hard day. We can have a better day tomorrow. And this applies to everybody on the care teams and especially to our sons. Things that don't work out or when we do have one of those bad days, they're just that. We can recover, we can talk about it, we can document what went wrong. We can try to find that point of failure that started us into a cascade of more and more disruption. But ultimately, we just have to move forward, right? We document what we can, we assess what we can, and then we move forward. We are a totally blameless culture. And we're like that because it works. And so on call. Nobody can be on call 24, 7, 365. You just can't. And so you have to lean on your team. My wife and I wouldn't be able to do the things that we do. I wouldn't be able to work the job that I work without our team. And so you really need to lean on your team. Your team is there for a reason. That's why they are your team. They're there to help you. And so you can't be a hero. You can't be on call 24, 7. You can't do it 365 days a year. So my wife and I, we work in shifts. And if my wife has had a hard day managing the children, I take over in the evening. Or if she knows that I've had a long day at work and I need an hour to rest before we do the marathon that is dinner time and bath time and bedtime. She gives it to me. And it's a give and take because nobody can do it 24, 7. And so one of the most important things is simply to stay committed to your team goal. If your goal is to build a great piece of software. If your team goal is to operate a really complex system. If your goal is to raise happy healthy kids, stay committed to that goal. It's your goal for a reason. It's your purpose. And so we have stayed committed to our main goal of building very enriched lives for Aden and Henry and for the whole family. It's chaotic at times, but it's our life and we're really happy to live it. And as you can see, the boys are really happy and our extended family is really happy. So I would like to conclude by touching on one last thing. We recognize that our son's inputs are critical to our success. And our aim is to build fast feedback loops for our children. The boys feedback is the most important measure for us. And since they're non-speaking people, we just have to know how to listen to them. And so I want you to take away one thing from today about non-speaking people. It's that there should be nothing about us without us. And so if this story strikes you at any level, I really encourage you to reach out to people with autism and their teams in your community and engage with them and communicate with them. They would love to tell you about their life. They would love to share their experiences with you. And they would love to learn from you. And I think you would probably enjoy learning from them. So I'm Zach Nickens. I'm really, really happy to give this talk. I can't wait to talk to you all during live sessions online. And if you'd like to chat with me, just reach out.