Podcast: Break Things on Purpose | Developer Advocacy and Innersource with Aaron Clark

In this episode, Jason chats with Aaron Clark, Director of Developer Advocacy at the Royal Bank of Canada. Aaron shares what it was like starting out as a developer at RBC and working in early cloud development, and then transitioning to his role as a developer advocate. Jason and Aaron talk about the value applying open source principles within organizations, or “innersource.” Their time ends with a discussion on continuing education and how to keep learning.

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 defining how we build applications for the cloud, which was really—it was a really good time. It was a really early time in the bank, so nobody really knew how we were going to build applications, how we were going to put them on the cloud, what does that structure look like? I got to do a lot of reading and research and learning from other people. One of the key things about, like, a really large organization that’s a little slow-moving like the bank and is a little bit risk-averse in terms of technology choices, people always act like that’s always a bad thing.

And sometimes it is because we’re sometimes not adopting things that we would really get a lot of benefit out of, but the other side of it is, by the time we get to a lot of these technologies and platforms, a bunch of the sharp edges have kind of been sanded off. Like, the Facebooks and the Twitters of the world, they’ve adopted it and they’ve discovered all of these problems and been, like, duct-taping them together. And they’ve kind of found, “Oh, we need to have actual, like, security built into this system,” or things like that, and they’ve dealt with it. So, by the time we get to it, some of those issues are just not there anymore. We don’t have to deal with them.

Which is an underrated positive of being in a more conservative organization around that. So, we were figuring there’s a lot of things we could learn from. When we were looking at microservices and, kind of, Spring Boot Spring Cloud, the initial cloud parts that had been brought into the organization were mainly around Cloud Foundry. And we were helping some initial app teams build their applications, which we probably over-engineered some of those applications, in the sense that we were proving out patterns that you didn’t desperately need for building those applications. Like, you could have probably just done it with a web app and relational database and it would have been fine.

But we were proving out some of the patterns of how do you build something for broader scale with microservices and things like that. We learned a bunch about the complexities of doing that too early, but we also learned a bunch about how to do this so we could teach other application teams. And that’s kind of the group that I became part of, where I wasn’t a platform operator on the cloud, but I was working with dev teams, building things with dev teams to help them learn how to build stuff for cloud. And this was my first real exposure to that scope and scale of the bank. I’d been in the smaller groups and one of the things that you start to encounter when you start to interact with the larger parts of the bank is just, kind of, how many silos there are, how diverse the tech stacks are in an organization of that size.

Like, we have areas that do things with Java, we have areas doing things with .NET Framework, we have areas doing lots of Python, we have areas doing lots of Node, especially as the organization started building more web applications. While you’re building things with Angular and using npm for the front-end, so you’re building stuff on the back-end with Node as well. Whether that is a good technology choice, a lot of the time you’re building with what you have. Even within Java, we’d have teams building with Spring Boot, and lots of groups doing that, but someone else is interested in Google Guice, so they’re building—instead of Spring, they’re using Google Guice as their dependency injection framework.

Or they have a… like, there’s the mainframe, right? You have this huge technology stack where lots of people are building Java EE applications still and trying to evolve that from the old grungy days of Java EE to the much nicer modern ways of it. And some of the technology conversations are things like, “Well, you can use this other technology; that’s fine, but if you’re using that, and we’re using something else over here, we can’t help each other. When I solve a problem, I can’t really help solve it for you as well. You have to solve it for yourself with your framework.”

I talked to a team once using Vertex in Java, and I asked them, “Why are you using Vertex?” And they said, “Well, that’s what our team knew.” I was like, “That’s a good technology choice in the sense that we have to deliver. This is what we know, so this is the thing we know we can succeed with rather than actually learning something new on the job while trying to deliver something.” That’s often a recipe for challenges if not outright failure.

Jason: Yeah. So, it sounds like that’s kind of where you come in; if all these teams are doing very disparate things, right—

Aaron: Mm-hm.

Jason: That’s both good and bad, right? That’s the whole point of microservices is independent teams, everyone’s decoupled, more velocity. But also, there’s huge advantages—especially in an org the size of RBC—to leverage some of the learnings from one team to another, and really, like, start to share these best practices. I’m guessing that’s where you come into play now in your current role.

Aaron: Yeah. And that’s the part where how do we have the flexibility for people to make their own choices while standardizing so we don’t have this enormous sprawl, so we can build on things? And this is starting to kind of where I started really getting involved in community stuff and doing developer advocacy. And part of how this actually happened—and this is another one of those cases where I’ve been very fortunate and I’ve had great leaders—I was working as part of the Cloud Platform Team, the Special Projects group that I was, a couple of people left; I was the last one left. It’s like, “Well, you can’t be your own department, so you’re part of Cloud Platform.” But I’m not an operator. I don’t take a support rotation.

And I’m ostensibly building tooling, but I’m mostly doing innersource. This is where the innersource community started to spin up at RBC. I was one of the, kind of, founding members of the innersource community and getting that going. We had built a bunch of libraries for cloud, so those were some of the first projects into innersource where I was maintaining the library for Java and Spring using OIDC. And this is kind of predating Spring Security’s native support for OIDC—so Open ID Connect—

And I was doing a lot of that, I was supporting app teams who were trying to adopt that library, I was involved in some of the other early developer experience things around, you complain this thing is bad as the developer; why do we have to do this? You get invited to one of the VP’s regular weekly meetings to discuss, and now you’re busy trying to fix, kind of, parts of the developer experience. I was doing this, 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].

Aaron: And my boss was like, “Well, Aaron’s got a lot of these other things that he’s involved with that are really valuable.” One of the other things I was doing at this point was I was hosting the Tech Talk speaking series, which is kind of an internal conference-style talks where we get an expert from within the organization and we try to cross those silos where we find someone who’s a machine-learning expert; come and explain how TensorFlow works. Come and explain how Spark works, why it’s awesome. And we get those experts to come and do presentations internally for RBC-ers. And I was doing that and doing all of the support work for running that event series with the co-organizers that we had.

And at the end of the year, when they were starting up a new initiative to really focus on how do we start promoting cloud adoption rather than just people arrive at the platform and start using it and figure it out for themselves—you can only get so far with that—my boss sits me down. He says. “So, we really like all the things that you’ve been doing, all of these community things and things like that, so we’re going to make that your job now.” And this is how I arrived at there. It’s not like I applied to be a developer advocate. I was doing all of these things on the side and all of a sudden, 75% of my time was all of these side projects, and that became my job.

So, it’s not really the most replicable, like, career path, but it is one of those things where, like, getting involved in stuff is a great way to find a niche that is the things that you’re passionate about. So, I changed my title. You can do that in some of our systems as long as your manager approves it, so I changed my title from the very generic ‘Senior Technical Systems Analyst—which, who knows what I actually do when that’s my title—and I changed that to ‘Developer Advocate.’ And that was when I started doing more research learning about what do actual developer advocates do because I want to be a developer advocate. I want to say I’m a developer advocate.

For the longest time in the organization, I’m the only person in the company with that title, which is interesting because then nobody knows what to do with me because I’m not like—am I, like—I’m not a director, I’m not a VP. Like… but I’m not just a regular developer, either. Where—I don’t fit in the hierarchy. Which is good because then people stop getting worried about what what are titles and things like that, and they just listen to what I say. So, I do, like, design consultations with dev teams, making sure that they knew what they were doing, or were aware of a bunch of the pitfalls when they started to get onto the cloud.

I would build a lot of samples, a lot of docs, do a lot of the community engagement, so going to events internally that we’d have, doing a lot of those kinds of things. A lot of the innersource stuff I was already doing—the speaking series—but now it was my job formally, and it helped me cross a lot of those silos and work very horizontally. That’s one of the different parts about my job versus a regular developer, is it’s my job to cover anything to do with cloud—that at least, that I find interesting, or that my boss tells me I need to work at—and anything anywhere in the organization that touches. So, a dev team doing something with Kubernetes, I can go and talk to them. If they’re building something in capital markets that might be useful, I can say, “Hey, can you share this into innersource so that other people can build on this work as well?”

And that was really great because I develop all of these relationships with all of these other groups. And that was, to a degree, what the cloud program needed from me as well at that beginning. I explained that this was now my job to one of my friends. And they’re like, “That sounds like the perfect job for you because you are technical, but you’re really good with people.” I was like, “Am I? I guess I am now that I’ve been doing it for this amount of time.”

And the other part of it as we’ve gone on more and more is because I talk to all of these development teams, I am not siloed in, I’m not as tunneled on the specific thing I’m working with, and now I can talk to the platform teams and really represent the application developer perspective. Because I’m not building the platform. And they have their priorities, and they have things that they have to worry about; I don’t have to deal with that. My job is to bring the perspective of an application developer. That’s my background.

I’m not an operator; I don’t care about the support rotation, I don’t care about a bunch of the niggly things and toil of the platform. It’s my job, sometimes, to say, hey, this documentation is well-intentioned. I understand how you arrived at this documentation from the perspective of being the platform team and the things that you prioritize and want to explain to people, but as an application developer, none of the information that I need to build something to run on your platform is presented in a manner that I am able to consume. So, I do, like, that side as well of providing customer feedback to the platform saying, “This thing is hard,” or, “This thing that you are asking the application teams to work on, they don’t want to care about that. They shouldn’t have to care about this thing.” And that sort of stuff.

So, I ended up being this human router are sometimes where platform teams will say, “Do you know anybody who’s doing this, who’s using this thing?” Or finding one app team and say, “You should talk to that group over there because they are also doing the same thing, or they’re struggling with the same thing, and you should collaborate.” Or, “They have solved this problem.” Because I don’t know every single programming language we use, I don’t know all of the frameworks, but I know who I asked for Python questions, and I will send teams to that person. And part of that, then, as I started doing this community work was actually building community.

One of the great successes was, we have a Slack channel called ‘Cloud Adoption.’ And that was the place where everybody goes to ask their questions about how do I do this thing to put something on Cloud Foundry, put it on Kubernetes? How do I do this? I don’t understand. And that was sometimes my whole day was just going onto that Slack channel, answering questions, and being very helpful and trying to document things, trying to get a feel for what people were doing.

It was my whole day, sometimes. It took a while to get used to that was actually, like, a successful day coming from a developer background. I’m used to building things, so I feel like success because I built something I can show you, that I did this today. And then I’d have days where I talked to a bunch of people and I don’t have anything I can show you. That was, like, the hard part of taking on this role.

But one of the big successes was we built this community where it wasn’t just me. Other people who wanted to help people, who were just developers on different dev teams, they’d see me ask questions or answer questions, and they would then know the answers and they’d chime in. And as I started being tasked with more and more other activities, I would then get to go—I’d come back to Slack and see oh, there’s a bunch of questions. Oh, it turns out, people are able to help themselves. And that was—like that’s success from that standpoint of building community.

And now that I’ve done that a couple times with Tech Talks, with some of the developer experience work, some of the cloud adoption work, I get asked internally how do you build community when we’re starting up new communities around things like Site Reliability Engineering. How are we going to do that? So, I get—and that feels weird, but that’s one of the things that I have been doing now. And as—like, this is a gigantic role because of all of the scope. I can touch anything with anyone in cloud.

One of the scope things with the role, but also with the bank is not only do we have all these tech stacks, but we also have this really, really diverse set of technical acumen, where you have people who are experts already on Kubernetes. They will succeed no matter what I do. They’ll figure it out because they’re that type of personality, they’re going to find all the information. If anything, some of the restrictions that we put in place to manage our environments and secure them because of the risk requirements and compliance requirements of being a regulated bank, those will get in the way. Sometimes I’m explaining why those things are there. Sometimes I’m agreeing with people. “Yeah, it sucks. I don’t want to have to do this.”

But at the same time, you’ll have people who they just want to come in, write their code, go home. They don’t want to think about technology other than that. They’re not going to go and learn things on their own necessarily. And that’s not the end of the world. As strange as that sounds to people who are the personality to be constantly learning and constantly getting into everything and tinkering, like, that’s me too, but you still need people to keep the lights on, to do all of the other work as well. And people who are happy just doing that, that’s also valuable.

Because if I was in that role, I would not be happy. And someone who is happy, like, this is good for the overall organization. But the things that they need to learn, the things they need explained to them, the help they need for success is different. So, that’s one of the challenges is figuring out how do you address all of those customers? And sometimes even the answer for those customers is—and this is one of the things about my role—it’s like the definition is customer success.

If the application you’re trying to put on cloud should not go on cloud, it is my job to tell you not to put it on cloud. It is not my job to put you on cloud. I want you to succeed, not just to get there. I can get your thing on the cloud in an afternoon, probably, but if I then walk away and it breaks, like, you don’t know what to do. So, a lot of the things around how do we teach people to self-serve, how do we make our internal systems more self-serve, those are kind of the things that I look at now.

How do I manage my own time because the scope is so big? It’s like, I need to figure out where I’m not moving a thousand things forward an inch, but I’m moving things to their completion. And I am learning to, while not managing people, still delegate and work with the community, work with the broader cloud platform group around how do I let go and help other people do things?

Jason: So, you mentioned something in there that I think is really interesting, right, the goal of helping people get to completion, right? And I think that’s such an interesting thing because I think as—in that advocacy role, there’s often a notion of just, like, I’m going to help you get unstuck and then you can keep going, without a clear idea of where they’re ultimately heading. And that kind of ties back into something that you said earlier about starting out as a developer where you build things and you kind of just, like, set it free, [laugh] and you don’t think about, you know, that day two, sort of, operations, the maintenance, the ongoing kind of stuff. So, I’m curious, as you’ve progressed in your career, as you’ve gotten more wisdom from helping people out, what does that look like when you’re helping people get to completion, also with the mindset of this is an application that’s going to be running for quite some time. Even in the short term, you know, if it’s a short-term thing, but I feel like with the bank, most things probably are somewhat long-lived. How do you balance that out? How do you approach that, helping people get to done but also keeping in mind that they have to—this app has to keep living and it has to be maintained?

Aaron: Yeah, a lot of it is—like, the term we use is sustainable development. And part of that is kind of removing friction, trying to get the developers to a point where they can focus on, I guess, the term that’s often used in the industry is their inner loop. And it should come as no surprise, the bank often has a lot of processes that are high in friction. There’s a lot of open a ticket, wait for things. This is the part that I take my conversations with dev teams, and I ask them, “What are the things that are hard? What are the things you don’t like? What are the things you wish you didn’t have to do or care about?”

And some of this is reading between the lines when you talk to them; it’s not so much interviewing them. Like, any kind of requirements gathering, usually, it’s not what they say, it’s what they talk about that then you look at, oh, this is the problem; how do we unstuck that problem so that people can get to where they need to be going? And this kind of informs some of my feedback to the systems we put in place, the processes we put in place around the platform, some of the tooling we look at. I really, really love the philosophy from Docker and Solomon Hykes around, “Batteries included but removable.” I want developers to have a high baseline as a starting point.

And this comes partly from my experience with Cloud Foundry. Cloud Foundry has a really great out-of-the-box dev experience for lots of things where, “I just have a web app. Just run it. It’s Nginx; it’s some HTML pages; I don’t need to know all the details. Just make it go and give me the URL.”

And I want more of that for app teams where they have a high baseline of things to work with as a starting point. And kind of every organization ends up building this, where they have—like, Netflix: Netflix OSS or Twitter with Finagle—where they have, “Here’s the surrounding pieces that I want to plug in that everybody gets as a starting point. And how do we provide security? How do we provide all of these pieces that are major concerns for an app team, that they have to do, we know they have to do?” Some of these are things that only start coming up when they’re on the cloud and trying to provide a lot more of that for app teams so they can focus on the business stuff and only get into the weeds when they need to.

Jason: As you’re talking about these frameworks that, you know, having this high quality or this high baseline of tools that people can just have, right, equipping them with a nice toolbox, I’m guessing that the innersource stuff that you’re working on also helps contribute to that.

Aaron: Oh, immensely. And as we’ve gone on and as we’ve matured, our innersource organization, a huge part of that is other groups as well, where they’re finding things that—we need this. And they’ll put—it originally it was, “We built this. We’ll put it into innersource.” But what you get with that is something that is very targeted and specific to their group and maybe someone else can use it, but they can’t use it without bending it a little bit.

And I hate bending software to fit it. That’s one of the things—it’s a very common thing in the corporate environment where we have our existing processes and rather than adopting the standard approach that some tool uses, we need to take it and then bend it until it fits our existing process because we don’t want to change our processes. And that gets hard because you run into weird edge cases where this is doing something strange because we bent it. And it’s like, well, that’s not its fault at that point. As we’ve started doing more innersource, a lot more things have really become innersource first, where groups realize we need to solve this together.

Let’s start working on it together and let’s design the API as a group. And API design is really, really hard. And how do we do things with shared libraries or services. And working through that as a group, we’re seeing more of that, and more commonly things where, “Well, this is a thing we’re going to need. We’re going to start it in innersource, we’ll get some people to use it and they’ll be our beta customers. And we’ll inform it without really specifically targeting an application and an app team’s needs.”

Because they’re all going to have specific needs. And that’s where the, like, ‘included but removable’ part comes in. How do we build things extensibly where we have the general solution and you can plug in your specifics? And we’re still—like, this is not an easy problem. We’re still solving it, we’re still working through it, we’re getting better at it.

A lot of it’s just how can we improve day-over-day, year-over-year, to make some of these things better? Even our, like, continuous integration and delivery pipelines to our to clouds, all of these things are in constant flux and constant evolution. We’re supporting multiple languages; we’re supporting multiple versions of different languages; we’re talking about, hey, we need to get started adopting Java 17. None of our libraries or pipelines do that yet, but we should probably get on that since it’s been out for—what—almost a year? And really working on kind of decomposing some of these things where we built it for what we needed at the time, but now it feels a bit rigid. How do we pull out the pieces?

One of the big pushes in the organization after the log4j CVE and things like that broad impact on the industry is we need to do a much more thorough job around software supply chain, around knowing what we have, making sure we have scans happening and everything. And that’s where, like, the pipeline work comes in. I’m consulting on the pipeline stuff where I provide a lot of customer feedback; we have a team that is working on that all full time. But doing a lot of those things and trying to build for what we need, but not cut ourselves off from the broader industry, as well. Like, my nightmare situation, from a tooling standpoint, is that we restrict things, we make decisions around security, or policy or something like that, and we cut ourselves off from the broader CNCF tooling ecosystem, we can’t use any of those tools. It’s like, well, now we have to build something ourselves, or—which we’re never going to do it as well as the external community. Or we’re going to just kind of have bad processes and no one’s going to be happy so figuring out all of that.

Jason: Yeah. One of the things that you mentioned about staying up to speed and having those standards reminds me of, you know, similar to that previous experience that I had was, basically, I was at an org where we said that we’d like to open-source and we used open-source and that basically meant that we forked things and then made our own weird modifications to it. And that meant, like, now, it wasn’t really open-source; it was like this weird, hacked thing that you had to keep maintaining and trying to keep it up to date with the latest stuff. Sounds like you’re in a better spot, but I am curious, in terms of keeping up with the latest stuff, how do you do that, right? Because you mentioned that the bank, obviously a bit slower, adopting more established software, but then there’s you, right, where you’re out there at the forefront and you’re trying to gather best practices and new technologies that you can use at the bank, how do you do that as someone that’s not building with the latest, greatest stuff? How do you keep that skills and that knowledge up to date?

Aaron: I try to do reading, I try to set time aside to read things like The New Stack, listen to podcasts about technologies. It’s a really broad industry; there’s only so much I can keep up with. This was always one of the conversations going way back where I would have the conversation with my boss around the business proposition for me going to conferences, and explaining, like, what’s the cost to acquire knowledge in an organization? And while we can bring in consultants, or we can hire people in, like, when you hire new people in, they bring in their pre-existing experiences. So, if someone comes in and they know Hadoop, they can provide information and ideas around is this a good problem to solve with Hadoop? Maybe, maybe not.

I don’t want to bet a project on that if I don’t know anything about Hadoop or Kubernetes or… like, using something like Tilt or Skaffold with my tooling. That’s one of the things I got from going to conferences, and I actually need to set more time aside to watch the videos now that everything’s virtual. Like, not having that dedicated week is a problem where I’m just disconnected and I’m not dealing with anything. When you’re at work, even if KubeCon’s going on or Microsoft Build, I’m still doing my day-to-day, I’m getting Slack messages, and I’m not feeling like I can just ignore people. I should probably block out more time, but part of how I stay up to date with it.

It’s really doing a lot of that reading and research, doing conversations like this, like, the DX Buzz that we invited you to where… I explained that event—it’s adjacent to internal speakers—I explained that as I was had a backlog of videos from conferences I was not watching, and secretly if I make everybody else come to lunch with me to watch these videos, I have to watch the video because I’m hosting the session to discuss it, and now I will at least watch one a month. And that’s turned out to be a really successful thing internally within the organization to spread knowledge, to have conversations with people. And the other part I do, especially on the tooling side, is I still build stuff. As much as, like, I don’t code nearly as much as I used to, I bring an application developer perspective, but I’m not writing code every day anymore.

Which I always said was going to be the thing that would make me miserable. It’s not. I still think about it, and when I do get to write code, I’m always looking for how can I improve this setup? How can I use this tool? Can I try it out? Is this better? Is this smoother for me so I’m not worrying about this thing?

And then spreading that information more broadly within the developer experience group, our DevOps teams, our platform teams, talking to those teams about the things that they use. Like, we use Argo CD within one group and I haven’t touched it much, but I know they’ve got lots of expertise, so talking to them. “How do you use this? How is this good for me? How do I make this work? How can I use it, too?”

Jason: I think it’s been an incredible, [laugh] as you’ve been chatting, there are so many different tools and technologies that you’ve mentioned having used or being used at the bank. Which is both—it’s interesting as a, like, there’s so much going on in the bank; how do you manage it all? But it’s also super interesting, I think, because it shows that there’s a lot of interest in just finding the right solutions and finding the right tools, and not really being super-strongly married to one particular tool or one set way to do things, which I think is pretty cool. We’re coming up towards the end of our time here, so I did want to ask you, before we sign off, Aaron, do you have anything that you’d like to plug, anything you want to promote?

Aaron: Yeah, the Cloud Program is hiring a ton. There’s lots of job openings on all of our platform teams. There’s probably job openings on my Cloud Adoption Team. So, if you think the bank sounds interesting—the bank is very stable; that’s always one of the nice things—but the bank… the thing about the bank, I originally joined the bank saying, “Oh, I’ll be here two years, and I’ll get bored and I’ll leave,” and now it’s been 12 years and I’m still at the bank. Because I mentioned, like, that scope and scale of the organization, there’s always something interesting happening somewhere.

So, if you’re interested in cloud platform stuff, we’ve got a huge cloud platform. If you’re in—like, you want to do machine-learning, we’ve got an entire organization. It should come as no surprise, we have lots of data at a bank, and there’s a whole organization for all sorts of different things with machine-learning, deep learning, data analytics, big data, stuff like that. Like, if you think that’s interesting, and even if you’re not specifically in Toronto, Canada, you can probably find an interesting role within the organization if that’s something that turns your crank.

Jason: Awesome. We’ll post links to everything that we’ve mentioned, which is a ton. But go check us out, gremlin.com/podcast is where you can find the show note for this episode, and we’ll have links to everything. Aaron, thank you so much for joining us. It’s been a pleasure to have you.

Aaron: Thanks so much for having me, Jason. I’m so happy that we got to do this.

Jason: For links to all the information mentioned, visit our website at gremlin.com/podcast. If you liked this episode, subscribe to the Break Things on Purpose podcast on Spotify, Apple Podcasts, or your favorite podcast platform. Our theme song is called Battle of Pogs by Komiku and is available on loyaltyfreakmusic.com.