 I guess I can cross out performance in the theater of my bucket list. All right, so let's just jump right into it, right? So why this ups? Why the topic, why the title? So I'm the guy who, I was that guy who raised their hand to like five times when Aaron asked in the beginning, who do I define myself with? Like I've been a developer for many years, way too many years. I've been a manager, both product and project, and I've been, for best many years, I've been an executive. So, and I learned two things about myself in all those years. First of all, I'm pretty damn good at what I do. And the second thing is I'm real modest. No, but the second thing I'm doing is the reason I'm good at what I do is because I always try to understand the business problem I try to solve, right? And it wasn't always easy, but it somewhat came as a habit. So for some time I wanted to come up with a talk or an article that would basically talk about that. And then earlier in the year, I heard Nathan give a talk at DevOps days Baltimore. And that was the title. I cannot pronounce it. But the whole point of the talk was that DevOps is somewhat of a misnomer now, right? It includes so much more than just developers and ops, right? It includes QA, it includes security, we had talks about it yesterday, because all sorts of stuff. But what really frustrated me and it still didn't have the business aspect of this, right? We talk about breaking all the barriers between all the tech teams, between devs and ops and QA and everybody else. But we don't want to talk enough about breaking the barriers between the non-technical people and technical people, right? So what is biceps, right? I don't know how many of you heard that term before. Not a lot, yeah. If you Google it, you're gonna get a lot of different definitions about the strategy and execution and synergy. Apparently biceps is even the less defined the DevOps, go figure. But as far as I care, biceps is everything not tech, right? It's your business people, marketing people, HR, finance people, anybody who is not tech. So the natural question is, why do you give a crap? Right? I assume there is no business people in the audience, right? I'm not even gonna try that, yeah, yeah. Yeah, so why would people whose job is really to build and operate software care about business or finance or HR? Well, mainly because your job is not to develop and operate software. And by the way, I'm gonna use a unicorns as cue cards for your emotions. So this one is confusion. So your job is not, despite what you might think, your job is not to build the software. Your job is to empower business, right? Anything that you do should be aimed at improving the business, making the business better or making the business better, right? Technology itself is useless for the sake of technology, right? I guess I just talked about, Susie just talked about the same thing about continuous integration. Don't do continuous integration just for the sake of it. Same thing with any technology decisions, right? You can build the best outdoor mall at North Pole, but why? Right? You may be proud of it, but nobody's actually gonna be using it. So as technology, so our job is actually to, behind the scene, make sure the business is running. Whether it's revenue, whether it's exposure, whatever the goal may be, we're there to support the business. I heard the best quotes and I've been using it for many years now. And it perfectly reflects what business thinks about technology. As funny as it is, it's true, right? I mean, if you go to the CEOs of non-technical companies, they really don't care what you do behind the hood, right? You talk about all the developed things that are called the tools and toys and all the concepts and content. And they look at you like, is it gonna make me more money? Right, that's what I wanna know. I don't know, have any of you heard about the term marketing technology? So marketing technology is an interesting concept. It's an idea that IT in general should not be its own unit. It should report to, let's say, marketing group, right? Because it's so job is to support like marketing initiatives. I don't fully agree with that philosophy for many reasons, but it shows to illustrate how the world works right now, right? I mean, the rise of SES was specifically so marketers can use the tools without IT group, right? That was the whole purpose of it. So when you think about your job, everything you decide, everything you do, every choice you made should be there to support some sort of business-related thing, right? I mean, and yes, it includes tool choices and all the toys that you wanna play with. I don't know how many times I've heard people choose in MongoDB just because it's cool, so. So I'll be giving a lot of examples from my life because I like to rant and I like to rant about stuff that actually happened to me. So one of the things we're doing recently, we have a pretty decent, we do consulting. So we use all sorts of tools, which is the beauty in the curse, right? Because you get to play with a lot of tools and curses. You get to play with a lot of tools you never wanna play with. But we still have a subversion server that we run a couple of our clients on. And the reason for the conversation started that it is 2016, so it's time to move something a little more modern, right? And when the folks started discussing where we should go, like there was a discussion, there was all the pros and cons, and obviously GitHub was the obvious choice, right? Everybody uses GitHub, everybody's familiar with GitHub, so I want to use just all the subversion users to GitHub. And then I heard the conversation and I was like, oh, we can do this, right? We're consultants, and as such, we work with all sorts of different customers. And all the different customers have different legal departments. And also we go to departments to have so to know idea how technology works this day and age, which means a lot of them have a clause that no part of the deliverable can go outside of the network domain that we have. So no SaaS products, no data living, so GitHub is just out of the question, right? So we just to go with the GitHub, it wasn't a big of an issue, but it just shows to us that some choices are not as obvious as you think they are, right? It makes sense, right? It's completely common sense. If you were privy to that information, it would be much easier to make the decision. So I love the older. And the reason I love the older is no matter how stupid or how funny or how absurd the comic strip is, I can almost point to it and say, hey, I know that guy. So in this particular example, I was actually in exactly that situation. I was troubleshooting some performance on queries. And I was going through some reports and some major queries that were running and I was looking at it, I was like, ooh, there's a bug. Right, I found a bug in the report and it was awesome. So I go to the business people, I go to the finance people, it's like, I'm so proud. I was like, here, I found a bug in your report. And the lady looks me straight in the eyes with no smile and goes, no, you didn't. And I'm like, no, no, no, but really, look, here's the old report, here's the new one, here's the bug that I found, it's been there like for years. And like, now you have all this brand new data and she looks at me, I was like, nope. And I'm like, okay. So as it turns out, that report that I had a bug in it was the one that was used for all the financial calculations for all the ledgers for all the reports to the board. So at that point, there is no bug, right? You're just making an enhancement. And it takes, it took a month if not longer to reconcile, they had to run both reports in parallel and reconcile it because if they just switched it like overnight, then, oh, hell, we broke off apparently. So again, if I had known that, I wouldn't be that excited about finding the bug, but nonetheless, so every decision needs to support some sort of a business. There's only one problem with that. You don't understand business. And that's okay, I don't understand business either. And it's not our fault in some ways, right? Sometimes we're not preview to those decisions, right? Sometimes the decision, the business decision I made, I would say otherwise. Sometimes we just don't care, right? I mean, let's be honest, like, but I was lucky enough to learn some business decision, no matter how us and I, they are, sometimes can actually make sense. So years ago, I was working with a company who was a marketing company and they were sending tens of millions of emails a day, like all sorts of A-B splits, all sorts of tests. And one day they sent me a creative which was this is actually a much pretty good representation of it. I kid you not, and it was pretty ugly. And they're like, hey, here's your creative, let's make it happen for all democracy. And I was like, I don't know if I have to. And then as I was working on it, another email came saying, hey, we would like to make some changes to it. We would like to make a background gradient, tags bold and red. And I'm looking and I was like, is that it? I was like, yeah, yeah, it's totally should do this. I mean, and I'm sitting there, I was like, why? Like my eyes were bleeding as it is. And now you wanna make that change. And the guy was nice enough for the marketing guy. He was like, it's gonna increase our revenue by 3%. And I'm like, you're outside your mind. Like, if I got an email like that, there's no way I would open it, right? It was just spam, the quote code that I can. I was like, nope, 3%. I was like, sure, sure. I was like, but you know what? You're the customer, let me do this. I don't have to open this. I don't have to read this. Fine, let's do this. So I did the same, but the next day I was like, I got the numbers. Let me look at the numbers and prove him wrong, right? So the next morning I'll run the numbers. 2.6% increase in revenue. Not even 24 hours. Like, I don't know. So you don't understand business. We all don't understand business, right? But that's okay. In some ways that's okay. I mean, we're not fully expected to know every inch and ounce of this. And to be fair, the business has no sense of theater. Right, how many times did you have the conversation that you felt like you're talking to a wall and you're speaking a couple of different like real business people, right? How many times do you have a conversation? I was like, what do you mean? You don't want to launch something at five to 30 on Friday. Right? I mean, it's the prime time. Like, we totally should do this. Or saying something like, I don't understand why you wake up so much at night. Why don't you just write the code that doesn't break? Right? I mean, you will, but it's an actual thing. See, we can just pick a different language, right? The whole fail, quick or fail loss of mentality that marketing has been built of, it's really hard for technologies to grasp, right? Because we want to do a good job, right? We want to release something that works. Whereas in marketing terms, for example, 80% is working today, it's much better than 100% working tomorrow, right? Even mathematically, because today they're going to get 80% of the revenue or the exposure to the needed. And we are going to fix it by tomorrow. So tomorrow they're going to get 100%, right? Versus not getting the 80% today, just going on the 100% tomorrow. For us though, it is frustrating as hell, right? You're pushing something that you know for a fact will break for 20% of users, right? So in a whole fail, quick or fail-off, all we see is fail, right? And it is frustrating, but it's fresher in both sides, right? I mean, I personally had this conversation so many times when I'm like, if you just give me another day, I will make this work, right? I know for a fact that it's broken. And the answer is like, I don't care. Like we're marketing people, we're going to get those people back anyways. Like that's our job, see? It's like, are you going to give me back my years of my life that I deal with this? But how do we learn, right? Because clearly there is a miscommunication somewhere. And the way we learn is in actual, in definition of DevOps itself, right? I mean, it's a culture of collaboration and communication, right? So all we need to do is collaborate and communicate, right? That's easy. But there are a couple of ways. So you're really doing, you're either doing DevOps or in your way to your DevOps journey somewhere, you're still already implementing the processes that should help you with those core concepts, right? So the goal is to try to get the business units come along with you in the journey, right? Try to include them in some of those processes. So first one, of course, is inclusivity, right? You want to invite them into conversations you're having. And like I said before, sometimes it's difficult, right? And sometimes it's really difficult because they truly don't understand what we do. Like, and I know that's a joke, right? I do. But you don't even imagine how many contracts I've seen the people sending that asking me to deliver a completely 100% buck-free code. It would be funny if it wasn't that sad. But one thing you can do and one thing you should do is I assume everybody's trying to do good, right? More often than not, people are not malicious. They're just ignorant, right? They don't know any better. And what we really have here is a failure to communicate, right? We don't speak the same language, right? And it takes work. It takes time to try to get people to get more and more on the same page or to try to descend the other side. And it doesn't happen overnight. It doesn't happen one conversation. It's not a big meeting that you can schedule and just have the conversation saying, we now should better understand each other and then go your own separate ways, right? It's gotta be continuous, right? It's gotta be through the every stage of your cycle, whether it's a project, whether it's a continuous project, whatever it may be. So I assume all of you talk to like business people during the requirements gathering, right? I would hope. But how many of you invite your marketing people to spread plannings? Postmortems? Oh, hey, there's two people who invite people to postmortems. But why not, right? Why wouldn't you? Don't you think that they have the insight that would give you a perspective on those things, right? You talk to them for the requirements, right? Because they're the ones defining the project. So why aren't they involved in all the other phases? In every stage of that process, you're asking yourself a question. How does my decision impact the business itself, right? I mean, we established that, that you have to ask that question, whether by purchasing your hardware, picking the technology, picking a new vendor, right? Or just investing into building a future, right? So if you're asking all those questions, why are you not involving the people who run that business? And how many people have a separate select channel that managers are not allowed in? Don't lie, don't lie, I know you have that one. So one of the things I see tweets like that, I actually have a couple of questions. First of all, how many zeros are in the zillion? Second of all, which chat product supports the one people? And instead of all like, why are you making an assumption that having the managers and VPs in the channel is a bad thing, right? And there may be, trust me. I mean, I've had multiple conversations where it's like, look, I can stop doing what I'm doing and explain to you where I am, or you can let me finish in peace and quiet, and then I'll give you the whole story about it, right? Everybody had that conversation, right? But it doesn't necessarily mean that you will have that conversation, right? It's going back to the whole education thing. You should judge on value the person provides, not on their title, for example, right? So if a project manager comes in and asking you for the status or asking you where you are in the process, you should educate them not to do that. But if they're asking you what you're working on in order to help you maybe ease your pain or take this off something else off your plate or something else, then it provides a completely different value, right? And you don't know what the value may be until you start knowing the people you work with. That's our understanding of the business more. I'll give you another example. I was working, I had one of those days, you know, where everything is going wrong, right? We had like credit card processing is broken, like all the major processes and applications broken, like companies losing money left and right. I'm doing the troubleshooting, Kamasutra, you know, the one with the phone on your shoulder, like typing on three terminals and, and I get a phone call, right? And I get a phone call from the CEO of the company and he was like, we have a problem. I was like, oh, no shit. You actually have multiple problems, but yes. He's like, yeah, we have a problem. We have a type on our terms of conditions page. I was like, okay, sure. I'll put it in the queue whenever I'm done with everything, we'll deal with this. He's like, nope, we need to snub all priority, drop everything you do and you need to fix this. And I don't even know what to say without, so like with non-currency worries. I'm like, are you kidding me? Like I am fixing your business, right? And this is not the situation where I don't know the business I'm making a subject. I actually don't know exactly how much money they're losing every minute the site is down, right? It has a lot of zeros in it. Like, so I know the business, I know what's critical for their business and I'm like, what are you talking about? Like, I have major, major malfunctions in yourself. They're costing you tens of thousands of dollars a minute and you want me to fix a typo. Like, does it sound different when I say it back to you? And again, he was gracious, I said, hey, I have a compliance officer sitting in my office right now and fixing that typo is the only way standing between that and us getting our compliance, which in the long term will save us millions and millions of dollars, right? And it makes total sense, right? But in a situation where you think you know, like in that situation, I knew exactly what was, I mean, I knew what was valuable for the company. And yet that computer caught me off guard, right? So going back to what I said before, having the different perspectives are very valuable, right? There's things that you just don't think about, right? Or you're not previewed to some information, right? Which perhaps knowing the information would have changed my mind that that typo is more important than the payment driver. So yeah, so different perspectives are available and even in retrospect, they're available, right? And everybody's doing their post mortem perspective trying to go through a problem, right? And as before, like why are business people not part of those retrospectives, right? They're the ones who know exactly what the impact of the problem may be on the business itself, right? Which is available, I think. So that's a familiar thing, right? I mean, everybody's in grass like this. Everything is fine, like you get your measure in the 90th percentile, and then you've got a big spike, 4.30 in the morning, 5.00 in the morning, right, you try to troubleshoot it, you fix the problem, everything is fine, and you're doing your post mortem afterwards, right? So yeah, something went wrong, you fixed it, but overall you're still under the 90th percentile, right? So you're still below threshold, you're still not violated, everything is fine, right? So there was a problem, you fixed the problem, everything is fine. So everybody, right, have the user perceived performance graph, right, I hope, or scene one or user one. How many of you actually thought how many users are affected by those spikes? Actual users, not the percentages of people, not the trends, how many actual users? This is exactly the same data, same graph, right? And this is the actual people that got affected and subsequently the revenue that might have been lost because those people's experience been affected, right? So once you look at it in this perspective, like you look at it under a couple of different rights. So perhaps that spike and this spike actually costs money that needs to be deeply investigated because that is not an acceptable order at this point, right? So maybe SLS needs to be modified, maybe some other checks and balsam need to put in place, but it puts a different perspective on the problem that you thought was minor, right? And that problem again comes from a business, right? When you look at something saying, hey, 20 people were affected in a half an hour period. Is it an acceptable downtime, right? Is an acceptable problem to have? And maybe it is, right? Maybe it's like, I ain't just 20 people, right? Oh, who cares? And maybe the answer is like, well, those 20 people are gonna spend 100,000 on our side. So yeah, we can't have this happening. So context is important and context really is important anywhere. And in order to gain the content, in order to gain context, you need to be looking at the same thing, right? Which brings me to my next point, visibility, right? How much of that information are you preview to? Right, that's the famous picture, right? And that's generally like, even looking at that graph, that's generally how you look at things, right? You see all the lady or you see young woman, right? Which one do you see? So I'll give you a different example. Again, user perceived performance. There's a huge spike as operators, you see this. You have no idea why this is happening, right? You just see the performance chirocurate, you start to check in the CPUs, you start database, you start to check in the application itself, right? Something went wrong. You're trying to figure out what it is. You have no idea, right? Where in the meantime, your market is looking at their graph and goes, yes, our promotion is working. This is what you're looking at. This is what they're looking at, right? You think context is important, right? If you had that information, it would be useful to say the least. So how many of you monitor or responsible for monitor in general, putting the monitors in place? That worries me that there's not all of the hands are up in the air. How many of you monitor like health of the systems, right? So CPUs, make sure everything is cool. How many of you monitor applications, like APMs and whatnot? Who wasn't? How many of you monitor business metrics, like revenue, number of visitors? Yeah, that's a problem. Because that content, like, you should collect everything you can, right? I mean, first of all, I'm not saying alert on everything because that's suicidal, but you should collect everything you can so you can correlate it later, right? There is no reason not to have the information. For example, we were talking about revenue a lot, right? E-commerce sites. There is no reason not to look at the revenue trends and seeing what that happened out, right? Because whether you're like cash hit-miss ratio is off slightly in the middle of the night, nobody really cares about it, right? If a revenue is below the threshold, I guarantee a lot of people will care about it, right? And from there, you can correlate the data, see what works wrong on the technical side and then work with business people to figure out what their sexual problem or it's a norm, right? So all of that is very collaborative in itself, right? Because you need to gain access to information you don't have and you need to share information that you have the other people don't. And last but not least, empathy. I actually didn't have an original on my slides, but then realized that, first of all, I didn't have enough unicorns. And second of all, I wanna make that point again. I assume everybody's trying to do good, right? Yes, there are bad managers. Yes, there are people who really don't care about IT and assume that we're just there to write code and nobody needs to talk to us ever again. But for majority of this, people are good, right? And people are trying to work towards the same goal to get the business working, right? They just try to do it from a different angle. So talk to them, find a common ground, find a way to share the information to get to you. And to finish off with Damon's words, I mean, DevOps itself makes sense because it's good for the business. And if she was right, because it's good for us, right? Or for everybody. And that's it.