 Hey, so I'm Matt Getty. I'm an SRE here at Twitter Boulder. And I'm here to basically talk about this idea of what problem you're trying to solve, kind of thinking of it from like an OKR planning sort of perspective. So for those of you who aren't familiar with OKRs, basically the goal is to try and figure out a way to move the needle in the right direction. Instead of having things that are boolean like launch this, you have increase it from 0 to 100. So if you hit 75, you can say, well, we got things in the right direction. But kind of taking a step back, right, before you have OKRs, you usually have a problem that you need to have an OKR that you solve for. And it usually winds up being something like a customer comes to you and they say that your service is slow. And you say, cool, there are a lot of different ways that we could go ahead and we could solve that. But you can't solve it until you know what the problem is. And all too often, people stop at the idea where the customer says our app is slow. And they say, well, we've got to make it faster. Super easy, we'll just make everything faster and that'll solve all of our problems. But if you take that road, then you have a lot of awkward solutions. My favorite one is if your site's not fast enough, you could just turn off your site. You could close up shop, stop your company, and that customer will stop complaining about your experience. Similarly, this is kind of the analog that I like to use. You see the car not starting in root cause analysis, right? There are a bunch of different reasons why your car might not have started. You left the seatbelt in the door. But ultimately, the light stayed on and it went ahead and it discharged the battery. There's a lot of solutions, same sort of thing here. You can remove the doors, turn it into a race car. That'll prevent you from accidentally leaving the seatbelt in the door that leaves the light on. But it's not really a practical solution unless you're like me and you like race cars. But we're really good at not doing the simple things. So all too often, we're all engineers. We like building things. And unfortunately for us, that means we like building things that are probably way more complicated than they actually need to be. In certain cases where a checklist could work, we don't have it. So we go ahead and we build something that usually looks like this. Some Goldberg-esque solution to try and prevent yourself from walking away from your car with the light still on or the power still draining on it. And don't get me wrong, this is really effective and it's a great engineering opportunity to spend a bunch of time. But there could be an easy fix. Where you go ahead, you exit the car, you make sure that the door's off and you kind of follow a process instead of solving it with code. And this is a lot cheaper and a lot quicker than anything else that you have. So you need to be careful not to confuse a technical problem with a business one. My favorite line from one of my old companies is only introduce code if it solves a customer problem. And that means that everything you do in code has business value. Which is really, really great. So you have business problems. This is kind of going back to the like OKRs, right? We need to make our service faster. We should peer more. We need to page too much. We need more log storage. These are slightly down from the customer saying that your service is slow. But they're all really important. But again, you have the familiarity thing where we say, well, the new framework is faster. We should migrate to it. That'll immediately solve all of our problems and we can just move on. Or we'll throw more money at it. And that might be a viable solution but it's probably not actually the problem that you're trying to solve, right? Building V2, it works, but you could go down and you could get to it and you need to do the whole root cause analysis to figure out why you actually want to go ahead and address it and why you want to spend the engineering time solving that problem. You know, here are some obvious questions that you have even before you go ahead and you start it, right? If we fix this, is the customer going to be happier? In a lot of cases, the customer might not even care that the site is slow or you might just have one customer but it turns out they're computers from 2006. But ultimately, this is what you want to try and wind up at with the problem that you're trying to solve is something that looks like this. Reduce the login service time from 100 milliseconds to 10 milliseconds. That's a problem, right? If you want it to be and it's actionable. You know, kind of going back to the car analogy, if you want to stop paging, you can turn off Nagios. You can turn off your services, you can turn off all of these different things and it's up to you to kind of decide where the value is but hopefully, you know, again, has business value. You know, technical problems are really, really cool but we're all too good at trying to build technical problems out of something that is actually a business problem and I see this all the time where we have to do this because we think we have to do it or because such and such wants to do it. Technology doesn't convey importance. It's an overhead to what you're actually trying to do. Keep in mind with the business problem you're actually trying to solve is. Again, introduce code only when it solves a customer problem and don't do things for the sake of doing it and always feel free to ask what problem you're trying to solve. Thanks.