Subscribe
Share
Share
Embed
The purpose of the IT Leaders Council is to bring together IT Directors and Managers for leadership training, educational content from guest speakers, and peer discussions in a vendor-free, collaborative environment. IT Leaders Councils are currently offered in Indianapolis, IN and Columbus, OH, with more cities coming soon!
00;00;00;09 - 00;00;17;28
Unknown
I want to welcome everybody. Thank you for having me. Many years ago, when Doug started doing these things, I kind of always dreamed of being up here and hopefully having something of importance. Something of importance to say and hopefully we do like this will be very interactive. Again, my name is Calvin Hendrix Parker. I'm CTO and co-founder of Six Feet Up.
00;00;17;29 - 00;00;41;20
Unknown
We are celebrating 24 years in business this year. Another number that makes me also feel maybe up there, but I believe me, I'm not that old, I swear. But I'm excited about engineering leadership. I actually just got back from San Diego from a CTOs conference and that just gives you a lot of inspiration when you're around other people who are trying to find their tribe and trying to figure out their way when it comes to engineering leadership.
00;00;41;22 - 00;00;58;26
Unknown
So what I'm going to talk to you today, though, about is accelerating the software development lifecycle process and some best practices and what you can do with your teams to actually make this happen. I will ask that if everyone can get out their phones. I know this is an odd request by a speaker, but this will be a very interactive talk.
00;00;58;28 - 00;01;22;06
Unknown
There are a lot of QR codes. None of them are nefarious, I promise. They're all safe to scan. I know this kind of crowd, so don't be too worried. But the slides and everything that's up here is actually on the GitHub repository. So that's how deeply invested I am in doing this right and making sure people have access to all the kind of open knowledge.
00;01;22;06 - 00;01;38;23
Unknown
So there's a PDF in there with the slides in there, the slides are built and then there's actually a link to this presentation right on that GitHub page. So if I may wants to be able to get that and put this up later as well. But I think we all know that every team is a software team. These days.
00;01;38;23 - 00;01;56;20
Unknown
Even if you're running I.T. operations, those folks are coding. Doing infrastructure is code. There's no lack of software development practices that are happening anymore in any of these groups. Even if you thought you were just a session man or network engineer and you're just going to hack on the consoles of things, that's not how this stuff happens anymore.
00;01;56;23 - 00;02;20;20
Unknown
And I think that those teams need to make sure we're adapting to this kind of modern world. So I want to kick it off though, with a bit of interactive, like I said, interactivity. So we're going to use slides now for if you've got Q&A while I'm speaking, feel free to drop questions in the slideshow, but we're going to do a quick poll, so go ahead and scan that code or go to slate.com and put in i.t.
00;02;20;20 - 00;02;40;18
Unknown
Leaders in D and that will get you to the first. We'll get you to the q&a section here, but I'm going to go ahead and put up a question I want everyone to answer as we talk about and think about this process of managing engineering teams over the long haul and how we actually improve on that process. So let's get kicked off with that.
00;02;40;21 - 00;03;04;28
Unknown
The first thing I want to ask is how many development teams are in your organization? And when I say development teams, this includes operational teams that may be producing infrastructure is code up there. So we're going to it's a live. There we go. Yes, ten plus. You're my people. That's who I'm talking to here for sure. Because again, that code can live in lots of places.
00;03;04;28 - 00;03;27;24
Unknown
You could have a product team or you could have a get an operations team, an engineering team that are they're all coding or have maintenance responsibilities around some level of code, you know, marketing automation. Those folks are now getting into Low-code No code. And how do they deploy and how do you maintain some level of consistency around that?
00;03;27;26 - 00;03;51;07
Unknown
Awesome. I got 27 people already voted because they're awesome. This is the best the techie crowd who gets it with the phone and understands this is so super cool. Okay. Now given that you've got maybe, you know, it looks like 2 to 5 teams, which is perfect. I'm kind of speaking to people who've got multiple potential teams here that they're trying to manage and actually be able to leverage the skills in both those teams.
00;03;51;09 - 00;04;16;08
Unknown
If you had to say, are you happy with their ability to deliver velocity, are you happy with the ability for them to get new features out the door quickly? Is this going the direction you want? Is a room for improvement. It's anonymous. There's no there's no no, not tracking who's putting what stars up there. So feel free to be a little honest about the situation.
00;04;16;10 - 00;04;43;24
Unknown
Suite 20 people. 23 people. Yeah. I think in the Enterprise, I kind of expected this. I kind of expected and there's still a lot of room for improvement. A lot of startups, you know, they're very agile. They can grab all the latest DevOps tools and throw them out there. But the enterprise, I think that's been there's been a little bit of friction in getting that going, but I think we want to look at how we can actually look more like those highly performing now accelerating software development teams.
00;04;43;27 - 00;05;06;05
Unknown
So awesome. That's really cool. All right. So I talk about a journey. This actually started a couple of years ago and then by say, started this actually started a long, long time ago with how we developed software over the years. But a customer of ours actually came to us. We were we were looking to do a different kind of project with them, like a Iot type project.
00;05;06;08 - 00;05;26;03
Unknown
But this they said, before we start, we would like to look more like you guys, like we would like to look like you all. We want to perform like you all do want to deliver software like you do. We suspect we have some poorly performing teams now. I mentioned six globally distributed teams that were six out of 30 that we actually got to talk to.
00;05;26;04 - 00;05;51;03
Unknown
So we were talking to specifically six teams throughout this process. But keep in mind, it's a team. They've got 30 globally distributed software teams and I'm only talking about a subset of them at the beginning of this journey. They want to understand if how they could deliver more features, more functionality and prove that velocity. But they had no clear vision as to why this was happening or even who is at fault.
00;05;51;05 - 00;06;26;10
Unknown
We had some initial assumptions, you know, things like poor test coverage or, you know, tech. It's a it's an organization that's been around, well, 50, 60 years. Maybe they've got software still running that's, you know, 20 plus years old. Maybe there's tech that and then that's actually causing them to slow down this this technical velocity. Now, the next thing you want to do is if you were in the same spot, what are common causes of poor, poorly performing teams that you may see?
00;06;26;12 - 00;06;51;08
Unknown
So if you go back to the slide show, you can type in a couple word answers here. Again, it will not pop up your name on there. So if you say like your team sucks and you're just not happy with them, that should not show who set it up there. But yeah, exactly. Communication issues, leadership of what kinds of things are you seeing in your organization right now that may be leading to more poorly performing teams?
00;06;51;10 - 00;07;16;11
Unknown
Process Complexity is a really good one. I think that that also leads to potential talking about like tech debt and things like that lack of collaboration. These are great. This is the best audience ever. I'm going to give you guys all a five star review. Yeah, this is the best. Nice. Oh, yeah, I see. Me. Who's typing? It's the first time I've used this for the presentation.
00;07;16;15 - 00;07;37;01
Unknown
I'm going to say I would do this again because it's actually working out really well. Tech that so? Yeah, same thing. I think that's a common one we always think about is like, is tech debt really what's like slowing it down and causing a lot of friction and potentially reducing our velocity? Okay. I think we get one person type out there and we'll come back to these.
00;07;37;01 - 00;07;53;27
Unknown
You'll be able to see them right in the the tab the results on your the slide show in there. If you want to take a look at this later to see what other people had said. But for now, you head back in if you can. If you have questions, don't hesitate to throw them on to the Q&A tab of that slide show page and we'll get to them at the end.
00;07;53;27 - 00;08;18;19
Unknown
Or if you get a burning question, you got to have an answer. Right now, I'm happy to make this very, very interactive and talk about that to So the discovery process I mentioned the six teams. We basically we basically asked for willing or unwilling volunteers from their their central organizing group. And they came back with these six teams who they thought would be willing to participate in the process.
00;08;18;19 - 00;08;40;02
Unknown
So you can only imagine in some enterprise that the resistance to change or things that are different or people coming in and stepping on your business might be a problem. So we got to six interesting teams that were there and got a sampling of people. And again, out of 30 people, 30 teams, we had six to deal with and we got a sampling of those people from those teams and interviewed them.
00;08;40;04 - 00;09;07;20
Unknown
6 hours per team in just the interviewing alone, not including any analysis or report write up. And I can tell you we uncovered many, many more issues like this was obviously not just a two things are kind of going sideways and we need to look at how we're going to fix these kind of pieces. We really looked at one team just to kind of focus in on going from six down to one that I think a lot of you put these up there on that site.
00;09;07;24 - 00;09;31;22
Unknown
Poor communication issues, access management, documentation, all these things were kind of lacking or weak in some way or another, and they were not all bad. Obviously. I mentioned power station set up. I'll tell a story about that in a bit. They actually had a good onboarding process that's, you know, from day one, a developer opening a laptop out of the box and getting started and being productive.
00;09;31;22 - 00;09;55;27
Unknown
What does that look like? And then kind of the middle, you know, coding standards, source control management, thinking about innovation, like forward thinking processes. Like we had to think about this as a like a holistic process from start to finish, but then you got to think about how you're going to prioritize. If you're looking at these issues, talking about them, how do we actually prioritize which ones are important to deal with?
00;09;55;27 - 00;10;14;18
Unknown
You can't boil the ocean and solve all the problems at once, especially as an engineering manager, we're going to need to understand if I did an analysis across the team and I looked at, for example, here, there's four stages across the top. You've got four stages that build upon one another and 19 units. There's 18 in this specific chart.
00;10;14;20 - 00;10;32;20
Unknown
But we actually have been iterating this over time of across those 19 units. You know, where do we start? And I think we have to establish like a baseline. When you're looking at those teams, there's there's certain like table stakes skills that the group is going to have to have to be able to accelerate up to the next level.
00;10;32;22 - 00;10;52;15
Unknown
So if you looked at that level one, act one right here, we were calling this build, and I'm going to give you this example framework so you can use this with your own teams. We talk about build like just getting set up day one with the kinds of things that a developer or engineer in your team needs to be successful.
00;10;52;17 - 00;11;24;05
Unknown
And that's where we started looking. And then we highlighted maybe top three things we think we should be taking care of as part of this process. In this case, it was the issue ID like are are we actually actively talking about the issues that affect not the software but the operation of the team? How are they surfacing issues inside the team itself, things like communication or poor documentation practices, or maybe don't have a pull request process in place or it's not documented or followed by all.
00;11;24;07 - 00;11;47;12
Unknown
So we highlighted that as a kind of a let's tackle these baseline table six issues first. The next one was source control management and then security. And normally I wouldn't put Act two, which is like the execute I'm calling this execute into that top three. But because security to certain organizations depending on your business needs may be more important, it may make sense for them to focus on that.
00;11;47;12 - 00;12;13;09
Unknown
But we try to apply the same set of units across all works, but then prioritize and based on the business need. And then last oh, then. So that's the execute column to go build, execute. The next one here is the streamline and then the last column so streamlines because these things like orchestration, automation, testing, those things that we can we can fully automate.
00;12;13;12 - 00;12;42;07
Unknown
And the last one being transform. Are we thinking about the future? Are we cross-pollinating the team? How do folks share knowledge or gain new skills and knowledge across the enterprise, which cleverly enough spells best? That was my tie in with the best title for this, but basically choose three. For example, focus on those, fix those issues and start building a great foundation for those engineering teams so they can actually perform at a higher level.
00;12;42;09 - 00;13;04;17
Unknown
So if we're looking at just one org or one team, it really be interesting to compare cross team. If we take two different teams and talk about those same areas across two teams, maybe there's energy or synergies that can actually happen here between those teams. We're going to tell you the story of two developers. We'll call them Pete Nandi.
00;13;04;17 - 00;13;31;09
Unknown
They're all fictitious names have been changed to protect the innocent that you see over here on the the build that foundational stage, this power station setup between these two teams, you get one with the red and one with the green. Just imagine, if you will, a story about two developers. Pete wakes up, New Day, first day on the job, comes in, got a brand new laptop on his desk and it's got nothing installed on it.
00;13;31;11 - 00;13;55;18
Unknown
So he has to go through a process of getting I.T approvals to get certain software installed. Maybe the computer's a little undersized so he can't run all the docker containers all at once. Maybe he needs to go find somebody in another department to get access to the source control repository for a specific project he's been put on. But it takes another day and a half for that person even to figure out where they put the access controls or get those things kind of thing set up.
00;13;55;21 - 00;14;20;05
Unknown
We're talking about, you know, potentially days of access set up. Maybe he's got to go figure out how to set up a test framework so he can try and run the CI locally before he commits any code in the repository. Maybe it takes him a couple of weeks to even get in code pushed into production. At that point, if we talk about the next team over here, maybe Andy in his power station setup, he grabs his laptop fresh out of the box.
00;14;20;07 - 00;14;40;01
Unknown
He fires up, installs Docker in his favorite IDE. He is pulling code down, running single make command. He's got the whole suite of tools running already for him to go. He's making code, making it pull requests, getting it reviewed within the first day of work. I mean, this is the kind of contrast we would love to see. Everyone would love to be over here.
00;14;40;01 - 00;15;00;06
Unknown
We want to have developers hit the ground running and be productive. But sometimes tech that and communication and documentation all kind of stand in the way of actually being effective at our jobs. When they just want to write code, they just want to be productive and produce new features. But they, you know, the whole process stands in their way.
00;15;00;09 - 00;15;20;27
Unknown
Another nice thing with this leveraging cross pollination is now any or Pete can go talk to Andy about how this works because now we're aware we've actually taken a look at the organization, assess them through these surveys and interviews and looked at like where certain teams are excelling in certain teams maybe are falling behind in analyzing that gap.
00;15;20;29 - 00;15;39;28
Unknown
Be able to look at that now gives us the ability to do, you know, either centers of excellence or some kind of guilds. We use developer guilds in our organization so we can put all the front end people together. They can discuss, even if they're not on the same projects, they can come together for kind of a mini conference on a periodic basis and share ideas between each other.
00;15;40;00 - 00;16;01;10
Unknown
And that cross-pollination can be really, really powerful because sometimes people are just stuck spinning the wheels. They just need a person to talk, to understand the kind of things they work on, on a day to day process our day to day basis. So where do you start in this whole process? I think the issue we saw it was that interviews are time consuming and biased.
00;16;01;12 - 00;16;25;13
Unknown
We ended up, I mentioned 6 hours per just the interviews. There were over 80 hours put into just talking to and reviewing these six specific teams. If you want to have success with tools like this, you're going to want to be able to do this on an ongoing basis, you know, maybe not quite monthly, maybe quarterly, at least a couple of times a year to kind of get a baseline and then see if you're moving the needle.
00;16;25;15 - 00;16;55;22
Unknown
But those interviews are going to be really, really expensive and costly. And you're only getting a small cross-section of the whole picture here. We only talk to six teams. We only talk to a couple representative people who decided they would show up for these interviews. They were biased at best. Not everybody was invited. Those who were invited. You can imagine talking to your software development teams who just speaks up, raises their hand and says, What's wrong?
00;16;55;25 - 00;17;18;25
Unknown
And not everybody wants to speak up and be heard. And it kind of means, but everyone does need to be heard and have their opinions taken into consideration when you're analyzing what where are the potential problems because otherwise you're going to get a very skewed view of the whole process in the picture. So a survey actually would be probably much better option here if we could use some kind of tooling to get more feedback from more people.
00;17;18;25 - 00;17;35;29
Unknown
And as part of the process, we think it gave us a lot better results in the end because we're actually getting more voices heard as part of doing this exercise. It is also important to focus on the aggregate results at a team level. I don't think anybody wants to ever be called out and there's a lot of great tools out there.
00;17;35;29 - 00;17;55;24
Unknown
So you could use things like door metrics or space to actually analyze these teams, but they may not fit your specific organization. You may go into one of those exercises using the door metrics tools like with Apache Dev Lake, which is open source. There's a lot of great tools that can do these kinds of things and actually help you watch metrics from your development teams.
00;17;55;26 - 00;18;24;28
Unknown
But they may say you're poorly performing when in reality it's a function of the type of business you run. Not everyone is meant to be a release a thousand times a day at a production DevOps organization. There's all kinds of constraints involved when it comes to different kinds of businesses, but the goal will be identifying these areas of synergy, looking for areas where you can have those cross-pollination magic moments inside of your organization's.
00;18;25;01 - 00;18;50;05
Unknown
But from there, so kind of give some recommendations here if you're going to take this on and do a bit of a DIY for yourself is identify what your software development, aspirational software development lifecycle best practices would be. You know, either said there's there's different needs for different organizations. You're going to need to understand for your own organization what makes the most sense and ordering them according to priority.
00;18;50;05 - 00;19;14;01
Unknown
So like I mentioned, we put together that four stages with like 19 units looking at what are the table stakes, the things that have to exist because it really shouldn't move into the stage two, three and four before I've mastered that stage one level of foundation inside the organization, you want to want to develop questions, you know, keep it simple.
00;19;14;03 - 00;19;40;25
Unknown
I think these things could be time consuming. You could get a large like subset of the organization to get to maybe disenchanted with it and doesn't want to do the process because it takes a lot of time. So you've got to make this as easy and frictionless as possible. We've kind of settled on using three options only for each the questions as opposed to, you know, maybe five or or more just for ease of scoring as well, and then have everyone do this.
00;19;40;28 - 00;20;05;09
Unknown
It would be nice to get 80%, you know, kind of like test coverage. It'd be nice to have 80% or better coverage across your team. So you're truly getting the bigger picture story. And if people know that they're not being individually reported on, you may get more realistic results back out of the process as opposed to trying to look at, you know, individual people uniquely and then identifying those internal domains of expertise.
00;20;05;15 - 00;20;35;24
Unknown
So you can have those kind of specialty guilds or centers of excellence inside of an organization gives you now an opportunity to, you know, even do things like a day of innovation. Have you thought about having an internal dev conference for your internal teams where one highly performing team can now show how they accomplished a certain task or gotten through a new process and rolled out some way of working that actually helps them accelerate to higher velocity, which is really ultimately the goal here.
00;20;35;27 - 00;20;57;16
Unknown
And then repeat every six months and monitor for progress. We want to make sure this is an iterative process and then we're continually watching and looking for either people falling behind or, you know, the only way to fall down in the process. We also want to be able to establish that, yeah, we are improving, we're moving forward. You know, the things only you only improve things if you measure them.
00;20;57;19 - 00;21;27;02
Unknown
So if we start measuring, we now have a chance to actually improve these kinds of things. Okay, I mention I was going to give you guys and give you a sorry guys, I hate. That's terrible. I'm going to give you all some bit of information here, some takeaways so that QR code will actually take you to a PDF that has our four stages on there that you can use as a maybe an initial framework or a starting point for this kind of activity.
00;21;27;04 - 00;21;45;14
Unknown
Then it also allows you to read it because I'm not going to try and read small text off of a big screen for you all, but that that will get you the download of our 19 best practice areas that we have been using to look at other organizations and talk to them about their where they're excelling. And they mentioned there's four stages.
00;21;45;16 - 00;22;12;21
Unknown
The 19 units, there's over 90 questions across this whole assessment that we've we've built to try and understand where and what's the maturity level of these various teams. And once you've understood these maturity levels and then now we can go and put in place an action plan. But I think if you don't know, it's a kind of that being self-aware, if you don't know, eating sugar like a Mad Men is bad for you and you're watching that, you can't go and improve it and fix it.
00;22;12;23 - 00;22;40;11
Unknown
So now and actually we're continually updating and evolving these sets of questions and stages. And you saw the original heat map put up there had like 18 to 19 adding in things like disaster recovery from that maturity level, from an I.T. and software development standpoint, it made sense in here because everyone's kind of involved in this process because everything has become code or structures code or automation that makes sure that these things happen.
00;22;40;14 - 00;23;06;03
Unknown
Because if they're relying on a manual process in any of these steps, there's potential for someone to not do it. Now, if you want to go to that next level, you're going to have lots of great data coming back in. This gives you an opportunity to take and slice and dice and look at it. So actually what we did here is we took each of those stages, each of the units, and put it on a radar chart.
00;23;06;06 - 00;23;30;27
Unknown
I never had much use for a radar chart before this activity, but it actually helps you understand where you've got high performing teams like toward the outside and lower performing teams on the inside. So at a quick glance now across these four stages and units, you can now understand where one team may need to come in and mentor another team of essentially top tech.
00;23;31;00 - 00;23;52;01
Unknown
Top tech must not have actually finished their survey right there because they're all right in the very middle. But the further out you are on the radar chart, the higher the scoring your team is doing on the aggregate for those various activities. So that training and growth mindset, you've got one group out here and one group closer in toward the middle.
00;23;52;04 - 00;24;24;10
Unknown
It could mean that they don't have a like skill matrix or a career path plan for their engineers and developers. These are kind of things that could go by the wayside if you're so focused on delivering new features very, very fast and building up TechNet at the same time. You need to think about balancing all these kinds of activities and making sure, for example, that you can maintain developer retention if you have those kinds of career path and innovation pieces in place, for example, that leveling up, you know, are you sending developers to conferences?
00;24;24;10 - 00;24;44;16
Unknown
How are they learning about new technology? These are the kinds of activities and behaviors you want to encourage across the organization. And when you look at at this level, you can now really clearly see the gaps. And I think that helps people focus on what's important and where they need to fix it. All right. All of those like no questions.
00;24;44;16 - 00;25;13;06
Unknown
That's amazing. Anybody got questions that can actually take them live in the room right now? Tiffany, a long time ago, we used to use the MCI levels to evaluate potential vendors. Yeah. How closely does this that actually it's interesting. I showed this to another organization. They're like, Ooh, we could use this to evaluate people we're going to acquire because it may show the maturity levels of those teams.
00;25;13;08 - 00;25;36;17
Unknown
We're not like a certifying organization. This is really a set of tools and thoughts and processes we came up with because just being being in software development for 20 plus years, we felt like it was important to actually spread this level of like knowledge about maturity to other teams. So I don't have a exact comparison to say like a standard like that.
00;25;36;17 - 00;26;13;02
Unknown
But I do know that it would be interesting to use this to evaluate maturity, maturity and the fact that it's our survey and actually we can customize it for a case by case basis. Maybe you've got teams where you want to be more prescriptive with the questions in the survey and the options that are there are chosen. For example, maybe you use LastPass instead of one password as a secret manager and you want to specifically ask about those, those kinds of things across your teams because maybe you've got teams that are using no password manager or different password managers across the enterprise.
00;26;13;05 - 00;26;33;12
Unknown
How are you scaling the answers based on the sizes of the teams? Yeah, that's actually an issue right now. If you have a single dev team, it's kind of hard to hide who that single one dev was. Right now we do average the scores across and this is just the technique we've been using is to average the scores across the team.
00;26;33;12 - 00;26;58;26
Unknown
So a single dev or small team might skew differently based on because there's just less population in that sample size. Obviously, for a larger group, you're going to get a more average, more rounded answer. I think the goal isn't to look at that number as it is to as a as a corrective measure. It's a how do we all grow together measure.
00;26;58;26 - 00;27;24;00
Unknown
It's identifying from a like a CTO or director engineering level. Do I have any issues you're busy with compliance or your roadmap or dealing with product. We may not be aware that there's even issues going on inside the team that would that you need to be addressing. You may think things are great. How many of us have just kind of been led astray by the tech lead who's like, Hey, yeah, everything's great, got all handled.
00;27;24;00 - 00;27;47;02
Unknown
But you, if you just kind of peeked under the covers or if the team members kind of did a skip level with them, you finally found out there's really underlying issues. We want to be able to surface those in a more frictionless way. Awesome. Any questions? Anything? Any thoughts on the development team working better with infrastructure and some of the legacy operations?
00;27;47;04 - 00;28;15;28
Unknown
Oh, I mean, so I'm also kind of like. Shea Well, it's people who bridges that operations and development world, and I have opinions that are not always popular when it comes to like infrastructure teams and development teams that I feel we're moving more toward. Everything is code and infrastructure code piece. I want to educate my operations teams to become just almost as much of a developer as my development teams who are implementing features on the front end.
00;28;16;05 - 00;28;40;26
Unknown
They're all writing code, they all need testing, they all need automated CI and CD. I get very passionate about that. Actually, this presentation I geeked out, it is actually being delivered via Skype. There's a GitHub action pipeline that actually produces it and publishes it and deploys it to GitHub pages. So when you go to that GitHub repository, that link was actually built by a pipeline for my presentation.
00;28;40;28 - 00;29;00;09
Unknown
So I think it's I think they're coming together. There's there's no more keyboard monkeys who are going to be hacking on stuff. It's just too risky. The world has gotten far too complex with all the layers we're putting in place to try and protect ourselves from this and that, that you can't manage those. It's just a human being, a manual process, not a question.
00;29;00;11 - 00;29;31;24
Unknown
Oh yeah. Did you study hybrid in house and contractor teams that we actually that that is us. We are a hybrid contractor and in-house team and the teams we were talking to were similar. These were globally two tribute teams had folks across three continents in the same team. And that was actually an important aspect, is that everyone's treated equally in this kind of a survey you'd onboard folks, and actually have everyone, contractors included, because we really want to consider the whole the whole big picture.
00;29;31;24 - 00;29;38;02
Unknown
I wouldn't leave them out. Awesome. Thank you for the great questions.
00;29;38;04 - 00;30;15;10
Unknown
One last question. I think we got enough time for maybe one more. Yes, sir. How do you deal with situations where the interests of the development team and the operation team are not aligned? Good examples of previous organization I worked for. The development team was rewarded for cranking out feedback operations and was rewarded for stability. Yep. So I was on the operations team and what my team felt like was the development team was making our lives because we could never stabilize things because so much new was being shoveled out.
00;30;15;13 - 00;30;52;20
Unknown
That's a that's an argument as old as time almost. It is harder. But I think the technologies like Kubernetes in orchestration technologies like our operations team, the level of control they can be comfortable with and development team, the level of delivering features at a rapid pace that the product team would be happy with. So I think containers have gone a long way to stabilize because now you can I can run security scans across the container as a whole, no other, and I've got unpatched cves buried in there.
00;30;52;20 - 00;31;27;22
Unknown
Or you can actually have metrics around code quality with test coverage and looking for regressions automatically where you can say, I'm comfortable given you've well tested the software and we know it's been security scan that it can be launched into this container environment which has access controls between the various pods for example that gives you, I think, more of that that fuzzy feeling as an operator of a system where you don't have to be as concerned or you should be less concerned with what's being delivered because of the standards and processes have been put in place.
00;31;28;00 - 00;31;58;28
Unknown
When you're following all these kinds of processes, you end up with higher quality software, with less regressions because there's a lot of things baked in there. I didn't talk about when it comes to test coverage and C.I., a lot of organizations may be sprinting so fast and building up a backlog of really TechNet that is only going to ever slow them down across this if you don't invest upfront in actually building software with these great these these kinds of practices, you're going to be delivering slower and in a in an unstable situation.
00;31;58;28 - 00;32;34;21
Unknown
So it doesn't benefit either organization. Yeah, thanks. I answered my question. So they've not asked me for advice, but I see the situation again. Really getting back to practices is a good way to stabilize things. Oh, hundred percent. I think that's a great way to go. Awesome. Well, if you want to explore this further, this is a link to some more narrative and descriptions up on the website where I go through and talk about these various stages a little more of the various units.
00;32;34;23 - 00;32;50;16
Unknown
If you're interested in talking more about these kind of things, I am happy to chat about that as well, which means you can find me on the interwebs. I'm not a hard person to find. I'm the only Calvin Hendricks Parker in the whole darn world. So if you can't find me, you're not trying hard enough. And I love talking.
00;32;50;16 - 00;33;03;27
Unknown
I love geeking out and talking about this stuff because it just makes the world a better place. So thank you all for letting me come and speak to you today. I was excited to come and talk about software and geeking out about the engineering leadership. Thank you. Thanks, Doug.