Brad Maltz and Ryan Wallner have helped Dell build a team with a unique approach to open source development. By tightly integrating DevOps and DevRel, Dell puts community insights and the developer experience at the forefront of the product development process.
Tune in as Maltz and Wallner discuss why a strong DevOps practice requires cultural alignment, the benefits of establishing an open line of communication with the open source community, and why platform engineers need to be well-rounded.
Listen to the full Open at Intel podcast episode here. This conversation has been edited and condensed for brevity and clarity.
Developer Advocacy Is a Two-Way Street
Katherine Druckman: Will you tell us who you are and what you do?
Brad Maltz: I'm senior director of product management of the DevOps portfolio, and I also run DevRel at Dell. It’s mind-blowing to see two things come together. When we kicked off the product management side of the DevOps portfolio, I told everybody we needed a DevRel team to help us talk to the community in the right way. Enter folks like Ryan.
Ryan Wallner: I’m a lead developer advocate for Brad’s DevRel team. I've been involved in the Kubernetes space since the early days. I worked at the Office of the CTO at Dell EMC back in 2013 when I first started to explore containers. That led me to several different startups, working anywhere between evangelism, advocacy, and technical marketing roles. It ultimately led me here to help build something new and different at Dell.
Katherine Druckman: Ideas need to flow freely between the community and the product team. How do you approach something like that?
Brad Maltz: When we first created the function, I took a hardline stance that the number one priority for these folks is to advocate for the community back into Dell, not to evangelize Dell out to the community. We said 50 percent of your job is participating in the community because so many people ask why Dell has DevRel and want to know what we’re really doing in the community. But the inverse of it is, inside Dell, our organizations, like product management and product marketing, don't understand Kubernetes admins, platform engineers, and the DevOps folks. So the advocacy is an educational function. I'm finding my DevRel team is on a continuous educational journey, external as well as internal.
Ryan Wallner: Having a direct line of communication changes a lot. It's very hard, especially in larger companies, to change something that's been done one way for a long time. How do you break down those walls? Being able to bring new ideas back to our strategies and the way we develop and think about things—that's a big reason why I got excited about this role. The educational piece is different at Dell than smaller startups or greenfield companies that are starting with Kubernetes. We’re trying to bring in this heavyweight thing that's been around for a long time and change mindsets. Education is an integral part of how you change that mindset.
Starting a Successful DevOps Practice
Katherine Druckman: What advice would you give to a DevOps newcomer?
Ryan Wallner: Don’t start with the Kubernetes community. Bring it back to basics—what does DevOps mean to your organization, both technologically and culturally? Culture is important. You can’t just throw a bunch of DevOps tools at a team, and now you do DevOps. The way teams are set up and the way they understand how they’re providing value up the chain to the platform—the culture has to mimic what your goals are. I’d say start there. Start reading about DevOps and organizational changes. You can learn the technology if you’re willing to pick up new things and educate yourself. The organizational side is often the hardest part.
Brad Maltz: I come from a slightly different background, closer to the architecture and virtualization side of the space. Even back in the early virtualization and VMware days, it was always about trying to get multiple functions to work together, and it became a cultural DNA discussion. DevOps is on the same trajectory. It's always about DNA, empathy, and humility. You need to be able to compassionately understand somebody else's pain and pull that into the larger process and operating model. For somebody who needs to learn how to live in a best practices-led DevOps world, the social skills are huge. If you're not good at understanding somebody else's viewpoint and what they do on a daily basis—DevOps fails if you can’t fix that.
Katherine Druckman: How do you capture the needs and pain points of the developers who are using the systems you set up?
Brad Maltz: In the DevOps world, you have different functions, such as Kubernetes admins and infrastructure engineers. The people that manage the pipeline—the CI/CD environment, the developer tooling, all that type of stuff—have been living in the wild, wild west. CI/CD adds a few more guardrails. Now, we have Backstage and other Cloud Native Computing Foundation (CNCF) projects that give us a more standardized way to develop a catalog and a developer-led approach. We can finally put the developer experience into practice. The nuance here is, does that developer experience stop at the pipeline developer tooling? Or does it go all the way down to the infrastructure bits? That's the shift we're starting to make now. How do you keep bringing it down further into the stack?
Ryan Wallner: For me, there’s two sides of the coin. There’s the developer experience internally—how you’re developing and dogfooding your product and technology. Then there’s the end users who interact with the product. In the cloud-native community especially, the first-touch experience means a lot, and we should think about it both internally and externally because it differs.
The Rise of Platform Engineering
Katherine Druckman: Can you talk about the difference between platform engineering and DevOps?
Ryan Wallner: Platform engineering is a big topic. We’ve been doing this DevOps and cloud-native thing for a while, but the cloud-native piece comingles DevOps and platform engineering. Part of it is that we need a better way to do these things together. Often, two teams within the same company may do it differently. The idea behind platform engineering is to solidify common practices, the same way we did with DevOps practices, and give them an identity.
Becoming a Well-Rounded Platform Engineer
Katherine Druckman: What advice do you have for engineers who are building these platforms?
Brad Maltz: When you’re building a platform, you’re building a full-stack experience across hardware, compute, operating systems, hypervisors, storage, networking, security—all the way up through the developer tools. People getting into a platform engineering-style role must become a jack-of-all-trades. You don't have to go deep on everything, but when I say storage, do you understand the basics? You don't have to be a subject matter expert (SME). You’ll have some people who are more on the SME side of certain pieces, such as automation, networking, and storage. However, everybody should understand the developer-led approach to what the platform’s delivering.
I put a spin on it and say that on a platform engineering team, you’re now a product team. You’re building the product that IT has always talked about but never actually delivered because IT was always in firefight mode and was too busy spinning up new nodes and upgrading and patching things. Now, we have to flip the mindset. How do you lead with product management through an engineering mindset but as an IT organization? Your skill sets need to become requirements-led; learn Agile and soft skills along with the technical side.
Katherine Druckman: As people become hyper-focused on a specific technology, does anybody really understand the big picture anymore?
Ryan Wallner: You need that [big picture] mindset. When you develop an application and put it into the Kubernetes stack, it touches a lot of pieces. So, if you don't understand the complexities, you won’t necessarily understand where something may go wrong. You can’t just throw it over the wall like we used to. Now, we have to know at least enough about pieces like networking and storage to know what's going on with an application.
Brad Maltz: You have to know almost all the pieces. Maybe there is a gap there. When you look across the ecosystem of people, certifications, and training, it used to be very vendor-led. If I’m Cisco, I would say, who are my full-stack experts from Cisco? They were Cisco Certified Internetwork Experts (CCIEs). They had to know the entire portfolio, everything from security to network and load balancing. When you look at virtualization, they had their own certification that had to be VMware-based. In the Kubernetes and CNCF space, maybe that platform engineer, higher-level stamp of approval has not been created yet.
The Power of Abstraction
Katherine Druckman: In my mind, Kubernetes is the biggest success story since Linux. It’s almost ubiquitous. Do you have any thoughts on that?
Ryan Wallner: I think the abstraction of containers is what changed the mindset. We were thinking in terms of containers, which led us to yet another abstraction of Kubernetes running those containers. But really, we're focusing on what's in that container and what application I can develop across many containers. We sort of lose the concern about where it runs, and that's a big part of the success of containers, even though we still have a lot of other concerns. Can I run these as Windows containers? What does that look like on Windows Server? What does it look like on Linux? All these things together abstract your thinking, and you get away from just thinking about the base OS because a lot of these Linux distributions will run your container the same way. You sort of operate at a different level.
To hear more of this conversation and others, subscribe to the Open at Intel podcast:
- openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Your favorite podcast player (RSS)
About the Author
Katherine Druckman, Open Source Evangelist, Intel
Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she’s a longtime champion of open source and open standards.
Ryan Wallner, Lead Developer Advocate, Dell
Ryan Wallner is a lead developer advocate at Dell Technologies and host of the Kubernetes Bytes podcast. Ryan is a cloud-native and Kubernetes enthusiast, husband, and dad of a fearless daughter. Ryan enjoys adventure moto riding, hiking, and mountain biking.
Brad Maltz, Sr. Director of DevOps and Developer Relations Ecosystems, Dell
Brad Maltz is the senior director of DevOps and developer relations ecosystems at Dell Technologies, focusing on delivering DevOps technologies and a developer-oriented user experience with the Dell portfolio. He leads a team that is connecting Dell to the community to enable customers on their journey to becoming mature DevOps organizations. Brad has been in the industry for over twenty years, driving innovation and solutions across the strategic technology landscape. With experience across multiple verticals such as healthcare, finance, biotech, education, government, and manufacturing, Brad has been able to help customers with a multitude of problems up and down the technology stack.