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.
And 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 Cutrelley listening to Developer Tea. My goal on this show is to help dream developers like you find a 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 of strategy or abstract the idea of problem solving if you are the manager of this problem. When abstract the different ways that you can interact with the problem. 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're given some kind of goal to accomplish with those Legos. So, ostensibly, the goal would be to have the Legos in a particular shape, but it could be that you need to have them reach. Any 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 aren't 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 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 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 and 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. 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 here, 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 probably experience this. If you try to add an engineer to a team, laid in the project, we know this from many books and many studies that adding more engineers, laid 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. So you have to add it. But there's other obvious examples of this and some less obvious examples. Obvious examples include 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 that we don't have the personnel. 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. Well, 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 some 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, that isn't 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's particular team that 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, right, 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, you're 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 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, and you are really missing out, it helps maintain sanity as you're releasing features because it allows you to turn those features on your team. To turn those features on selectively and with something as mature and well developed as launched darkly, 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 a battle tested and proven. There are large businesses already depending on it. For example, Chris Gidry, who is O'Reilly's VP of engineering, had this to say about launch darkly. He said with launch darkly, our engineers can ship code whenever they want and we can test features and production well in advance of a marketing launch. And if a feature causes problems on the day of the launch, we can just turn it off with a kill switch, no rollbacks. Launch darkly 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. What launch darkly allows you to do is decouple your features from your code. Go and check it out. Head over to launchtarkly.com. Thanks again to launch darkly 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 when I talk about the next approach first, which is subtractive thinking. Subtractive thinking. And 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. The perfect example of this. If you're trying to solve your calendar, it's very likely that you need to approach with the 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 large. Subtractive and by the way, subtractive and additive kind of come along with the territory of variance 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 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 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. What you'll start to notice if you use this framework is typically these mindsets are wrapped in a lot more 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 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 headcount. These are all the ways that we can change things. 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 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. 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 additive mindset. All of that to say, we have all of these different ways of manipulating the components in our problems. We very often forget the last one. We very often ignore the last one. 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. They change and morph and grow or shrink on their own without any intervention. 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. Sometimes, the interventions that you try to impose on a garden can ruin it, can make it worse. If you're having team issues, let's say that your team is not getting along incredibly well. 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. Or to transform. 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 his 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 move position and continue on. These organic components, they change when they're in contact with one another. 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. You can think back to this model and imagine, 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. And I think 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, launch darkly. Launch darkly is today's leading feature management platform with launch darkly a IBM went from deploying twice a week to over a hundred times a day. If you want to be like IBM and deploy often what you do head over to launch darkly dot com to get started with feature flags as a service right now. And so much listening to this episode if you want to join the developer D 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 do the fame 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 Developer Tea. A gmail.com you can also reach out to me on twitter and add Developer Tea. Thanks so much for listening and until next time enjoy your tea.