In today's episode we talk about good key results and objectives, and how to clean up your goals. Having a goal is not enough and knowing your principles and what makes you different from others is the hardest part.
In today's episode we talk about good key results and objectives, and how to clean up your goals. Having a goal is not enough and knowing your principles and what makes you different from others is the hardest part.
Build a custom point of sale that connects to Square Terminal, an all-in-one credit card device built by Square for contactless and card payments.
Start building with Square Terminal API by visiting https://developertea.com/square today!
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com/contact.
If you would like to join the new experimental DIscord group, reach out at developertea.com/contact, developertea@gmail.com, or @developertea on Twitter.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
If you're like most developers, you probably have something that you're measuring. Your team has some kind of goals that you're trying to hit and part of your job is to move the needle. In today's episode, we're going to talk about the good of that and hopefully reinforce why it's important that you get to that place. But we're also going to roll back a little bit. Go upstream, a couple of steps, to what the measurements are trying to indicate in the first place. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And I can almost guarantee you that your career will be improved. You will improve not just in your career, but in your personal aspirations. If you have some kind of way to measure your progress towards a goal. So what this often looks like for teams is having some kind of metrics. We've talked about this, surely hundreds of times on this show before the idea of an objective and a key result. That's the same thing as saying some kind of goal or some kind of intention and the proof that you've met that intention. Or in some ways, the key results is the definition of success on that pathway towards that goal. So most teams set these. I mean that most teams have some kind of way of evaluating success. But most of the time, they're not doing it in a way that's measurable. What do I mean by this? Most teams will have, let's say, quarterly reviews. Most teams are going to have some kind of where the rubber meets the road moment. But the backwards thing is that most teams are not explicitly defining these. These are sometimes softer metrics and often they're not optimized or measurable in any meaningful way. So you probably are measuring it, but you're probably not measuring it the same way that someone else says, and so success means different things to different people on the same team. This is most critically important when you have a difference in your definition of success and some stakeholder or someone who is responsible for financing your team or financing your job. Someone who is going to decide whether or not you're going to continue working in this capacity. If you have different definitions of success between those layers, you can come into some really damaging problems for teams. And this creates a lot of miscommunication, not to mention that you're probably not going to meet your goals as a team, as a company. So what I want to talk about today is fixing this problem first starting by actually measuring something that you can both agree on, but then I want to go upstream. And we'll talk about that upstream part in just a moment. But first, let's talk about what it means to have a shared measurable goal. A shared measurable goal means that if I as an outsider and given the proper measurement tools, I can have the same measurement as an insider would have. In other words, the measurement should be observable. It should be a concrete measurement, something that is definitive and available. A good example of this might be a percent change in some particular number. Another good example might be a particular rate of a particular event occurring. Other examples include reducing a number from some magnitude to another magnitude, sometimes even to zero. And there are even good measurements that are binary where we can say true or false. Did this thing, for example, did we publish the thing that we set out to publish? That's a good example of a binary key result. We'll stick with that terminology. So it's just as important, though, since we've given a definition for what a good key result might look like, we need to talk about what a good key result doesn't look like or more specifically what bad key results might be. So remember the definition here is that anyone given the proper tools and access could come up with the same measurement. These are outsiders, right? These are people who don't need context. A bad key result then would be something that requires context or requires some kind of institutional or cultural knowledge to be able to measure. Now this, once again, we're not talking about access or how to filter that data or something like that. We're talking about measures that are based in someone's state of mind or opinion or in some collective sense of satisfaction. Now I want to be very clear here because we're not going to go so far as to say that none of those things are important. No matter what we do as humans, we will never get away from the idea that working together is a human endeavor. And so political affiliations within a company are always going to exist because they are part of our fundamental human makeup, at least for the next many generations, this will be true. And so we shouldn't try to completely eradicate these things because that effort would fail miserably. But instead, we shouldn't rely on these political measures, right? These cultural kind of sense of accomplishment or anything like that to determine all of our actions in planning. We can wrap those political measures. We can wrap those cultural understandings, those not-so-concrete things. We can wrap those around what I'm talking about with the more concrete measurements. So I want to be extremely clear just once again that our goal as engineers, whether you are on the management track, if you're a lead engineer, if you're a junior engineer, all the way across the board, our goal is not to try to eliminate those relationship type discussions. This opinion is very often, unfortunately, shared by a lot of software engineers that the opinions of other people or that the political affiliations within companies that these are meaningless, that they don't matter, but this simply isn't true. And so what we need to do as engineers is understand both how to work within those structures in meaningful and useful ways, but also that we should push for a better understanding and appreciation for the more concrete measurements. So what we shouldn't do is conflate these ideas, and that's where we go wrong. We understand our concrete success based on, based on potentially inconsistent opinion and other measurements that we can't nail down, that a third party, an impartial person, an outsider, wouldn't be able to understand. So we can't rely on these measures to be definitive. We can't rely. What we can do is have those cultural discussions about the measurements. What we could do is, for example, we could look at a measurement and we could say, okay, this data is suggesting a couple of different narratives. Let's talk about those narratives so we can understand and adjust and adapt and do all of those things that humans are incredibly good at doing in a collaborative atmosphere. What we shouldn't do is look at that data and say, either we have failed or succeeded and there's nothing to learn. So the marriage of these two things is very important, but we shouldn't conflate them. We shouldn't say that failure is necessarily determined purely out of these key results. We need some kind of contextual discussion around it. We also absolutely shouldn't say that failure or success is determined purely by somebody's opinion. We need both sides of this coin. So if you are leading a team, if you are in a place of influence, it is your responsibility to clean up, to clear up your key results so that they are measurable and clear and they can be disambiguated very easily by any third party. This is the kind of easy way to understand. Now the quality of that key result is a different question entirely. We're just talking about whether or not it is a valid key result, but it can be valid and a very low quality or low signal key result. In other words, the key result doesn't necessarily represent the goal perfectly. All right. We're going to kind of assume that your key results do map to your goals. But I do want to talk about goals. I want to go upstream and talk about goals right after we discuss today's sponsor, Square. No matter what part of your developer journey you are in, you probably will deal with some kind of payment system again in the future. There builds the square terminal. This is a custom point of sale. It's an all-in-one credit card device, a physical device. It allows for contactless and card payments. It has a 5.5-inch corner to corner touchscreen. It's easy to disinfect. It's safe. It allows for distanced payments. But for software engineers, it also allows you to seamlessly integrate with your app via the terminal API. You can accept Apple Pay, Google Pay, other NFC payments plus. It has a MagStripe and chip card reader for a smooth checkout experience. The terminal API is compatible with basically every web and mobile platform, pretty much anything you use, iOS, Android, Flutter, React Native, or Windows applications. It can work on all of those. Square also has your back. If you build with the terminal API, you can take advantage of squares into end encryption, dispute management, and fraud detection. Connect your app to the all-in-one payments device merchants love with a simple, rest API head over to developertea.com slash square to get started today. Thanks again to Square for sponsoring today's episode of Developer Tea. On today's episode, we've been talking about this idea of cleaning up your key results, cleaning up your goals, trying to come up with some more correctly measurable key results, but also marrying those rather than completely abandoning the idea of cultural context, marrying those two ideas together. You need both. And I want to move on upstream to talk a little bit more about how we get to these goals to begin with. Very often, these kinds of questions are the ones that we're not asking. We say, for example, that we want to increase our user count. But do we know why? Can we draw a clear line? And that one seems pretty easy, right? If we increase the number of users we have, then probably we're going to increase our revenue. How does that actually work? This is the question that I want you to ask about each of these goals. I want you to understand these, especially if you're in the process or in the group that is setting these goals. That's determining what are these top level goals going to be that you derive all of these other measurements for, because here's the thing. This is one of the most powerful levers, one of the most important levers that you have in a company. Defining the goals that then cascade into multiple key results, multiple things that you're caring about, that you're measuring, that people are kind of staking their entire work on, that they're targeting towards. This is the critical juncture to understand leverage and to be incredibly clear, incredibly clear about the why. You see, goals don't come out of nowhere. When we set goals or when we set objectives or when we set these things out, it's very important that we make a clear line of logic to something that that goal accomplishes. When I say accomplishes, I mean, what is the measurable difference in reality if that goal is met? Now, once again, I want to be clear about this because on this side of the equation, we allow for non-measurable things. In other words, it's not necessarily a concrete answer. For example, you might say that the reason that we have this goal is because it's derived from our set of values. We want, let's say we want happy workforce that are company. This is a common goal, especially for, let's say, an HR department, right? We want our workforce to be happy. That's the objective, that's the goal. Some of the key results that we're going to target in order to make that happen, we're going to have a low turnover. Some percentage is going to be our maximum or zero turnover, even. Very aggressive key result. We're going to have maybe an internal survey that standardized so we can measure the satisfaction or maybe an internal NPS score or something like that. There's plenty of things that you could do to measure this, but if we go up the chain again, if we go upstream and ask, okay, why do we care about a happy workforce? Why do we care that the people who are working at our company are satisfied with what they're doing? This question, you may not be able to easily say, well, it's good for business and here is the measurable impact that this is going to have. That may be true, but it's not always going to be the reason for the goal. The reason for the goal might simply be that we set out to build a workplace or to establish an organization that has happy workers. That's part of who we are. It's part of our identity. It's part of our values. We don't want to exist as a company unless we can do that. This may seem antithetical to the first part of this episode where we talk about how key results need to be measurable, but here we're talking about a different kind of derivation. We're not saying that we have confusion about whether or not we have succeeded. What we're doing is we're giving justification to the existence of the goal itself. The justification for that doesn't necessarily have to be always driven back to some kind of hard numbers factual statement. It might be that you set a goal to increase your net promoter score amongst your customers because NPS has a high correlation for your particular marketer, for your particular product, to revenue. This is a reasonable thing for you to say that the reason that we want to have a high NPS or the reason that we want to have happy customers is because that results in more money for our company. There's nothing wrong with that being your justification for that goal either. What are we saying? We're saying that you shouldn't come up with goals out of nowhere. You should be able to explicitly state when those goals don't have a measurable reason. They don't have a measurable business level impact that should still be allowable within a business goal framework because businesses have values. They have principles. They have charters. These are all the things that businesses can have and what separates one business from another could be the things that they value. But on the other end of the scale, on the other end where we're trying to measure whether we are actually meeting these goals through some kind of measurable metric, right? Something that says that we've kind of all agreed that if these things are true, then we will consider that goal to have been met. Those have to be concrete, those have to be measurable by a third party and external person, someone who comes in with no cultural knowledge at all. Hopefully this will help you as you begin to kind of lay out your intentions and your goals as a company or as an organization, even as a department in your company, whatever your org chart looks like, you can look at these goals as things that you want to do for one reason or another. Because we can always go back. We can always go beyond something concrete at that top level. We can always say, okay, well, you want to make more money as a business. Why do you want to make more money as a business? You can still continue to go up that Y chain. So it is okay to set those goals, birth those goals out of something that isn't a business, kind of universal business concept or fiscal responsibility that's okay to do. On the other end, when you're measuring your outcomes, the only way to measure outcomes is in a way that is repeatable, in a way that is shared, in a way that is visible and accessible to all the people who care about that measure. Thanks so much for listening to today's episode of Developer Tea. Thank you again to Square for sponsoring today's episode. Head over to developertea.com slash square to get started with the square terminal API. If you want to join the Developer Tea Discord community, you can reach out to me directly at Developer Tea at gmail.com. You can also reach out to me on Twitter at at Developer Tea. This community is full of people who are not talking all of the time, constantly chattering, but instead are asking meaningful questions and we have open question channels. There's a channel called no stupid questions. There's a channel that is for an interview prep. If you're preparing for an interview, you can go in and ask questions about what you should expect or is there anything that you, is there a strength or a weakness that you should be working on? There's a kind of things that we talk about in this discord community. Send me an email at developertea.com. You can also reach out to me directly on Twitter at developert. Thank you so much for listening to this episode. Until next time, enjoy your tea.