Developer Advocacy and Innersource with Aaron Clark

In this episode, we cover:

• Aaron talks about starting out as a developer and the early stages of cloud development at RBC (1:05)
• Aaron discusses transitioning to developer advocacy (12:25)
• Aaron identifies successes he had in his early days of developer advocacy (20:35)
• Jason asks what it looks like to assist developers in achieving completion with long term maintenance projects, or “sustainable development” (25:40) 
• Jason and Aaron discuss what “innersource” is and why it’s valuable in an organization (29:29)
• Aaron answers the question “how do you keep skills and knowledge up to date?” (33:55)
• Aaron talks about job opportunities at RBC (38:55)

Links Referenced:

• Royal Bank of Canada: https://www.rbcroyalbank.com
• Opportunities at RBC: https://jobs.rbc.com/ca/en

Transcript

Aaron: And I guess some PM asked my boss, “So, Aaron doesn’t come to our platform status meetings, he doesn’t really take tickets, and he doesn’t take support rotation. What does Aaron do for the Cloud Platform Team?”

Jason: [laugh].

Jason: Welcome to Break Things on Purpose, a podcast about reliability, learning, and building better systems. In this episode, we talk with Aaron Clark, Director of Developer Advocacy at the Royal Bank of Canada. We chat with him about his journey from developer to advocate, the power of applying open-source principles within organizations—known as innersource—and his advice to keep learning.

Jason: Welcome to the show, Aaron.

Aaron: Thanks for having me, Jason. My name is Aaron Clark. I’m a developer advocate for cloud at RBC. That is the Royal Bank of Canada. And I’ve been at the bank for… well, since February 2010.

Jason: So, when you first joined the bank, you were not a developer advocate, though?

Aaron: Right. So, I have been in my current role since 2019. I’ve been part of the cloud program since 2017. Way back in 2010, I joined as a Java developer. So, my background in terms of being a developer is pretty much heavy on Java. Java and Spring Boot, now.

I joined working on a bunch of Java applications within one of the many functions areas within the Royal Bank. The bank is gigantic. That’s kind of one of the things people sometimes struggle to grasp. It’s such a large organization. We’re something like 100,000… yeah, 100,000 employees, around 10,000 of that is in technology, so developers, developer adjacent roles like business analysts, and QE, and operations and support, and all of those roles.

It’s a big organization. And that’s one of the interesting things to kind of grapple with when you join the organization. So, I joined in a group called Risk IT. We built solely internal-facing applications. I worked on a bunch of stuff in there.

I’m kind of a generalist, where I have interest in all the DevOps things. I set up one of the very first Hudson servers in Risk—well, in the bank, but specifically in Risk—and I admin’ed it on the side because nobody else was doing it and it needed doing. After a few years of doing that and working on a bunch of different projects, I was occasionally just, “We need this project to succeed, to have a good foundation at the start, so Aaron, you’re on this project for six months and then you’re doing something different.” Which was really interesting. At the same time, I always worry about the problem where if you don’t stay on something for very long, you never learn the consequences of the poor decisions you may have made because you don’t have to deal with it.

Jason: [laugh].

Aaron: And that was like the flip side of, I hope I’m making good decisions here. It seemed to be pretty good, people seemed happy with it, but I always worry about that. Like, being in a role for a few years where you build something, and then it’s in production, and you’re running it and you’re dealing with, “Oh, I made this decision that seems like a good idea at the time. Turns out that’s a bad idea. Don’t do that next time.” You never learned that if you don’t stay in a role.

When I was overall in Risk IT for four, almost five years, so I would work with a bunch of the teams who maybe stayed on this project, they’d come ask me questions. It’s like, I’m not gone gone. I’m just not working on that project for the next few months or whatever. And then I moved into another part of the organization, like, a sister group called Finance IT that runs kind of the—builds and runs the general ledger for the bank. Or at least for a part of capital markets.

It gets fuzzy as the organization moves around. And groups combine and disperse and things like that. That group, I actually had some interesting stuff that was when I started working on more things like cloud, looking at cloud, the bank was starting to bring in cloud. So, I was still on the application development side, but I was interested in it. I had been to some conferences like OSCON, and started to hear about and learn about things like Docker, things like Kubernetes, things like Spring Boot, and I was like this is some really neat stuff.

I was working on a Spark-based ETL system, on one of the early Hadoop clusters at the bank. So, I’ve been I’m like, super, super lucky that I got to do a lot of this stuff, work on all of these new things when they were really nascent within the organization. I’ve also had really supportive leadership. So, like, I was doing—that continuous integration server, that was totally on the side; I got involved in a bunch of reuse ideas of, we have this larger group; we’re doing a lot of similar things; let’s share some of the libraries and things like that. That was before being any, like, developer advocate or anything like that I was working on these.

And I was actually funded for a year to promote and work on reuse activities, basically. And that was—I learned a lot, I made a lot of mistakes that I now, like, inform some of the decisions I make in my current role, but I was doing all of this, and I almost described it as I kind of taxed my existing project because I’m working on this team, but I have this side thing that I have to do. And I might need to take a morning and not work on your project because I have to, like, maintain this build machine for somebody. And I had really supportive leadership. They were great.

They recognize the value of these activities, and didn’t really argue about the fact that I was taking time away from whatever the budget said I was supposed to be doing, which was really good. So, I started doing that, and I was working in finance as the Cloud Team was starting to go through a revamp—the initial nascent Cloud Team at the bank—and I was doing cloud things from the app dev side, but at the same time within my group, anytime something surprising became broken, somebody had some emergency that they needed somebody to drop in and be clever and solve things, that person became me. And I was running into a lot of distractions in that sense. And it’s nice to be the person who gets to work on, “Oh, this thing needs rescuing. Help us, Aaron.”

That’s fantastic; it feels really good, right, up until you’re spending a lot of your time doing it and you can’t do the things that you’re really interested in. So, I actually decided to move over to the Cloud Team and work on kind of d...