Monkeys and Rocks with Matt Greenberg

Episode 19

If a friend asks you to help them move something heavy, like a rock, you probably wouldn’t think twice. But if they asked you to take care of their pet monkey… That’s the beginning of our chat with Matt Greenberg, Vice President of Engineering at Credit Karma, who compares problems of various types and sizes to monkeys and rocks. The goal of effective leaders should be to break down bigger problems into smaller ones, going from monkey-sized problems to smaller, rock-sized ones.

 

 

Show Notes

• Framing problems as monkeys — vs rocks
• It’s not easy once a problem has become a monkey, to shape it back down into a rock.
• It might be something like choosing a programming language for a specific problem.
• what you’re ultimately trying to do is build teams of Michael Jordan’s, so that they can do huge impact things, but that they’re easy for them
• I see most of the challenges with my teams are when people don’t have the empathy to see the state from other people’s point of view

Links:

• O’Reilly Velocity Conference – Berlin, Germany.  November 4-7, 2019. Use discount code MB20 to save 20% on Bronze, Silver, and Gold packages.
• Credit Karma
• Matt Greenberg on LinkedIn
• Matt Greenberg on Twitter: @matt_muffin

Transcript

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

 

Marcus: All right, welcome to the show. I’m Marcus. And today, I’m going to have a conversation about Monkey Makers, with Matt Greenberg. Welcome to the show, Matt.

 

Matt: Oh, thanks, Marcus. I really appreciate you having me on.

 

Marcus: Matt is the Vice President of Engineering at Credit Karma, one of my favorite services by the way, Matt. I’m a big fan, a big user, so thank you for all the work you’re doing there, to help me improve my credit score.

 

Matt: I really appreciate it.

 

Marcus: So, you just told me this crazy story. It’s a wonderful metaphor for thinking about… this is the way I took it, about delegation and leadership and problems. Let’s start. What is the monkey and the rock story?

 

Matt: Yeah. This actually comes from an old boss of mine and I thought it was a really kind of creative metaphor for thinking about work. Oftentimes when you’re trying to take on a project, and that project is big and complex, your goal is going to be to need help. And you need to be able to take this problem and get other people to help you out. So, imagine that problem is moving a large rock. And what you need to do, is you need to get a group of people together, lift the rock up, move it from point a to point b, put the rock back down. In order to do that, you’d tell them what time to be there. You know that you have enough people who are capable of lifting a rock. Everyone’s in good, healthy shape for doing so. You organize the group, they pick up the rock, they move it from point a, they take it to point b, they put it down, and everybody’s done.

 

This is like a very well-formed, well thought out problem. Everyone knows exactly what their role is and they can lean in, help you out, and leave. And, in this case, that’s great. People are very willing to participate and help out. And if you ask someone to help you with your rock problem, they’re always enthusiastic to do so.

 

Marcus: Absolutely.

 

Matt: The flip side of that is the monkey problem. If I were to say, “Hey, I have this pet monkey. I’m going away for a week, and I’d really like you to babysit it. I’m going to take it over to your house, and I’m going to drop it off, and I’ll see you later.” That monkey needs to be fed. It’s going to rip up your couches. It’s going to fling poop all over the place. It’s a sort of unbounded, uncontrolled problem that you don’t know how to deal with it. And it’s not really something that you feel ownership of and ready to move with.

 

These sorts of monkey problems pop up at work all the time. Part of our key capability as leaders, is to figure out how to take monkey problems, de-risk them, reshape them, turn them into rocks, and then delegate them down. And really good leaders, whether they’re people managers, or they’re engineers, or they’re project managers, know how to take these really complex monkeys and turn them into rocks. Then the business is able to rapidly move through them.

 

The flip side of that is, some people are able to take problems, regardless of how they look, and turn them into monkey problems. And these monkey makers are one of the more difficult components of your organization to deal with. And, over time, you have to coach them into becoming rock makers. Once you’ve coached someone in an area so they know how to turn complex problems, to them, into rocks instead of monkeys, then it’s so much easier to deal with it. But everyone’s had that person they work with, who seems to take little things and make them big mountains, and drag everyone along on the drama and the complexity of solving it, instead of just making it feel easy.

 

Marcus: I am imagining someone who has worked for me, maybe multiple someone’s, right now, as we speak. These people are popping into my mind.

 

Marcus:  To get ahead today and stay ahead, your organization needs to be cloud-native. The 2019 Velocity Conference program in Berlin on November 4th through 7th is gonna cover everything from Kubernetes and Site-Reliability Engineering to observability and performance to give you a comprehensive understanding of applications and services and stay on top of the rapidly changing cloud landscape. You’re gonna learn new skills, approaches, and technologies for building and managing large-scale cloud-native systems. And you’re gonna connect with peers and other people to share insights and ideas. We all love the “hallway track,” right? You’re gonna join a community focused on new strategies to manage, secure, and scale the fast, reliable systems your organization depends on.

 

Do not miss this: you’ve got industry leaders like Jennifer Davis, Liz Fong-Jones, Aish Dahal, Heidi Waterhouse, and even more giving keynotes at this very special event. Get expert insights and essential training on critical topics like chaos engineering, cloud-native systems, emerging tech, serverless, production engineering, and Kubernetes; including an on-site CKAD Prep and certification. Velocity is going to be co-located with the software engineering conference this year, which presents an excellent opportunity to increase your software architecture expertise.

 

You can get access to this and all the software architecture keynotes and session on Wednesday and Thursday for just 445 Euros, and as a listener to this show, you can get 20% off most passes to Velocity when you use the code MB20 during registration. To find out more and to register, go to velocityconf.com/blankenship that’s velocityconf.com/blankenship. You’ll be glad you did.

 

Marcus: So, Matt, let’s just talk this through because I think it’s a wonderful metaphor. And it’s really rich. Let’s start with the last part. The people who make monkeys out of rocks, which now that I say it, the way of phrasing it doesn’t quite work, but they are making things harder, more complicated. And, I love the way you phrased it, they’re actually dragging the team along with them. Are these people doing, what’s sometimes been called yak shaving, or is that different?

 

Matt: Yeah, I think there’s a component of that. Another good area I’ve kind of heard is are you an igniter or a calmer? Do you take a problem and make it bigger, or do you take a problem and relax everybody working through it? Whether that problem is important or not important… I think yak shaving has a little bit more to do with how critical is this issue that you’re dealing with and are you making a mountain out of a molehill. We’re all over the metaphor train today.

 

Marcus: We are. We should talk about bike-shedding, too.

 

Matt: But the reality is a problem is a problem. It doesn’t start as a monkey problem or a rock problem. It’s just a problem. And it’s the way that you start to frame it, and form it, and figure out how to move an organization through solving it, that starts to shape the problem for everyone else.

 

If you’re the calmer, who says, “Hey, we have an issue. We need to work through it. I’m going to gather the right people together.” And you’re taking a calm and reasoned approach to doing it, and you’re moving forward. Everyone feels like the steps are being taken to get through the problem. You’re taking the whole group along with you. That’s a really excellent way to think about things versus the person who’s standing there and just saying, “This is a huge problem. There’s just a problem here. This is just a big problem.” And there’s no advancement. That’s where those problems start to become monkey problems.

 

It’s not easy once a problem has become a monkey, to shape it back down into a rock. It takes even more time, right? What you’re thinking through in these sorts of issues is, you’re looking for your leaders and your bench and your team to be able to give you options and a recommendation to calmly walk forward through it. So, you have to shape your organizations capability for problem solving, and find people who sort of impede that, and teach them the process and get them on board.

 

Marcus: Let’s get concrete for a minute, because I love metaphors. I think this is great, but I’m trying to imagine… so, maybe, I’m going to challenge you. Tell me a problem that you have seen as presented as a monkey problem.

 

Matt: I think in software engineering, there are a few common types of issues that every organization runs into. That there’s always a group of people who want to make monkeys out of it.

 

Marcus: Okay.

 

Matt: It might be something like choosing a programming language for a specific problem. It almost becomes religious. There’s often not rational discourse about it. Even once a decision is made, a person is unwilling to disagree and commit. And they bring that up, often, for years, about what we should do. In fact, in Credit Karma, we heavily leverage Scala. There was an engineer who was here when we made that decision to really sort of productionize it and leverage it heavily within our organization, who still believes we should be using Go. And it’s been a solid three and a half years, and that conversation comes up once a quarter. And it’s sort of like, “I hear you, but I think we’re done with this one,” right? You can let the monkey off your back. You can let it go. I think that’s probably an example of the concept, but less practical.

 

Marcus: So, would you say monkey problems maybe have an emotional aspect to them? I imagine picking a programming language, you said it gets to be like a religious war. It seems like the people, when I talk to them, have an opinion. It’s not an academic opinion. No one is quoting the Church-Turing thesis to me about how all languages are equally powerful. They have a very strong, emotional opinion. Do you think that’s a component of framing, or creating monkey problems?

 

Matt: Ultimately, most solutions exist in a gray area, where there’s not a perfect solution. One of my kind of common frameworks for helping my team through this is, letting them know that at the end of the day, if they can’t make a decision, they should bring me options and a recommendation and I’ll help them walk through it. This framing of options and a recommendation sort of starts with the idea that you can have more than one solution to a problem.

 

Marcus: I like that.

 

Matt: And this is an important kind of concept to recognize that oftentimes an engineer will view the world as black and white and say, “This is a solution. We must do it this way. It’s definitely the best way.” With options, there’s pros and cons to everything. It doesn’t matter if it’s an architectural layout, a choice of a technology to use, or even a product approach, we’re able to take those things, lay them out in a reasoned way, talk through options, and make a recommendation. Even within those options, it’s not always clear why a recommendation should be what it is.

 

Another common concept we talk about for the same thing, is a clean escalation. Oftentimes two people disagree. When those problems become a monkey, is when one of them is coming to a one-on-one and telling you how awful this experience is, how this other person’s not helpful, and we have all these issues. Then you go meet with the other person and they’re saying the same thing. As soon as that stuff starts happening in my organization, I’m usually like, “Stop. Make this a clean escalation. The two of you get together, come to me, explain to me the disagreement, and then we’ll help solve it together.” I don’t want to talk to both of you separately and have this weird he said, she said game that we’re going to play with it.

 

I want to have a clear, clean, concise conversation where we can make a reasoned decision together. And then, at the end of it, we’re going to disagree and commit. We’re going to say like, “Cool, I hear this decision’s been made, and now we’re going to move forward.” Hopefully teams know how to do this within themselves. But the problems that become monkeys start to just keep boiling up the organizational layers.

 

Marcus: Yeah, so maybe another type of monkey in our zoo here, is the kind that involves multiple people. Not just between one person and completing a task, like I have to optimize this query. But it seems like these monkey problems tend to run around and throw poo all over the organization.

 

Matt: Yeah, I think that’s definitely true. When you think of it in the context of one person, it’s usually more of a situation where someone’s taken something that they could approach simply and they’ve created too many moving parts. And when you sit down with someone in your organization and they say, “I’m really stuck,” and they start walking you through what they’ve done. And you usually say like, “Well, have you just tried not doing all that stuff, but approaching it with sort of the Occam’s razor direction.” People take a deep breath and they’ll start with, “There’s 10 reasons why I can’t do it that way.” By the end of it, they’re like, “Oh, I did that thing, and it was really easy. I wish I had just done it that way in the first place.”

 

It’s been a while since I’ve coded every day, but the one advantage I still have is simple things are just so much easier. Almost every time I’m sitting in a technical discussion, simplify is just such good advice. It’s very easy for me to be like, “Why are there so many moving pieces? Can we simplify this? Is there a way to do it with less?” All the really highly trained, experienced engineers in my organization, they take simple approaches. It’s usually newer people in their career who want to add this piece, and they’ve seen this design in theory, but they’ve never actually worked on it in practice. And they don’t understand that all those moving parts just mean more places that something can break and more areas where someone has to maintain. Those are things that make systems very, very difficult.

 

Marcus: I have the perception… it’s been awhile since I coded every day, too, and I have the perception that having a little distance from whatever the other person is talking about gives me an advantage. It’s like if I can back away from the monkey cage… I don’t know why I keep, I love monkeys I guess. But the closer I am to the monkey, if it’s screaming right at me, I have a hard time thinking. I kind of go into like I think everything has to change at once. But when somebody walks in and talks about something that’s more abstract, that I’m not as close to, sometimes the simple answer is just right there.

 

I have noticed that my engineers somehow… the better engineers I’ve worked with, can almost do that for themselves. They can step back from it. I don’t know. Does any of this resonate or am I being crazy?

 

Matt: No, I think you’re a hundred percent right. One of the best engineers I’ve ever worked with basically just runs around from project to project helping people simplify stuff. It’s one of those things where people learn about a new tool and they want to use it, and the reality is a hammer is still a really great tool.

 

Marcus: It’s a great tool.

 

Matt: And it solves a lot of problems. A lot of times people are like, “Well, I’m going to build a new tool in order to do this thing. I’m going to modify a hammer with all of these components,” and it’s just like, “But can’t we just use a hammer?” And the answer is usually yes. The projects where people just use hammers work out really well.

 

Then you have to be really thoughtful when you go and do something more and above and beyond that. Your organization only has so much space for high risk, high reward activities. This original concept of the monkey and the rock often comes down to a risk reward. If you imagine how you’d want your organization to spend your time, you can think of sort of a graph, where one axis is risk and the other axis is reward.

 

Let’s start in one corner of high risk, low reward. We never want to do those projects. Once you’re in that area, you know it’s a big mistake. There’s no reason. The next area you could talk about is low risk, low reward. There’s almost never… you’re never so needing to do stuff that you’re in the low risk, low reward camp. You just don’t want to do things that have a low reward in a high growth environment.

 

Then you would go into the high reward, low risk. In that camp, these are the things that you, as a leader, are always looking to delegate. You just want to give your team layups over and over and over again. So, you’re constantly in the camp of trying to package risks down so that things are easy, with big impact. Now, easy is relative. Easy for Michael Jordan is very different than easy for me on the basketball court. So, what you’re ultimately trying to do is build teams of Michael Jordan’s, so that they can do huge impact things, but that they’re easy for them. They’re stretched, but not stretched to the point where failure is happening everywhere. That the failures are straight forward and recoverable and we can keep moving forward.

 

Then, what you do, is you personally are taking the projects that are high risk, high reward and you’re working through the pattern of de-risking. You want to package it so you can take all the risks out, get it to the point where it’s high reward, low risk, and then move it along down the chain. If you think about things that are happening within an organization, it’s basically like a repeated pattern over and over again, where the principal engineer is taking the highest risk parts of the problem, working the organization through solving them, breaking it down into it’s component parts, moving that to what would be a executable project for the staff or senior engineers, giving it to all of them. Then they’re packaging those problems, working them down, and taking them into things that, you know, like all the way down to the entry level engineering can execute on.

 

You’re doing this in a group dynamic. Everyone’s coming along for the journey. But it’s that leadership, leadership with or without authority, that’s helping everyone along the path. They are the ones who are turning all the problems into rocks.

 

Marcus: Okay, okay. So that last thing, thank you. I’m glad… So, I have questions about this because I hear from, probably people who are more junior, although I hear it from mid-level engineers too, that they feel “Bored at work.” I don’t know if you ever hear this. And what they tell me is that sometimes the work has been decomposed so much that it feels just like tasks. And they’re like, “I really want to do something impactful. I want to solve problems, but I am coding yet another report, yet another login screen, yet,” you know, they look at it as it’s already been, all the fun parts, the challenge, the problem has been taken out. Do you ever hear that or maybe I’m just talking with the wrong people?

 

Matt: I think two things come from this. Thing number one is early in your career, everyone wants to build a rocket ship. What you don’t realize is that people don’t build rocket ships. Hundreds of people, thousands of people build a rocket ship. Most people spend their whole career building like the phalange that allows a window to move in a certain way.

 

Marcus: Right.

 

Matt: And you don’t go into your career saying, “I want to be an aerospace engineer and I want to build a phalange.” You go into your career saying, “I want to build a rocket ship.” Over time, you realize that it takes lots of pieces and parts to build these huge systems. So the first thing is it comes with expectations.

 

The second piece of it comes with… the nuance of the thing that I was talking about earlier is, if you have a team of Michael Jordan’s, you don’t want to de-risk something to the point where you’re rolling them out against the high school team. You want to de-risk something so that it’s effective for them to accomplish the task, but it’s very reasonable that they feel comfortable on the court, but not that it’s a waste of their time.

 

Marcus: Yeah, I was thinking, Michael Jordan might occasionally want to play against a high school team, but that’s not what he wants to be paid for. He might do it out of love, but he must love the competition against going against other pros.

 

Matt: Right, so, bad leadership is decomposing stuff too much. Because if you say your job is de-risking and delegating and you can get more projects done, the more leverage your time has. So if you’re de-risking more than the person you’re delegating to needs, then you’re sort of like wasting your time. And time is the most premium thing you have. So your most senior people, who you want on your hardest problems, they’re premium. There’s just less and less of them over time. So, you’re constantly looking to make sure they’re stretched the right amount.

 

Marcus: Yeah. There’s a bunch of studies that talk about we do our best work when we’re challenged, but not overwhelmed and not bored. So there is kind of that sweet spot or that part of the bell curve that people absolutely, I think, want to be stretched and challenged. And that’s what they’re excited about.

 

Matt: Yeah, it’s not dissimilar… I’m a parent and-

 

Marcus: Me too.

 

Matt: … with my children, boundaries are really healthy. They like to know that they’re there. They feel safe. They want to be stretched. They want the opportunity to stretch. But they also want to know that ultimately there are boundaries that help keep them safe.

 

I think the projects that we work on are often the same way. If it’s completely unbounded, if you don’t have any sort of magnitude and direction to go on, it’s really hard to solve problems. There’s a famous video that Spotify did, that talks about the different ways to pass problems along to people. And if you’re passing on that fully decomposed problem, that says, “Here build a bridge, do this, do that, here’s the designs,” then all you’re really doing is getting labor out of it. But if you say like, “I need to get to the other side of the river,” and people have the capacity to do that, that’s really valuable. But if you just plop a bunch of wood in front of people and walk away, they don’t really know what they’re doing.

 

Marcus: Well, that’s true, they might build a hut instead of a boat.

 

Matt: Exactly. And if you don’t care if they build a boat or a bridge as long as they get to the other side, then you’re fine. But if there are specific reasons and requirements that you’re trying to get to, you just have to make sure that you outline that for people. So you can say like, “I want this usable again and again. I don’t want it to require a person every time. Long-term maintenance and cost is very important to me.” Then you know, okay, I can’t just build a boat, I have to build a bridge, or something similar. The structure in which I have to solve this problem has to meet all of the requirements that are kind of coming down to me. There’s going to be some areas where those requirements are ambiguous and you have to figure out what you want to do yourself. And there’s going to be some areas where they’re really clear. But no direction is really bad. The nuance in these processes is doing it at the right level. As you grow as a leader, you’re testing people out in your organization, giving them stretch opportunities, seeing how they stretch.

 

One of my favorite things to talk about with my team is what I call vacation theory. So, I think it’s my job to take a three week vacation at least once every like 18 months. And I think three weeks is really important. So, if you disappear for like a day or a week, people just ignore and deal with the pain of all the stuff that you’re doing. If you go on vacation for two weeks, then people can do a little bit of that or very temporarily sit in for you, but you can sort of weather that storm. But if it’s three or more weeks, people basically have to act like you’re not coming back.

 

There’s just too many things that pass in that many cycles and it allows you to see what in your organization is working really well as people stretch into it, and what doesn’t. And then you can come back and reevaluate what does my job need to be now? How have things matured over time? Who’s ready to step up and stretch into these positions that if I weren’t here that they could have? So as you’re soft of succession planning through these things, you need to give your organization a healthy attempt to do it. Also, personally, I love to just get away.

 

Marcus: Absolutely. I love that. At two weeks, as you were describing it, I thought to myself, it’s like people are probably holding their breath, just waiting for you to come back. And, of course, we can’t hold our breaths forever. So, I think you’re right, at three weeks, they’re thinking, “Well, I’m going to have to figure out how to get this done.”

 

I want so shift gears and go back to, if you don’t mind, can we go back problem framing and problem solving for a minute?

 

Matt: Absolutely.

 

Marcus: So, it does remind me of that story the Five Blind Men and the Elephant, right, where the one says it’s a wall, and one says it’s a tree, and one says it’s a snake, and one says it’s a fan. It’s all about their perspective. One’s feeling the side. One’s feeling the leg. One’s feeling the trunk. So, it dawns on me, as you said, kind of rewinding to the beginning, problems aren’t inherently rocks or monkeys. They’re just, in fact, I might even assert, they’re just situations. Even calling it a problem begins to frame it in a certain way. In fact, what you might call a problem, I might call an opportunity. I might call a feature, right? We’ve all heard that is it a feature, is it a bug kind of thing.

 

So, as it seems like what you are building in your organization, is some language and capacity around thinking about problems and problem solving. And maybe, what is the problem? Is that something that you work with your engineers to talk through and ask? Because I bet in any given situation, different people see it differently.

 

Matt: Yeah, this is the number one scale that we try and teach and pass along. One, because it’s very generic. It doesn’t even have to sit with engineering and not just leadership. A lot of the people… Early in my run at Credit Karma, we invested really deeply in this concept of Growth Engineering and building a growth team. And there were certain principles and styles that we were looking for that, I’d say normal engineering teams don’t generally value. So, like very rapid experimentation, throwing lots of code out, and just sort of throwing things at the wall and seeing what sits and then continuing to iterate on it. Our cycle time was less than a week on a lot of our projects, instead of your kind of like two week sprints, traditionally.

 

We spent a lot of time with culture, but also what we realized is there were a lot of people who had built problem solving habits that were quite extensive in their area and it was hard to undue. So, we looked in numerous places to help find people and sort of bring them along on the journey. We hired people out of code schools. But we also had like two analysts, who became software engineers. And a marketing person who became a software engineer. And we were happy for them to bring their problem solving skills to bear, for thinking of problems with a diverse and thoughtful, different direction, and help us move really fast through these types of problems that we had, or opportunities if you will. And like build this new muscle in the organization. Then, over time, that became a thing that we spread all throughout Credit Karma. And we built learning and optimization teams in almost all of our verticals because it was such an effective methodology for thinking and doing.

 

Typically, what I say to my teams is that there are sort of three steps to solving a problem, whether that problem is organizational, code, or whatever. And in this case, we usually say first you have to see the problem. Then you have to map a path. Then you have to walk the path.

 

Marcus: Tell me more.

 

Matt: So, if you sit down and you look at a problem. Your five blind people and an elephant is a great example. Wherever you’re sitting in that day, in that seat, is one perspective. And if you can see from all five perspectives at one time, then you’re highly likely to be able to come up with a better solution than the person sitting in just one seat. So, part of what we practice is how do you see the most layers you possibly can.

 

In some ways, if you take a very experienced, super senior CEO, like a Jeff Bezos, and you brought them into your job that day and you explained to them some thing that you were trying to think through, they would start bringing in all these perspectives that you had never considered before. Because the scope and scale of problem they’re trying to solve is much, much larger. They’ve had to see so many more perspectives and they’d say like, “Well, the market thinks about it this way. And competitors. And this and this.” If you go talk to the CEO of your company and you’re asking them for their perspective on an issue, they’re rarely going to sit in your seat and tell you how you see it. They’re going to say like, “Well, what about our member support team. And our BD environment. And this and that.” And all these different angles that you probably don’t see from where you sit, but they have to see every day in their work. So the broader perspective you can see, the better.

 

Oftentimes, I see most of the challenges with my teams are when people don’t have the empathy to see the state from other people’s point of view. The larger the organizations get, the more people have to work together. Very few of us can sit down and be Hercules and move the rock by ourselves. They need a group of people all working in concert to move, to do something big, to have a huge impact. So, people who know how to get groups of people to do things together with leadership without authority, they’re hugely impactful. You have to be able to see how each of those people see’s the problem and bring them to where you are in order to solve it.

 

That’s that second thing. It’s how do you bring everyone to where you are? How do you map the path? And you have to sit down and say this person is here, and this person is here. If it’s a group of friends trying to get together, you’re saying like, “Well, this person needs to fly in, they’re really far away. This person has to drive. I know that person has kids, so they’re going to have to plan ahead and have a babysitter.” All these things will fit together. And if you see all of the edges of the problem and you say like, “Let’s go have a weekend in Vegas,” everyone will just say no. But if you know what the path looks like for everybody, you can say like, “Well, I have to do all of these things and if I lay my groundwork” and then I say, “Let’s all go to Vegas for a weekend,” people are ready to go, raring to go and they’ll say yes. So, the last thing is you actually have to-

 

Marcus: It’s a rock, not a monkey.

 

Matt: It’s a rock. Well the last thing you actually have to do is be able to walk the path that you’ve planned. I think that people over their career, they gain different influence skills. Think of them as tools in a tool belt. If you don’t have a saw in your tool belt, but you plan to use a saw, or your saw isn’t sharp yet, it doesn’t matter how great your plan was, you weren’t able to walk that path. So, if you think through this process, you’re, over time, working on the skill to see problems. Working on the skill to plan through how to solve them. And then working on the skills necessary to make sure that when you’re actually walking those paths, you can bring lots of tools to bear.

 

Over time in our career, we’re just like looking to do this at larger and larger scale. And the more you can see, the more you can plan, and the more capability you have to influence and walk those paths, the bigger, the harder the things that you can get done.

 

We build this framework for people to think through what they’re doing and oftentimes we use this vocabulary in coaching. We’ll say like, “Well, you’re not really seeing the whole problem. You’re missing that this other team has this other goal for this other project and that’s why they’re not able to commit the resources that you want.” So, even though you think you’re making a simple ask of them, they have this extra stressor. Or, we’ll say, “You went into that meeting to try and influence people to this point, that was the right point to influence people, but you were missing these skills in the meeting to bring everyone along. Your tone and tenor wasn’t right from the get go. We can work on that.” Usually what I do for myself and, annoyingly for the people I work with, is I’ll often say like, “Imagine a perfect being had replaced you for solving this problem. Would the outcome had been better than the outcome you drove?” Invariably the answer is yes. If I could see-

 

Marcus: Well, we’re not perfect.

 

Matt: … Exactly. And if I could see past, present, and future, the outcome would be better. Because the thing that most people get into is some sort of victim mentality. They’ll say, “Well, this problem would be super easy to solve if these people just agreed with me.” And it’s like, “Well, you can’t control what those people do. You can’t control anyone else’s actions. So, all you can control in your own path for growth, are the levers you have to bring to bear. So if you had influenced a little bit better, the outcome would’ve been better.” That’s what you have to focus on. That’s the takeaway you have to have in those scenarios, and I think that these are the things I’m constantly trying to do.

 

So then what you need, lastly, is reps in problem solving. So the bigger the problem you’re solving, the more practice you need. And the problems take longer to play out. So, it’s harder to get feedback on how were my decisions.

 

Matt: So the next thing we talk about is stealing other people’s problems.

 

Marcus: Hmm.

 

Matt: Yeah, this is a great one. Typically, what you would imagine is you have as many reps as you take. But-

 

Marcus: What’s a rep? Sorry, is this like a weightlifting term? Just so I know.

 

Matt: Yeah. Repetition. Weightlifting term I think is a good way to think about it. A rep is a practice. An attempt to go through the process.

 

Marcus: Okay, got it.

 

Matt: You go through the process, you see the outcome, and at the end of it, you can retrospective and learn from what happened. So, in this case, what we’re trying to do is go through each of these processes and come to an outcome. And then, retrospective and learn from it, and get better.

 

Well, in your career, the bigger the problem you’re trying to solve, the more time it takes, the longer you’re in it, you don’t get a lot of practice. Except if you’re in an organization where lots of people are taking lots of challenges forward, you can learn from them too. So, what I encourage people to do is, when you see someone else solving a problem, the type of problem you want to solve, or you want to get better at solving, or they have a different style or direction to do it, you’re looking to take that repetition, you want to steal the problem. So you’ll ask them, “Hey, I saw you were doing this. Can you walk me through what you were thinking? Can you explain to me what you saw? Why you picked the path that you picked? What it was that got those people on board, who I can never get on board?” And you take that experience and you bring it into yourself.

 

Matt: What you’re trying to do, in addition to that, is think through like, “Well, what would I do differently? And if I were being intellectually honest, how do I believe it would play out differently?” And learn from those experiences as well. So, [inaudible 00:37:23]. You’re just like training this muscle of problem solving, larger and larger problems and taking the practice of figuring out how to turn things into rocks, and scaling it up for yourself over your career. And the bigger a thing that you can take from a monkey to a rock, the bigger an impact you can have in an organization.

 

Marcus: I really like that, everything you’re saying, but the thing that is just striking me so much right now, is that once you learn how to start asking, to have that position of inquiry, say, “How did you do that? That thing you did there that I saw.” Maybe it’s the person I can never sway, or whatever it was, again, stealing other people’s problems. I found that all of life presents you with opportunities to do that. Not just work. You can become curious and whether it’s your spouse, or sometimes even your kids, you can become a learner from everyone around you.

 

Matt: Yeah. I actually think that this is the thing that most people miss when they talk about talents. So they’ll say like, “This person is innately a good communicator.” And I usually say, “No, communication skills take decades to learn.” And this person has been doing it for years. A lot of times when I look for leaders, it’s often like a person who they spent the time to organize their friends to go out to movies every week, they were the captain of the math team. They’re the one who hosts dinner parties and thinks through all these processes. Because the problem solvings aren’t really all that different. The influence skills aren’t that different. They’re kind of the same. And people who have never done that, but really want to take it on at work for the first time, they face an uphill battle of time. You just need more practice. A lot of times what that means is, not that you can’t do it, but it literally might take you 15 years.

 

Marcus: Well, it’s like people who… you talk to somebody and they say it looks like they’re an overnight success. But they’re like, “Well, I’ve been playing a favorite band that makes it big.” And they’re like, “We’ve been playing in little clubs for 20 years.” So there is no overnight success. They’re just, at some point, you become aware of them. And they’re so good at it because of practice.

 

Matt: Yeah, exactly. I think that ultimately a lot of the things that people look at as talents are just things that take a really long time to practice. And there’re people who have been practicing them for a really long time. You can also develop those skills. For myself, I don’t think I’m innately an extrovert or a good communicator. And early in my career, I realized it was something that I needed to learn. So I just practiced and practiced and practiced. And, at this point, I’ve worn the masks for so long, that they come naturally to me. I even gain energy from my social interactions. And I didn’t 15 years ago, 20 years ago.

 

So, these things can take a long time. They can be changed. You just have to work really hard, and the going is quite slow. And there’s lots of nuance in building out the skillset. There are people on my team who never imagined they’d be a people manager because they didn’t know how to build empathy with others, they didn’t like communicating, they didn’t like putting themselves out there. And 5, 6 years later have developed a toolkit for making themselves very capable of doing it. Then they’re so proud of what they’ve accomplished.

 

Marcus: I love it. I know one of the skills I’ve been working on is actually something you touched on. It’s something I’ve been aware of for probably a decade and have been working on it. And that’s the idea, you mentioned talking to all these people when you’re problem solving and getting as many perspectives as possible. When I was a young engineer, I found that it was really hard to hold multiple perspectives that were in conflict in my head. And it was uncomfortable to the point that I would say I can’t deal with all this. I’ll disregard all of them except these two that seem to be in alignment more with what I want to do and that’s how I’ll go forward. That, of course, had it’s own problems, or created more problems.

 

So, the idea and the skill of holding the tension of multiple perspectives in my head at once and learning to be okay with that, is something that I’ve been working on for probably 10 years. And I found it’s gotten a lot easier.

 

Matt: Yeah, those are exactly the types of things that, when you’re learning how to work through things, take a lot of time. One that I’ve been working on really diligently is waiting. I’m very action oriented. I like to just get stuff done. And I often like to believe that if you can just explain it to people, they should all agree and move forward. And one of the most valuable tools I’ve developed in my tool belt is recognizing that now is not the right time to solve this problem. Yes, it’s a real problem. I could even potentially get everyone to agree to it, that it was a real problem. But, actually putting the effort into solving it is something I can’t get everyone to do.

 

And if I wait, the situation will change. And sometimes I can be really thoughtful about it and say, “Well, you know, this project is going here and this team is working on this and this leader is in this state.” It actually looks, if I played the problem forward, in three or six months I actually think everyone is going to be in a different state for a variety of reasons and then I bet I can influence everyone to get the problem done. I think I can wait. Let me wait. Let me use time as an element to change the way that I look at it.

 

Once I realized that I could do that, it unlocked a whole fleet of capabilities for me in just thinking through sequencing, on how I move stuff forward. Credit Karma is this amazing company. And in my time there, it’s quadrupled in size, and revenue and growth, and all this crazy stuff that happens. But those things come with many problems. Success brings many opportunities to learn how to do things. Oftentimes, even a thing that you go through, and you solve, and you make better, the growth breaks it again.

 

A great example for us was recruiting. When I first came in, we had one methodology. It just wasn’t working for us. We sat down and figured it out and it helped the scale a lot. We doubled the staff with really high quality, fantastic folks over the next year. And about 18 months later, it was actually working terribly. And it wasn’t because what we had done was wrong, it was right for the situation, but the circumstances caused it to break again. All of a sudden you’re trying to do different things. You have different specializations. You have more hiring managers. Those variables broke the equation. We had to go fix it again. So, as you look at these types of opportunities to solve problems, it’s like the best part of being at a fast growth company, you just get so many reps and you get to see things play through much faster.

 

Early in my career, I was at Lockheed Martin for a while and things took a very long time to move through its cycle. No one was incentivized to move fast. And the company was largely static and didn’t kind of break its own processes over time, at least not for that reason. At these high growth companies, you have so many learning opportunities. And it’s this fantastic environment to play through different problems, to see different dynamics, and to get the feedback loop really quick so that you can learn and grow. And I love it.

 

Marcus: Awesome. Rocks. Monkeys. Reps. Problem solving. What a fantastic conversation, Matt. Thank you so much for joining us. Where can people find you online?

 

Matt: They really can’t. I don’t have a lot of places to find me online. I’m basically never on Twitter, but I am @Matt_Muffin. If you want to reach out to me, you can email me at matt@creditkarma.com and I will probably respond. I also am on LinkedIn. Happy to find anyone who wants to talk and make time.

 

Marcus: Thank you for being on the show today, Matt.

 

Matt: Thanks, Marcus.

 

Closing: 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.

 

Closing: This has been a Humble Pie Production. Stay humble.