There’s Always More Information

Episode 13

Breaking a problem down can help you see it more clearly, and attack the issues wrapped up in that problem more effectively. Sometimes we tackle problems that are large or connected to other issues, and it can be helpful to take a step back, consider other perspectives, get more information, and try breaking things down and solving each issue individually.

 

 

Show Notes

• There’s always more information.
• Consider more sources of information.
• Challenge your assumptions, and try to integrate different points of view.
• Who are we not talking to? What are we not considering?
• Often the solution to one problem reveals other underlying problems that need solving.
• The more perspectives, the better.
• A four-part approach to systems thinking, DSRP: distinctions, systems, relationships, and perspectives.

Links:

• https://www.estherderby.com/workshops/psl 
• https://webinar.gitprime.com/developing-engineering-talent/
• https://www.ecornell.com

Transcript

Announcer: Welcome to the Programming Leadership podcast where we help great coders become skilled leaders and build happy, high-performing software teams.

Marcus: “There is always more information.” – Esther Derby, PSL, May 2019.

Esther said this statement as we were debriefing in one of our sessions at Problem Solving Leadership, which was originally designed by Jerry Weinberg back in the 70s. If you can imagine, the same leadership seminar workshop really has been running continuously for like 40 years. In that moment, we were trying to make sense of some situation.

Esther said this one small thing, there is always more information, and it hit us like a bolt of lightning. I actually wrote it in my little notebook here. What she meant by that is when it looks like you’ve completely exhausted all the information you have, when you’ve taken apart everything and laid it in front of you and you and your team are looking at a problem, you’re trying to estimate something, you’re trying to figure something out. It’s very easy to imagine.

Well, we’ve reached the end of the information. We now have all of the information. Frankly, I hear this a lot from technical leaders, teams and programmers. In fact, it’s not hard to imagine a programmer saying, “Well, I have everything I need to know to finish this.” But that one statement that introduces uncertainty and that shows us that there are possibilities out there that we do not have all the information and that there is always more information means that we need to be careful about closing the lid on our information gathering activities.

Now, one of the worst things you can do when you’re trying to problem solve is to imagine you’ve got everything you need, and that’s because it really limits where you can go from there. So I want you to try this. The next time your team is working on decomposing stories or you’re working through a situation with someone or maybe you’re even just trying to analyze a situation yourself. I want you to write this one statement down: There is always more information.

Then I want you to consider sources of information that haven’t yet been introduced into the problem space. The problem space, by the way is the container where you in your own head, you with someone else, or maybe your whole team are working together on something. So I want you to introduce this idea, there is always more information. Then ask what other information could we be overlooking and where could we go look.

Sometimes, we don’t even know where to go look for more information, but let me give you a few examples of places I go look for information. One thing is I try and find data about how people are feeling. Yeah, that’s a weird phrase. Data about feelings. But yeah, knowing how your team feels about things is an incredibly important part of their problem solving and decision making process.

So getting people to talk about the data for what’s going on inside them, which is usually information that’s not considered when we’re trying to evaluate a technical framework or debug some sort of production problem.

How people are feeling about it oftentimes limits what they can see. Isn’t that crazy? How people are feeling about things limits the possibilities and the data they can gather. So talking about the way they feel, the assumptions they make and what we’re not at all talking about is an incredibly important part of problem solving.

This leads to the next kind of data that is oftentimes isn’t talked about. When we think about there is always more information, assumptions come to mind. What assumptions are we making? What assumptions are we not talking about? What crazy ideas are so far out in left field that we’d never even consider them?

I was once talking with Jerry Weinberg, and I was complaining that my dog wouldn’t be quiet because we were trying to record a podcast and my little dog was yipping and wanted out. I said, “Jerry, I have to get up and let my dog out.” And he said, “Well, you don’t have to.”

Now, this is going to sound really harsh. Jerry loved dogs. In fact, Jerry and his wife, Danny, were professional dog trainers. In fact, Danny is like a dog psychiatrist now. She helps the people that owned the dog, but she helps them, people and dogs live in harmony.

Jerry said to me, “Well, you don’t have to. You’re not compelled.” And I said, “What other choice do I have?” And he said, “Well, you could shoot the dog, right? And that would shut the dog up.” And I was horrified, I said, “What do you mean I could shoot the dog? I couldn’t.” And he said, “Well, maybe you couldn’t bring yourself to, but you’re always talking in this limiting language like you have to let the dog out. No, you don’t have to. You get to, you can. You can choose to do that.”

Now, of course, I am not advocating anyone hurt their dog. I love dogs and I love my dog, but the point is, is when we say the word have to, we’re revealing a mental model that has boundaries. Have to is a container, a box that we put our ideas in. Usually when we say, “Well, we have to do it this way,” what we’re actually saying is we cannot do it any other way. We must do it within the parameters of X to Y. We cannot look above or below or beside or around or beneath those ideas.

This is the constraints we have and yet those constraints are almost always not true. They’re limited. Yes, maybe your boss said you have to solve a problem this way, but frankly, I doubt that’s happening. I doubt your boss or your user actually cares how you’re solving problems. I think instead though that your team is constraining too often the way they think about problems. So recognizing there’s always more information. One of the things we should ask again is, what assumptions are we making?

Software engineers are difficult to hire and often require time to ramp up, so growing the existing team can be the most immediate and effective way to move the needle on value delivered. But growing the existing team that is building career frameworks and finding additional opportunities to develop engineering talent can be a vague and daunting task.

Join us on August 1st to hear from panelists, Erica Stanley, Lara Hogan and Matt Greenberg as we discuss various approaches to facilitating growth in software engineering teams. We’re going to discuss how to build career ladders that create alignment, drive momentum, and reinforce your company’s values, best practices for introducing, changing and communicating expectations around career growth, strategies for helping team members grow beyond title changes and promotion. And we’re going to take your questions live.

This webinar is presented by GitPrime, which helps managers and engineers use data to deliver better products faster. Start your free trial at getprime.com.

So far we’ve said, “How do we feel about things? What’s our gut reaction?” And next we said, “What assumptions do we have about this?” That is more information we often don’t talk about.

The next one that I love is who are we not talking to? So in the same way as we could say what are we not talking about, who are we not bringing into this conversation? Oftentimes other people bring new perspectives. Yes, sometimes that’s a challenge to integrate those perspectives into our thinking. Okay? When we start to say who else can give us more information, because we believe truly in our heart there is always more information.

Does that mean we need to talk to the user, the business owner, we need to talk to the client? Maybe we need to talk to QA or a designer or heck, maybe we need to talk to the CTO or a different engineer. I don’t know who we need to talk to.

By the way, the word need, the word need is also a little bit wrong too because it’s who else could we talk to? The more perspectives we get and the more we can map out the perspectives of different people, holistically we see the problem. There is always more information.

Here’s another place to get information and that’s breaking things up into distinctives. Okay. I’ll be honest, I’ve been taking a course at eCornell, which is like Cornell’s online university thing and they have a really wonderful systems thinking course. In it, I’ve learned this four part approach to systems thinking, which can be categorized as DSRP, distinctions, systems, relationships and perspectives.

When you think about a bug, a behavior in the system, a problem, that problem can always be decomposed into smaller, distinct problems. Then from there, you can continue decomposing them.

Now, why is that important? That is incredibly important to systems thinking because when we see that we take one thing, we call the problem, and we break it into four things, we recognize that the same solution may not fit for all those problems. Or actually even more often, maybe only one of those is a problem and the other three are just factors.

Let me give you an example. I was speaking with someone the other day who had an engineer who lives in a neighboring city, is trying to move to the city where the team is co-located. That was part of the hiring agreement, but keeps finding reasons to work from home.

Yes, it’s a 90 minute drive, but the reality is that, that’s where the job is. It’s a co-located job. The manager was frustrated because the person left unexpectedly in the middle of the day after a few months work. “Oh, I need to go home. I’m just sending a Slack message to everyone saying I’m working remote for the rest of the day.”

Now, this might sound totally reasonable to you. When the manager went back to the person and said, “Wait, you’re doing what? I need you here.” The person said, “Well, you should probably hire someone to be there like who can fill in because I’m not able to work on all of my most important projects anyway.”

Now, the manager has a whole bunch of stuff running around in his head. When they pinged me on Slack, we were able to talk through it and I immediately saw that there were actually multiple things occurring at once. This is where it goes from a big mess and systems thinking helps you turn a big mess into discreet, smaller situations.

One of the first things I did is I created distinct problems. I said, “Well, one of the situations is that the person who should be on site is not able to be on site.” That is a situation. The second situation is how they’re handling it. Their second distinctive. How they’re handling it. They are not checking with you and talking with you and openly communicating with you about when they need to work from home. They’re just taking off in the middle of the day and saying, “Please cover for me.” And that’s bothering you.

Now third, there’s the idea that they’re not able to get their most important work done, so maybe you should hire someone to offset some of that work. Yet, all of those three things got jumbled into a 30-second conversation that left the manager feeling really frustrated and overwhelmed.

Now, after we took it apart … By the way, taking things apart is a way to get more information. Yes, this is a way to just embrace that rule. There’s always more information. Taking it apart, we said, “Does the problem with the person not being able to get all of their most important projects done, have anything to do with them being not co-located?”

Well, it turns out it didn’t. Those were separate problems. The idea of hiring someone to help was completely disconnected from the fact that they really needed to move to that town and join the co-located team.

Now, it was the fact that they hadn’t moved to the town yet related at all to the fact that they were not clearly and respectfully communicating with their manager. No, that was a separate issue. Did all of these have a relationship to each other? They did. It was a temporal relationship in time.

Maybe you might say a little bit of causation. One thing sort of caused another behavior or led to without causation. Maybe you say correlation, but either way they were related in time and proximity. But ultimately, these three things were separate.

With that, the manager could go back to the person and say, “I have more information. I see three distinct issues, not one. And I think we should address these as three distinct issues. The first one being, are you able to do this job where the job needs to be done? The second one is our relationship. Why aren’t we communicating effectively about this topic? And the third one is why can’t you get your most important projects done and how can we help you to do that?”

Because jumping all the way from A to Z to say the solution is to hire someone to fill in and do the least important work is really not going to fix problem A, B, or C. And it probably will introduce more problems because that’s what solutions always do. Breaking something down is a way of getting at the more information that is inherent in every situation.

I think that you should try and practice asking how do we feel about this, what assumptions are we making, who else’s perspective and ideas need to be brought in here, and how can we break this down into smaller pieces so that we can check and see if a solution is the right fit for all these. Or more often, we need to have different approaches and solutions to different situations. Because sometimes as you might expect, when we fix one thing, we actually make the whole situation worse because we haven’t broken it down and thought about it systemically.

I’m Marcus at marcusblankenship.com. This is the podcast called Programming Leadership. Thanks for joining us today. Send your questions into marcus@marcusblankenship.com and I’ll answer them on the air and go be with your team.

Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time.

This has been a HumblePod production. Stay humble.