how do we keep the big picture in mind when we're doing daily work that's what we're talking about in today's episode of developer t my name is jonathan cuttrello my goal on the show is to help driven developers like you find clarity perspective and purpose in their careers we're taking a short break uh at least this episode we're taking a break from our better report better manager series to talk a little bit about this big picture approach what does it mean to have a clear big picture and how can we do something about that on a daily basis here's what tends to happen we get into our work and we have ideas of what we want to accomplish Maybe these ideas are determined as a team. Maybe they are determined individually. Maybe they're determined on an ongoing basis. Maybe there is some higher level determination set by, let's say, company leadership. And so we start out our day or we start out our sprint or our week or whatever unit of time you want to think about with that vision in mind. But then things start to degrade and change. We start having new ideas of what we might want to accomplish. And perhaps more often we get distracted by the administrivia and all the things that other teams are asking us to do. All of the technical debt that we forgot to address in the last iteration, the last sprint, the bugs that pop up, all of the things that we can't really say no to, but aren't really, in our minds at least, a part of the big picture. Now, what we're not going to address in today's episode is the importance of discipline. Yes, it should be a given at this point, if you've listened to this show, that it does take discipline to actually... ...prioritize and to know when it's time to say no or how to say no for that matter. And to be able to back that decision up, to be able to say, here are my priorities. And unfortunately, these other things that we're being asked to do as a team, they are putting these other priorities at risk. And then, of course, to share that priority set with the person who's requesting with you. That is really the hard exercise of prioritization. We're not going to talk about that in depth today. Instead, I want to talk a little bit more about the mechanics of how you actually go about practicing keeping the big picture in mind while also working day to day. I'm going to give you a fairly cheesy alliteration to help you remember how to think about the big picture. We're going to call this the big picture. Big picture pyramid. And there's more P's coming. At the top of the pyramid is process. The next part of the pyramid is priorities. And finally, the bottom of the pyramid is principles. We're going to talk about each of these in a little bit more detail right after we talk about today's sponsor. This episode is brought to you by LaunchDarkly. LaunchDarkly is featured. You can just update the features and infrastructure in your real production environments without impacting your actual end users. And then once you're ready to release more widely, you can just update the features and infrastructure in your real production environments without impacting your actual end users. At the top of the pyramid is progress. At the top of the pyramid is progress. time streaming architecture that LaunchDarkly is so famous for. Go and check it out. Head over to LaunchDarkly.com. With LaunchDarkly, you'll innovate faster, deploy fearlessly, and make each release a masterpiece. Once again, that's LaunchDarkly.com. So let's talk about the big picture pyramid. The big picture pyramid. This is how you can think about how to define your work. All of your work will ultimately be based on the bottom of this pyramid. The big part is principles. Principles are simply something that is pervasive. They are pervasively true in some demonstrable way. Many principles are formulated as heuristics, like, for example, the Pareto principle, the idea that 80% of the value comes from 20% of the work, and the remaining 20% of the value comes from 80% of the work. This is considered a principle because in a lot of cases, this is demonstrably true. Now, don't confuse principles with proofs. Yet another P here, I realize, but proofs are not a part of the big picture pyramid. Don't confuse principles with proofs. If the principle is useful, and if it's demonstrably true most of the time, then you can use that principle as a basis for a lot of your work. From principles, you derive both your priorities and, your processes. So first and most important is your priorities. We've kind of already touched on this. We're not going to get into the do's and don'ts of prioritization or the difficult parts, but the critical thing here to recognize is that your priorities should not violate your principles. And you can quickly see why it's so critical to think clearly about your principles. For example, let's say you adopt a principle that says the customer is always right. The resulting priorities of this principle might mean that fixing an issue for one customer comes in front of developing a feature for, let's say, hundreds or even thousands of customers. For this reason, we also need to differentiate principles from values. Values are typically a limited set of things that you can do. And so, if you're going to do a feature that's that sets you apart as a company, that might look a lot like principles, but actually they're decisions on what you're going to optimize for. Principles, on the other hand, is less like a curated list and more like a domain-relevant list of mental models that you can apply. For example, if you think about a principle of the customer always being right, you may also counterbalance that principle with a different principle. The idea being that the customer who complains the most tends to get the most attention. Your company might adopt a value that says build for the right customer. And that value may be based on some principles, some economic principles that choosing your specific customer base may yield better results. But with the value in mind of building for the right customer, you can take those previous principles and apply them to your company. And that's what we're going to do. Principles that we talked about, the squeaky wheel gets the grease and the customer is always right, and develop a prioritization that understands that not every customer is going to be the right customer. It's important to note that this is not easy. Just developing these principles and weighing them against your values, it's not an algorithmic process necessarily. Instead, you have to think about this as pieces of information, kind of atomic information, that you can compose together to develop your priorities. Now, here's where it gets interesting and where we get down to the day today. Keep in mind, by the way, that priorities are things that might change over time. And your principles are things that are going to stay relatively the same. You may have some new principles come in, or you might find that a principle changes, that you're not able to demonstrate it as true as much as you were able to before. But overall, your principles will change much slower than your priorities. The most atomic actions that we take are expressed in processes. Our processes should be informed by both our principles and our priorities. This is how we keep the big picture in mind. If we're running a process like, let's say, sprint planning, it might feel like our job is to walk through those steps. And to some degree, that's exactly what process is. And I'm specifically making process the top part of the pyramid because process should be relatively small actions. We don't need to think about process as a whole suite of actions taken all together, but instead individual atomic actions that are derived from our principles and our priorities. So if we're doing sprint planning, then we might take into account, for example, the principle in software engineering called, you aren't going to be able to do this. You're not going to be able to do this. You're not going to be able to do this. You're not going to need it. And we may have a few cards in the backlog, whatever tool you're using that documents your work, that describe some feature that isn't going to be used until some future date. And then we may have some less exciting work that is more immediately valuable. We can use this principle of you aren't going to need it to quickly prioritize the items that are in our backlog. We're generating the value of the product. We're generating the value of the product. We're generating some priority and our process now becomes more informed. The higher priority items are likely to be the ones that deliver value most immediately. However, we may also adopt another principle that says that smooth delivery depends to some degree on lower technical debt. So using these two principles together, we can recognize that value delivery, immediate value delivery over time, is going to be more important than the value of the product. So we can also adopt another principle that says smooth delivery depends to some degree on lower technical debt. However, we may also adopt recognize that value delivery over time may be threatened by approaches that only optimize for value delivery up front. In other words, we might take on stories that don't immediately provide value but do create some basis for better, smoother value production into the future. Once again, this is difficult. How do you choose between delivering value now or delivering value into the future? You may use yes or no. You may use yes or no. You may use yes or no. You may use yes or no. Yet another principle to help you define a strategy for this. Your process may include creating explicit buckets. Think about your time as an investment. This is another mental model. You could probably formulate a principle like the things that you want to take care of, you consistently invest in. And with this principle in mind, you think about your technical debt in terms not of dealing with it when it becomes an emergency, but rather proactively dealing with it upstream of any problems that might occur. Now, we've been talking about all of these specifics as examples of ways that you can use your principles to derive both your priorities and your processes. Now, the amazing thing here is that... Your kind of library of principles can continue growing. You're going to have principles that span almost every area. For example, team dynamics, you're going to think about psychological principles. You're going to think about market principles when you're trying to make value decisions. And there's even kind of meta principles. The idea that trying to use too many principles in a given situation may actually be detrimental rather than helpful. Okay. The check that I want you to perform on a regular basis, you can think about this in terms of your sprint iterations or maybe in terms of quarters. This is how you think about the big picture. You audit those atomic things that you're doing. Look at your processes and look at your priorities, which are kind of determined in some ways by your processes, right? You can derive whatever your priorities are based on how you're spending your time. And the way that you spend your time is... Tied up in whatever your processes are. So look at these two things and determine where is the source, right? What is it that is driving the way that you're setting both your process and your priorities? If it's not based in principles, right? If you're not able to base it in principles and instead you're reacting to some environmental situation, then what you're actually doing is accidentally applying... Perhaps a suboptimal principle, right? The principle of that decision-making process, of that prioritization process, is unintentional. The underlying principle might sound something like, I always need to help my coworkers because if I don't, we'll fail. The audit to perform here is to recognize when you are being intentional with your processes and your priorities. And when you're being reactive and using these implicit principles that are suboptimal to your goals. I hope this will help you see the big picture and learn how to actually apply those principles all the way through to your processes. Thank you so much for listening to today's episode of Developer Tea. This episode was sponsored by LaunchDarkly. You can get started with enterprise-grade feature flags by heading over to the website, launchdarkly.com. I promise you, if you start using feature flags, your releases will go smoother and you'll probably sleep a little bit better at night. That's launchdarkly.com. Thanks so much for listening to this episode. If you enjoyed this discussion, then I'm going to ask you to do something that I don't often ask on this show. You probably know that iTunes reviews are in many ways the lifeblood of a podcast. We've been around for seven and a half years or so, and you've been so generous. I'm sure you've been a great help in helping us stick around, adding more reviews. If you've never reviewed this show, and plenty of you haven't because I know how many reviews there are on iTunes, if you've never reviewed the show, it would be so helpful if you go and do that. That helps both give me real feedback on how to drive the show and what to keep and what to drop, but it also helps other engineers and other people who are interested in this content to find the show and decide that they want to actually commit to listening to it. So please leave a review. Thanks so much for listening, and until next time, enjoy your tea.