This is Lyft FM, where I share stories, interviews, and lessons from the trenches building multiple billion dollar software products, 40Xing my career and compensation along the way. Imagine you have two software engineers. These are modeled on actual people that I know. Imagine both of these people enter the same company at roughly the same time, working in the same area. Both start at the same level, making maybe $200,000 a year. Both have roughly the same number of years of experience. Both know the same languages and frameworks. Both have roughly the same problem solving and technical skills. both have the same educational pedigrees. And yet within three years, software engineer now earns $250,000 per year and software engineer B now earns $500,000 per year. What are the key differences between these two engineers? They started in roughly the same place and have many of the same environmental factors, both positively and negatively impacting their progress. Yet, software engineer B is now making twice as much than A. How is this possible? Today's conversation is about focusing on outcomes and working backward to solutions. While there are many different micro decisions and qualities that might contribute to the difference between these two characters, I have found this to be the number one contributor to success. Working backward from outcomes does four things for you as engineer B. First, it aligns your thinking with the business by focusing on where the customer realizes value. And that's only natural in your typical engineering role. The who and the why are often handed off to your friendly neighborhood product manager to take care of. But it doesn't have to be like this. Most PMs that I know love having a peer in engineering who thinks about things from the customer's perspective. It makes their job easier. It leads to a better product. You make thousands. of tiny decisions in the course of building a great product. And if a PMS has specified each of these one by one, the odds of the product being great start to rapidly shrink. So operating with the outcome in mind helps you make directionally correct moment to moment decisions quickly. You move fast with less review and hopefully less rework. The second thing this approach gives you is self-awareness over time. Starting with outcomes forces you to consider your own role and how it relates to the roles of others and doing this regularly forces you to consider yourself through the eyes of others. You can then compare these predictions against what actually happens and doing this over and over again helps you make better decisions over time, predictions over time, which is in essence self-awareness. The third is that it helps you cut through your ego. I think as you get better at figuring out what needs to be done and become more self-aware, you start to better understand not just where you need to step in, but maybe where you shouldn't step in. Harry Truman is credited with saying, It is amazing what you accomplish if you do not care who gets the credit. And I have found this to be 100% accurate. This is hard at first. If you're listening to this, it's probably because you consider yourself a high performer or at least aspire to be one. And being a high performer requires some amount of ego, some amount of self-belief. But the same ego that helps you in some areas can get in the way in others. But the same self-awareness that helps you step outside yourself also helps you cut through your ego and find a, find the best way to move forward. It'll help you win people over, help you understand what they really want. And it'll help you find win-win solutions. The fourth thing that working backward from outcomes does is it helps you put the right amount of emphasis on decision-making versus execution. I think most of us have heard of the phrase armchair architect, and these are very senior engineers who step away from the day-to-day trouble of execution. And instead these people hover at 30,000 feet. Most of the time they'll swoop in to make a few big decisions and then they'll fly away. and leave the details to someone else. Sometimes that's fine. An executive can't be expected to track every work stream end to end. If you're an architect, you're usually overseeing anywhere from 100 to 250 engineers work, sometimes more. And so it's impossible to stay connected to all the itty bitty details. But if you wanna do the best work, build the best relationships, find the best opportunities, you need to stay connected. to the problem and staying connected to the outcomes along the way helps you do that. So you specify an outcome and then you work through with your org all the things that need to happen for that outcome to be true. Now contrast these four things with what you normally see from an engineer A. Many engineers over rely on their PMs to over specify every move, big and small. Many of these engineers ignore the customer experience, which if you think about it, the customer experience is the ultimate decider of scope. And in the context of something like distributed system design, you can't really design a distributed system of any size until you pin the scope. Scope is ultimately decided by the contract that you set with the customer. Sometimes that contract is just a user expectation. Sometimes that contract is quite literally a service level guarantee where the company will pay out if you violate the contract. And so if you want to build the correct system, you have to work backward from these customer outcomes. Many of these engineers will ignore the total costs of ownership of the thing they build. A product only makes sense if you can offer it profitably to customers. If you don't keep total cost of ownership in mind from the beginning, you'll either end up with something that is so expensive, no customer would use it or your only options are to operate it as a loss leader or shut it down. And the loss leader strategy can work, but it requires careful thought. And more often the thing will simply lose money. It'll lose money, it could shut down. And then you're remembered as the guy who burned a million dollars or $10 million. or $100 million on something that was entirely preventable. So engineer A may be a wonderful coder and maybe a very wonderful small scope system designer, maybe within the scope of just the tech, but it's engineer B who is considering their work in the scope of the broader business system. And come promotion time, choosing which of these two characters to promote becomes a laughably simple problem. It's the one who obviously connects their work to the business. So here's your homework for this week. First, think of a time when you were having a disagreement with a peer or some other stakeholder about how to move forward with something and you had to escalate to a manager. Was there a problem with the other person's decision-making process or were they simply operating against a different set of goals and incentives? And once you knew these goals and incentives, were you able to find a mutually beneficial solution? Second, as you go through this week, make it a habit to ask yourself why and what. Why does the customer want to perform this action? Why is this the best user experience design for performing this set of actions? What will it cost us to let the customer perform this action? What will it cost the customer if they perform this action as in, in money or time or patience, what value will they gain? in terms of time saved or new capabilities that they can offer their customers. What could I change about this thing to either reduce the cost or increase the value? Why is doing these things worth it or not worth it? Do this as much as possible this week. To start, try to do it at least once a day. And over time, it'll start to become second nature. And you'll find your job actually gets easier. You'll have greater impact, hopefully with less effort, because it'll be more judicious in what you pursue based on these questions of value and cost. And over time, you can parlay that into working on better projects. promotions and top tier compensation. This has been LiftFM.