We chat with Andrew Boyagi, Atlassian's Senior Developer Evangelist, about bringing great developer experience to teams and platforms with thousands of engineers. When the software sprawl gets so big you spend more time looking for answers than solving problems, it might be time to try something new.
Andrew has worked in many roles, including as Executive Manager at the Commonwealth Bank of Australia, where he established and grew a platform engineering function that supported 7,000 engineers.
You can find him on LinkedIn here.
You can learn more about Compass, a developer experience platform, here.
Shout to Amelio for earning a stellar question badge and helping over six hundred thousand people with this gem: Getting the name of a variable as a string
[intro music plays]
Ben Popper Hello, everybody. Welcome back to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ben Popper, joined as I often am by my colleague and compatriot in arms, Ryan Donovan. Ryan, how’re you doing today?
Ryan Donovan Hey, how’re you doing, Ben?
BP Pretty good, pretty good. So today we are going to be chatting about developer experience and DevOps– things that we know pretty well from our blog and from our time here. If you had to define the key trend in DevOps for the last year, Ryan, what would you say?
RD It's just increasing automation, moving towards platform engineering, just taking things off of everyone else's plate.
BP Great. Well, our guest today is Andrew Boyagi, who is a Senior Technical Evangelist over at Atlassian. Lots of thoughts on DevOps and DevX. So Andrew, welcome to the Stack Overflow Podcast.
Andrew Boyagi Hey, Ben. Hey, Ryan. Thanks for having me.
BP Before we dive into some of what you're thinking about these topics, just give folks a quick flyover. How did you get started in the world of software and technology and what led you to your current position?
AB All right. Well, I'll start with my current position. I lead the Agile and DevOps Evangelism Team at Atlassian, and as a part of my current role, because not a lot of people know what an evangelist is, I speak to a lot of customers around the world about developer experience, platform engineering, and how to improve this within their organizations. Prior to joining Atlassian, I spent 20 years leading multidisciplinary tech delivery teams, including leading a platform team at the Commonwealth Bank of Australia where we supported the developer experience for 7,000 engineers. I'm pumped to be here and talk to you about all things developer experience.
RD So we've talked a lot on the blog and the podcast about productivity, trying to measure it, whether you can measure it for individuals or for teams, things like the DORA metrics. Is it possible to measure productivity? Is it even worth it to try?
AB It is possible to measure productivity, but the real question is why do you want to measure it? I speak to a lot of CIOs and CTOs and the most common reasons I come across are really two. The first one is that the CIO or CTO is under a lot of pressure to prove the value that their teams are delivering to their peers, and the second reason really is that they already recognize that their teams aren't as productive as they could be so they're looking for ways to try and quantify that. However, I do think we're still talking about the wrong thing though, because I get asked a lot about how should we measure developer productivity and how do we know if we're productive, but no one really asks a lot about how we help our developers be more productive. I don't know about you guys, but I've never spoken to a developer who doesn't want to be productive, and so really, I think the conversation should be, how do we help those developers be more productive?
BP I noticed on your LinkedIn you had a couple of featured articles which sort of speak to what you're saying– how to tame software sprawl and how to lift the complexity limit. So from your perspective maybe, if you think about DevOps as trying to organize your team or their workflow in a way that makes them more productive, for you that would be equally as much about developer experience, making sure that they feel empowered, making sure that they don't feel overburdened, things of that nature?
AB Yeah. I think if you look at productivity, the way I see it is that there are two main ingredients, and they are developer experience, as you just mentioned, and also engineering culture. And so we're looking at productivity and a lot of the conversation is about measuring that. I see it as productivity is the outcome of experience and engineering culture. Just to highlight it, I was chatting to a friend a few weeks ago and I was scheduled to go and speak to the CTO at the company where they're working. He was pulling his hair out saying, “I can't believe we're spending so much time talking about productivity and trying to improve productivity, but I can't even get a laptop that's capable of doing what I need to do every day.” And so I think there's this weird dynamic where companies are looking to measure productivity, but they already know what they need to do to help their developers be more productive. And so really I think it's a balance. You asked before, is it worth measuring it? Should we try? I think it is worth it. I think you should try, but I think we also shouldn't lose focus on actually helping developers be productive. Because that's the main game, the measurement is just getting insight into how productive they are.
BP When you look at something like DORA metrics, are there things that you don't like about it? If you had to pick a few things that, from your time as an engineer, you would say indicate a team that's happy and high functioning, what would they be?
AB Let's touch on DORA first. The way I see DORA metrics are that they are just table stakes these days. If you look back a few years ago, it was actually pretty hard to get access to your DORA metrics. There wasn't really an easy way to get access to that, whereas now DORA metrics are pretty accessible to most teams. If you look at even just within Atlassian’s developer experience platform, Compass, it just comes out of the box. So it's pretty accessible, everyone can get access to that, so I think every team should be using that. It does not indicate team happiness though, and you talked about how you know and what are the metrics for team happiness, I don't believe there is a quantitative measure for team happiness. I think it's more qualitative. You get that information through engineering surveys and actually speaking with engineering teams to find out, are they happy, are they satisfied, and if not, what could we do to improve that?
RD You link developer happiness and productivity, but is it possible for unhappy teams to ship software?
AB They do that everyday today. However, if we're talking about productivity, the way that I look at productivity, the definition of productivity is output over time. That's not really helpful because you could be really productive at getting poor quality stuff out there, or you could be really productive at building the wrong thing. So it's not really productivity, it's probably more value that we're looking at. However, I have never met a really unhappy, super productive developer. They're pretty closely linked. And they're also linked if you have a look at any academic research that exists about productivity, there's a very strong link between satisfaction and organizational citizenship behavior, which is basically those engineers that you've worked with in the past where you see them exceeding expectations, going over and above, doing what they need to do to ensure a positive outcome, all of that is linked to satisfaction and happiness. And so from where I see it, we should be looking at developer satisfaction and developer joy rather than just simply looking at productivity.
BP So you mentioned that DORA is kind of table stakes now. What do you see as smart, reasonable and effective leveling up from that? And maybe that will take us into talking a little bit about Compass, which I know is a new product over on the Atlassian side that you wanted to dig into.
AB I think when you look at metrics, it's got to be something that's unique to the company. And if you look at the SDLC, there are so many things you can measure. You can pretty much measure anything you want in terms of the SDLC. Everything has an output that can be a measure. There are very few organizations that I've seen that have really effective measures to give them insight into how they're performing throughout that SDLC, but every company that does do it really well has one thing in common: all of their metrics are unique. You don't see them having a common set of metrics across multiple organizations, and that's because the ingredients of developer productivity that we spoke about are also unique to an organization. So if you look at developer experience, you could have the same tools as another company, and the developer experience is still going to be unique to the company that you work in. If you look at engineering culture, it's so unique. You couldn't replicate the culture of another company even if you tried. So if they're the two inputs to developer joy and productivity as a byproduct, and they're so unique to your company, then the measures that you also pick should be unique to your company as well. So to me, I think it's more about the journey that an organization goes on to find the right metrics for them rather than saying, “Oh, here's a bunch of metrics that are really good and you should look at these.”
RD You mentioned that the DORA metrics are table stakes. Are those actually a reasonable measure of productivity or does it just give you a sort of vague sense of whether things are shipping well?
AB I think it's more the latter. I don't see DORA metrics being a productivity measure. They could be a performance measure if you look at it that way, rather than productivity, because the DORA metrics in themselves also lack context. If you look at two teams within an organization and one's working on a really old monolith and another one is working on an application that's more modern and using a microservices architecture, the DORA metrics are going to look very different between those two teams. Would you say that the team working on a monolith are not productive because maybe they've got bigger cycle times and things like that? You wouldn't, because it depends on the context in which a team is operating. So again, DORA metrics are great, I think every team should be looking at them in the context of their work, but I wouldn't say they are productivity measures.
RD How about platform engineering? I know we've seen DevOps grow into that and you led a platform team previously. Do you think that's part of developer experience?
AB Absolutely. I think the shift towards platform engineering is basically a key enabler of DevOps and a positive developer experience. If you think about how much complexity developers need to deal with these days, they've gone from needing to code to also needing to understand how to use a huge number of tools on a daily basis. They need to understand security, testing, cloud infrastructure, and with DevOps, they're also now deploying and running their code. That's all intrinsic complexity. If you think about the extrinsic complexity they need to deal with, that's the stuff that comes with the company that you're working in. So if you think about if you work in banking, for example, there's a lot of regulatory oversight on what you do and so that all adds a different type of complexity on the developer. And so really when you look at platform engineering, it's about abstracting that complexity for developers so they can actually focus on solving problems for the company and shipping high quality software.
BP Do you think that software teams within different industries now feel that at, let's say a financial institution, you might have a culture and an experience –DevOps and DevX– that's as good as you would at a technology company? I feel like the idea that there are software technology companies and non-software companies is kind of outdated. You worked at a big bank with 7,000 engineers. That's a lot of people who know how to code. But I think people also still have the conception that if you work in an old line industry, people are going to be less aware of a lot of what you're talking about– how to bring a great working environment, the right tooling, the things that will make developers more productive.
AB No, I think there's definitely a focus on platform engineering and building a great developer experience regardless of industry. So like I said, I speak with many of the Fortune 500 companies quite a lot about developer experience and platform engineering, and everyone I speak with has a really strong focus on improving that developer experience because they recognize that software developers are getting involved much earlier in the process in the SDLC, but also they’re so much more important now to the overall success of the company. And so it's in everyone's interest that every company has a really solid developer experience, and they're rightly focusing on that, regardless of industry.
BP I feel like the mobile apps that I open which are updated most frequently are all the ones I have for finance. There is always a new coat of paint, a new this, a bug fix that, and they're always showing off. Maybe just because they didn't used to have great mobile apps and now that they do, they want to let everybody know.
RD Maybe they're faster at patching security holes.
BP One would hope. All right, so let's talk Compass for a little bit. What is this product, where did it come from, and how does it maybe try to embody some of the principles you've been discussing?
AB So Compass, one of my favorite products. Let's have a look at the Stack Overflow survey actually from last year. I was reading through it the other day and something really stuck out to me and that was that 25% of developers spend more than an hour per day looking for information just to do their jobs. That's crazy. An hour a day looking for information, not doing your job, not shipping software– looking for stuff. That's a problem that Atlassian had, and it's also a problem that many of our customers had. So Compass was initially developed as an internal tool really to help Atlassian developers deal with complexity. And over time, we heard hundreds of stories from customers who were dealing with the same problem, and they were coming to us asking us how we deal with that. So if you think about Compass as a product, it's a developer experience platform and it has four core capabilities. So if we look at the first one, the first one is really a software component catalog. So I spoke just then about how much time developers are spending looking for things and the software component catalog is built to reduce that. So within the software component catalog, it's really easy to find who owns a software component, where all the documentation is, who owns it, how you can get in contact with them, where the source code repo is, up and downstream dependencies, everything you could really want to know about a piece of software is there within the software component catalog. And what this does is it creates an information on demand culture, so instead of having to ping someone and asking them a question or looking through hundreds of pages or where do I find this information, within Atlassian we have one URL where everyone in the company can go to find exactly what they need, and we find that really helps developers stay in the flow. The second capability that I'm going to talk about is health scorecards and metrics, and this basically helps you understand both software and team health. And so when you look at the modern day developer and how there’s software sprawl occurring within organizations, what's really hard is to understand the health of software. So with scorecards, what we really do is we bake company expectations on things like application readiness into scorecards. And what this means is that teams know upfront what they're expected to do, and they have that information during their delivery cycle so that when they get to the end, there's no nasty surprise of some governance person saying, “Oh, here's six things you haven't done. Can you go back and rework those?” I know you're laughing because we've all probably experienced that in the past. The third one is around software templates, and what that really is is your golden path. So this is where you can create reusable templates to do things like create a source code repo. You can connect it with an orchestrator to provision your cloud infrastructure and CI/CD pipeline. All these things that can take weeks in some companies to get these things set up can all be done within a couple of clicks, and that also saves devs a lot of time and pain in engaging with other teams. The last one I'll talk about is extensibility. So to me, this is what's really essential to driving a positive developer experience. That's because, yes, we have all these tools that developers work on, and extensibility means they can all be connected with Compass to reduce some of that context switching, and it brings everything into the context of a software component that a developer is interested in. But extensibility means that you can also extend the platform in a way that suits you. No one understands the developer experience within a company like the developers who work there. That also means that they know what they need to improve that experience, and so what's been built into Compass is a way to easily extend the platform so that engineers can create their own apps, add that into the platform, and improve their own developer experience. And that's great because it actually reduces reliance on platform teams. They're busy solving the problems that all the teams within a company are having. But by giving teams the ability to improve their own developer experience, they can add apps directly into Compass and improve that for themselves.
RD It's interesting that the software catalog you mentioned is huge. My last job I had was basically started as a tech writing job and grew into evangelism and developer experience, and we didn't have that software catalog. When I was trying to find answers on code or services, I had to create for myself this sprawling sheet that eventually everybody added to and I had to check every three months and make sure it was updated. It was a huge pain. It's good to see that other companies are solving this for everybody.
AB And I think it really drives something I like to call ‘high value collaboration.’ So if you look at collaboration, what really annoys developers actually is low value collaboration, like, what does this do, how does it work, where do I find documentation? It takes everyone, both sides, out of the flow, and there's not really any value that comes from that interaction. Whereas if you look at high value collaboration, if you already know all of that stuff and you want to work with someone on something, the collaboration is accelerated into something that's high value where everyone's already on the same page and they're able to actually have an outcome.
BP I was just going to say, are you familiar with Backstage? It's a product from Spotify. Listening to you talk, I sort of heard a lot of things that sounded familiar. This was something we built internally to solve problems and our developers loved it so much that now we're bringing it out. It's a way for developers to understand what is the provenance of this code I'm working on and get up to speed quickly and be able to find what they need. And then also it has that sort of app store, solve your own problem component where if the developer sees something, they can fix it, and then that has that great ripple effect that now everybody at the company can access it. So it’s interesting, it seems like two great software companies kind of came maybe to the same place.
AB It's definitely a problem that is worth solving.
RD These developer experience tools are wonderful, but I feel like they're caused by the modern scale of software companies. It's all services broken up into small teams as opposed to the old monolith where everybody is sort of working on the same thing together. Do you feel the same way or do you think this is a natural progression for software?
AB I think it's definitely born out of additional complexity as software within companies grows, however, I think it is also a natural evolution, as you say. It's the way to deal with complexity and really address some of that software sprawl that we're seeing across the industry.
BP You mentioned at the beginning, does this also bring together documentation or is it just for code and for developers? Or is it pulling from Confluence or a wiki and stuff like that?
AB So essentially within the software component catalog, we've got a section for links where teams are able to link all the documentation associated with a software component. So when I spoke earlier about collaboration and being able to find information on demand, developers normally work in the context of a software component that they're modifying or that they're working on, and so they don't want to trawl through a bunch of different tools looking for the information they need; they want to search in the context of that software component. So within Compass, you can search for that software component and it will bring up all the links associated with that component so you can easily find the information you're looking for.
BP It's like you've got footnotes for every software component when you need them.
AB Yeah.
[music plays]
BP All right, everybody. Thank you so much for listening. It is that time of the show. We want to shout out someone who came on Stack Overflow and helped to spread a little knowledge or asked an amazing question. Let's give a shout out to Emilio, awarded a Stellar Question Badge for, “How do I get the name of a variable as a string?” It's a pretty basic question, asked 10 years ago. It's helped 662,000 people. So thanks for asking, Emilio, and thanks to all the great folks who gave answers underneath. As always, I am Ben Popper. I'm the Director of Content here at Stack Overflow. Find me on X @BenPopper. Shoot us an email: podcast@stackoverflow.com. And if you like the show, why don't you leave us a rating and a review.
RD I'm Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. And if you want to reach out to me on X, my handle is @RThorDonovan.
AB Hey, I'm Andrew Boyagi, Evangelist at Atlassian, and you can find me on LinkedIn.
BP All right, everybody. Thanks for listening, and we'll talk to you soon.
[outro music plays]