WEBVTT 00:00.000 --> 00:07.560 Before we start, how many of you, that's really loud. 00:07.560 --> 00:12.520 How many of you this is your first positive, amazing, amazing. 00:12.520 --> 00:15.200 How many have been here more than five times? 00:15.200 --> 00:16.200 Okay. 00:16.200 --> 00:17.200 Any more than that? 00:17.200 --> 00:19.840 You're just, you might as well live here. 00:19.840 --> 00:20.840 Okay. 00:20.840 --> 00:22.840 Well, we'll go ahead and get started. 00:22.840 --> 00:27.440 We're going to talk about, well, if the, hey, look at that, we're going to talk about 00:27.440 --> 00:33.040 the developer experience and how it is more than just productivity metrics. 00:33.040 --> 00:34.040 They're not the same. 00:34.040 --> 00:37.400 They might have, they might share a word, but they're not the same. 00:37.400 --> 00:39.320 So we've all had that experience. 00:39.320 --> 00:45.720 Using a tool that or service, that was a disaster, I'm sure if I asked, you know, everybody 00:45.720 --> 00:51.040 just say it the same time of a tool or service, you could probably come up with one off 00:51.040 --> 00:52.720 top of your head. 00:52.720 --> 00:56.320 But that experience could be maybe your worst deployment process. 00:56.320 --> 01:00.760 You've ever seen could be the most painful code base that you've seen, hopefully you 01:00.760 --> 01:03.160 haven't looked at mine. 01:03.160 --> 01:04.560 Or it's maybe documentation. 01:04.560 --> 01:10.120 It's so confusing that you don't even know how you're supposed to, you know, use what 01:10.120 --> 01:12.840 the tool is doing. 01:12.840 --> 01:15.160 Who has had that kind of an experience? 01:15.160 --> 01:16.160 Yeah. 01:16.160 --> 01:18.640 Like it's pretty, it's pretty common. 01:18.640 --> 01:23.520 There are also plenty of examples, though, that we could point to, that really kind of illustrate 01:23.520 --> 01:25.120 a good developer experience. 01:25.160 --> 01:29.440 How many of you could also come up with a tool or so that you're like, I really enjoy 01:29.440 --> 01:30.440 using that? 01:30.440 --> 01:31.440 Yeah. 01:31.440 --> 01:35.280 They're very, they stick in our minds. 01:35.280 --> 01:38.680 One that for me, always comes to mind is, you know, think it back about Haroku, back 01:38.680 --> 01:45.480 in the day, and I say back in the day, 10, 15 years ago, you could, you know, as simple 01:45.480 --> 01:50.800 as get push, who wrote who main and you would have whatever you were building was now 01:50.800 --> 01:54.080 up running as simple as that. 01:54.320 --> 01:58.160 It was one of the simplest ways for, you know, developers to spend something up, really 01:58.160 --> 02:01.760 get started without a whole lot of, of headache. 02:01.760 --> 02:04.320 Now they've since made some changes. 02:04.320 --> 02:10.480 They're not as, you know, as easy as they used to be, but that was the core of that service. 02:10.480 --> 02:14.760 There's others that have now kind of come along, like, you know, NetLify kind of has 02:14.760 --> 02:18.040 the push, you know, push button, and now you can deploy a site. 02:18.040 --> 02:22.800 There's a lot of the same kind of idea, but the, you know, they're not the only game 02:22.800 --> 02:26.920 in town now that has kind of the idea of trying to make it as simple as possible for 02:26.920 --> 02:31.080 a developer to, to do their work and get it out there. 02:31.080 --> 02:36.800 My name is Jeremy Meese, a developer, head of direct, head of developer experience and 02:36.800 --> 02:39.840 developer relations at a company called One Stream Software. 02:39.840 --> 02:45.800 I also help organize step-up stays in Kansas City, and I am a CDF ambassador, so I'm glad 02:45.800 --> 02:47.440 to be here. 02:47.440 --> 02:57.400 Okay, so, because developer experiences self is such an integral part of, you know, 02:57.400 --> 03:00.840 like the entire development lifecycle, and yes, this is an AI-generated image, it's going 03:00.840 --> 03:04.400 to have all sorts of issues, it's just meant to be there. 03:04.400 --> 03:09.600 It means that, like, the ease of use, sort of reliability, you know, how accessible and 03:09.600 --> 03:14.920 understandable the documentation is, how efficient our processes are, the effectiveness of, 03:14.920 --> 03:19.480 like, our frameworks, and, you know, even the smoothness of those development procedures 03:19.480 --> 03:23.520 that we've talked about, all of those things have an impact on the overall experience that 03:23.520 --> 03:26.680 we have as developers. 03:26.680 --> 03:31.280 So I want to start with kind of a definition of, like, developer experience and developer 03:31.280 --> 03:34.920 productivity, kind of level set, kind of the differences that we're talking about here. 03:34.920 --> 03:39.760 So developer experience really is that journey that developers have as they are learning 03:39.760 --> 03:45.720 and deploying technology and developer productivity comes to how effective and efficient 03:45.720 --> 03:47.120 they are at producing. 03:47.120 --> 03:51.520 One is about that experience, the other one is about the bottom line, really, for the company, 03:51.520 --> 03:53.400 how can they make money as quickly as possible? 03:53.400 --> 03:57.200 They're definitely different. 03:57.200 --> 04:01.280 And also, I will have the slides you've already posted up and shared, so you'll be able 04:01.280 --> 04:03.000 to get those as well. 04:03.000 --> 04:08.680 But there's this subtle difference between, you know, developer experience, developer productivity, 04:08.760 --> 04:12.120 developer productivity is really, you know, how effective efficient, 04:12.120 --> 04:17.320 DevEx is the, you know, experience they have, and it's at its core, it's about the 04:17.320 --> 04:21.920 practitioner, it's about that developer, whether they are, you know, in the back end, 04:21.920 --> 04:28.360 maybe the front end, wherever they are within that cycle, those things, you know, they're 04:28.360 --> 04:34.680 not the same, developer experience and productivity, developer productivity is a metric 04:34.720 --> 04:39.200 where as developer experience is a feeling, it's at experience, what they're feeling 04:39.200 --> 04:40.320 as they are working. 04:40.320 --> 04:44.680 So sustainable productivity itself is not going to be forced. 04:44.680 --> 04:50.640 You're not going, you know, it's a natural outcome of a superior developer experience. 04:50.640 --> 04:55.320 It's, you know, DevEx is that leading indicator of kind of what the success of your organization 04:55.320 --> 05:01.080 is going to be, because you're really focusing on that developers, the, the lived reality 05:01.160 --> 05:06.680 they have as, you know, within your organization, well, the productivity is kind of lags 05:06.680 --> 05:07.680 behind. 05:07.680 --> 05:12.360 You don't know how productive things are going to be until you start to see the money 05:12.360 --> 05:19.560 in the bank, highly simplified, but it measures really that ultimate business impact. 05:19.560 --> 05:22.160 But developer experience itself is not really a new thing. 05:22.160 --> 05:26.560 The first mention of, you know, developer experience as a concept was in a paper that 05:26.640 --> 05:33.640 presented at the 2012 IEEE International Conference on Software and System Process in ZERC. 05:33.640 --> 05:40.080 In this paper, which I do have a link to that you can download or if you get downloaded, 05:40.080 --> 05:45.480 you can see me and I can get it to you, so you don't have to go through the IEEE process. 05:45.480 --> 05:48.880 There are references in that paper, though, that go back to some concepts and ideas 05:48.880 --> 05:55.200 back from 1985 that talk about like programmer performance and effects of the works. 05:55.200 --> 06:01.080 So we were thinking about this, you know, even 10, 20, 30 years ago, or 40, if I think 06:01.080 --> 06:04.440 about math correctly in 1985, 41 years. 06:04.440 --> 06:08.440 A few things do stand out in this paper that I'll share really quickly. 06:08.440 --> 06:13.320 The first is where, you know, it talks about these new ways of working where development 06:13.320 --> 06:18.480 was globally distributed and integrating, you know, self-motivated external developers 06:18.480 --> 06:23.560 into software ecosystems and would require a better and more comprehensive understanding 06:23.560 --> 06:29.040 of developers' feelings, their perspectives, motivation, identification with the tasks 06:29.040 --> 06:30.680 in the respective project environments. 06:30.680 --> 06:31.680 All that sounds great. 06:31.680 --> 06:36.520 Like that's what we want good experience for developers. 06:36.520 --> 06:39.400 The second thing that we really kind of stood out in this paper was that, you know, 06:39.400 --> 06:45.160 Devx could be a means for capturing how Devs think and feel about their activities at work 06:45.160 --> 06:51.920 and that improving their experience impacts things like sustained team and project performance. 06:51.920 --> 06:56.400 So this idea, the developer experience really over the last five, six years has really 06:56.400 --> 07:00.800 started to become a more talked about thing, people have, you know, developer experience 07:00.800 --> 07:04.960 engineers within their departments, the organizations now. 07:04.960 --> 07:09.680 But it is largely, you know, driven by companies that are trying to sell something. 07:09.680 --> 07:12.600 There's a lot of different tools out there that, hey, we're going to improve your developer 07:12.600 --> 07:16.560 experience or, you know, different frameworks that we're going to talk about here in a 07:16.600 --> 07:17.560 minute. 07:17.560 --> 07:21.240 But, you know, it doesn't mean that there's not good value in those things. 07:21.240 --> 07:26.000 But in a lot of those cases, they are more touching on that productivity and less about 07:26.000 --> 07:28.680 what is a good experience look like. 07:28.680 --> 07:35.480 So for decades, we've seen engineering leaders kind of grapple with, how do we measure 07:35.480 --> 07:36.480 productivity? 07:36.480 --> 07:40.200 You know, often relying on flawed metrics. 07:40.200 --> 07:48.600 Like who here has ever been judged by or graded or rated on how many commits you push 07:48.600 --> 07:53.320 to production right or, you know, how many changes to documentation or, you know, these 07:53.320 --> 07:55.160 are metrics that are easily gained. 07:55.160 --> 07:59.200 Like you can easily make yourself out to be a great developer within your organization 07:59.200 --> 08:03.400 because you've pushed, you know, 25 commits in a day when all it was, you're changing 08:03.400 --> 08:04.400 just a few things. 08:04.640 --> 08:10.720 That's, that's not good productivity, but it's a way to gain the metric. 08:10.720 --> 08:15.520 We have some frameworks now that are kind of shifted that focus to like the entire value 08:15.520 --> 08:17.840 stream itself. 08:17.840 --> 08:25.880 And with a lot of research around them, like Dora, Space, GetDX has kind of core for them. 08:25.880 --> 08:32.600 And they're all research back, but they really still are on that performance view. 08:32.600 --> 08:37.280 They have shifted that conversation from a lot of that pipeline metrics to more focusing 08:37.280 --> 08:39.360 on business align kind of metrics. 08:39.360 --> 08:45.680 When you look at these, you know, the shifts, some being more on the, like engineer side 08:45.680 --> 08:50.720 to all of a sudden, more, or the getDX side is more on the, you know, what does it look like 08:50.720 --> 08:58.120 for the bottom line for the C-Suite, you know, chief executive officers and whatnot. 08:58.160 --> 09:04.480 So what we've seen with these measurement frameworks in 2014, who's here as heard of 09:04.480 --> 09:12.440 Dora report, sure, yeah, it established really kind of this gold standard of, you know, 09:12.440 --> 09:18.760 how we measure DevOps pipelines to start out that way, giving, you know, proven it speed 09:18.760 --> 09:25.000 and stability are not really things that you are not trade-offs and that you can provide 09:25.000 --> 09:30.200 engineering teams with, you know, quantitative kind of evidence backed language for software 09:30.200 --> 09:31.200 delivery performance. 09:31.200 --> 09:36.440 That was the kind of goal at the, when it started, the Space Framework that was introduced 09:36.440 --> 09:42.520 in 2021 kind of came through collaboration with Microsoft, and it built on Dora, adding 09:42.520 --> 09:48.200 in some kind of more holistic human-centric kind of models that argue that productivity 09:48.200 --> 09:49.920 is really multi-dimensional. 09:49.960 --> 09:56.400 It's not just one, or, you know, or getself, but it's, you know, the importance of the satisfaction. 09:56.400 --> 10:02.120 They did add some experience pieces, the well-being, how your developers are actually working, 10:02.120 --> 10:10.360 our critical components of performance, and then getDX in 2024, a few years ago, they kind 10:10.360 --> 10:16.960 of tried to add a lot more business kind of impact to it, and their biggest thing was, 10:16.960 --> 10:22.840 like, practical, prescriptive frameworks that you can kind of put all of these things together, 10:22.840 --> 10:29.160 creating kind of that direct link between, okay, here's what your department can get the 10:29.160 --> 10:34.760 value to the bottom line, how you can report up to the executives based on how your teams 10:34.760 --> 10:35.760 are performing. 10:35.760 --> 10:41.840 So, kind of tried to draw that direct line, but it was more like ROI and revenue, and less 10:41.840 --> 10:46.440 about, like, how are people actually working and how are they enjoying their jobs and 10:46.440 --> 10:51.920 how well are they actually being efficient as a result of the things they enjoy doing? 10:51.920 --> 10:58.280 So, building a great developer experience is not something that comes by accident. 10:58.280 --> 11:00.280 It's built with, you know, the developer in mind. 11:00.280 --> 11:03.560 People are actually using the tools that you have inside your organization. 11:03.560 --> 11:10.280 I mean, here has a tool that you're using that was kind of forced upon you, and you know 11:10.280 --> 11:15.480 that it doesn't work great, but because somebody, you know, swipe the card and said, okay, 11:15.560 --> 11:20.560 we got to use that tool now, yeah, like, we've all kind of had something that we wish 11:20.560 --> 11:23.840 we were using some other tool. 11:23.840 --> 11:28.440 So, you know, a good developer experience is minimizing a lot of that friction, reducing 11:28.440 --> 11:33.040 the mental overhead, and enabling a lot of deep, focused work. 11:33.040 --> 11:40.760 So, we'll dive into each of these pieces and add some actual, you know, some key steps 11:40.760 --> 11:45.720 you can take, and then we'll talk about what kind of some good baselines are for how you 11:45.720 --> 11:49.320 can get a measurement about developer experience. 11:49.320 --> 11:52.560 So, that'll be our kind of end result here from here. 11:52.560 --> 11:59.240 So, a core developer experience and really devops in anything related with the software 11:59.240 --> 12:04.880 development pipeline is going to be fast high quality feedback loops. 12:04.880 --> 12:09.480 Being able to have, you know, some ways you can put this in a practice would be, you know, 12:09.520 --> 12:14.160 you can have visual regression testing now within your CIC pipeline. 12:14.160 --> 12:20.680 You can have it to where, you know, tools like Backstop, Percy, Appletools, they all have 12:20.680 --> 12:25.920 ways that you can take like a screenshot as part of the process of the, you know, your 12:25.920 --> 12:34.440 UI to compare it against kind of that baseline to see was there a regression change. 12:34.440 --> 12:37.000 Catch some of those before they go to production. 12:37.000 --> 12:42.760 You can integrate a lot of static analysis in linting tools like ESLIN, SONERCube, check 12:42.760 --> 12:48.520 style in your developer IDE's before things even get to production. 12:48.520 --> 12:54.520 Husky and conventional commits are great ways to kind of standardize your commit messages 12:54.520 --> 12:59.560 so that you can kind of, and help you focus on like some of those code style variations 12:59.560 --> 13:06.080 that make it hard to review to you set a lot of that stuff at the beginning. 13:06.080 --> 13:11.320 And then implementing, you know, robust monitoring systems, canary deployments you hear 13:11.320 --> 13:17.280 it uses progressive delivery or like feature flag kind of things, yeah, like that type 13:17.280 --> 13:22.760 of thing can really help you, you know, catch a lot of those issues, measure your deployments 13:22.760 --> 13:29.520 over time, dedicating you know, specific time slots during your sprints or during a 13:29.520 --> 13:34.560 week for, you know, pair programming sessions that you can kind of come up with new ideas 13:34.560 --> 13:38.440 makes, you know, help with kind of force yourself and your organization into some really 13:38.440 --> 13:45.240 good ways to help onboard new developers and also help the juniors learn and become senior 13:45.240 --> 13:52.120 and senior, you know, learn from that as well, but that immediate feedback really helps 13:52.120 --> 13:56.960 with development, you know, instead of having to wait for a review or something later 13:56.960 --> 13:59.720 down the line. 13:59.720 --> 14:04.240 And then like bug bash events, I've had, I've seen some companies over the years that 14:04.240 --> 14:07.800 will, uh, something that I've even worked at that would do like, hey, once a month, we're 14:07.800 --> 14:12.240 going to just, we're going to, on one day, we're going to just spend time dealing, going 14:12.240 --> 14:13.240 through all the issues. 14:13.240 --> 14:16.080 We're going to beat those bush, the beat those bugs down. 14:16.080 --> 14:21.080 We're going to, you know, that was actually the term that was used, uh, but like this, this 14:21.080 --> 14:26.000 way of looking kind of, uncover some issues that might be found earlier, or might be 14:26.000 --> 14:30.240 found later, kind of get them done, find them and get them done all at once. 14:30.240 --> 14:35.040 Those are good ways to boost that feedback loop, which gives them a lot better experience 14:35.040 --> 14:39.000 for a developer than to have to wait until they've context switched and forgot what 14:39.000 --> 14:40.000 they did back then. 14:40.000 --> 14:43.280 And now we have to, you know, just take longer. 14:43.280 --> 14:47.320 Uh, we think about like low cognitive load for your teams. 14:47.320 --> 14:50.760 That is your, you know, implementing and forcing consistent code style. 14:50.760 --> 14:56.040 So, you know, we talked about ESLent, there's, you know, prettier, some other, like things 14:56.040 --> 14:59.760 that are out there for different, whatever your team might be using from a programming 14:59.760 --> 15:01.800 language perspective. 15:01.800 --> 15:05.320 You can also, like, you've, hopefully, I would think at this point, everybody's using 15:05.320 --> 15:07.880 version control in some, some way. 15:07.880 --> 15:13.880 Uh, so you can put in, you know, like, those commit message hooks to make sure that, you 15:13.880 --> 15:15.640 know, you have some uniform format. 15:15.640 --> 15:19.280 So when you're looking at your commits, it's easy to see what's actually happened. 15:19.280 --> 15:24.520 It's not just some, you know, a couple lines of, you know, if you look at my commit histories 15:24.520 --> 15:31.560 of, like, well, F, EAML, and that, like, you actually have the idea of what's actually, 15:31.560 --> 15:34.720 what was done, what work was done, so it's easier to review. 15:34.720 --> 15:40.160 Also, having, you know, those times in your sprint address technical debt as part of your 15:40.160 --> 15:41.160 sprint. 15:41.160 --> 15:44.440 I know people are like, oh, we could do, we'll push technical debt later. 15:44.440 --> 15:49.440 Like, it's easier to deal with it now than to deal with it a year or two later, uh, 15:49.440 --> 15:54.960 it's always cost more, um, a single source of truth for all project documentation. 15:54.960 --> 15:59.480 Um, how many of you have here, have something like that so that you know what, when 15:59.480 --> 16:03.680 you're building a project, like, with all the decisions that are made and all of the, uh, 16:03.680 --> 16:10.480 the template that you're going to use for the project or, uh, just the decisions that, uh, 16:10.480 --> 16:12.920 when you are encountered this, here's how we're going to handle it. 16:12.920 --> 16:16.520 Like, who has projects documented in the way that you know right now where you're going 16:16.520 --> 16:18.520 to go get it, just a couple. 16:18.520 --> 16:19.520 Okay. 16:19.520 --> 16:24.360 It's a great way to reduce a lot of that, uh, uh, have documentation as part of the workflow. 16:24.360 --> 16:28.440 I know as engineers and such, like, we don't like doing documentation, but some simple 16:28.440 --> 16:33.880 ways to just keep things documented is going to help, uh, everybody in the long run. 16:33.880 --> 16:39.360 Um, make sure you do a lot of automated tests, unit integration, uh, end to end, all those 16:39.360 --> 16:40.360 type of testing. 16:40.360 --> 16:44.280 Hopefully everybody's doing testing and just nod your head just so I feel better 16:44.280 --> 16:50.920 that we're testing our things, uh, beginning that rapid feedback as part is going to, uh, 16:50.920 --> 16:55.600 going to really help us with that, we don't have to think as much about what again, what 16:55.600 --> 16:58.040 do we do six months ago, we're catching it early. 16:58.040 --> 17:05.960 Um, there you are, uh, and then improving your flow state, that is, you know, how many, 17:05.960 --> 17:10.760 are, uh, get frustrated with all of the notifications you're getting, not just from your 17:10.760 --> 17:18.400 phone, or I even get happy, everybody's like, yes, me, uh, like, constantly inundated with 17:18.400 --> 17:23.560 a notification about this build or about, you know, some email you got to go to or some, 17:23.560 --> 17:29.640 like, we're just, notification overload, uh, so getting away from, especially within your 17:29.640 --> 17:34.680 development teams from, like, everything gets emailed out or everything gets notified 17:34.680 --> 17:39.440 doesn't have to be an email note itself, it could be a slack, you're always getting 17:39.440 --> 17:46.800 message and slack for everything, um, only notify from things that break. 17:46.800 --> 17:51.200 That's where you should be worried about it, not that, hey, this build, uh, you know, it 17:51.200 --> 17:56.560 worked or there's been a comment and it has nothing to do with anything else, like, assume, 17:56.560 --> 18:04.040 uh, you know, uh, make the decision based off of, why does it really matter? 18:04.040 --> 18:06.920 Does that notification really matter for me? 18:06.920 --> 18:10.400 Or is this something that we don't have to tell everybody about and maybe we just have 18:10.400 --> 18:15.160 a small group and not everybody joins, like, don't have to notify and everything. 18:15.160 --> 18:22.120 The amount of time we have to get break our flow when we're working, uh, come pounds 18:22.120 --> 18:24.640 the amount of time we've lost and wasted. 18:24.640 --> 18:26.520 Uh, have a code review process. 18:26.520 --> 18:32.760 That's prioritizing your speed and constructive feedback, uh, like, put guidelines for 18:32.760 --> 18:38.280 how the code reviews are done, uh, so that there is, like, clarity, you can maintain it. 18:38.280 --> 18:43.840 There's kind of architectural consistency with how it goes through, like, how many of you 18:43.840 --> 18:47.480 have just one person, your organization, your team that does code reviews? 18:47.480 --> 18:53.520 Okay, just a couple of you, how many have, like, a team of people that it goes through, 18:53.520 --> 18:58.960 yeah, somebody that's just, just me, uh, having, putting an, in fact, GitHub does this 18:58.960 --> 18:59.960 now. 18:59.960 --> 19:03.880 There's other ways you can do it to, that when there, you request a code review, it can 19:03.880 --> 19:09.160 do a group, pick from a group of people, kind of do a round robin, instead of it being 19:09.160 --> 19:17.240 the same person, uh, that cognitive load of always having to review, uh, gets us, we're 19:17.240 --> 19:18.240 humans. 19:18.240 --> 19:23.320 We're not great at repetitive tasks, uh, so break that up, have someone else do it. 19:23.320 --> 19:29.400 And make sure that, you know, there's a, um, that there, there's actual suggestions. 19:29.400 --> 19:34.320 It's not just nitpicking, uh, things that actually matter, because you've set up the structure 19:34.320 --> 19:37.160 of how you're going to do your code reviews and how, what they're the things you're 19:37.160 --> 19:41.960 checking for, uh, make those go a lot quicker, and you're not just getting nitpick comments 19:41.960 --> 19:47.400 that don't really matter, uh, ensure everyone's working from the same baseline and standards. 19:47.400 --> 19:51.400 So have that, like, development environments, everybody's on the same, have a, you know, 19:51.400 --> 19:55.560 special with onboarding, you make sure everybody knows, here's where we go, this, again, 19:55.560 --> 20:01.960 goes back to having good project documentation, uh, break, work down into a lot more manageable, 20:01.960 --> 20:07.360 uh, chunks, um, there's ways like Pomodoro technique where you can kind of, just take 20:07.360 --> 20:10.800 a short period of time to work on this, and then go take a break, and then come back 20:10.800 --> 20:15.640 so that you're not just, uh, losing focus, you know, maintain focus, there's other different 20:15.640 --> 20:21.640 ways to do that prevent, uh, burn out, have that be a structure to approach that everyone 20:21.640 --> 20:28.600 uses and not just something you suggest, um, encourage asking questions, like how many feel 20:28.600 --> 20:35.760 like within your organization, you could be asking questions, uh, and not feel like, uh, 20:35.760 --> 20:39.680 somebody's shining a spotlight on you that you don't know what you're doing. 20:40.320 --> 20:45.840 Okay. Good. Um, having that space, if you're an engineering leader, uh, within your 20:45.840 --> 20:51.120 organization, like make sure there's that space for those questions, and that every question, 20:51.120 --> 20:59.200 uh, is treated with the same kind of respect. Uh, yeah. Uh, but when you introduce a measurement 20:59.200 --> 21:06.240 system or any way of trying to track something, uh, there is that inherent, uh, risk of misuse, 21:06.400 --> 21:12.400 um, good hearts law who are here is heard of good hearts law before. Okay. It is really that 21:12.400 --> 21:18.160 idea that, um, you know, when a metric becomes a target for, you know, performance evaluation, 21:18.160 --> 21:21.760 it's ceased to be a good measure because you can gain it. You can do the things that's going 21:21.760 --> 21:27.440 to make it look better, and other plate things are going to suffer. Um, so if you're incentivizing 21:27.440 --> 21:34.000 those things that are based on like a number, uh, it's very simple to just do what it takes to hit 21:34.080 --> 21:40.240 that number. Uh, so, you know, we're, it's imperative that we look about at DevEx, and even 21:40.240 --> 21:46.480 with productivity metrics that we're using them as tools for systemic, uh, you know, improvement, 21:46.480 --> 21:52.480 not as like this instrument for judging or ranking things. Uh, it's important to keep that in mind. 21:53.760 --> 21:59.360 Okay. So when we think about like moving from the abstract to, uh, actionable, uh, you really want 21:59.360 --> 22:04.400 these kind of metrics, these are kind of, uh, like conversation starters and not just like, 22:04.400 --> 22:09.520 hey, this is always going to be the thing. Use these, you know, to start those conversations, 22:09.520 --> 22:15.760 not just for judgment. Um, these are some six that we'll touch on really quickly. Uh, I want to 22:15.760 --> 22:20.240 stress these are not like one size fits all, uh, just because there might be a number here. It's 22:20.240 --> 22:24.560 going to be a baseline. Always look for what your baseline is, and then adjust from there, not trying 22:24.560 --> 22:28.800 to hit something that's, uh, mythical that you might have read on a blog post or heard some 22:28.800 --> 22:35.440 speaker say you should, uh, go for, uh, sorry point, not an end point. So cycle time, it's that, 22:35.440 --> 22:41.120 uh, time it takes to go for my data production. Uh, so, you know, having small batch sizes, 22:41.760 --> 22:46.240 uh, test automation, CIC pipelines, like, you know, hopefully preaching of the choir there, uh, 22:46.240 --> 22:50.640 you know, have in development environments set up in standardization, everybody's in the same, 22:51.360 --> 22:54.640 uh, using the same things, developing the same way, uh, 22:55.520 --> 22:59.920 proactively identifying remove those issues that kind of, you're always having to ask questions. 22:59.920 --> 23:04.960 You're always having to depend on someone else's work, minimize, or, uh, you know, remove those, 23:06.560 --> 23:11.040 PR review time. That's, you know, that also plays into the cycle time. So that's, you know, 23:11.040 --> 23:16.480 make sure you have guidelines around smaller PRs where it's possible. Um, automate those as 23:16.480 --> 23:23.440 possible, uh, have that reviewer rotation we talked about, mandate clear in concise PR restrictions, 23:24.240 --> 23:30.800 have SLAs for, you know, poor request, poor request reviews, make that visible. Uh, especially if you have 23:30.800 --> 23:35.600 a organization that's, you know, there's a lot of poor requests out there, uh, to good kind of 23:35.600 --> 23:41.680 way to help raise the, that there's a lot of cognitive load happening, and that you need to, uh, 23:42.640 --> 23:48.880 help drive some change instead of keeping that in that cycle. Uh, rework rate is really that 23:48.880 --> 23:52.800 percentage of work that has to be read done. How many times have you had to read done a, 23:52.800 --> 23:58.800 redo a, a commit to redo a poor request, uh, maybe because scope changes, because that's happens a lot. 23:59.840 --> 24:06.800 This is a good way to keep track of how often is that happening. Uh, that would be a negative 24:06.800 --> 24:11.440 that would not get great metric to have that you have a high rework rate. So, you know, 24:11.440 --> 24:16.800 that can help with user stories, uh, have you can also look at that as, you know, help with better 24:16.800 --> 24:23.680 tooling, uh, have a robust definition of what done looks like, uh, as opposed to, uh, with a lot of 24:23.680 --> 24:29.920 sprints, it's like, uh, we're never done, uh, that's not actually great, uh, enforce that kind of 24:29.920 --> 24:34.560 what does it look like to be done? Uh, you can also improve your feedback loops and communication 24:34.640 --> 24:42.080 is a result of understanding what your rework rate is. Uh, also we talked about, like, how many people 24:42.080 --> 24:49.360 spend more time on meetings than actual development? That's, yes. Uh, so have a meeting free day, 24:49.360 --> 24:54.560 or even just an afternoon or something that blocks out that time, so you don't have to have those meetings, 24:55.840 --> 25:02.320 have standard meeting agendas, uh, make sure that, uh, you know, you're auditing who gets invited, 25:02.400 --> 25:07.920 how many people are actually participating, uh, because, like, not 15 people don't need to be there. 25:07.920 --> 25:13.360 It might just be free and really else can actually do work, uh, have a meeting budget that if you've 25:13.360 --> 25:19.520 already meet that, met that? Well, catch me next month. Uh, new hire onboarding, uh, making sure 25:19.520 --> 25:25.920 that you have that going, uh, so that's really good there. We'll get through the last, we'll give 25:25.920 --> 25:33.920 this last little slide, uh, there. So these are the quick breakdown, uh, and, uh, yeah, just establish 25:33.920 --> 25:38.480 that baseline, know where you're at and adjust from there. Uh, there's a few other things that are 25:38.480 --> 25:45.920 in the slides, but, uh, really want to focus on, like, get, remove the barriers that get in the way 25:45.920 --> 25:50.720 of your developers being successful and it's important to understand how they're working and how 25:50.720 --> 25:56.720 that influences the productivity as well. So with that, thank you.