 Welcome, everybody. Thanks for coming to this talk on scaling software delivery framework for developer enablement. I think that this is a really good talk because not a lot of conferences talk about developer enablement. And so from the standpoint of this being one of the first talks about this, I really did want to lay a foundation for it. I think it's always really cool to talk about things that you do at work. And I actually do this at work. I am leading a global engineering team at Autodesk. And we are in charge of global developer enablement and support. I will say I started at Autodesk earlier this year. So a lot of the examples that you'll find and results they've come from earlier this year. And it's just, like I said, laying a groundwork for future iterations of this and conversations around this. So happy to answer any questions that come up afterwards and just continue to have spaces like this where we're talking about developer enablement. I also do a bunch of other talks and things in the community. So if you want to follow me, I am there. But the agenda is pretty straightforward. And we're going to be talking about where this lives in the context of continuous delivery in the ecosystem. And then I'll share the framework and we'll have time for Q&A. Cool. OK, so I know that a lot of us here have seen developer reports, measures of what could happen if you have continuous delivery. I think it continuously shows that we're able, if we were able to implement continuous delivery, DevOps practices, that we're able to reduce product defects, increase time to market, and also reduce development time in general. And the studies continue to show that year over year. The state of DevOps reports by Puppet, Dora also has them, Atlassian, Forrester Research, and even communities where they focus in specifically around product or agile development. They've also found similar processes. I think we also generally know what we want to target in terms of practices and things that work in the community. And so you can insert any buzzword, continuous delivery, infrastructure as code, chaos engineering, SREs. We have all these practices and ways of implementing the results that we want to have. And if you were to boil it down, you would basically have three categories. We generally know what kind of people or roles we need, the processes, and then the technology. Even though there may be differences in the end technology or tool that we use, we generally know these are the principles that are going to follow along. And that's what we're going to focus in on. So this talk is specifically about how do we scale this? This is the how of it all. We know the what. We know generally what we're targeting. We know the outcomes. This is how we scale it. So hopefully this talk can be really helpful for anyone in the room who may be looking for opportunities to scale this externally as a developer advocate, but also internally for your internal platform engineering teams and new processes that you're introducing into your organization. So why are we looking at this in the context of DevRel and Outreach in the first place? Like why is the talk talking about DevRel and Outreach? I think this conference is a good example of why. We get to interact with each other and then attend these sessions, learn a lot of things, go back into our companies, and implement a lot of our learnings. And the nice thing about that is we get to build relationships, provide support, and then interact with the developer community. And it helps not only our internal companies that we work for, but also the developers that are interacting with our services and that work with us. And so the idea of this talk is to really inject a lot of DevRel and Outreach type activities so that it can help companies, both your company and then also the developers that you interact with. So that's a little bit of a hint for anyone who is not maybe familiar with DevRel. So here's the framework. The idea here is there's three areas that you want to focus in on when it comes to developer enablement, specifically related to DevRel and Outreach. And I'm sharing it here. And we'll talk more about how it'll drive success, minimize impact, or maximize impact and then minimize interruptions. So the first part of this frame, well, this is the framework, the three things that you want to be doing is targeting developer activities that will sustain software delivery, fixing incidents on the spot to empower developers and facilitating platform trainings and services to stop developers from introducing vulnerabilities. So we'll talk about each of these things in more detail in this talk. I would not be an engineering manager or an engineers manager without trying to tell you all how you may want to manage or organize these activities. So I have a little framework for this and this is how we're going to talk about each of the three areas or pillars of this. The first step is to identify what is the problem? What is the feedback? What are you hearing in developer communities? Second is to activate. So actually engaging with the right stakeholders, the right communities, the right environment. And then third is to action on that, right? Now that you've identified and activated, time to take action. That's how we will scale and transform the software delivery and how we sustain it, right? Okay, so let's talk about that. Let's apply it to all these things, right? When it comes to targeting and developer activities, in order to identify that, the biggest thing that you want to look at here is the entire software development lifecycle. And beyond just looking at what projects are working really well and what teams are working well, really being able to understand what are the developers saying. And the way that you do that is actually looking at things like bug reports, survey results, feature requests, and even suggestions for improvement. I think the pitfall here that happens often is we conflate getting feedback from developers as a measure of productivity. And productivity is actually very different. We all know about the Dora metrics. We time to deploy, right? Meantime, the recovery, all that stuff. But what you want to be measuring here is actually developer feedback. And this is not a measure of productivity. So I just want to send this caveat here that oftentimes developer enablement or even platform teams will fall into the pitfall of saying like, okay, let's just measure like what teams are doing really well, like how fast are you delivering? Even counting like what does your architecture look like? Is it monoliths, microservices? What is it? And we count these things. But it's not necessarily feeding the impact for how we can identify dev rel activities that would be helpful. So that's what I want to say here about identifying. Like I said, you want to be looking at bug reports, things that are actually coming up in developer surveys or conversations. And you can often find those things in Slack or even in sidebar conversations. It's almost like water cooler conversations amongst developers, right? And once you've identified what's being said, it's now time to activate, right? Activate the right communities to be able to engage with people. And the way that you want to do that, there's a variety of different ways that you can do that, but some ideas and some things that have been working well at my company at Autodesk is we've been organizing events, meetups, conferences, and even online forums so that developers can connect, share knowledge, and collaborate. One thing that's been really interesting is also hosting AMAs on Slack, which is pretty cool because you just set a time where you're like, okay, you can ask the core team and even HR recruiters to answer any kinds of questions that you may have and people just drop in the questions in Slack and they get the answers. And if they miss the session, they can read the log, right? It's all there. So that's a really great way to help a crowd source and find solutions to common challenges, common questions about what you do, about what are some of the best practices and things like that. So it's actually been really helpful within the AI practice at Autodesk. But the caveat here is you just want to make sure that you're creating environments where there may not be any at the moment because oftentimes we build so fast in our environments. We create new teams, we create new projects, we throw in new people, processes, technologies, but how do you integrate that without harming your productivity? This is what this is about, right? So that's a little hint there. The other thing about activating communities and people is you want to constantly give yourself momentum when you go and do this because as much as you give, you want to receive back. So when I talk about performance, when I measure what's going on or when I talk to business leaders about what exactly we're doing, I look at three things. And this is how I also manage engineers. I look at the business impact, the team impact, and the technical impact. So you want to look at those three things to really just align it together so that it feels like a cohesive experience. And it's not just this thing that leadership will look at and be like, oh, what is this team doing in these alien practices that you're now throwing in, right? So you want to constantly feed that as a feedback that you action on. So a lot of the action steps here are really about closing the loop and you'll continue to see different ways of doing this. But one thing that we decided to do is create a space for where developers can quickly access our events, resources, and other enablement activities. And it spotlights things like our solutions, any updates, we have a blog space, any events that we're hosting, partners, our customers, and then our actual team. So it's actually really helpful because now you can quickly get those things. But building a site also gives you the opportunity to now make this a push model for developers where you're like, okay, we have this event coming up, we can automatically trigger a newsletter to come out or some announcements to come out and so you're able to sustain yourself when you're sustaining software delivery. And it's really important to kind of think about that. Like in this room, we've probably heard some of the technical talks that are like, oh yeah, we want the push model instead of the pull, right? And it's the same way here. So that was a little bit more about targeting DevRel activities. I'm gonna hop to fixing incidents on the spot so that you can empower developers. This is an important one. I think a lot of people forget this one because we're building new technologies, we're letting it be accessible to other developers. But we forget sometimes that even getting access to things or even getting started is a hurdle oftentimes. And that's something that developer enablement can really help bridge. So this activity about fixing on the spot is about improving productivity and lowering idle costs or just idle time for developers where they're just sitting and they're like, well, I can't get access to this thing so I don't have my dashboard. And now I'm not delivering any code because we're just waiting on the infrastructure team and the operations team to do XYZ. So we made this process open and easier for developers by introducing and creating a Slack to Jira integration. And basically the nice thing is that in Slack, customers or developers can issue a ticket that they need if they need access to something and it syncs up with Jira. So it automatically assigns this to a support team member who can then resolve the issue and then they can follow up and it's all synced together. And that's really cool because now we're able to understand the issues, resolve them and then we have a record of everything. It's not just like, oh, this was a one-off, one-message thing, right? That someone needed to get access to a system and boom, now it's gone or someone spent a lot of time doing something but we can't quite measure it. So yeah, the Jira part helps because, and also the solution helps other team members as well because now you can share it with other teams, maybe product management teams and stuff like that. And this just gives you a language, a common language for you to be able to now follow up with internal product or platform teams to be able to enhance the developer experience. Like if you see an uptick of tickets where they're like, oh, I can't get my dashboards running. We had to run a Jenkins pipeline to get everything set up. For some reason, we get a lot of questions about that, that can hint towards an improvement for the developer experience and that's the kind of stuff that you would want. That's the developer feedback loop. One thing to know about fixing incidents and gearing yourself up to be able to fix things on the spot as a team is you have to know who and what you want early on. And it's a simple exercise and you all can even take a screenshot of this, I don't mind. But this is an example of a write-up that I did explaining what skill sets would be needed in order to support this type of work and then also what their main responsibilities are. And we'll talk more about this because it's strategic more than anything else to make sure that you're getting the right people in the right room who are able to grow and help scale this out as you begin to really hunker down and scale the software delivery. So we'll talk more about this in the facilitate aspect. All right, this is the last bit. Yay. Facilitate this activity is all about creating and providing platform trainings and services that help developers learn the practices and tools that align most with your organization. So this is the idea that repeated exposure in practical settings to the right processes will help you essentially commit less errors that may introduce vulnerabilities or failures in your code in the first place. So it's really important when you're identifying what you want to facilitate to really think about who you have as resources and who's available to be able to help with what. Learning takes time and learning takes place in real time and in practical settings. And so there are different ways to facilitate this whether it's like a sandbox environment or a training platform. And so you really want to spend your time thinking about what is going to be the highest impact, what's gonna get the most buy-in as well when you're doing this because you can only stretch yourself so thin when it comes to this kind of stuff. And I have some tips around how you may want to activate your staff members or your teams about this work specifically. And I think the biggest thing is getting that leadership alignment and investment early on because you have to know that when it comes to software delivery, if you were to look at this from a very traditional engineering standpoint, what typically happens is you have your engineering leadership set principles, like guiding principles about how you want to do things at the org. And then your teams will decide the practices and the tooling, right? We're not trying to set new principles. We're not trying to set new practices. We're just exposing developers to what it may look like. And that can be a hard concept to understand, especially when there's already so many things going on in an organization. I think it's also really important that when it comes to like, that that's the managing up piece, right? When you're managing your actual teams to really train your personnel to be able to scale this out in the future as well. And so I have a little sample career ladder, but it's also helpful to align this in like engineer's growth path because supporting a platform and a platform service within a company, it has very different focuses and sets of skills than a traditional software engineering team has. And so even just having something like this can be really helpful for everybody involved in the process where they realize like, okay, these are the main kinds of activities that will be done. And this is like the level of expertise required for each kind of step. So you have to pave the way a little bit when it comes to this, just because it can't, like I said, it's different. And there are differences, right? In focus, like we're mostly focused on building relationships, right? Where a traditional software engineer is gonna be more focused on developing software applications and features, right? Same thing with the communication. We're mostly, we're focused on creating and building relationships with other engineers where a software engineer may be solely focused on gathering feedback and requirements from their product management or their team leads, right? So there's a variety of differences here and I wrote this up and it's a great shot. But fundamentally, like there are differences and you wanna be able to navigate those as well, especially for folks that like maybe you'll hear, like you'll sign a title, right, to this kind of team. And everything means everything until you start to talk to people and then they learn more about the role and you don't want to undersell or oversell what this actually is. You wanna be very intentional about what this role is about, what it's growth paths are and then go from there. So one thing that we did, that was interesting, was build a knowledge portal and that knowledge portal consisted of troubleshooting guides, quick starts and then exposure to best practices and additional training material for the platform services that we provide within Autodesk. And it's been really helpful to build this out. Actually, this is in Confluence, but you know, there's also a parallel universe where you have a public version of this, right? There's also another parallel universe where depending on your system or your product or technology, right, you may be building like an API first type of system or a public documentation space, right? And all this stuff then becomes public and external facing versus internal facing. I think the nice thing about internal facing specifically is you're able to quickly get people the guides and resources that already somewhat exist as tribal knowledge within the company already and so you can almost kill two birds with one stone by talking to the right people and even getting like that by and early on. Doesn't always happen, but in the best of best worlds, this can be something that you leverage from other knowledge bases like in Confluence or Slack or wherever you all store company knowledge, engineering knowledge. So I went over the different pillars of the framework, right? We were talking about targeting, fixing and facilitating and then I walked through like the different ways that you wanna manage each of those activities within your teams, within developer enablement organizations or functions. It may not be an organization. The idea of this talk was to be seen in the community, to create a community and to nurture and get as much as you give to the space and I encourage you all to be seen in what you do, experiment, encourage your developers to do the same thing as well. I know a lot of companies that build like internal championships and even programs where they make it really fun and like being the driver of that gets to be really fun especially once you host the AMAs and the workshops and you get to see how people react to that. So that's my talk. Thank you for attending and we can take some questions if there are any. Yeah, so this slide deck will be public. I tweet about it so I'll have a link to this slide deck specifically and it'll be like a PDF that you all can share. I made this slide so that it would be consumable. Like, you know, all the points are nicely written up and everything so yeah, it'll be available, thanks. We don't at Autodesk but I've been at companies where we do have communities of practice. I think the biggest thing around building communities of practice and really getting them off the ground is having people that you trust in those to start them up and typically like what you wanna be looking at from that standpoint is technical guidance, right? Because from the standpoint of like how is this gonna be structured? What are our cadences? What is actually needed? That takes a lot of driving but yeah, communities of practice are really great ways of, they're also called COPs. They're great ways of driving initiatives in terms of building like cohorts almost of activities and that's how you can scale it in the future as well, yeah. Great question. Did anyone else have any other question? Yeah, I think it's gonna be really important for you to focus on the targeting and the facilitating. You know, the targeting is really important. Like you said, the last thing that you wanna really do is set up like a cadence or set up some type of event where it kind of missed the mark and you didn't get the turnout that you wanted to. I think that can be demoralizing in the beginning because essentially you've killed your momentum, right? You're like, oh, I put this effort in here and now I got nothing out of it. I think there's different ways to go about it. I think opening up that space is really important first because once you get more questions and you can say, oh, well actually we'll host a session all about this or I'll host only in office hours, right? And that can be something that can be helpful because once people have those individual conversations, you can then see like, okay, what's the back and forth and will there be a back and forth in this forum that I create? So that's another thing. And then secondly with facilitating, if you're getting a product off the ground, you'll have initiatives already mostly centered around product enablement itself right off of that because if there's already momentum there, docs look great, product site looks great, everything else looks great, then it's a matter of evangelizing that almost where you're saying like, okay, here, check this out. Like here's a demo and building that out versus trying to like fix too many problems early on or get too much feedback at the start where you're like, oh no, there's now so many activities that we have to do and we don't actually know what we're gonna get the most impact off of. So that's my recommendation there. Yeah, cool, well, I'll be around after my talk so if you are shy or want to just say hi, happy to talk after this, but thank you everyone.