Featured Speaker – Brian Keith (Engineering Manager at Duo Security/Cisco)
Topic – “What is Developer Productivity?” Brian will be sharing perspectives on how we can organize our work with a focus on Developer Productivity from his recent learnings and experiences leading product development engineering and DevOps teams. If you are part of the software development process in your work or you lead a software engineering team and you can’t stand inefficiency and wasted time – this is for you.
Transcript: What is Developer Productivity?
Jim Shilts 0:02
Welcome, everybody. Welcome to this edition of DOGCAST. This is the DevOps group webcast by North American DevOps group, also known as NADOG. I mean, you can find us at NADOG.com. I am Jim Shilts on the leader and organizer of NATO dog. And we have a great talk plan today with Brian Keith. He’s an engineering manager at Cisco duo. And Brian’s talk is titled, What is developer productivity? Brian just shared this talk a few weeks ago with us at our Southern California event at NADOG. If you’d like to attend a local NADOG event, joining us free check the links in the description to become a free member to register for Upcoming Events, and also to join us on slack to continue the conversation there. And also, if you would, if you would, please take a moment to like this video and subscribe to the channel. We agree greatly appreciate that as well. So does now my pleasure. Let me turn him on. There is now my pleasure to introduce our featured speaker, Brian Keith. Like I said, Brian is an engineering manager at Cisco duo. Brian also has the distinction of being one of eight lucky attendees of the very first NADOG event seven years ago, here in Southern California. Brian, thanks for being on the DOGCAST here to share your talk with the rest of the community.
Brian Keith 1:16
Absolutely. My pleasure. Thanks, Jim.
Jim Shilts 1:19
So I’m going to ask you to do two things here before you start your talk one. Share your very first role. What was your very first role in tech? And then also, I’d like to hear your recommendation for local restaurant, bar brewery, anything like that?
Brian Keith 1:35
Yep, sounds good. So my first role in tech was kind of unintentional, I was at a bookstore, selling music and books and things of that nature. And the computer point of sale system was on a 10 base T network. And because no one else really had the desire to fiddle with it, I got to be the guy who managed kind of, you know, plugging in BNC, cables and connectors and also just trying to keep the system up and running and re indexing databases and things of that nature. So that was kind of my first unintentional unofficial role in tech. I’ll talk a little bit more about some of my more official roles a little bit later in my talk. But then, as far as some recommendations on places to eat, I’m going to give you two so one is if you’re looking for like a nice night out, you want to get a decent meal where you’re being served well and the food’s good. There’s a spot not too far from where I’m at called reunion. recommend you check that out. It’s up in North Orange County. And then if you like a good cup of coffee, there’s a coffee chain in my area called Bodhi leaf, highly recommend that to different kinds of brew but still brew nonetheless. Bodhi leaf Bodhi leaf, Bo d h i, yeah.
Jim Shilts 2:45
Ah, I Okay, cool. Sorry. I’m taking notes here. I take these recommendations seriously. Awesome. Well, thank you, Brian. I’m going to actually step back now and give you center stage. I want to thank you again for joining the webcast today. And I’m gonna turn on your screen and give you the mic.
Brian Keith 3:02
Sounds good. All right. Thanks so much. So what I want to talk about today is the topic of developer productivity. But before I get into the topic, I wanted to just share a little bit about my career journey. And we talked a little bit obviously about where I landed at the bookstore and how I initially had my first forays into tech. But let me talk about the professional journey a little bit. So I was born and raised in Southern California, I lived here all my life and went to school at Azusa Pacific to study computer science. And the reason I did that is just because that was one of the areas of interest I had at the time, the other was music.
The other was aerospace, but decided, you know, hey, I better follow this kind of tech thing and see where it goes. And when I was in tech, the one thing that was really not clear to me is what I was going to do with this degree, it was really, you know, that was kind of the path that was really only one degree at the time that was in the computer science realm. It’s in the late 90s. And so after graduation, I just did a little bit of networking, talk to a couple of folks that I knew and trusted in the area and learned about an opportunity with a company that was writing software for time and attendance purposes called e labor.com.
We had a product whereby people would you know, badge in and badge out of software systems so that they could get their paycheck turned or their their time cards turned into a paycheck. And so we’re to the labor and kind of a hybrid role. One was doing tech support working with large enterprise companies like Arizona Public Service carrier, air conditioner, even Mountain High the ski resort up here in the local mountains. And the other part of my role was to build software for the business on a system called remedy and for those of you who may have used it in the past or been exposed to it, the thing that was actually a lot of fun about remedies, you could build software systems really quickly so you could get great prototyping out you could put up ideas and make iteration into the software very quickly and rapidly. Did that for about two and a half three years in a hybrid role? Where then I decided to go ahead and do full time development for Net Zero they used to ride free internet service on If you remember these days will CDs, you pop in the mail and you get free dial up internet in exchange for having a little ad running on the side window of your computer screen.
And so did that for about eight or nine months and decided it was time to maybe shift into a slightly different arena of Southern California and took an opportunity with Broadcom in the IT department was kind of brand new and getting up off the ground, landed into an opportunity where I used the remedy system to build different software solutions for the company and the IT services management space. And really had a great time doing that during a time when the company was growing. And we were scaling and things were just exponentially going nuts. During that time period, I think I joined a company we had like 3000 employees. And you know, when I left, we had 16,000, initially we were doing like 900 million in revenue. And when I left we were around eight $9 billion range. And really was fortunate during that time period, that the way leadership had things structured is that there was a platform ownership mentality. What that meant is I was responsible for the entire ITSM platform. And so I got to wear all the hats related to the software development lifecycle. So I did business analysis, I did coding, I did support the testing, I manage releases, I did project management, so on and so forth.
What is Developer Productivity continued
And at the time, I didn’t realize that those are independent disciplines, and they are in our industry today, they’re unique, but during that time period really enjoyed being able to kind of see end to end how you can take an idea and get it into production in the long run. And so when we had a change in leadership, I took an opportunity at that point to shift more formally into project management. During that time period, I learned a lot about vendor management, business relationships, working with legal and finance, and so W’s and all the different elements around keeping the business side of the technology working, enjoyed that as well. And I stayed in that role for a time period until I realized that by the delivery of projects involved onboarding people, and I had a team of about 45 that I was responsible for. So I looked behind me, I realized I needed to figure out what it was what type of manager wanted to be in what really is this discipline of management, how do I bring myself to the team as a good manager.
So I shifted more formally, and people management did that for about two to two and a half years until the company got acquired. When they were acquired the Ria, they decided that they didn’t need my role in the long term organization, and pursuant to some recommendations of some friends of mine had looked into the startup space. And so shifted over to humera, where I served as the director of software engineering for about three to four years, and then only recently decided to shift back out of startup go more into the corporate world where I’m now with do overseeing engineering efficiency, along with another team. And we are focused on you know, our issue tracking system, our software configuration management system, ci CD, build systems, and etc, as required to help to build great products for the market. So that’s been a little bit of my kind of professional journey, just wanted to paint that picture a little bit. But with that, let’s go ahead and get started. So first things first, with a talk like this, I just I want to just start by saying developer productivity in and of itself is a journey. It’s not a destination, I don’t want anyone to, to who watches this talk to get this idea that I’ve got it all figured out, I have all the solutions and everything’s perfect. What I want to share today as a piece of this journey, but please know that I’m far from being an expert, I’m just going to share kind of my experience, what that’s looked like what I’ve learned along the way, and maybe some ideas on some things that you might want to apply in your organization.
Specifically, I’m going to talk about what this journey looked like for me. But again, what you apply to your organization might need to be fine tuned or tailored based based on where you are and what the areas of opportunity are for you and your organization. So at the beginning, realize we had an issue, we were trying to get code changes into production. And we were not able to consistently and reliably get those code changes in the prod, we had schedules where we had about every two weeks, we decided that we wanted to release the prod, we’d have everything lined up and all the people lined up all the resources lined up, and we’d go to release and we’d find unexpected issues, unanticipated problems. And it got me to thinking, what is everybody else in the industry doing? And maybe this is normal, maybe this is just the way it is. And this is the way other organizations are dealing with this is no different than we are. So one of the organizations I was volunteering my time with was an organization called playdough. And it’s designed to help brand new engineering managers that are new to the engineering management discipline to connect with more seasoned engineering managers, and even directors and VPs of engineering. And while I was on one of their their summit sessions, I heard Christian McKarrick talking about this book called Accelerate specifically around the topic of measuring productivity and identifying productivity as it relates to engineering. And so I said Gosh, I feel like this is this is probably the book I need to go get I need to understand this because a lot of different organizations will have different definitions for developer productivity is and I wanted to find out like, what is the rest of the industry doing specifically, you know, with OS zero, and now he’s with Facebook, these great companies that have a phenomenal reputation in the market.
What I really wanted to understand is, what are they doing? And what are the things that I might be able to learn from some of these organizations. And so as I started to read through the book, what I learned is that there’s an annual report that’s put out by an the some of these folks here on the screen, as well as some other fine folks, they call the state of DevOps report, what they do is they go, and they query a bunch of different technology companies. And they asked them a series of different questions. And they pull all that data back and put it into a report that basically says, This is how technology organizations are doing as it relates to delivering software into their companies in their organizations. And it got me to thinking like, okay, there’s this really great question about developer productivity, but I needed to have some semblance of a target. And so as we think about developer productivity, one of the things I realized that my organization is that we didn’t have a consistent and agreed upon target, we would have a target that we thought was the right one, but maybe it was, and maybe it wasn’t, some of the typical, you know, targets that people shoot after, when it comes to developer productivity is things like lines of code, or number of hours spent coding or number of commits per sprint, number of bugs fixed, could be story points as an example. But one thing, though, that was really interesting is that as we started to really think about some of the more classic or traditional definitions of productivity, my question was, does that even make a difference in the long run of an organization’s health or an organization’s success? Is that really the target that we all should be shooting after?
Like, if I write more lines of code, does that really get us where we need to go? And many of your listeners will understand and agree that sometimes it’s actually more beneficial to reduce lines of code not to add lines of code. And in some ways, we have to have the right target in front of us for developer productivity before we know that we’re making a positive difference in the business. So got me to thinking about this topic of developer productivity. So why does developer productivity even matter? Why do we even spend any time talking about it? The research from the state of DevOps report actually highlighted some of the very, very important reasons related to developer productivity. So companies exist for a reason, typically, their for profit or nonprofit, they want to solve a problem. They want to create revenue, they have a vision or mission, typically, they have objectives and key results. One of the really great things that that stated about support highlighted is that all these different organizations that have objectives and things they want to get done, there’s a direct correlation that they discovered between organizations that have high level of organizational performance and those that have a high level of software delivery performance. So if an organization is doing well on their goals, typically underneath the foundation, there’s a technology component that also is doing well. So that led me to this roadmap that comes out of the book. So if you have a copy of the book, you can actually find it in the state of DevOps report, as well. Use looks a little bit like this. And plus is on if you have the book, it’s on page 208, if you want to flip to it, or use that as reference, and over here on the right hand side, what you’ll see is that organizational performance tends to be the goal of most organizations and goals, they want to achieve their goals, if they’re a nonprofit, they want to deliver services and values to people who have need. But as it relates to organizational performance, the one thing that really stood out to me when I looked at this report is that software delivery performance has a direct impact on an organization’s ability to do their job.
What is Developer Productivity continued
That means that for those of us who are involved in productivity, or in software delivery, we have an opportunity to have a very significant meaningful impact on our organization’s abilities to get the things done that they want to get done, this allamuchy. But this was kind of exciting to me to know that we were in such a key place in the organization to have that level of impact. So the first thing that I pulled out of this was just this very important element of impact. And the thing, the thing that was interesting, though, if we go back to this report here on the roadmap, is that all of this requires a definition. Before we even get into developer productivity, we need to understand like what is software delivery performance. So fortunately, the report gave us some definitions. And as they looked at all the data, and they crunched all the numbers, what they found is it wasn’t so much lines of code, but there were four specific areas that they call the productivity metrics. And when organization software delivery and development organizations are doing well on these four areas, they can have a positive impact on the organization’s ability to execute. So those four different areas of performance of four different metrics are the frequency of deployment. So how often do you deploy your code changes to production? Your lead time for change? That is how long does it take you to get a code commit into production? is your time to restore service? If and when you have a service issue? How long does it take you to get your service back up and running? And then how frequently do we have failures as it relates to changes in the organization? So those are some really cool metrics. And I mentioned a couple he’s like, how long does it take. And that’s so obviously, on these four, there’s a, there’s a spectrum, there’s a range of performance, where one would be considered high performance and won’t be considered low performance. And so again, as we started to call through the data in this book, and accelerate, and in the reports, one of the things that we found is that there’s this really great definition for organizations that are either considered high, medium, or low performing against these four metrics.
So what I want to show you now is what the different ranges are related to those different performance metrics. So here are the four different metrics define that definitions on the left. And again, this comes straight out of the book, and straight out of the report. So I just went cut took a screenshot, drop it in here, so we could talk about it. Um, as you can see, we’ve got different columns on here. So I’ll start with deployment frequency. And you can see that if you’re in a lease, or the highest performing organization, you’re deploying multiple times per day, if you’re on the low end of the spectrum, maybe you’re deploying less than once every six months. Same thing for lead time for changes, we’ve got the spectrum of performance between elite high, medium, and low, and so on, and so forth down to four metrics. And what was really cool about having a matrix like this is it gave us an opportunity as an organization to self assess. So I’m going to show you where we landed. But if you have access to this information for your organization, I encourage you also to evaluate yourself and your org and see how you’re doing against these different areas in the spectrum. So as we looked at our deployment frequency, we were somewhere in between once a week to once a month, we were kind of in that high range, opportunity area for developments improving that space. But then obviously, too, you know, we weren’t doing super bad. As far as lead time for changes, we were somewhere between the high in the medium range, a little bit more than a week, but less than a month. And then as far as time to restore service, when we had issues, we were less than one day, usually we could get things back up and running really quickly.
If things have problems in production. What are changed bill rate is where we were having some significant problems. So at least at that time, any organization, we had a higher than 30% Change flow rate when we were pushing our changes to production. So it was pretty clear that there was some room for opportunity, if we were to align around these different metrics, and I’ll cut to the chase, we actually did, we decided these were great metrics for us, because we wanted to have that positive impact on the organization. And so with this, we decided, yes, let’s go ahead and continue to measure our performance against these four metrics. Now, this reports been going for a number of years. And so as the group has been tracking this data, one of the things that they’ve noticed is that by doing the survey year after year, after year, organizations are generally maturing and are getting better at these different metrics. And so one of things I want to show you next is the way that different organizations have matured across the last few handful of years. So what you can see here is across 2018 19, and 21, there has been an increase in the number of companies operating at the high and the elite level of performance.
There was not a report done in 2020, due to pandemic, but you can see here that even in the midst of all of the stuff that was going on in the world, at that time period, there still has been an improvement. And so as I looked at these, you know, these different breakdowns, and I Okay, 26 of the companies that they surveyed come back as elite, how did I kind of guess that we might land as an organization across these four different bubbles, and in my, you know, kind of non scientific assessment is that we would be somewhere in this high to medium range. So we’ve got this great kind of set of metrics. We’ve got this, you know, report, we’ve got some excellent data. But now the question was, how do you go in and implement this and in a team in a way that has a positive outcome? It’s great to have the information. But the next step was, how do we apply it?
So what I wanted to talk about now is what I’ll just call it levers and dials. So let me quickly go back to the accelerate roadmap. And the way you can read this chart is that the items on the left side of the screen have an effect on the things on the right side of the screen. And so if I want the things that are on the right, if I want high performance, if I want job satisfaction, if I want less deployment pain, if I want greater organizational performance, those are things on the right, then I have to have an intentional focus on some of the things that are on the left half of the screen. So first thing I did is I took in just a view, just kind of an assessment of the organization asked myself, How are we doing and what are the areas of opportunity as it relates to this framework, this this roadmap that accelerate puts in the book for us, and there were a couple of different areas that popped out to me me right out of the gate is areas that we could be a little more cognizant, a little more intentional about. The first one is that we wanted to talk about culture. And so I’m going to talk about culture in a minute. And some of the things that we discovered some of the things that we found and some of the things that we wanted to do to make sure we had a healthy culture. Because according to state of DevOps report, we find that a Western culture, and I’ll talk about that in a minute, can have a positive impact on your performance on job satisfaction and on your software delivery. The second thing that we wanted to focus on was decreasing deployment pain and having less rework. So I talked a little bit about this earlier, there were some challenges related to deployments. And I said, Gosh, would be great. If we could just reduce the pain, we would have to rework as much. But in order to have a positive impact on your deployments, you need to have a concerted focus on continuous delivery. So this was our next area of focus. And you can see there’s only one real line going into continuous delivery, it’s that box down in the bottom left corner. So I looked at that list. And I asked myself, what were the different areas in that bottom left corner that we needed to focus on? For us, it was deployment automation, it was loosely coupled architecture and version control. And I’d encourage you, as you take a look at a roadmap like this, just know that this was our picture. But if you’re going to do an assessment for your organization, I encourage you to be honest with yourself about what are the different areas that your team needs to make some improvements, if any, maybe it’s only one, maybe it’s everything. But this is the picture as it looked for us at the organization at that time. So let me first talk about culture, I want to tell you what we did in the depart in the area of culture to really have an intentional focus on it. So a couple things I want to say about culture.
What is Developer Productivity continued
First and foremost, culture. By and large is not an accident, it’s not something that you can just have happen perfectly without having an attentional focus leaders and leadership team needs to be focused on culture and intentionally define the type of culture that they want. And I’ll talk about some some different styles that are out there. And you need to have a focus on actually implementing that enacting that away on a day to day basis. So there’s been a couple different definitions tossed out there, you can drop out to Wikipedia, you can look at the other ways of books are written on it. But the difference, the definition that I like to use, for me personally, is it’s the way things are it’s the behaviors that are encouraged, rewarded and tolerated. It’s not the, you know, nice fancy saying that they’re on the wall. But it’s the behavior that you see that you that you can observe around you and the way that people actually behave towards one another. So let’s talk about the work that Google did related to culture and having an assessment on culture. So there was a two year study done at Google where they found results related to culture, and that high performing teams needed a culture of trust and psychological safety. Well, that’s a great explanation and great thing to say. But we need to put some language around that. And so the result of some of that work at Google came up with this model that I have here on the screen here, we call the Western culture model. And so over on the left, we have different definitions of what a pathological culture looks like. And over on the right, we have what looks like a generative culture. And so as I was looking at the organization today, the first question I had to ask myself was, which one do I want? What type of culture do I want to be a part of?
And what type of a culture do I want to work in? And then from there, what does everybody else around me want? And how do we support that in a body that is not enforced that but encourage that type of culture? throughout the organization? We want a court culture where there’s high cooperation, we’re bridging and sharing is encouraged, encouraged, we’re novelty is implemented? So I’ve just asked you, as you’re looking at this little matrix here, ask yourself, Where is your organization’s culture today? And where is the culture that you want it to be? The first step towards towards changing culture is just to be honest with yourself about where it is, and what’s happening right now, what you’re seeing, talk with your leaders, if you are a leader, you have an opportunity to shape this, by the way that you act, by the way that you treat one another, by the way that you encourage behaviors across your team. And if you’re in an organization has a culture that it’s maybe a little bit more on the left side of the spectrum, just ask yourself, is that the is that the place you want to be? Do you want to be in that type of a culture? Do you want to be in a culture that is more like the one on the right? And you can open conversations with your leadership team just to say, Hey, did you know that Google did the study, and I’ll provide the link for this here at the end of our talk today. But you can actually share the results of this talk with your team to let them know about the research and the work that Google did and how culture can have a positive impact on performance and productivity, let alone job satisfaction and people just being generally happy at their work. So for us, it was opening the conversation. It was really just having a framework whereby as leaders, we could talk about what we were seeing and what we were being and what we wanted to be as it relates to leading, leading people in the organization.
What is Developer Productivity continued
So this is where we started. Culture is not something you change overnight. It’s something that takes years and years and years and I like I said earlier requires you to be intentional, but it starts with the conversation, it starts with a definition. And it starts with really just, you know, setting a challenge out there to say, Hey, this is the type of culture we want. And this is how we want to treat people. So this is what we’re going to aspire to, and allowing people to hold one another accountable if we’re not aligning to that goal. So culture was where we started. And like I said, we made significant progress, even just by having some type of alignment on the way culture could be. But the next thing we wanted to look at was continuous delivery. So specifically for us, as we think about continuous delivery, there’s a couple of areas I want to call out back to my roadmap. We knew that we just have this organization, we wanted it to be able to achieve its goals because of our teams. And we knew that there were some different areas, we needed to make some improvements. And specifically, like I had highlighted for you before, we wanted to focus now on decreasing deployment pain, that was obvious that people were having some real challenges with deployments, we’re not having fun and things, we’re not moving forward at the rate that we wanted them to move forward in production. And so we needed this focus on continuous delivery. And as it relates to continuous delivery, the three areas that we decided to focus on because they were areas of opportunity for us are in deployment automation, loosely coupled architecture and version control. Alright, so let me first start with the deployment pain. So what is deployment pain?
It is software that’s not written to with the playability in mind manual changes that are made in a deployment, multiple handoffs, etc. And it’s come straight out of the accelerate book. And as I read this chapter, it just, it really resonated with me, because I realized that we had a lot of this in our organization at that time, there were some very, very brittle processes, we had buttons that were being pushed with not a lot of understanding as to why we were doing what we were doing. And we needed to figure out a way to address some of the deployment frustrations that existed in our systems. So in order to decrease deployment pain, some of our intentional focus was around reducing that pain. And specifically, we realized we needed to build systems that were a little bit more failure tolerance, that were the components could be updated independently, it says the decoupled architecture topic. Specifically, we needed to find ways to automate our deployment through information that was in version control, we wanted to build intelligence into this application, so everything could be as simple as possible. So if I were to summarize the three areas of focus for us under reducing deployment pain, because we wanted to improve our delivery, they were really around resilient architecture, an automated deployment and improved version control. So digging into those three areas, first thing I want to talk about is I want to talk about architecture. So I have an architecture diagram, but it would be a little bit too much of an eye chart to throw on the screen here.
But this is a summary of what I saw, when we looked at our architecture, we needed it to be more loosely coupled, we needed it to be better capsulated resilient, we needed improved version control on everything that we had in the system, we were actually doing really good on version control of the the source code and the database structure. But some of those other items down there that were part of our environment, were not so great in the area of version control. Some of them’s were just jotted down notes jotted down, you know, in tickets, but they were not put in specifically into the version control system. And so in order to be able to get to a place where you can automate your deployments, you have to have be able to recreate the deployment through information in version control. So this was some of the focus for us on architecture. And as you guys can imagine, architecture takes time, it’s not something that you just flip the switch and all the sudden your architecture is perfect and performant and fully fully organized. For us, it took a little bit of time, we opportunistically would make architectural improvements along the way. And anytime we were thinking about a new service are a new capability, we think about it for a modularized perspective to make it easier to deploy on a go forward basis. around the topic of automated deployments, specifically, the focus for us was that we wanted to find tools that could help us with both building and configuring environments, promoting code, configuring values, and settings, etc. All these different bullets are here on the screen. We had some really smart engineers on the team, we realized that what we needed to do was to have a focus on engineering the release process. And so we made some shifts and some changes in the work structure to be able to bring one of our engineers more directly into the DevOps role, so that he could apply his engineering mindset and his engineering skill set to the deployment process itself. Maybe jokingly said that if you want to fix the deployment process, maybe this will work for you because engineers hate churn and they hate waste. But that’s exactly what happened for us. Some of the engineers we brought into this process, really found very creative ways to deploy some of these metrics or to automate some of these manual steps so that they would no longer Have to be manual steps. And they can easily just push a button and execute a set of scripts or a set of commands as required for the deployment.
What is Developer Productivity continued
So those were the two kind of, sorry, the major areas of change. For us, it was a focus on talking about our culture, and then specifically around continuous delivery, automated deployments increasing in our footprint on version control. And so it was a multi month project for us, I would say we probably spent somewhere between three and six months before we saw results. But your question might be, what kinds of results did we see? So first, I want to talk about culture. Like we had some awesome conversations with management about how to build some healthy and productive culture in the organization. We then aligned our team’s culture underneath the company values, it was very intentional, but very much a work in process. These are things that like I said, they take some time. But opening the conversation is the first step in the journey. As far as decreasing deployment, pain and rework. There, those three areas I talked about, first talk about decoupled architecture, again, it was a long road. There were a lot of small changes that we made along the way, but the conversations and just setting out the goal to say, hey, we want our architecture to be decoupled in the future. As we move forward, as we build more, it created the groundwork for breaking up the monolith that was our application up to that point, to create a platform for more independent microservices approach, again, another work in process. But as we were making adjustments and changes and adding services, we’re able to do that with a decoupled architecture framework in mind. And then as far as the version control repo, all of the work that we did in adding more to our version control, and then also engineering, our deployment process, had a significant effect on decreasing the amount of time required for deployment. And also significantly decreased errors, probably not a big surprise to you there.
But things that had been copied and pasted previously, then would be pulled out of version control systems rather than copying and pasting. And so that decreased typos and different errors related to copy and pasting key values, etc. We also had a reduction of just the overall feeling of frustration associated with appointments because it became less and less of an event, and more just routine, we knew what was going to happen. We knew what the steps were, we knew where the recipe was. And it was easy to just improve the recipe if there was an issue with that. And overall deployments became more predictable and more consistent. So as you’re thinking about your team, and you’re thinking about the different areas of responsibility that you might be able to influence might be different areas where you would want to dig in and having different areas that could benefit from some of this intentional effort. But specifically, I just wanted to share with you some of the areas that we looked at, and the different focus areas of improvement for us. So back to the roadmap here. Just as a quick recap here, the areas of focus were around deployment automation, loosely coupled architecture, version control, Westrom organizations, organizational culture, and decreasing deployment of a plane, but through continuous delivery. If you think that there’s an opportunity to improve your performance of your organization, I highly recommend you check out the book, this is again on page 208. Or even you can just download the state of DevOps report for free. And you can get most of the content in the report the differences, the book will go into a little more detail because it’s got a few more pages available to it. As far as resources, a couple of different resources I wanted to drop off, make sure Jim gets these links to you so that you can download them or click them there from the YouTube video. But the first one is, where’s the latest state of DevOps report? That’s the link there. Where is the link to the research that Google did around the Western culture and a lot of other DevOps related assessments. It’s a great document, if you haven’t already taken a look at it. It’s not something you can read in one sitting, but a great research document you can take a look at. And then thirdly, there is the talk that Christian McKarrick gave in 2020, at the playdough Summit, where he specifically was talking about measuring deployment or development, productivity, and getting a sense on what are the different metrics that actually have a meaningful impact in the organization and can help an organization be more productive. So with that, I think we’re all set. Jim, I’m going to go ahead and pass it back to you.
Jim Shilts 34:20
Awesome, thank you so much, Brian. I have to say though, I think I might have preferred the first time you gave this talk but that might have something to do with the whiskey tasting station at then a dog event. I don’t know though. Good, be good be. But I do look forward to seeing you at the next one in Southern California. if not sooner, maybe at reunion or buddy leaf metals. I’ll put the links for those in the into the at the chat but the description as well for everybody and then I will also put the link to the book, Brian referenced accelerate, if you haven’t read that yet. Really great read if you’re in this space and interested about measuring productivity. Really, really great. Good place to start. And I’ll share all the other links that Brian referenced as well. So I want to thank everyone for tuning in here today, Brian, thank you again for sharing. Check our YouTube channel for tons of other great speakers and content. And don’t forget to like and subscribe to the channel and we appreciate it. Thanks for tuning in. Thanks Brian.
What is Developer Productivity end
Transcribed by https://otter.ai