 Good afternoon. I hope you had a splendid lunch. I'm Allison Stanton, the chief problem solver at Stanton Ventures, and my pronouns are she, her, hers. I'm here to talk about ways DevOps could be more accessible. The perspective I come from is unique. Both of my parents are programmers. I'm a white, cis, pansexual woman. I've had access to computers since I was three. I've been online since 1995. HTML is my gateway drug into programming. I make a living as a data consultant, and currently my main languages are SQL, Python, and Lookamal. I found the word goat in the DevOps dictionary and found love because it is an affirmation that talking to people to make things work for everyone is indeed a great thing, not something to be chastised for. It also nods to interdisciplinarity, which believe it or not was my undergraduate major. To me, DevOps was just another word for system administrators, the new word. Given my experiences, it meant that it was closer to the hardware level and that it's the land of duct tape and band-aids, the land of older men. But see, if you get told enough times that the system is too fragile to give you access to it, you actually start believing that the system architecture is 30 seconds from falling over at any given time. Turns out that's not what DevOps is about, but it took some outreach to help me realize that. So what do I mean by accessibility? I mean the ability to enter and stay in DevOps by people currently underrepresented in DevOps. I am not talking about accommodations for missing senses, at least today. To me, the root issue is tribal knowledge. To learn DevOps, you must already be a part of the tribe. The entry procedure is a secret, and you're either standing still or you're on the highway. The on ramps are almost non-existent. Now, I do data for a living, so I went to Amazon.com and got a quantitative measure for us. These are the numbers of books and Amazon search results for these technical keywords. The year Wikipedia says the keyword came into usage and the rate at which books for that keyword are published. Therefore, my main point to you today is that the root solution for accessibility in DevOps is to start being teachers. Share the wealth of knowledge, give lessons, answer questions, mentor, draw diagrams. There are multiple ways to contribute. The principles for teaching that I would personally encourage starting with, begin at universality. Expand your audience. How could someone learn DevOps from a local library computer? Be multimodal. People learn in different ways. People have different circles of friends and different meetups. The approachability of people who work in DevOps is also key. Honestly, I think DevOps has a perception problem of being folks with unattainable expertise. Perception issues are hard to combat, so be welcoming, be nice. Not only in words, but in deeds. I'm going to go into phrases here today. The first is use case learning. To me, use case learning embodies the concept of teaching with a focus on reaching a deliverable. It doesn't see setup as a thing to learn. It realizes setup is the first thing in getting to something productive. Full examples are the way that you make up for unintended gaps in your assumptions. You assume that people know what you do, but if you give a full example, you give more context to the learner and make yourself more accessible. You know how in stock overflow, the top answer is go to the log file. Do you know how many log files there are in a Linux box? Every time I see that line, I'm like, which one? What directory is that in? So my recommendation on how to make DevOps more accessible is for all of you to turn into teachers. Be the best teachers. I would challenge you to try to explain one thing a week to at least one person. Here are some examples. They span mediums and audiences. Ideas like giving credentials are I would hazard to bet scary at first glance. It's okay to start at read replicas. It's okay to start at staging. It's okay if you only explain one thing a month, not one thing a week. My point is that it's a not one and done item. You'll notice that I continue to be multimodal in my suggestions because just as all learners learn best in different ways, so too do all the teachers have their best mediums. The important part is that you aren't insular, that you aren't contributing to the DevOps echo chamber. And honestly, stop with the excuses about why underrepresented people can't have access to systems, especially the excuse that is silence. Do you have any idea how hard it is to learn a technology with access to that technology? It's almost impossible. These are some words that I wrote on LinkedIn posts earlier this year. And they resonate now more than ever. So hopefully in this five minutes, I have taught well. Thank you again for having me. Remember feedback is love. Go forth and teach. I look forward to hearing about your success and failures throughout the year.