Aaron Aldrich

Tech support, government, and Linux, oh my!

Hi, My name is Aaron Aldrich. I was exposed to tech from a young age because my father had been in and around tech since the 90s. Every now and then, my dad had to bring something home so he could learn and understand it, which meant that I got to play with it as well. High school is where I really started getting into computers, but at that point in time I had to use dial up, there were only really four different computer options, and in order to get new parts I had to go to the computer fair that came by once a month. To me, it was more a side hobby, as I was looking into getting into music.

My mental health story and tech story collided when I went to college, because I had a lot of issues that sprung up surrounding my ADHD. I went to Berklee College of Music to study production engineering (of course, a techy major) and my primary instrument was the electric bass. However, I had a rough time going from my home environment to being all alone at school, so I ended up dropping out.

Eventually, I needed a way to make an income and not be entirely dependent on my parents while I was living at home. Lucky for me, I knew computers pretty well so I started doing inbound phone support for an ISP in the New York area. To be honest, this was soul-crushing work; no one calls for fun, everyone’s complaining, and you have to tell people to try restarting it. Every. Time.

I had to move on from there, so I ended up working tech for the U.S. District Courts in the federal court in Connecticut. That was a really interesting job from a company politics perspective, because the company was the actual government. There were many moments where I would want to use a specific technology, but it would’ve taken a literal act of Congress to use it.

Getting into the DevOps scene

After the courts, I worked at a metal company in Connecticut that was unique because they did everything on Linux. In the 80s they moved all their inventory systems and their DRP to mainframes in a custom written language because programming languages weren’t even a thing yet, and they had Linux boxes and terminals. I learned a whole bunch of cool, crazy Linux tricks when I was there because they had built all of these systems themselves and we used them to run the whole company. Learning Linux here is where I discovered DevOps as a concept, and I dove into it later in life after I recognized many of the practices from my time at the metal company.

Making new strides at DevOpsDays

I went to my first DevOpsDays in Colorado after being invited by a few different friends from different companies, and I immediately fell in love with the conference. I ended up crashing the speaker’s dinner, but it was great because everybody was friendly and I got to know everybody in the conference and make awesome initial connections. The community was and is always welcoming and community oriented. It felt like a group of peers contributing to a conversation and sharing their experiences more than someone just talking from a stage with a deck.

When I got home to Connecticut, I immediately tried and failed to find anything close to an established DevOps community, so I started one: that’s how DevOpsDays Hartford came to be. I ended up kind of becoming the name of DevOps in Connecticut, which led me to getting a job at Elastic as a developer advocate. This is where I got into the observability world, which was my subject matter expertise at the time. I was lucky enough to be there through their IPO, which was fantastic, and I stayed on there into 2020.

The path to Red Hat

After leaving Elastic, I was trying to find the right thing (and there was also a pandemic, which you may know about) but I eventually ended up at Red Hat. It has definitely been a long 2020.

Some of my first interactions with the DevOps side of Red Hat were at DevOpsDays Ghent in Belgium for the 10th anniversary of DevOpsDays in 2019. It was a unique experience because our entire community rarely gets to talk about what we do at scale since we’re used to doing it in our own little communities around the world.

This conference is where Andrew Clay Shafer, who kicked off the beginning of the DevOpsDays conferences, announced he was joining Red Hat to join the Global Transformation Office, which now also includes Jabe Bloom, Kevin Behr (one of the authors of The Phoenix Project), and John Willis, one of the authors of The DevOps Handbook—all awesome people. For me, this was an important moment: if these were the people that Red Hat was hiring and there was a solid plan (even if I didn’t know what it was), I was interested and wanted to know about it.

By the time the project was kicking off and they were forming a new team at a global office for managed OpenShift, which I’m now on, it was November 2020 (You can read more about this here). I got the job through connections and conversations I originally had in Ghent from knowing the people on the ground. I owe a lot of my career to DevOpsDays.

Life as a developer advocate

Being a developer advocate can mean a lot of different things at a lot of different companies. It requires finding the right fit to match your strengths with what that company wants out of that role; that is the main trick of it. For me, the developer advocate role has always been about projecting a company’s presence out into the community and working closely with the real people using the product.

Of course, part of this is being the face of the company and explaining how you think you can help and what your philosophies are. For example, at Elastic I was always sharing information about observability and why it was important to talk about it, how we use it, what the value of investing in observability is, etc. Then, if people agree, I can share how Elastic could help them, which is when you need to be able to convey the company value and get people on board for why they need your product.

The other side of this is that you can be really valuable on the internal company side as well, because you’re getting first hand information and feedback about how your product is received and what people think about it. In an interesting blog by my friend Austin Parker, who is a developer advocate at Lightstep, he talks a bit about the “celebrity” of the developer advocate role, which definitely isn’t always true. However, a small portion of it is continuing to keep up your personal brand that aligns with who you are so it’s not just a persona. You want it to be a two-way street: enhancing your brand while enhancing the company and working in harmony that way.

Philosophies around resilience and reliability

I’ve always loved people and having a very human approach to ops has always been a part of who I am and what I put out into the world. When you always work with computers, losing sight of the humans that are involved makes the whole point moot. Sometimes there's this thinking that if it weren’t for those pesky humans, all the computers would work perfectly, or that we can automate out human error. Well, there isn’t any “human error” because the only reason anything works at all is because humans figured out all those squishy bits around it that don’t make sense.

Humans are the only ones who can operate in a world of uncertainty because we have to make gut choices and decisions using emotions that computers can’t figure out. They need precise instructions, and sometimes things just break because systems are becoming increasingly complex and we can’t always predict the waterfall of issues that lead to, say, a server going down. It is more beneficial to learn from an incident that occurred rather than trying to find a root cause to blame on someone or one thing. The goal is ultimately to understand the many different nuances and interdependencies in your systems and how they influenced the outcomes so you can learn and evolve together.

It’s amazing how much “meta learning” occurs in this field, because as you learn how to recover from incidents and how communication is set, you are also learning about how information flows between engineers, teams, and different sectors of the organization.

Community now and into the future

It’s been an interesting year for the DevRel world because our standard operating procedure and our fallbacks disappeared in one fell swoop. Conferences all ended, and we had to figure out what to do next—moving to virtual conferences and community spaces was the first step. We wanted to be able to get together and share ideas, but we quickly found out that meeting virtually is a completely different animal. You miss out on the side conversations, the chance meetings, and all of the social moments that make in person so much better.

Austin Parker, who is truly amazing and clever, ran the Deserted Island DevOps Conference, which took place on the video game Animal Crossing. At the heart of it, it recreated some of the communal space that was lost when we had to shift on to Zoom. The conference is still digital, but because your avatars can reach out and interact, it feels a bit more personal. All of the speakers and people involved were all collaborating on this idea because it was fun and we wanted to make it happen—we made sure themes, fonts, and decks matched, which ended up meaning that they all vaguely matched Animal Crossing. No small part of the success of the conference was due to the fact the conference happened on Twitch, which is different from other webinar platforms because it’s specifically designed for community and social interaction; these tools that influencers and younger people use are actually really powerful for reaching people, and it was easy to see why people are using them.

The birth of Tabletop DevOps

I wanted to try something completely new to keep up the community within these online spaces, so I started trying to combine things that I like to do. I like board games, and I like DevOps, so I started streaming a thing called Tabletop DevOps on Twitch. For our first one at the end of December, we played a game of Werewolf (which is like Mafia, if you’ve heard of it by a different name) which is actually a DevOpsDays staple. It’s a great game for observing different social dynamics and information flow, which is why I love running games as opposed to participating because it is just so fun to watch what happens.

In bigger and brighter news as well, a few of us who have been streaming in the DevOps world are getting together and starting what we are calling Deserted Island TV. If you’re interested, come join us on our Discord! We are all going to combine into one Twitch channel so we can bring everyone along with us and get together. I think it will either be like a bunch of friends all hanging out and having fun, or maybe it will even be something new and interesting that changes the way we do DevRel, but either way I think it will be awesome. Right now with COVID and immense amounts of civil turmoil, we all need some fun stuff along with our work, so I want to take advantage of any way I can inject some joy inside the community.

Aaron recommends

I’ll give you a couple of recommendations. If you want to lean towards strategy, I’ve really enjoyed deck building type games, especially Clank! or Clank! In! Space! They’re a fantastic combination of a run-and-get-the-treasure-before-the-big-baddie-kills-you as well as having the strategic, deck building element.

If you want to go in more of a role play game direction, one I love is 10 Candles—it’s pretty small right now so you can either pay 10 bucks for the PDF of all the rules, or you can get a print edition. It’s a tragic horror RPG where all players work together to build a story, but it’s spooky and you will all die by the end. What it uncovers about people on the way is interesting because characters are flawed, they have moments that push them to the brink, but they also have moments that bring them hope. Stay tuned, we will probably play it again in the future on our Discord if you wanna play!