Bridging DevOps and Platform Engineering with Andrew Boyagi at Atlassian Team ’24

This is Techron tv. Hi, am Mitch Ashley here at Atlassian, team 24, having some great conversations. Um, I, I, I have the privilege of being talk, talking with someone who is in the DevOps advocacy with Atlassian.

Andrew, how do you say your last name? I didn't Ji Ji. Okay, fantastic.

So you've been with Atlassian a couple years. You were practitioner for that, right? Doing DevOps and using Atlassian technology, Right?

Yeah. So before I joined Atlassian a few years ago, I was an executive manager at the Commonwealth Bank of Australia, where I led a quite a large platform team over there for a few years. And then I joined Atlassian as leading the DevOps evangelism team.

So I speak to customers and I work with our product teams on topics like developer experience, developer productivity, and platform engineering. Very Nice. How do you engage with the community?

Is it kind of your job to evangelize or do you get called in with customers or prospects and kinda help us understand how we solve this certain problem? Yeah, there's no two days the same in the life of an evangelist. Um, it's a mixture of those things.

So, uh, locally within our community in Australia, I run a platform engineering meetup. Uh, but I also am heavily involved with the, the rest of the Atlassian community. I do get, uh, called in to speak with customers and engage with them on, uh, things they're seeing and, uh, help they need in terms of platform engineering as well.

So a mixture of ways that I get involved. You know, it is interesting when you have lived in a DevOps or platform engineering world, you start to get in this bubble of thinking the whole world's like that when not everybody is either that far along in adopt or maybe even started doing that kind of thing. What, what do you think comes first if people say, I've got these tools and now I wanna figure how to do DevOps or platform engineering with them?

Or are they starting like, we wanna move to DevOps and platform engineering and what's the technology that would help meet best get there? Is there, is there a pattern there at all? Yeah, you said everyone, we think everyone does do it.

I think everyone should, if they Do it, everyone should, of course. Absolutely. Um, I think the pattern that I see the most is everyone, uh, is already using some developer tooling.

So I haven't come across any engineering teams who are not. Um, but I think it gets to a point where complexity starts to, um, play a role in their ability to develop software. And there comes a time where teams hit the complexity limit and they just realize that they need something to be able to go beyond this limit and something that is gonna help them continue to deliver high quality software at a good speed.

Uh, so I think a lot of people naturally get to the point where they realize they need something. Sometimes they don't know that it's a platform or sometimes may might even be a platform. Mm-Hmm.

Uh, but I think everyone starts off with DevOps tooling and then, uh, they get to this limit where they realize they need something to boost them beyond that limit. Yeah. So sometimes that complexity just can be how much can we really mentally understand and keep in our minds at one time?

'cause it gets to be so big you can't conceive it all together. Um, so, so dividing those things up into smaller parts of work, even if you're not going to, to cloud native, um, being able to automate that so things will flow faster. And you know how the automation works, you don't have to know how every piece along the way works.

Is that where people start or do you see it more of, um, I need to do more agile kind of thinking around how we're delivering what we're doing and planning our work and, you know, sort of a Jira kind of approach? Where's the complexity first solved from? Not that there's one answer to every question.

No, I think that you raised such a good point because a lot of companies I speak with try to solve one side of complexity. Mm. So there's intrinsic complexity.

So that's the complexity associated with being a developer. So needing to know how to use different tools, needing to know about cloud and all the different things that the modern day developer has to know about. And then there's extrinsic complex complexity, which is more around the company that you work in or the industry, uh, that your company operates in.

Uh, so for example, looking at my own history in banking, there's a lot of, uh, regulatory requirements associated with banking and that introduces a lot of extrinsic complexity, but solving only one isn't really looking at a total developer experience. A developer has to, uh, traverse both types of complexity. Uh, so really when you're looking to solve that complexity, you need to look at a, um, completely look at the whole picture and solve both sides.

So yes, there's the tooling side, and to be honest, I feel like that's the easiest, um, side to solve. You know, there's some existing patterns that, uh, that companies can use to solve some of that, uh, intrinsic complexity. Uh, but the extrinsic complexity is really around processes and governance and all that friction that comes along with the company that you're actually working.

It's interesting. Good. I started in banking also in my career and sometimes, you know, there's a lot of momentum that we have in the way we do things right?

'cause it's worked for us. So we've got working and sometimes regulatory things get blamed, if you will, for well, that's why we have to do that. Well, no, actually there's other ways we can accomplish and, and satisfy that requirement.

Just what we're doing now currently does it. And so it takes a little bit of a, let's step back and kind of think about how we might solve the problem a little bit differently. How do you help people kind of get unstuck from, not that they're, they, they're not, they're not stuck, but how do you kind of open up the possibilities of if you're gonna take a DevOps approach, how you might adjust what you're doing in those processes and things like That?

Yeah, like I think, uh, something that I've always done and encourage people to do is really question the requirement. So, you know, an anti-pattern, um, when working with engineers is just giving them, uh, the output that they, that you want or the requirement that you've got without any context behind that. And I do see that a lot happening with regulatory requirements where they say, we need to do this thing because the regulator said we have to mm-Hmm.

Uh, and I I to encounter that quite a lot and I spoke to the regulator and they're like, we, we didn't say that. Mm-Hmm. That's not what we need you to do.

Um, so it's similar to building a good product. You, uh, you need to understand the actual requirement and the context around that. And then I think empowering engineers to actually meet that requirement, uh, is the way to get unstuck.

Yeah. The, sometimes we mix up requirement with our implementation of it. Right?

Right. And, uh, it, it sounds crazy. Something that's worked for me is, let's think of the opposite way of we're currently doing it and what would that enable us to do?

Not that that's the right answer, but kind of opens up that space to say, well actually, hey, this is a really great way to solve this. Yeah. Like, you know, a good example is, um, with governance of software teams, right?

Uh, normally what happens is, um, there's a governance teams who's in charge of making sure that an organization's expectations in some certain aspect of software delivery unmet. And the most basic way they do that is to set up a meeting and a process where everyone follows this process and they come to that, to that committee and say, here is evidence that we've done everything that we need to do. Mm-Hmm.

Another way that you could do that is, uh, by using scorecards. So scorecards is a feature in one of our engineering products called Compass, our platform Compass. Yeah.

And, um, with scorecards you can reverse that and make it governance on demand. So you embed requirements for all teams into a scorecard, and during a delivery cycle, teams can see are they meeting those expectations or not. So it makes it easy for them and avoid rework.

Whereas for the governance teams, they don't need to have this meeting where everybody comes in and explains to them what they've done. They can filter for score cards to show me the ones that are not meeting our expectations, and then they can reach out to that team or those teams and have a different type of conversation. They can say, look, this isn't where we need it to be.

What can we do to help you to get it where it needs to be? And it really changes the dynamic and the relationship between those teams. So I think that's a good example of, that's great.

Changing things around, like looking at things a little bit differently. You know, another example of that is, since so much of our workflow, we use automated, you know, technology tools to do that well, that captures data, right? What do we need to satisfy regulatory requirements, evidence of we're doing something a certain way that that puts us in compliance.

And whether that's a workflow or checking security of software, when we do A-C-I-C-D build or whatever it might be, all of that data can be surfaced to something like Compass or the, or other tools, workflow tools that you've got. Data and providence of where that data came from to satisfy be much better in filling out a form. I'll tell you That.

Yeah. Like, I'm sure you've been involved in audits as well and they're, they are very time consuming. So bring me, Show me this.

Right, exactly. That's the first question. So Like, having, having something pre-prepared, like on demand to show, we don't dunno.

We're not gonna just show you one example we can show you every time we've done this, um, goes beyond satisfying the requirement of an audit. I bet more than one conversation. I believe you, but the auditors won't.

Right. They need to, they need something that says it shows that you did that. Um, let's talk a little bit about platform engineering since you ran a platform team when it kind of arrived on the seam as a term.

We've been, we'd already been doing it for a long time. Um, you know, some were saying, oh, that's the replacement for DevOps and or this is we, we forgot about the developer. And so that's what platform engineering here is kind of focus on the developer.

And, and you might, you may say some of those are true or, or to whatever degree, what's your perspective about how platform engineering and DevOps fit together, complement each other? How does the workflow, what, what is a well functioning DevOps and platform engineering organization look like? Yeah.

I've always been a little bit confused about a DevOps engineer or DevOps role. I know it's, it's widely used. I never looked at DevOps that way.

I mean, the tooling is one aspect of DevOps for sure, because It's a how, right? Yeah. How you do things, not just a tool.

Exactly. Well, it's, it's a, uh, there's a bit more of a cultural change that's required within DevOps rather than like if you just, uh, implement a bunch of tools, you can't say that you are working in a, in a DevOps kind of way. Um, so I, I'm definitely in the camp that DevOps and platform engineering are complementary.

I think platform engineering's an excellent way to enable, uh, DevOps because it takes away the complexity of the tooling away from engineers and allows them to focus on what they're actually getting paid for, what they're there to do and what they like to do, which is deliver high quality software to production. So I think, um, I think it is difficult to be really successful with DevOps without platform engineering, but I think the two are complimentary, um, terms, Seems like anything that can solve the problem, well, it worked on my machine, right? Yeah.

You know, the platform and let's standardize some of those things and make it easier to spin up environments. And whether it's a dev test or reduction is a great thing, right? Absolutely.

I think people do sometimes lose sight of the fact that developers want to be productive, they want to ship high quality software to code, They don't wanna do the drudgery Work. Exactly. Nobody does.

So, uh, and I think Platform engineering's an excellent way to enable that. So it, we do see that, um, you know, internally we use Compass, which is our platform, and it does help us drive developer joy because it takes away some of the mundane parts of being a developer and it helps 'em focus on, uh, adding value and shipping high quality software too proud. Excellent.

Where, where would folks find you engage with you? Is it in the community that you, they would mostly see you or where, where would you find Anthony and, or I'm sorry, Andrew, uh, talking about what you talked about. Yeah, I'm, uh, pretty active on LinkedIn.

Okay. So you can find me on LinkedIn, Andrew Ji and the Atlassian community. So, uh, I'm pretty active in the DevOps Atlassian community as well.

Great. Answering questions, helping out. Yeah.

Giving people, writing articles, answering questions. Yeah. Very cool stuff.

Well, thank you Andrew. It's great to talk with you and, uh, thanks for joining us and sharing, you know, those are all kind of like, how do these things work? Right?

We're all, I think ever, all of us are trying to figure out how do we make things better and is this something that will help us? And it's a journey for sure. It's a journey.

And we go, you know, you don't do it alone, right. Possible. A lot.

It's A all way Safe, you know, is it, uh, go fast alone, go far together. Exactly. That's definitely true.

Yeah. Well, thank you for joining us. And Andrew's been sharing with us a really great perspective.

You know, he has his own background of, uh, leading platform and doing DevOps, and now he's helping others doing that through the Atlassian role that he plays. Welcome. Thanks again for coming back and welcome to, uh, this conversation.

We'll be back with another great interview coming up real quick.