AJ Oller: [00:00:00] So I guess I would start off by saying the idea that there isn't cool tech happening in insurance is categorically false. But I would say the base skill set in the engineering side of the organization is systems administration. Hands down a Linux admin and a windows admin skill set will take you very far.

And I, maybe I sound old fashioned in saying that, but that is your base. Folks look at regulations as something that might hold you back. But in reality, they're there to keep you from messing up. So I think there's a very human aspect to engineering that might go unnoticed. I won't say that it does, but it might go unnoticed if your focus is purely tech.

Ashish Rajan: If you're working in the insurance space trying to figure out how do you go through multiple digital transformations, How do you even look at cloud infrastructure platform? What's required to start off even doing these things or even understanding these teams so you can help your business scale faster in a compliance driven world like insurance.

I had the pleasure of talking to AJ Oller, who is the AVP of engineering at the Hartford, a very popular insurance company. And he was shared some time with [00:01:00] us at HashiConf in Boston. We spoke about how insurance industry, as a lot of people may assume that due to regulation, compliance, they may not be able to adopt technology that quickly but we realize actually the reason for this is maybe a lot more simpler than that.

And I think it's a very valuable conversation for us to hear the engineering side of building the platform team with security compliance in an insurance world. I hope you enjoyed this conversation with AJ Oller from Hartford. By the way, if you have been listening to Cloud Security Podcast on Apple, Spotify, I would really appreciate if you give us a review or rating

it definitely helps more people know what the work we're doing here to bridge the gap between engineering, developers, builders, and cloud. If you're watching on YouTube or LinkedIn, just hit the subscribe and follow button so you can show support to the work we do as well. I appreciate all the support and love that you showed us at the HashiConf as well.

I look forward to seeing you at the next conference as well. In the meanwhile, I hope you enjoy this episode. I'll talk to you soon.

Hey everyone, we are at HashiCon Boston. This is the 10th HashiCon, who would have known. And we get to talk to AJ. Welcome to the show AJ, thanks for coming in man.

AJ Oller: Thank you for having me.

Hey everybody, my name is AJ Oller. I am AVP of [00:02:00] engineering at the Hartford. Responsible for our IAC platforms and solutions, along with our platform as a service, web and app hosting space, VDI infrastructure, middleware and integration layers, document management and managed file transfer. Just summarize it as one short sentence, right?

Ashish Rajan: And to help us summarize all of this as well, because the battle has been between the three top cannoli places in Boston and it's a blind test. You get to try each one of them and pick your favorite. You can finish the one you really like the most. Obviously that's the sign for us to choose for your favorite.

Even I don't know except for the producer, which one is which, but I know for sure we have one is from Modern bakery. One is from Mike's pastry and the other one is from Bova ,all of them very well known. Which one would you want to start first with?

AJ Oller: We'll go biggest to smallest and then I'll whichever one is the best one, I'll finish eating that one.

All right we'll be fine. All right, let's, I'll let you dig in. All right, we're going to try here first. It's a, it's very flaky.

Ashish Rajan: Oh even the flakiness as well. Describe what you're eating and what you feel like.[00:03:00]

Oh, he seems satisfied.

AJ Oller: Like speechless. So there's a good crunch here. Very creamy on the inside. I'm not going to rate this one, but it's very good. Yeah. Oh, all right.

Ashish Rajan: Next one. It is. We're going for the medium sized one now. All right.

I love how your eyebrows just went oh. Okay. All right. How would you describe the flakiness on this one?

AJ Oller: Less flaky, more crunchy. And not as sweet. So this one's a little bit lighter. Oh, this one's sweeter and crunchier. And this one's crunchier, but this one's flakier.

Oh. Okay's a good, interesting one. Okay, let's see. This one has pow, like this has powdered sugar on top. Oh. And it has a little bit of give. Oh. This one is not as crunchy or as flaky. Yeah. . Oh

Ashish Rajan: wait, I'm guessing. I think I know which one is that because I think that anyway, I'll let you finish it, but so that's your favorite

AJ Oller: Yes, and the reason why and I don't know I guess this might be controversial. So don't come [00:04:00] for me in the comments But it's because it's crunchy, but it's light and the consistency of the I guess the filling.

Yeah is just very like whipped airy. It's really good

Ashish Rajan: Wait, I'm gonna guess which one this is and the producer can nod is just the one That's the Bova. The moment you mentioned it's not too rich. That was my clue. I'm like, oh yeah, that's definitely.

AJ Oller: This one's good. So

Ashish Rajan: this is the one that is open 24 7, by the way.

AJ Oller: Oh, so I'm grabbing one before I go back. I like this. I wouldn't wait in line for that. Yeah. But this one I would. This one I would wait in line for. It's just so big. So maybe you could share that between you and some friends. Yeah.

Ashish Rajan: You definitely want to have the whole thing.

AJ Oller: This one you can have on your own.

Ashish Rajan: Alright, we're gonna bring that Jenga into the picture then. Now that we know a bit about yourself and what you're doing in the insurance space, I want to start by saying this I think we have an audience, which is a lot of platform people, cybersecurity people, the general rep for insurance world seems to be that it's not that forward in terms of technology.

And they could be multiple reasons because it's regulatory or in terms [00:05:00] of whether there has been not been many changes in that space. And that's why they don't have to be technology first, but here we are, we were talking about this earlier that you guys are IaC, automation, that's like things you're working on.

Give me a bit lowdown on the insurance tech space as you see it. And where does automation fit into all of this?

AJ Oller: So I guess I would start off by saying the idea that there isn't cool tech happening in insurance is categorically false. I don't know where the stigma comes from. Maybe it's because insurance companies are old and then big conglomerates.

And while those things are true we do heavily invest in our technology, whether it's automation, new things that are coming AI, some not so new things anymore, like IOT. There are applications for technology that could really be applied in insurance across the board. There's technology internally, right?

So like your kind of corporate technology provide, but also to your end users and your customers. And then also like, when you think of like our telephony system, so it when you think of the whole customer experience, there's [00:06:00] technology embedded into each part of that. And for us, that means investments over, the last, 20, 30 years into that technology.

So I would say that's categorically false.

Ashish Rajan: Because I guess a lot of people may not even be aware of what happens and be like everyone probably understand , oh I have a car insurance. I have whatever workers compensation. There's multiple kinds of products. So what we define as some of the newer form of technology that we are seeing in the insurance tech industry as a whole?

AJ Oller: There is a mainframe component that's at the heart of about every insurance or financial services company.

That you can think of largely because the computing power off of mainframe for the large data sets that we feed it is still unmatched, right? And like we look forward to the day where that might change, but you shouldn't look at the mainframe as something that's holding you back or anchoring you to your data center because now we know that you have options to move your mainframe off premise, you have opportunities to co locate your mainframe and sometimes you [00:07:00] share facilities if that's what makes sense for you.

So your mainframe isn't something that should be locking you in when you have a solid digital strategy of what you build around it. So when you talk about. Let's say COBOL to other machine languages. That's your first kind of translation or transformation that you can make and then start to build integration layers around that.

Parts of my team specialize in exactly that. Wow. So that's their bread and butter that really enables other applications internally to talk to each other. And if you could think of the core of rating and data crunching and price crunching happening in the mainframe.

Yeah. But it's not being served up on a green screen to our end customers, right? Or even some of the internal folks. So then you build applications around that feed of data that can then present that to an end user. So whether that's a claim system, a billing system, a telephony system that helps folks really get the insurance that they need but yeah, that's ultimately what we build behind at the end result, but your mainframe isn't necessarily holding you back, so I think that's something [00:08:00] that is also starting to shift. The way that we think about mainframe and it's placed in your I. T. estate, and then automating around that is really what it looks like. Not to say there is automation on mainframe, so that's definitely happening, but the rest of the I. T. real estate where you talk about your web, app, database layers, integrations around network security, I think that's where we introduce more automation because one, the technology lends itself to it, but also you see heavy investments in that space. That the industry is putting forward that help you, essentially meet them where they're at.

Yeah. And so that's how I look at the overall landscape where there's automation being injected into each part of the stack. And if you have a holistic strategy about where you're going, it definitely helps you not have to build it more than once.

Ashish Rajan: Interesting. And talk about, your IT estate

We have Jenga in front of us, which is a quietly set up a state for us as well. I just say, you have a production environment. Let's just say you've clearly explained to me the rules now that I would play the right way. Actually you should make the first move. Consider that you're a [00:09:00] pro in this. I'll let you make the first move.

Cause I feel like it's like chess. The first move can make the difference. So I'll let you kick it off. All right.

AJ Oller: I will try and not sabotage you, even though that might be a strategy. I'm going to go right here.

Ashish Rajan: Oh. Oh, wow. Okay. That I thought that was going to definitely good job, man. I think it's just going to be I think when I feel like I should take this one out, I can barely see it. So we're doing it quicker as well. As you can tell. And this is,

oh, you got that. Okay. You use the technique. I showed you,

you gave me good points.

AJ Oller: A little thigh tap. Oh, good job. Gotta get my pinky in there first. My index finger's a little too big. Oh, I lost. Wait, is that? I touched another one, inadvertently. So did I intentionally lose? No, but honor system here.

Ashish Rajan: We're flexible. I'm [00:10:00] playing with the first step. I'm gonna pretend I don't know the rules.

So I'll let you pull that out. Oh, that's a clean, that's a clean one out. Alright, I'm gonna take out one more and then we'll go back to questions.

Is this coming out? Oh, that's a good one. Oh, you can feel the weight of the thing as well coming off. All right. We're in HashiCon. We talk about platform this, platform that.

How do you define platform? Because a lot of people don't even know what a platform is.

AJ Oller: I would say a set of capabilities that abstract decision making from its consumers. Okay. To provide value, right? So I have a platform as a service organization in that we have, your web, app, integration layers.

You'd have Kubernetes platforms, you have your infrastructure as code platforms, essentially, they all serve up a function of sorts. Yeah. And we try and package that together as much as a black box as we can. Not because we're holding anything behind the curtain, but because we think that these are not value add decisions for your day to day developers, right?

Choosing what [00:11:00] versions of a particular app server that you need is while yes, you do need to know. Can I give you something a little bit more generic and then go from there? I would say yes. And so for me a platform as a service model, when you think of when you go up the stack, everything below is prescriptive.

So when I think of like bare bones IaaS right. That you're procuring compute, whether that's a container, whether that's a VM on prem or in the cloud, if I move a layer up and I say that, Hey, I'm going to do platform as a service now I need compute what's running on that compute bundled together, provided to me as a service.

That's right. And that could be white glove. That could be self service. That's up to how your organization wants to go about it. But that's how I would define platform.

Ashish Rajan: And. As someone who's building a platform or is thinking of building a platform, is there a nuance to specific challenges in the insurance or I guess the regulated industry in terms of the people need to cater for Oh, okay.

So if I'm [00:12:00] building a PaaS for a better word, a platform as a service. I need to be able to have this kind of skill set in my team. I need to have these kind of capabilities in my team. What are some of the things you look at from that perspective for people to start working on it?

AJ Oller: But I would say the base skill set in the engineering side of the organization is systems administration.

Hands down a Linux admin and a Windows admin skill set will take you very far. And maybe I sound old fashioned in saying that, but that is your base, right? Knowing how the operating systems function, I think is your door in. And when I talk to kids that are still in college and they're like, oh, where should I start?

I said, you will never go wrong by understanding an OS. Because that becomes like your building block to what goes on top of that. So it's imagine trying to understand Kubernetes, but you don't know Linux. Oh, it's not going to happen. Yeah, it's not going to happen. And so I do think that, so those skill sets build on top of each other.

So the first thing I will say is your base operating system skill set, the very next one I then think becomes. Some level of scripting and automation. You still don't [00:13:00] have to learn, tools like Puppet, Chef, or Ansible, or anything like that. But understanding how do you automate things bare bones, either PowerShell or Shell, or, and, languages like Python definitely help, but that becomes your next level up, is understanding how to scale things through automation that you would have done manually.

And you can keep all of this in context to like systems administration. Like we're still in the OS, right? Yeah. They haven't built anything on top of that. I say those are like your first two, like bare bones skill set that everyone has across the board. Then you go a layer up and think about, all right.

What tooling can help me do this in a way that scales a little bit better for a large scale enterprise? And that's where I think you're like configuration management tools come in Puppet, Chef, Ansible to essentially create that consistent layer of applying automation across the board. Yeah, now you take that one step further now I get into the image creation terraform space where now I can definitively recreate an OS process over and over.

Now I'm ready to feed that to an image. [00:14:00] And then I'm finally able to take that image and then say this is golden, I'm going to put that on the shelf. And everyone can prescriptively grab this. I think that becomes like the skill path within the organization that everyone really needs to have across the board.

And then how good are you at those different pieces? I think that's where you start to really differentiate yourself.

Ashish Rajan: Would you say anyone and everyone who's starting today would need a platform team or a platform capability? In terms of if I've never done building of automation, building of platform, and I'm starting today, I hear go, and AJ sounds super awesome.

I want to do automation. So should they be going straight for the platform team on building a platform? Or should they, is there like a maturity for, hey, you know what, level one is this and level five is when you start thinking about platform as a, some kind of a thinking around that from your perspective.

And so we've done this in the regulated space?

AJ Oller: So I'd say depends. So if you are a small company that has relatively simple objectives, relatively [00:15:00] simple IT infrastructure space. You could decide that, hey, this is a skill set that every developer should have. And you end up in like a system team model where every developer has IAC and automation skills.

They also understand the OS and they're essentially your full stack developer. Depending on your organization, I don't think that's a bad trade off to make. Now, what we see is that the bigger you scale a company, the bigger you scale an operation. Now, our developers have so much on their plate that some of these infrastructure activities start to fall by the wayside.

Whether it's patching, whether it's lifecycle management, those kind of day two and day three operations become a little bit harder to do if it's not fully automated. And you've done some of it like piecemeal automation, and then you've built some more stuff that's custom manually on top.

That's where I think it becomes difficult for a small shop of developers to manage it all. But if you think of a strategy that's automation first I do think it's totally possible for a small shop to not need a platform team. Now the platforms themselves depending if, they're not all SaaS [00:16:00] solutions need care and feeding as well.

So that's for the example of you have Ansible, you have Terraform, those exist as standalone platforms. That need their own OS patching that need their own life cycle management for the versions that they're running on and bug fixes and those things. So now without a platform team, how does your developer who's responsible for getting business features out of the door?

Prioritize the patching of an automation system?

Ashish Rajan: It should not be a question for them at all

AJ Oller: Yeah, and so that's where I think a platform team brings a lot of value especially at scale where we start to see I need a team to care and feed the platform And if it's a SaaS maybe not so much, but you generally still need someone to administer it at scale and then how do I provide that to developers in a standardized way because What could happen, I'm not going to say it's guaranteed to happen every time, but almost every time is without prescriptive guardrails, everyone starts to create a snowflake.

Even though you could have a set pattern architecturally, folks can go after that in different ways. And I think that's the value that a [00:17:00] platform team brings is saying, here's the prescriptive way to build a three tier application in our company. And if you talk to the big unicorns, everyone doesn't build whatever they want in whatever language they want.

That does not happen, right? And I think that's the value you have of standards and like standardization around a platform and a platform team to then empower developers to really focus on delivering business value as opposed to, making technology for technology sake decisions.

Ashish Rajan: Oh, Fair. Talking about guardrails. Sure. I'm gonna, I think it's my move. Ah, there you go. I got mine.

AJ Oller: Alright, we're gonna spice things up. Oh! Oh, I can feel this thing shaking.

Ashish Rajan: Oh, yeah. Ah, come on. All right, to your point, in the interest of time, quick decisions, make quick ones.

AJ Oller: Oh. This whole thing is moving.

Yeah. So maybe that's not the place. Oh, we're gonna make this fun. All right.[00:18:00]

Ashish Rajan: Oh, okay. Okay, I see. I see you. All right, I'm gonna take that, just underneath. All right, you're up, man. All right.

AJ Oller: This is

Ashish Rajan: gonna get

AJ Oller: really complex. So this one is just basically asking me to do it. So I'm just gonna go ahead and take this one right here. Place this bad boy on top.

Ashish Rajan: Wait, so is the three layers going up as well?

Or now can we start poking from here? Can I start digging out from here as well? I'm not gonna stop you. Ah, okay, but so is that a rule? Or do you just finish? How does it work in terms of, taking out layers? Can I just take out any? I

AJ Oller: believe so. Now this might have like prescriptive rules, like UNO, that no one collectively knows how to play.

Wow. That's completely shaking everything.

Ashish Rajan: That's definitely shaking it. Oh, there you go. Found one. The entire thing shakes. That is very few things remaining in there. [00:19:00] Good job. You finally found one. Oh!

Oh, good job. Steady hands, my friend. Steady hands. I feel like this one is going to come off.

AJ Oller: Can I keep on top of that? It has to be somewhere on the top layer. Oh my god. Gotta wait for it to steady.

Ashish Rajan: Oh! Wow, that's brave, man. That is brave.

Oh, wow. Okay. Fair. Fair. All right. Challenge accepted, my friend. I have to go for the bottom there as well. It's like performing surgery. Yeah, it's

AJ Oller: I'm sure the surgeons will say no, it's not.

Ashish Rajan: So it came to the [00:20:00] close, came pretty close. I guess I lose another one. I guess my final couple of questions more around, we've spoken about the tech side. I'm also curious from the business side as well, for some of the business leaders who are on the security side, as well as on the engineering side, on the other organizations were regulated perhaps, and struggling with the ideas and probably selling sounds like the wrong word, but selling the idea of automation and the value of it at a business level, because they would hear organizations that are quite advanced talk about, we'll do deployments multiple times in a single day into production.

They hear that and go, Oh, is that the standard? I would love for you to share what is a good selling point for the business for them to help understand. Why is this a good idea for us to go down the path of investing in automation, investing in the engineering side of it? Is the reality that you are deploying multiple times, is that the golden for lack of a better word, a benchmark that people should be aiming for?

AJ Oller: So I'll start with the later part of the question. I do not think that is a golden benchmark [00:21:00] for every company and every industry. Absolutely. If you're more, let's say web facing or media, social media facing, then absolutely. That makes sense. because you're getting customer feedback on your product in real time that warrants you adjusting, a hundred times a day.

Yeah. So it's if you're Amazon and you need to ship new features in real time, that makes sense for their business model. But if I apply that to insurance, yeah. Would you like for your billing button to change every time you log in and move somewhere else? Probably not. No. Or if you call on the phone and now wait, I called yesterday, but now to speak to a representative, it is now four.

It's no longer the two button. Yeah. So depending on your industry kind of change isn't received the same way. So I wouldn't necessarily say that is the, like the business value everyone should go after when it comes to automation. But I do think the value comes in consistency and repeatability.

So if I think of what the world [00:22:00] look like before you had automation as a standard across the board, you have a developer's dev environment when it gets promoted to QA, wait, it's not working, but my code is the same. So what's different about QA and in a world that's not automated? We know that we potentially have introduced different settings in QA than we had in dev likely the person that made those changes is different than the person that made your dev environment.

And that kind of also can perpetuate into prod. So you get your QA. Dev doesn't match QA doesn't match production. That's one thing, right? I think that's more of the development lifecycle part that it addresses is knowing that you have environment stability and some level of ephemeral nature to how you can treat your environments.

That's without introducing IAC without introducing infrastructure as code. Yeah, you're right. Yeah Then, you could look at on the actual operation side of things. What's the benefit of automation? So let's say I have any and go back to the operating systems, right? So if I can upgrade my operating system through automation, it's no longer a [00:23:00] task that's going to take me several weeks to react to a zero day or sleepless nights on behalf of an engineering team that leads to no one being happy, right? So I can focus on building a set of automation that'll take me from Windows, 2016 to 2019 and I can, very easily push that out at some point. scale and still schedule these things and still go through all the change management rigor.

Those things don't go away. But now I don't need to have someone staffed 24 7 to just continue to push this along, right? Especially knowing that a lot of the instructions are very prescriptive. Our upgrade looks the same in just about every environment. So that's one aspect to it. And then on the security side of things, I think having an IT estate that is, I would say, generally pretty homogeneous and how it's treated and how it's operated lends itself to more stability and you can react faster to any security challenges that you might face, right? Whether it's a misconfiguration or reacting to some zero day, right? I think automation helps you react faster and helps you recover [00:24:00] faster.

So you think of also what is at the heart of your disaster and your cyber recovery strategies. It's now your automation platforms, right? It's no longer just hey, frontline staff and, so you think of what do I bring up after Active Directory? What do I bring up after network? Now you're starting to bring up your developer tools suite, your automation suite, because that's essentially how we're going to start to recover in the future, right?

It's no longer just, I have a backup. Great. You have a backup. What are you doing with it? Is it a single person going to go and take a thousand backups and restore them, so like you also have to think about how that can be applied there too. So I would say it's no singular answer for why you should automate, but more of why shouldn't I is the question I think modern enterprises have to ask themselves.

If you're really stuck to legacy manual processes, why aren't you automating? Is the question I would ask instead.

Ashish Rajan: I would think a lot of people would challenge that with regulation as a way. That, hey, it's our regulation, they haven't changed, blah, blah. Do you find that automation [00:25:00] helps or enables automation of that

as well?

I

AJ Oller: certainly think so. And there's, for us, specific insurance regulation. Yeah. That's one thing, but then there are the regulations that every company in the fortune 500 has to abide by. So PCI SOCs. Yeah. NYDFS. Yeah. GDPR. This goes on. It goes on and on. And that's not specific to any particular industry.

That's just if you want to stay in business. Yeah. And I think automation tools actually help you achieve those standards in a more reliable and consistent way across the board versus I'm going to solve all of these different requirements in different spaces in different ways. I think so. You can bring one consistent approach knowing that it will be.

A little bit tailored to the technology domain, right? So like multifactor authentication looks very different for, let's say, user and web portals, as it does for like machine accounts, right? What does the multifactor authentication look like for machine accounts, right? I wait for someone to answer.

[00:26:00] Those are the things that I think bring value, regardless of how tightly or loosely regulated you are, is the consistency that you can apply across the board, right? And I think folks look at regulations as something that might hold you back. But in reality, they're there to keep you from messing up.

Ashish Rajan: And if you automate that you're already in that path of by the nature of following it, you're still able to continue doing business. You're still able to do everything that you were saying that you can achieve a lot more. Yeah, that doesn't mean you have to deploy multiple times every single day.

AJ Oller: Again, that doesn't match our business model. Now, there are certain parts of the business that deploy more frequently than others, but deploying several times a day, it's great if you can, right? If you have to invoke that capability in a disaster or some cyber recovery scenario, it's great to have the ability.

Like your board of directors will love to know that this is something you can do.

Ashish Rajan: Yeah, fair.

AJ Oller: But it's not something that you're in the business of doing every single day, unless it is the business that you're in.

Ashish Rajan: I think I'm glad you build out the business objective and the business goal [00:27:00] into the conversation, because I guess to your point, if you are not a, I guess a tech company, and I don't mean the tech in the context of you're an insurance tech, but more in the context of if you're not a product, which is a technology website company product, like a SaaS, then you probably want to question the need for a benchmark for deploying multiple times a day.

I love the example of the, if I call customer service, I don't want the number to be four today, five tomorrow, and it's like a zero that in one year later, I just wanted to be the same thing because I imagine it's also an industry where being steady is a sign of reliability as well. It's not, it's whereas in the other spaces, changing constantly is a need or is a necessity.

So to be competitive, whereas not in the insurance space or not in the regulatory space is the reason why, and I'm going to extend the example to banks as well. You don't want your bank thing to be changing every two days. You want it to be the same every single day, right? I go in, check my balance. Yep. All the savings that I've been saving up for, that's still there.

I love the analogy that you gave. To people who are probably listening to this and going, [00:28:00] and leaders specifically, how can they build up an understanding in this space? Now that you've helped us word it in a way that it can be shared a bit more broadly. Not everyone may have the skill set.

A lot of people may have people come in from an on premise world. What do you think would be some of the things they should look out for so that they can deliver this. I don't want to say automation is the key, but more deliver this value to the business that they can do a lot more in the same time that they could not do before.

AJ Oller: We talked about the base skill set that you'll need. So I won't revisit that, but if you take two views, your business objectives and start to say, what is it going to take to get there and then start to try and map out. And I love to ask our leaders this. What do you envision working at our company is going to look like as a developer, as an IT operations person to meet that business objective and then ask the same question again, what is it going to take to get there?

And then if you take it a step further and say, okay, what's the architecture, what's the landscape going to look like in that future state, that [00:29:00] nirvana, and then ask yourself, what is it going to take to get there? And I think those three things starts to define like a business technology and a capability roadmap that you can execute on iteratively. So it's not like you're, that eventually the whole ocean will be boiled eventually, but you start to go after foundational components first that are going to, essentially layer that backbone across the board. And I think if you take the approach of taking your way up the stack.

Normally, the further down you go, the longer it takes to deliver, so if I think of like bare bones network, then compute then I get into the database space, app, web, load balancing, like firewall on top, like the higher up I go, the top things are actually easy to institutionalize and to roll out, but like getting core networking right, you don't want to have to redo that, right?

So that's where I think like the measure twice and cut once approach really helps. And saying, walk your way back from the end state, ask what it's going to take, but invite some engineers into the room, like it's not helpful to [00:30:00] anyone to have a bunch of like executives that the last time they touched a keyboard was two decades ago to find the future of a company without engineers in the room, so definitely invite them in so you get a good sense of this is not going to be done in a year.

This is not going to be done in two years. We've been talking transformation for over 10. While that looks different at different points of time. At one point, it was an agile transformation. At one point, it was a DevOps transformation. At one point, it's a digital transformation.

At one point, it's a cloud transformation, right? And all of those are to like, mean different things to different people. But transformation, I think, has become the norm as companies try and change the way they work and modernize their IT real estate.

Ashish Rajan: And I remember you telling me about the whole being cheerleader as you go through different transformations as well.

Can you share that a bit about that as well, considering you've gone through a few transformations? Why is there a need for cheerleading at all?

AJ Oller: Especially for the engineers, I think change fatigue is very real. Meaning, you're asking them to learn new skill sets. You're asking them to learn potentially new tools.

In some cases, [00:31:00] you're asking them to learn languages. They've never had to before, because I'd done all of this manually. Why do I need to learn Python? Yeah. And so I think over time that fatigue, you'll find it in your regular team meetings and you'll see like the lack of enthusiasm.

For the next change and the next change and the next change. So I think, yeah, part of what we have to do as leaders is to one, constantly reinforce the end goal and why we're going after it. But then, within your own teams, keeping morale up so that you keep like those small wins as something that you really celebrate.

And it's somewhere between being a cheerleader and like a therapist, I think where I find myself a good amount of time yes, you lead your team and you want to take them to a direction, but you don't want to lose anyone along the way. Like we have so many years of institutional knowledge.

I have folks on my team that started their careers with punch cards in the mainframe. Oh, wow. So that is so cool as well. And they're still in the workforce, right? And so I think while some folks have a stigma against they're going to drag us down or anything like that I think it's quite the opposite that [00:32:00] workforce and that part of the workforce has seen so many transformations over time that there are a lot of pitfalls that you can't avoid that not are not always technical, right?

Some of them are cultural and history repeat itself so I think there's a very human aspect to engineering that might go unnoticed? I won't say that it does, but it might go unnoticed if your focus is purely tech.

Ashish Rajan: I almost feel I have to share the quote a friend says, there is no algorithm for experience as well.

There's no automation for experience. Like someone has tried something and it hasn't worked, knowing that something has happened in the past. It's definitely something goes a long way. That's most of the technical questions I had. I have three fun questions for you. All right.

Fun question. First one being, what do you spend most time on when you're not building guardrails, platforms that I've broken into multiple pieces over here.What is the e other things that keep you excited about life?

AJ Oller: Beyonce. No, but I'm serious about that one, but I would say I have a huge love for music.

We've been collecting vinyls the past couple of years. That's a plus. I think physical sales of music is like on the rise or has been the past couple of [00:33:00] years, music festivals, and then generally trying to stay like active in some level of like fitness, whether that's, Most days is just I pick things up and I put them down in the gym, but that can also mean going on a bike ride, going on a walk.

I also like really enjoy boba tea.

Ashish Rajan: So work that off.

AJ Oller: Yeah, let's go take a walk to go grab this and like then stuff our face of tapioca and cannoli. Oh this one's tough, right? Like at least the gym is right there.

Ashish Rajan: The second question, what is something that you're proud of that is not on your social media?

AJ Oller: So in 2018 and 2019, I led up the company's like first DevOps summit day, where we invited all of the partners that are part of the transformation in some way or aspect, whether it's like a managed service provider, whether they're a systems integrator, whether they provide some of the tooling behind our transformation, bringing on all under one roof and essentially hosting what is like an entire conference within our doors. Oh, wow. Because it's, what's really hard for a company to do is send 4, 000 developers to a conference. Yeah. But you can [00:34:00] actually bring the conference to you. Your partners will be up for it. Yeah. And so I think that was probably one of my proudest moments that's not on my social media.

Because in 2018, who was thinking about podcasting this stuff? Of course. Yeah, it did not make sense back then.

Ashish Rajan: Now everyone's a podcaster now.

AJ Oller: Yeah.

Ashish Rajan: Last question for you. What's your favorite cuisine or restaurant that you can share with us?

AJ Oller: So I was a vegan for a really long time, and there was a restaurant, I don't know if it's there anymore, but when I first moved to Miami, it was called Minty Z, which was like a Korean fusion vegan restaurant.

Restaurant. Oh wow. That is was it like a hole in the wall? At least for Coconut Grove? For Miami. It was like a hole in the wall. Still very nice, but it was so authentic and felt so, so decadent and rich. That's where like I held like my 29th birthday. It's the first date I went on with my partner was there.

Oh, nice. So it's actually been a little played out in our house where it's like we can't go there anymore because we've gone so many times. But that is like probably some of my favorite cuisine is. It's things in the vegan realm, but if you can give me like an Asian fusion really well I'm there for it every [00:35:00] time.

Ashish Rajan: I love that. I love the flavor mix as well. Where can people find you on the internet to connect more about all the amazing work you're doing in the insurance tech space and I guess in the engineering space as well. Where can people connect with you online.

AJ Oller: So I would say you can connect with me on LinkedIn linkedin. com slash in slash AJ Oller. You can look me up. I probably should be the only one, but who knows that changes every day. But yeah, if anyone wants to connect, feel free, shoot me a message and we can talk.

Ashish Rajan: Awesome. And I'll put that in the shownotes as well. But dude, thank you so much for coming on the show, man.

And I appreciate you dressing up as well, by the way. I think it made me so much happy as well.

AJ Oller: Yeah, it makes it a lot to live up to. The cannolis don't hurt.

Ashish Rajan: It definitely does. You're going to need to fit yourself somehow into a suit after that. Just trying to squeeze the button in. Yes.

It's just oh God. Yeah. But no, this is really good. I appreciate it coming over, man, and I'll see you. See you all next time. Please.

Thank you for listening or watching this episode of Cloud Security Podcast. We have been running it for the past five years, so I'm sure we haven't covered everything cloud security yet.

And if there's a particular cloud security topic that we can cover for you in an interview format on Cloud Security podcast or make a training video on tutorials on Cloud Security Bootcamp, definitely reach out to us on info at [00:36:00] Cloud Security Podcast tv. By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister AI Cybersecurity Podcast which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and cybersecurity.

How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring next as an evolution of ChatGPT and everything else continues. If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop that in the description and the show notes as well so you can reach out to us easily.

Otherwise, I will see you in the next episode. Peace.

‍