Vox

Leitura de 20 min

Lego Problems - Modes of Operation on Component-Driven Problems

Summary

In this episode, Jonathan Trellier introduces a framework for understanding problem-solving through the metaphor of Lego blocks. He explains that many problems we face—whether in software development, team management, or personal life—can be viewed as having distinct components that can be manipulated in specific ways. The Lego analogy helps visualize these components as building blocks that can be rearranged, added to, subtracted from, or left alone.

Jonathan outlines four primary modes of operation when dealing with component-driven problems. The first is the transformative approach, which involves reorganizing existing components without changing their fundamental nature. This is similar to rearranging Lego pieces to form a new structure, and it applies to situations like reassigning team members to different roles or projects based on their interests and collaboration preferences.

The second mode is additive thinking, where new components are introduced to solve a problem. Jonathan cautions against the zero-sum fallacy—the assumption that available resources are fixed—while acknowledging that adding components (like hiring new team members) can sometimes create more problems than it solves. He also notes that what appears as an addition problem at one scale (like hiring a new data scientist) might be a transformation problem at a larger organizational scale.

The third approach is subtractive thinking, which involves removing components to simplify or resolve issues. Examples include removing meetings from a crowded calendar or reducing team size when a group becomes too large. Jonathan connects this to multiplicative and divisional thinking, where problems involve rates of change rather than simple quantities.

Finally, Jonathan discusses the often-overlooked option of non-intervention—the “do nothing” approach. He compares this to gardening, where organic components (like people) change and evolve on their own, and excessive intervention can sometimes worsen situations. This perspective is particularly relevant for people problems, where components are dynamic and reactive to their environment and to observation itself.

Recommendations

Communities

  • Developer Tea Discord — A Discord community for developers to support each other, ask questions in a ‘No Stupid Questions’ channel, and improve their careers without fear of judgment.

Tools

  • LaunchDarkly — A feature management platform that allows teams to safely deliver and control software through feature flags, enabling selective feature rollouts and kill switches without code rollbacks.

Topic Timeline

  • 00:00:00 — Introduction to problem-solving with Lego metaphor — Jonathan introduces the episode’s theme of problem-solving strategies using Legos as a metaphor. He explains that daily problems—from time management to team issues—involve components that can be manipulated like building blocks. The goal is to abstract different ways of interacting with these components to develop better problem-solving approaches.
  • 00:03:08 — Transformative approach to component problems — Jonathan describes the transformative approach, which involves moving or reorganizing existing components without altering their nature. He uses the example of a team where members are mismatched with their tasks or collaboration preferences. By transforming—reassigning roles or partnerships—the manager can solve productivity issues without adding or removing resources.
  • 00:04:59 — Additive thinking and the zero-sum fallacy — The discussion shifts to additive thinking, where new components are introduced. Jonathan challenges the zero-sum fallacy—the assumption that available resources are fixed. He acknowledges that adding (like hiring late in a project) can backfire, but also gives examples where addition is necessary, such as starting a new feature or filling a missing role on a team long-term.
  • 00:07:30 — Framing addition vs. transformation at different scales — Jonathan explores how additive and transformative approaches depend on the frame of reference. Hiring a data scientist might be an addition problem at the team level, but at the organizational or industry level, it becomes a transformation of existing human resources. This highlights that problem categorization is relative to the boundaries we set.
  • 00:11:10 — Subtractive thinking and rate-based approaches — Subtractive thinking involves removing components to solve problems, like cutting meetings from a calendar or reducing team size. Jonathan extends this to multiplicative and divisional thinking, where problems involve rates (e.g., user acquisition) rather than static quantities. He notes that division of a large team into smaller ones with additional management is a form of reorganization.
  • 00:14:47 — The non-intervention or ‘do nothing’ approach — Jonathan presents the often-ignored option of non-intervention, comparing it to gardening where organic components self-regulate. He emphasizes that with people problems, components are dynamic and can change on their own; intervention can sometimes worsen situations. Even observation can alter behavior, making deliberate inaction a valid strategic choice.
  • 00:17:18 — Conclusion and practical application of the framework — Jonathan concludes by encouraging listeners to apply this four-mode framework (transformative, additive, subtractive, non-intervention) to component-driven problems in their careers. He suggests questioning default assumptions—like automatically thinking additively—and considering alternatives, including the gardening perspective of allowing problems to resolve organically.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2021-03-01T13:35:00Z
  • Duration: 00:19:39

References

Podcast Info

Transcript

[00:00:00] In today’s episode, we’re going to talk about the theory of problem solving, going to do

[00:00:10] it using Legos.

[00:00:12] My name is Jonathan Trellier, listening to Developer T. My goal on this show is to help

[00:00:16] driven developers like you find clarity, perspective, and purpose in their careers, and I’m excited

[00:00:22] to talk about problem solving.

[00:00:24] We have problems facing us every single day.

[00:00:29] Sometimes those problems are about what to do with our time.

[00:00:33] Sometimes the problem is as simple as what we’re going to have for dinner.

[00:00:38] Usually those problems have some consequence, and sometimes they have major consequences.

[00:00:47] Some things are common with our problem solving processes.

[00:00:53] And in today’s episode, I want to talk about different types of strategy, or kind of abstract

[00:01:01] the idea of problem solving.

[00:01:03] If you are kind of the manager of this problem, I’m going to abstract the different ways that

[00:01:09] you can interact with the problem, and we’re going to talk about it using Legos.

[00:01:15] Let’s imagine that you have a table.

[00:01:19] On this table is a set of Legos.

[00:01:23] Let’s say you have some set number of Legos, and you’re given some kind of goal to accomplish

[00:01:31] with those Legos.

[00:01:33] Ostensibly the goal would be to have the Legos in a particular shape, but it could

[00:01:38] be that you need to have them reach any particular height and no specific shape is necessary.

[00:01:46] This is very much like the problems that we face in our day-to-day lives.

[00:01:52] In the sense that we typically have a variety of factors, which turns out to be our Lego

[00:01:59] blocks.

[00:02:00] Those factors might be people, they may be actual facts, or resources, some kind of component

[00:02:08] that we can take into consideration.

[00:02:10] Sometimes those components are much smaller than we expect them to be, like for example

[00:02:16] a component might be something that you said to someone a long time ago that has affected

[00:02:21] them until today.

[00:02:24] Other times those components could be very large, very important, like for example resources,

[00:02:31] money.

[00:02:32] These are things that can be treated in a very similar way to Legos because they are

[00:02:38] components of our problem.

[00:02:40] For the sake of this argument we’re going to treat them as such.

[00:02:45] When you have a problem that has a bunch of different components, there are only a

[00:02:51] certain number of ways that you can interact with that problem.

[00:02:54] There’s only a certain number of ways that you can work with these Legos.

[00:02:57] We’re going to talk about all of them on today’s show and we’re also going to explain some

[00:03:04] examples of each of these kinds.

[00:03:08] The first kind that we’re going to talk about is probably the kind that comes to mind when

[00:03:13] you think of Legos, but interestingly rarely comes to mind when you think of actual problems

[00:03:18] that you have, and that is the transformative approach.

[00:03:25] We’re not talking about reforming your Legos, melting them down and creating something new,

[00:03:29] we’re just talking about moving them to different places.

[00:03:33] Moving the Legos in such a way that they are in a different shape than they were before.

[00:03:39] This is how you would expect to play with Legos.

[00:03:42] This is how you would expect to build a given shape with Legos that have already taken a

[00:03:49] different form.

[00:03:52] But we rarely think about there are problems this way.

[00:03:54] We rarely think about our problems as a reorganization problem, and we’re not talking about reorganizing

[00:04:01] people.

[00:04:02] We’re talking about reorganizing resources, or for example on your team.

[00:04:08] You could imagine that you have three people on your team, maybe you’re a manager, and

[00:04:14] those people are not producing the work in the way that you would expect them to.

[00:04:20] When you start talking to those people, you realize that person A is working on something

[00:04:25] that person B really wants to work on, and person C actually wants to work more collaboratively

[00:04:32] with person A.

[00:04:35] Person B doesn’t really want to work with person C at all, but they’re forced to collaborate

[00:04:40] right now.

[00:04:41] You can see that there are some ways that we could reorganize these people.

[00:04:45] These are components of a problem, and transforming those components could help you solve the

[00:04:51] problem.

[00:04:54] The second way, the second way that I want you to think about changing this scenario

[00:04:59] is adding.

[00:05:00] I know this seems like I’m cheating because we’ve got a table and there’s only a certain

[00:05:05] number of blocks.

[00:05:06] Where did these other blocks come from?

[00:05:10] If you think this way, you are exposing a way of thinking that is very common and sometimes

[00:05:17] is a fallacy, and that is the zero-sum fallacy.

[00:05:20] The idea that whatever is currently available is always going to be available.

[00:05:26] I know I’m playing a bit of a trick on you here, but it’s critical to understand that

[00:05:31] Adding is not just a magical cheat code.

[00:05:35] You don’t always want to add.

[00:05:37] Sometimes adding causes more problems than it solves.

[00:05:40] You’ve probably experienced this.

[00:05:42] If you try to add an engineer to a team late in the project, we know this from many books

[00:05:47] and many studies that adding more engineers late in a project tends to make the project

[00:05:52] even later.

[00:05:56] Adding does sometimes actually solve problems.

[00:06:00] The most simple example of this is when the table that you’re starting with has no Legos

[00:06:04] on it at all.

[00:06:05] In other words, you’re starting something brand new, then you want to add, let’s say,

[00:06:09] a feature.

[00:06:10] It’s net new.

[00:06:11] You don’t have the thing and now you need to have the thing in front of you, and so

[00:06:15] you have to add it.

[00:06:17] But there’s other obvious examples of this and some less obvious examples.

[00:06:23] Obvious examples include the team over the long haul, not just for a specific project

[00:06:29] but over the long haul is missing a particular element.

[00:06:33] They are in need of a particular role, and that role just doesn’t exist on the team.

[00:06:39] We don’t have the personnel, and so it might make sense that adding the person is the right

[00:06:44] solution.

[00:06:46] Interestingly, sometimes adding at the right frame, theoretically always at the right frame,

[00:06:54] is a process of transforming.

[00:06:57] So let’s say you’re zoomed in to your team, you have three people on your team and you

[00:07:02] need that fourth person because the three people that you have only have experience

[00:07:06] with application development and you need somebody who has some data science experience.

[00:07:11] You could transform somebody within your team to take on the data science role.

[00:07:17] It’s going to take some time.

[00:07:18] They’re going to have to learn.

[00:07:19] That’s more transformation, but what you really want to do is add a person to the team.

[00:07:25] When you’re zoomed in at this level, that is an addition problem.

[00:07:30] You don’t have the resources to shuffle around, but if you zoom out, possibly there’s another

[00:07:36] team that has somebody on their team, and that particular team, they might be redundant

[00:07:44] on that team.

[00:07:46] So at an organizational level, it may just be a process of transformation.

[00:07:53] Even beyond your organization, if you zoom out to your network, now you’re talking about

[00:07:59] a larger pool of people and if you cut down the company barriers as these kind of artificial

[00:08:06] barriers between people, your process of adding somebody to your team from another company,

[00:08:12] or hiring them from another company, or maybe even hiring them from a new graduate pool,

[00:08:19] that is also a transformation move.

[00:08:23] So we can imagine that transformation is, in many ways, encompasses a lot of these things,

[00:08:29] but at a certain frame, what we’re looking at in these kinds of problems is an addition

[00:08:36] problem.

[00:08:37] We’re going to come back and talk about the other two types of approaches to our LEGO

[00:08:42] problem-solving schema right after we talk about today’s incredible sponsor, LaunchDarkly.

[00:08:49] LaunchDarkly is today’s leading feature management platform.

[00:08:59] It empowers your team to safely deliver and control software through feature flags.

[00:09:04] If you’re not using feature flags, by the way, you are really missing out.

[00:09:08] It helps maintain sanity as you’re releasing features because it allows you to turn those

[00:09:14] features on selectively, and with something as mature and well-developed as LaunchDarkly,

[00:09:21] you can turn those features on selectively in a much more intelligent way.

[00:09:26] This is not your homegrown feature flags that are buggy and require loads of integration

[00:09:31] tests or something to make sure that they’re working properly.

[00:09:34] This is a platform that you can depend on.

[00:09:38] How do I know you can depend on it?

[00:09:40] Because it’s battle-tested and proven, there are large businesses already depending on

[00:09:45] it.

[00:09:46] For example, Chris Guidry, who is O’Reilly’s VP of Engineering, had this to say about

[00:09:52] LaunchDarkly.

[00:09:53] He said, With LaunchDarkly, our engineers can ship code whenever they want, and we can

[00:09:57] test features and production well in advance of a marketing launch.

[00:10:01] And if a feature causes problems on the day of the launch, we can just turn it off with

[00:10:04] a kill switch, no rollbacks.

[00:10:07] LaunchDarkly makes our releases boring.

[00:10:11] You do want boring releases, believe it or not.

[00:10:14] And we know as software engineers that when we decouple things, they tend to work better.

[00:10:19] What LaunchDarkly allows you to do is decouple your features from your code.

[00:10:23] Go and check it out.

[00:10:24] Head over to LaunchDarkly.com.

[00:10:25] That’s LaunchDarkly.com.

[00:10:26] Thanks again to LaunchDarkly for sponsoring today’s episode of Developer Tea.

[00:10:37] So, we’re talking about the different ways that you can approach problem solving, specifically

[00:10:45] when you’re talking about different components of a problem or different factors.

[00:10:49] We’re using this Lego metaphor.

[00:10:53] You can kind of visualize how this works.

[00:10:57] And it’s not a perfect metaphor because sometimes one factor will disappear or mutate entirely

[00:11:04] on its own.

[00:11:06] We’ll talk about how that matters in just a moment, but I’m going to talk about the

[00:11:10] next approach first, which is subtractive thinking.

[00:11:14] Subtractive thinking.

[00:11:17] This is intuitive if you think about it, right?

[00:11:20] Subtractive thinking, additive thinking, these are kind of the opposite.

[00:11:24] Sometimes you have too much of something.

[00:11:27] The perfect example of this, if you’re trying to solve your calendar, it’s very likely that

[00:11:33] you need to approach with a subtractive thinking mindset.

[00:11:38] Removing elements from your calendar, removing meetings, removing events from your calendar.

[00:11:44] There are other situations like having a team that is too large.

[00:11:48] By the way, subtractive and additive kind of come along with the territory of variants

[00:11:56] of these things like division and multiplication.

[00:12:02] Division is in essence a type of addition.

[00:12:06] It’s just a rate rather than, it’s a difference in rate rather than concept.

[00:12:13] So you might think multiplicatively when you’re talking about reaching new users.

[00:12:20] You might think in terms of division, let’s say if you have a team of 10 engineers and

[00:12:25] there’s one manager and you’re thinking in terms of division, if you’re going to add

[00:12:29] a new member to that team, you might think, okay, well, now we have 11 engineers.

[00:12:35] This person, this manager is already at their kind of at their limit.

[00:12:39] What can we do?

[00:12:40] Well, we can divide this team up into two teams and we can add another manager.

[00:12:47] So these approaches, it seems very clear and obvious when you think about this.

[00:12:53] But what you’ll start to notice if you use this framework is typically these mindsets

[00:12:59] are wrapped in a lot more kind of ceremony than they actually contain.

[00:13:05] There’s only so many fundamental ways that we can change these components.

[00:13:09] We’re either going to move them around, right?

[00:13:12] Division is kind of a moving around in that previous example.

[00:13:16] We’re going to add something new to the mix.

[00:13:18] We’re going to hire a new person.

[00:13:20] We’re going to start a new habit.

[00:13:22] We’re going to remove something.

[00:13:24] We’re going to stop our bad habits.

[00:13:26] We’re going to reduce the headcount, right?

[00:13:31] These are all the ways that we can change things.

[00:13:34] And if you’re familiar with algorithmic thinking, then this shouldn’t come as a surprise at

[00:13:38] all because when you start to think about the shape of a problem, for example, you want

[00:13:46] a particular rate of user acquisition.

[00:13:50] What is that rate?

[00:13:51] It’s a multiplication rate, right?

[00:13:53] It’s an exponential rate.

[00:13:55] It’s something greater than linear.

[00:13:58] And so the additive thinking that you’re using in this scenario is very different.

[00:14:02] It’s very different from, let’s say, logarithmic thinking, which is still an additive mindset.

[00:14:11] Okay, so all of that to say we have all of these different ways of manipulating the components

[00:14:18] in our problems, and we very often forget the last one.

[00:14:23] We very often ignore the last one.

[00:14:26] I’m cheating again a little bit because we’re calling these components Legos, but in reality

[00:14:33] they’re much more alive than Legos are.

[00:14:37] They’re much more organic, and they change and morph and grow or shrink on their own

[00:14:44] without any intervention.

[00:14:47] And so the final way that we might look at our problem and the components of our problem

[00:14:53] is to simply do nothing, to sit back and do nothing.

[00:15:00] Why would we think this way?

[00:15:01] Well, you can think about your problem sometimes, you can think about your problem as you might

[00:15:05] think about a garden.

[00:15:07] A garden is relatively self-regulating, and sometimes the interventions that you try to

[00:15:14] impose on a garden can ruin it, can make it worse.

[00:15:20] And so if you’re having team issues, let’s say that your team is not getting along incredibly

[00:15:26] well, and you feel that it’s your responsibility to do something about it, because humans,

[00:15:34] when we see problems, we feel the need to act on those problems, to actually intervene,

[00:15:40] to do something about them, to change something, to add or subtract, or to transform.

[00:15:51] And so we look at these problems and we want to do something, we want to be active, but

[00:15:55] sometimes the best thing we can do is allow that problem, as cliche as it sounds, to work

[00:16:02] itself out.

[00:16:04] Because once again, these components are not inanimate objects.

[00:16:07] When we deal with people issues, we have to remember that the components that we’re moving

[00:16:12] around, the things that we’re transforming, that they’re not going to simply move position

[00:16:17] and continue on.

[00:16:20] These organic components, they change when they’re in contact with one another.

[00:16:27] They change as time goes on.

[00:16:32] And so as we look at our problems, more often we might ask, what if I did nothing?

[00:16:39] What if I sat back and watched?

[00:16:43] The amazing thing is that if we were to do this, even our presence alone in that problem,

[00:16:51] even the fact that we are observing, can change the behavior of those components.

[00:16:59] This is a very important option that is very often skipped.

[00:17:02] And so I want you to keep it in your repertoire.

[00:17:04] Because if you don’t have that option available, sometimes you’re going to add or subtract

[00:17:11] or transform when the best thing you could have done was nothing at all.

[00:17:18] I hope as you move forward in your career and you face problems that have these kind

[00:17:23] of component changes in them, that you can think back to this model and imagine, okay,

[00:17:31] what are we talking about?

[00:17:32] Are we talking about an additive problem or are we talking about a transformational problem?

[00:17:37] What are the implications if we were to zoom out and imagine that all of these are more

[00:17:42] like transformation problems?

[00:17:45] This way of thinking can set you on the right pathway and it can have you brainstorming.

[00:17:51] You can imagine, for example, when you start to believe just by default that something

[00:17:56] is an additive problem, you could question yourself and consider the parallel alternative.

[00:18:03] Consider am I thinking about this additively when I should be thinking about it subtractively

[00:18:08] or when I should be thinking about it from the do-nothing perspective, from the gardening perspective.

[00:18:15] Thank you so much for listening to this episode of Developer Tea.

[00:18:18] Thank you again to today’s sponsor, LaunchDarkly.

[00:18:22] LaunchDarkly is today’s leading feature management platform.

[00:18:26] With LaunchDarkly, an IBM went from deploying twice a week to over 100 times a day.

[00:18:32] If you want to be like IBM and deploy often, which you do, head over to LaunchDarkly.com

[00:18:39] to get started with feature flags as a service right now.

[00:18:43] Thanks so much for listening to this episode.

[00:18:45] If you want to join the Developer Tea Discord, which, by the way, you should, we have a lot

[00:18:51] of developers in there that are trying to improve their careers, and we even have a

[00:18:55] channel that is literally called No Stupid Questions.

[00:18:59] You can go and ask any question at all and no one is allowed to do the feign surprise

[00:19:07] where they say, wow, I can’t believe you don’t know that yet.

[00:19:09] Nope, that’s not allowed.

[00:19:11] Your questions are welcomed.

[00:19:13] We want people asking questions and learning in this Discord and supporting each other.

[00:19:17] So go to get an invite for this Discord.

[00:19:21] You can send me an email at developertea at gmail.com.

[00:19:24] You can also reach out to me on Twitter at Add Developer Tea.

[00:19:27] Thanks so much for listening and until next time, enjoy your tea.

Visão de gráfico