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 Tea. My name is Jonathan Cutrell and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. We're taking a short break, 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 administrative and all of 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, you know, 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 pyramid. And there's more peas 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 Launch Darkly. Launched Darkly is feature management for the modern enterprise, fundamentally changing how you deliver software. And here's how it works. Launched Darkly enables development and operations teams to deploy code whenever they want to, even if the feature isn't ready to be released to users. Dropping code with feature flags gives you the safety to test those new 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 flag status and the changes are made instantaneously by the real time streaming architecture that Launched Darkly is so famous for. Go and check it out. Head over to launch darkly dot com with Launched Darkly. You'll innovate faster, deploy fearlessly and make each release a masterpiece. Once again, that's launch darkly dot com. So let's talk about the big picture pyramid, a 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 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. Right? You had another P here. I realize with 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. And 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 dos 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 adopt that sets you apart as a company that might look a lot like principles, but actually their 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 squeaky wheel gets the grease. 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 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. So 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 to day. 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 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 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 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 yet another principle to help you define a strategy for this, right? Your process may include creating explicit buckets and think about your time as an investment, right? 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. 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. 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. 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. 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, 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 Launched Darkly. You can get started with Enterprise Great Feature Flags by heading over to launchadarkly.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 launch darkly.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 in around for seven and a half years or so and you've been so generous 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 this 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 on iTunes. Thanks so much for listening and until next time, enjoy your tea.