There are only so many ways you can manipulate LEGO. In today's episode we talk about those fundamental transformation steps and how they apply to your daily problem solving.
There are only so many ways you can manipulate LEGO. In today's episode we talk about those fundamental transformation steps and how they apply to your daily problem solving.
Today's episode is sponsored by LaunchDarkly. LaunchDarkly is today’s leading feature management platform, empowering your teams to safely deliver and control software through feature flags. By separating code deployments from feature releases, you can deploy faster, reduce risk, and rest easy.
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.
In today's episode, we're going to talk about the theory of problem solving. I'm going to do it using Legos. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help dream developers like you find clarity, perspective, and purpose in their careers. And I'm excited to talk about problem solving. We have problems facing us every single day. Sometimes those problems are about what to do with our time. Sometimes the problem is as simple as what we're going to have for dinner. Usually those problems have some consequence, and sometimes they have major consequences. Some things are common with our problem solving processes. And in today's episode, I want to talk about different types. I want to talk about different types of strategy or kind of abstract the idea of problem solving. If you are kind of the manager of this problem, I'm going to abstract the different ways that you can interact with the problem. And we're going to talk about it using Legos. Let's imagine that you have a table. On this table is a set of Legos. Let's say you have some set number of Legos. And you have a set of Legos. And you're given some kind of goal to accomplish with those Legos. Ostensibly, the goal would be to have the Legos in a particular shape. But it could be that you need to have them reach a particular height and no specific shape is necessary. This is very much like the problems that we face in our day-to-day lives. In the sense that we typically have a variety of factors. Which turns out to be our Lego blocks. Those factors might be people. They may be actual facts or resources. Some kind of component that we can take into consideration. Sometimes those components are much smaller than we expect them to be. Like, for example, a component might be something that you said to someone a long time ago that has affected them until today. Other times those components could be very large, very important. Like, for example, resources, money. These are things that can be treated in a very similar way to Legos because they are components of our problem. For the sake of this argument, we're going to treat them as such. And so when you have a problem that has a bunch of different components, there are only a certain number of ways that you can interact with that problem. There's only a certain number of ways that you can work with these Legos. And we're going to talk about all of them on today's show. And we're also going to kind of explain some examples of each of these kinds. The first kind that we're going to talk about is probably the kind that comes to mind when you think of Legos. But interestingly, rarely comes to mind when you think of actual problems that you have. And that is the transformative approach. Transformative. But we're not talking about reforming your Legos. Melting them down and creating something new. We're just talking about moving them to different places. Moving the Legos in such a way that they are in a different shape than they were before. This is how you would expect to play with Legos. This is how you would expect to build a given shape with Legos that have already taken a different form. But we rarely think about our problems this way. We rarely think about our problems as a... A reorganization problem. And we're not talking about reorganizing people. We're talking about reorganizing resources. Or, for example, on your team. You could imagine that you have three people on your team. Maybe you're a manager. And those people are not producing the work in the way that you would expect them to. And when you start talking to those people, you realize that person A is working on something that person B really wants to work on. And person C actually wants to work more collaboratively with person A. And person B doesn't really want to work with person C at all. But they're forced to collaborate right now. And you can see that there are some ways that we could reorganize these people. These are components of a problem. And transforming those components could help you solve the problem. The second way. The second way that I want you to think about... Changing this scenario is adding. I know this seems like I'm cheating. Because we've got a table and there's only a certain number of blocks. Where did these other blocks come from? Well, if you think this way, you are exposing a way of thinking that is very common. And sometimes is a fallacy. And that is the zero-sum fallacy. The idea that whatever is currently available is always going to be available. I know I'm playing a bit of a trick on you. But it's critical to understand that adding is not just a magical cheat code. You don't always want to add. Sometimes adding causes more problems than it solves. You've probably experienced this. If you try to add an engineer to a team late in the project. We know this from many books and many studies. That adding more engineers late in a project tends to make the project even later. So adding does sometimes... Actually solve problems. The most simple example of this is when the table that you're starting with has no Legos on it at all. In other words, you're starting something brand new. Then you want to add, let's say, a feature. It's net new. You don't have the thing. And now you need to have the thing in front of you. And so you have to add it. But there's other obvious examples of this. And some less obvious examples. Obvious examples include... Well, the team over the long haul... Not just for a specific project. But over the long haul is missing a particular element. They are in need of a particular role. And that role just doesn't exist on the team yet. We don't have the personnel. And so it might make sense that adding the person is the right solution. Interestingly, sometimes adding at the right frame... Theoretically, always at the right frame... Is a process of transforming. So let's say you're zoomed into your team. You have three people on your team. And you need that fourth person. Because the three people that you have only have experience with application development. And you need somebody who has some data science experience. You could transform somebody within your team to take on the data science role. It's going to take some time. They're going to have to learn. That's more transformation. But what you really want to do is add a person to the team. Well, when you're zoomed in at this level... Well, that is an addition problem. You don't have the resources to shuffle around. But if you zoom out, possibly there's another team that has somebody on their team. And that particular team, they might be redundant on that team. So at an organizational level, it may just be a process of transformation. Now, even beyond your organization, if you zoom out to your network... Now you're talking about a larger pool of people. And if you cut down the company barriers as these kind of artificial barriers between people... Your process of adding somebody to your team from another company... Or hiring them from another company... Or maybe even hiring them from a new graduate pool... That is also a transformation move. So we can imagine that transformation is... Transformation is... In many ways encompasses a lot of these things. But at a certain frame... What we're looking at in these kinds of problems is an addition problem. We're going to come back and talk about the other two types of approaches to our Lego problem solving schema... Right after we talk about today's incredible sponsor, LaunchDarkly. LaunchDarkly is today's leading feature management platform. It empowers your team to safely deliver and control software through feature flags. If you're not using feature flags, by the way... Man, you are really missing out. It helps maintain sanity as you're releasing features... Because it allows you to turn those features on selectively. And with something as mature... And well-developed as LaunchDarkly... You can turn those features on selectively in a much more intelligent way. Right? This is not your homegrown feature flags that are buggy... And require loads of integration tests or something to make sure that they're working properly. This is a platform that you can depend on. And how do I know you can depend on it? Because it's battle-tested and proven. There are large businesses already depending on it. For example... Chris Gidget... Who's O'Reilly's VP of Engineering... Had this to say about LaunchDarkly. He said... LaunchDarkly makes our releases boring. You do want boring releases. Believe it or not. And we know as software engineers... That when we decouple things... They tend to work better. And what LaunchDarkly allows you to do... Is decouple your features from your code. Go and check it out. Head over to LaunchDarkly.com That's LaunchDarkly.com Thanks again to LaunchDarkly for sponsoring today's episode of Developer Tea. So we're talking about the different ways that you can approach problem solving. Specifically when you're talking about different components of a problem... Or different factors. We're using this Lego metaphor. You can kind of visualize how this works. And it's not a perfect metaphor. Because sometimes... One factor will disappear or mutate entirely on its own. We'll talk about how that matters in just a moment. But I want to talk about the next approach first. Which is subtractive thinking. Subtractive thinking. And this... This is intuitive if you think about it, right? Subtractive thinking. Additive thinking. These are kind of the opposite. Sometimes you have too much of something. A perfect example of this... If you're trying to solve your calendar... It's very likely that you need to approach with a subtractive thinking mindset. Removing elements from your calendar. Removing meetings. Removing events from your calendar. There are other situations like... Having a team. That is too... Too large. Subtractive... And by the way, subtractive and additive... Kind of come along with the territory of variants of these things. Like division and multiplication. Multiplication is, in essence, a type of addition. It's just a rate. Rather than... It's a difference in rate. Rather than concept. So you might think multiplicatively... When you're talking about reaching... Reaching new users. You might think... In terms of division... Let's say if you have a team of 10 engineers... And there's one manager. And you're thinking in terms of division... If you're going to add a new member to that team... You might think... Okay. Well, now we have 11 engineers. This person... This manager is already at their... Kind of at their limit. What can we do? Well, we can divide this team up into two teams. And we can add another manager. So these approaches... It seems very clear and obvious when you think about this. But what you'll start to notice if you use this framework is... Typically, these mindsets are wrapped in a lot more... Kind of ceremony than they actually contain. There's only so many fundamental ways that we can change these components. We're either going to move them around. Division is kind of a moving around in that previous example. We're going to add something new. We're going to add something new to the mix. We're going to hire a new person. We're going to start a new habit. We're going to remove something. We're going to stop our bad habits. We're going to reduce the head count. These are all the ways that we can change things. And if you're familiar with algorithmic thinking... Then this shouldn't come as a surprise at all. Because when you start to think about the shape of a problem... For example... You want... You want... A particular rate of user acquisition. What is that rate? It's a multiplication rate. It's an exponential rate. It's something greater than linear. And so the additive thinking that you're using in this scenario is very different. It's very different from, let's say, logarithmic thinking. Which is still an adding... It's still an additive mindset. Okay, so... All of that to say... We have all of these different ways of... Manipulating the components in our problems. And we very often forget the last one. And we very often ignore the last one. And I'm cheating again a little bit because... We're calling these components Legos. But in reality... They're much more alive than Legos are. They're much more organic. And they change and morph and grow or shrink on their own. Without any intervention. And so the final way that we might look at our problem and the components of our problem... Is to simply do nothing. To sit back and do nothing. Why would we think this way? Well, you can think about your problem... Sometimes you can think about your problem... As you might think about a garden. A garden is relatively self-regulating. And sometimes the interventions that you try to impose on a garden... Can ruin it. Can make it worse. And so if you're having team issues... Let's say that your team is not getting along incredibly well. And you feel that it's your responsibility to do something about it. Because humans... When we see problems... We feel the need to act on those problems. To actually intervene. To do something about them. To change something. To add or subtract. Right? Or to transform. And so we look at these problems... And we want to do something. We want to be active. But sometimes the best thing we can do... Is allow that problem... As cliche as it sounds... To work itself out. Because, once again, these components are not inanimate objects. When we deal with people issues... We have to remember... That the components that we're moving around... The things that we're transforming... That they're not going to simply... Simply... Move, position, and continue on. These organic components... They change... When they're in contact with one another. Right? They change... As time goes on. And so as we look at our problems... We might... More often we might ask... What if I did nothing? What if I sat back and watched? The amazing thing is that... If we were to do this... Even our presence alone... In that problem... Even the fact that we are observing... Can change the behavior of those components. This is a very important option... That is very often skipped. And so I want you to keep it in your repertoire. Because if you don't have that option available... Sometimes... You're going to... Add or subtract... Or transform... When the best thing you could have done... Was nothing at all. I hope as you move forward in your career... And you face problems that have these kind of component... Changes... In them. That you can think back to this model... And imagine... Okay, what are we talking about? Are we talking about an additive problem? Are we talking about a transformational problem? What are the implications if we were to zoom out... And imagine that... All of these are more like transformation problems? This way of thinking... Can set you on the right pathway. And... It can have you brainstorming. You can imagine, for example... When you start to believe... Just by default... That something is an additive problem... You could question yourself... And consider the parallel alternative. Consider... Am I thinking about this additively... When I should be thinking about it... Subtractively? Or... When I should be thinking about it... From the do-nothing perspective. From the gardening perspective. Thank you so much... For listening to this episode of Developer Tea. Thank you again to today's sponsor... LaunchDarkly. LaunchDarkly is today's leading feature management platform. With LaunchDarkly... IBM went from deploying twice a week... To over 100 times a day. If you want to be like IBM... And deploy often... Which you do... Head over to LaunchDarkly.com... To get started with feature flags... As a service... Right now. Thanks so much for listening to this episode. If you want to learn more... You can join the Developer Tea Discord. Which, by the way... You should. We have a lot of developers in there... That are trying to improve their careers. And we have a... We even have a channel... That is literally called... No Stupid Questions. You can go and ask any question at all... And no one is allowed to... You know... Do the feign surprise. Where they say... Wow, I can't believe you don't know that yet. Nope, that's not allowed. Your questions are welcomed. We want people asking questions... And learning in this Discord. And supporting each other. So go... To get an invite for this Discord. You can send me an email at... You can also reach out to me on Twitter... At... Thanks so much for listening. And until next time... Enjoy your tea.