How to Tackle (Organizational) Debt

Jonathan Raymond- Author of Good Authority; Founder & CEO @ Refound

Jonathan Raymond is the CEO at Refound and author of the award-winning book, Good Authority. In 2018, he was named one of Inc. Magazine’s top 100 leadership speakers. Refound trains leaders on how to give effective feedback and create a culture of accountability. The former CEO of EMyth, Jonathan has led business transformation projects in technology, renewable energy, and the coaching industry. He’s a half-decent barista, a bad-but-enthusiastic surfer, and will never give up on the New York Knicks.

“As organizational leaders, when it comes to organizational debt, we know that we take shortcuts. We make easy decisions. We do things that are expedient in the moment. But it has a cost. But we have to deal with it as a responsible leader.”

- Jonathan Raymond

SHOW NOTES

• What is “organizational debt?” (4:35)
• Defining technical debt. (5:56)
• How you know when you have technical or organizational debt. (7:26)
• The first step to solve technical/organizational debt. (8:23)
• Second step, what’s next before entering “solution mode.” (11:39)
• Understanding the problem now that the issue is in the open(12:49)
• How you sell someone on doing something new (14:04)
• Where we often leave the process of solving organizational debt unfinished. (15:14)
• The active solution after the first three steps. (16:44)
• What separates good engineering leaders from mediocre ones. (19:24)
• Become the engineering leader your team is waiting for. (22:14)
• Additional examples of organizational debt. (23:11)
• Who owns organizational debt. (24:14)
• Dealing with over-leveling or title inflation. (25:09)

TRANSCRIPT

Technical debt.

Now unless you were in a peculiar mood, or you had something odd for breakfast, you didn't wake up this morning excited about tackling your technical debt. I don't love that you have it either, but what I love about it is that you know what it is. You know how technical debt gets created, you're probably keenly aware of the problems that it causes, you know how to solve it, and most importantly for our conversation today, even though you don't always look forward to doing it, when you do, you know what a powerful cultural moment that is for your team.

It's a win. It's a critical skill as an engineering leader to be able to acknowledge the existence of, and take a thoughtful approach to, resolving technical debt.

Did you know that you could apply that same thinking, the mindset and many of the tactics that you use to solve technical debt, to another area of leadership, another critical area, the people part? What I'm gonna call organizational debt.

So what's organizational debt? Organizational debt are all of the missed conversations, the half-given feedback, the leadership dysfunction, the cultural and legacy issues inside the organization, the challenges when you go from 25 to 50 to 2,000 employees. All the things that creep in that result in the politics, and the gossip, and the disengagement. All the things that lead otherwise great people to leave otherwise great companies. So that's what we're gonna talk about for the next few minutes.

I have one disclaimer and one ask of you. So while I've been around a bit, I'm not an engineering leader. I'm a leadership trainer. I get really excited about organizational debt. Now you may not get all that excited about organizational debt, but I hope that you will at least come away with a framework for how to approach this as you see this on your teams, and in your organization. And if I speak about technical debt in a way that isn't exactly how you speak about it in your organization, if you can just cut me a little bit of leeway, everything's gonna work out fine.

So let's start by defining our terms. What is technical debt? So the top hit in Google says,

"Technical debt is the implied cost of rework that is created by choosing an easy solution now instead of a better one that might have taken longer. Or would have taken longer.”

It's a beautiful definition, right? It's logical, it's intuitive, it matches our experience. It's kind of how it is, right? Sometimes we choose easy over better, and there is a cost.

What's not in that definition? Does it say you're not a good person if you sometimes just choose easy over better? No.

Does it say you don't know anything about engineering if you sometimes choose easy over better? No.

Does it say anything about your personal character, your moral fiber, or the evolution of your consciousness if you sometimes choose easy over better? No. It simply states something that we know to be true, that sometimes we choose easy over better, and it has a cost.

We know, as engineering leaders, when it comes to technical debt, and as I'll argue, as organizational leaders when it comes to organizational debt, we know that we take shortcuts. We make easy decisions. We do things that are expedient in the moment, but it has a cost, and we have to deal with it as a responsible leader. We have to deal with it. It doesn't have to be the most exciting part of our day, it's not the sexiest thing in a release, but it's important. It's a powerful win for the organization.

So let's start. How do you know when you have, or you suspect, that you have a piece of technical debt? Well, you're probably going to tell me when I walk into the hallway, some ways that I didn't think of, but there are at least three. So one is the code isn't working the way it was intended. It's behaving in a way that's buggy, or erratic. It's not doing what we want it to do. So we think to ourselves, “oh, we probably have, or maybe we know, we have a piece of technical debt.”

What's another way? Maybe the code is working, but it's slowed down. Still doing the thing that we asked it to do, but it's not doing it as fastly, or with as much crispness as we would like.

What's another way, a third way? It shows up in morale. You're hearing it in your office. People are saying, "Hey, I'm spending a lot of time "and energy dealing with this. "Can you please do something about this? "It's driving us crazy on the team." So it's either something erratic, something inefficient, or it's causing problems for other people.

How about organizational debt? What are the symptoms where you either know or you suspect that you might have organizational debt? Same three. Somebody or some group of people is behaving erratically, doing something unexpected, second, maybe they're doing the thing you asked them to do, but it doesn't have that same crispness. It doesn't have the same quality that it used to. And you're just like, "Oh, there must be something going on." Or third, a person or people are causing problems for others, and you're hearing about it in your office, and it's cutting into your creative and strategic time 'cause people are coming to your office and saying, "Hey, can you please do something about this?"

So what's the first thing that you do? What's the first step that you take when you suspect or think you have a piece of technical debt? Do you go and solve it? No. The first thing that you do is you name it. Now maybe that's putting a sticky note on a white board, or a task in Asana, or whatever tool you use, but you take a pure first step. You just name it. You get it out of your head, and you put it on a page, or the page.

Why? Why is that so important? The reason why that's so important when it comes to technical debt is because the universe of things that you don't know yet is enormous. You don't know how big it is, you don't know what that data's touching, you don't know what's gonna happen if you pull on it, you don't know what its favorite color is, or its favorite stuffed animal. You don't know anything about it other than you know it's causing problems. That's it. But that's all you need to know because now you can have conversations about it.

So let's go back one sec. So on technical debt, what are the things that you don't know? You don't know how big it is, you don't know what the implications are, you don't know how expensive the fix is gonna be, (really important). You don't have a project plan for how you're going to solve for it, you don't have anyone accountable for who's gonna be responsible for solving it, and you haven't made the choice, as a team or an organization, to actually tackle it.

So let's flip to the other side, to organizational debt. Same first step. If you suspect that you have a piece of debt on your team, something that isn't quite right, somebody's behaving in an odd or unexpected way, or they're not doing the work the way they used to, or you're hearing a lot of gossip and politics, and you think, "You know what, we've got a piece "of organizational debt. I wanna do something about it.”

The first step is that pure muscle of naming it, getting it out in the open. So with a person it might sound something like, "Hey Kevin, you seem a little distracted in our standups this week. Is there anything going on?"

I'm not trying to solve it, I don't know why Kevin is feeling that way, I'm not making an assumption, or a judgment, I'm not punishing Kevin for being a little bit distracted, I'm just naming it so that we can have more conversation about it. When it comes to those things that are in the culture that are hard to talk about, finding oh hey, I don't know what it is, but there's something about the way we're working, are you picking up what I'm picking up?

It may be a little bit harder to quantify, and maybe a little bit harder to put some boxes around than technical debt, but it's the same. It's taking it out of your head, out of your subconscious awareness, maybe, and bringing it up to the surface so that you can work with it.

So that's the first step. It's naming, whether it comes to technical debt, organizational debt. Naming it, getting it out in the open, that pure first moment of awareness.

What do you do next with technical debt? You still don't go into solution mode. That's not what you do next. You ask more questions. You're gonna do some scoping. So you're gonna find out how big is it, what does it touch, what are the parameters of this problem? Maybe the thing that we first thought was the problem is actually a symptom of a deeper problem. So we're asking questions, we're in this phase of scoping, we're in the state of curiosity so that we make sure that we're gonna solve the right problem because we know how important the resources are that it's gonna take, that we're gonna have to divert, to tackle that piece of debt. Let's make sure we're solving the right problem. So we do scoping.

Let's talk about the organizational side; same thing. You're gonna ask more questions, you're gonna stay in that space of curiosity whether that's in a hallway conversation with somebody, or in a team meeting, or even in an all-hands. You're gonna ask more questions. What are you seeing? What am I not noticing? Maybe there's something that I'm doing that is contributing to this problem that I'm not aware of yet. I really wanna know those things. You have to create space to do scoping in an intelligent way just as you would with a piece of technical debt.

So, first two steps: we've named it, we've got it out in the open so we can have a conversation about it without judgment, without punitivity, without blaming. Next thing, we're scoping. We're saying, okay well, let's get some more parameters. Let's understand the problem better. Let's get more fidelity on this problem so that we can design an intelligent solution.

What do you do next? If someone on your team came to you and said, "Hey, we have this piece of technical debt. We wanna roll it into the next release, we wanna design a fix, and we've done some scoping, we've asked some questions, we really think it touches a bunch of stuff, but we think we have our heads around it."

What's the next question, or one of the next questions that you're going to ask if you're on your game, or you should ask?

What's the business case? Because if you have a piece of technical debt that's costing you $5.00 a day, but it's gonna cost $3 million to fix, you ain't gonna do it. So your team is gonna have to sell you on diverting precious resources towards tackling that piece of technical debt over others, diverting resources from other projects.

There are many things that you could put your dollars, and time, and people, and morale against. You only have so much of that in the bank. So your team's gonna have to sell you on it, or you're gonna have to sell your manager, if you have one. Hey, this is the cost of inaction is really high. That's how you sell somebody on doing something new most of the time. Hey, if you stay doing what we've been doing, this pain that we have, that's like this, is just gonna keep getting bigger, and it's gonna get more and more expensive to fix later. I think we should do something about it. It's part of your skill. You may not think of yourself as a salesperson in that way, but that's part of what we do all the time when we have limited resources and we're trying to manage priorities. When it comes to the organizational debt side of it.

So we've named it, we've done some scoping, we've asked some questions. What does that look like when it comes to resolving or tackling organizational debt? Now we're into helping people understand. We still have to sell. A lot of good people management is about selling. Not in a cheesy way, not in a slimy way, but it's about helping people see a gap. What is sales? Sales is helping people see a gap between where they are and where they could be. And if they'd buy our product, or use our service, we're gonna help them close that gap. That's your job as a people leader.

“Hey, here's where you are, here's what you're doing today, and here's where you could be. I'd love to help you get there. I'm your coach, I'm your mentor, whatever it looks like in your organization.”

But that's the setup. But what we do, oftentimes, not always, but oftentimes, as leaders and managers, is we leave this step in the process unfinished. We give a little bit of feedback, we talk a little bit about how it might be causing some problems, but we don't do the step of actually selling that person on why that's so important using the same parameter. What's the cost of inaction, using questions like, “well, if you continue to stay in this state that you're in, how might it be impacting your teammates?”

They've never asked themselves that question before, usually. If you stay in the state, if you keep showing up on our team this way, how might it be impacting our customers? They probably haven't asked themselves that question, or partners, or vendors. How might it be impacting our working relationship? You don't wanna have me frustrated with you. I don't wanna, you know, we're trying to all get along here. How might showing up in this way be impacting our relationship? And most importantly, how is showing up in this way holding you back from the career development that you're looking for, from becoming and getting to that next place that you wanna get to in your career?

So look at all the steps that we've taken so far, and we haven't solved our piece of technical debt, or organizational debt, or have we? We've named it, we've got it out in the open, we got it out of our heads and onto the page, we did some scoping.

We said, "Okay, we need to understand the parameters. We need better fidelity on this problem. Third step, we said, Okay, we gotta make the sale. We gotta close the deal. We're almost home."

So we've done these first three steps, we haven't gone into active solutioning yet, but now we will because what's the next thing that you do. You've named it, you've scoped it, you've sold the team, "Hey, we're gonna tackle this piece of technical debt." What's the next thing?

Do you say, "Oh well, we should probably do something about that someday. I wonder if somebody will take this on?" No.

You put a name on it, Melissa, and it's gonna happen by March 31st. You put a name and a date. If you don't have a name and a date, you don't have accountability. It's just a theory. So it doesn't mean there aren't other people that are gonna be working on that project, but that project needs a champion. The project needs someone who says, "Hey, this is mine. I'm gonna do this. I'm gonna enlist, I'm gonna get with other people to get what I need in order to do this, but I'm responsible for this. I'm gonna drive this forward, and I'm gonna communicate with the rest of you how it's going, and if I need to update something, or if I need to change something."

So we're putting it on the calendar. There's an avatar, someone's avatar, and it's in some tool as on that project.

When it comes to organizational debt, the same thing has to be true. It can't be an etheric, abstract concept. If somebody has a performance issue that you need to help them with, or the team has some kind of challenge, or struggling with some dynamic, you have to make a project out of it.

There are too many distractions, way too many distractions, there are so many shiny objects, not just in our professional life, but in our personal life, things that we could divert our attention to, we make a project out of it. We decide, okay, this is important, and it's important enough to put on the calendar, and put someone's name on it. Same goes with organizational debt. Somebody needs to be responsible. Hey, we need better communication standards on our team. It's a little bit squishy.

If I send an email to somebody, when should I expect a response? How do we use Slack? What are the rules of the road for how we do things here, how we're supposed to show up for one another? Somebody should own that project. Other people can have input, but somebody should own that. We need to do a better job of managing, of setting, clear expectations. Who's gonna do that for this piece? Who's gonna do it for that piece? Some of that may be yours, as the leader of that team. But we put a name on it, and we put it on the calendar.

The last step that you do with technical debt, so you've named it, and you've scoped it, you sold the team, hey, this is really important. The cost of inaction is too high. We can't persist in this state, it's not worth it. I care too much about this product to let this piece of technical debt rot away in the architecture. I care too much about you as a team to let it persist. What do we do next?

What's the thing that separates good engineering leaders from mediocre ones? It's the same thing that separates good people leaders from mediocre ones. It's the people who commit. They say, "Look, you know, we put all this time and effort into understanding what this problem is, of getting more fidelity around it, of moving priorities, and you know what, I know that there's new stuff that's come along, I know we could probably change it, but there's value in completion."

We know that, if anyone has ever been on a team other than your own, you know that one of the most difficult things is when you have all these unfinished projects, and it always feels like you're constantly restarting things. It's really frustrating. It really degrades morale very quickly. So we see it through. We say, "Look, I know we found this other thing in the process of scoping this piece of debt that we wanna retire, we learned some other things, we're gonna put it up on the board. Goes in the backlog. We're not forgetting about it, we're not ignoring it, but we're on track. We're committed. We are going to complete this project, not only for the sake of resolving that piece of debt, but for the sake of the health of our team."

And that's the thing that separates good people leaders, effective people leaders, is that they change that equation, they say, "You know what, it's awkward. Naming it is awkward and uncomfortable. I didn't really know how to do it, but I tried anyway. Asking more questions, taking time out of my day, sitting down one on one, it's awkward. It's uncomfortable. I'm worried that they're gonna get defensive."

A million good reasons, right? What if there are some pieces of information that's about me. Maybe I caused this, and I don't really wanna know that. Whatever the case may be, there are a lot of obstacles. But we see it through. And if you've been on a team, as I'm sure almost everybody in here has, when a performance issue with a specific individual who's been causing problems for others, or some morale, or some dynamic, something needs to change in that organization, we have this dual experience where leaders often wait too long, typically way too long.

But when they do, when you say, "You know what, I'm committed. This is not okay. "The cost of inaction is too high,that's when your team goes, Whoa. That's the kinda person I wanna work for."

Somebody who values these other elements, who prioritizes cleaning out our organizational debt, thinking thoughtfully about it, thinking methodically about it, not giving feedback about every little thing, but choosing and picking their spots, and realizing what is the highest-value things that they can do to advance the cause of our team, that's the person that I wanna stick around and work with. Almost regardless of what happens around us at this organization, I'll stay with that manager or leader for a really long time.

I saw some nodding heads. People know we'll stay working for a leader for a really long time if they do the right things, if they keep their house in order. So whether it comes to identifying, and thinking about, and working with technical debt, or organizational debt, they're kinda the same.

The process, the technical process that you follow, of course there are vagaries, there are distinctions, but the framework for how to solve it, to name it, to get it out in the open, to do some scoping, ask more questions, stay back in that space of curiosity. Do the work to make people understand if it's not intuitive at first, hey, the cost of inaction is too high, and then put it on the calendar, and put someone's name upon it, and have however many conversations you need to have to make sure that the right things happen on your team, and your organization. And if you do that, you'll become the leader that your team is waiting for.

Thank you so much for listening.

Moderator: Thank you, Jonathan. We have time for a couple questions. Jonathan, can you please give some more concrete examples of organizational issues you'd classify as debt?

Jonathan: Yeah, so for example, maybe you have a CEO who struggles with delegating, and is overly-controlling of process. Maybe… anyone ever been around a situation like that? So that's organizational debt.

It could be hey, we have too many projects and we're really struggling with letting go of some nice-to-haves. That's another form of technical debt, sorry, organizational debt.

Between two people, hey, there's tension in this space. You can think about it just like you think about code. And again, I'm speaking as a non-technical person, but to me, it's like, the code was either written poorly, it's obsolete, it wasn't badly written, but it's obsolete now, or we forgot to write it. Same thing.

Organizational debt. It's either something that we did badly, we didn't think enough about it in the moment, or we did it fine, but it's now obsolete, or we forgot to do it. All that housekeeping in the organization.

Moderator: The next question is from Dan. Who owns organizational debt, especially cross-team debt?

Jonathan: Yeah, depends on the organization. So I think one of the things that you're seeing as a shift, in particular around employee experience and leadership experience, is that we're expanding that definition so it's going beyond HR, and certainly beyond L&D.

So who owns it in your organization? I'm not sure. It depends. Certainly you should own it relative to your domain, and this is a place for more manager conversation like, “Hey, here's something that I'm seeing, are you suffering with that, too? Hey, maybe we can do something together?”

It's one of the underutilized, usually critically underutilized skill sets and capacities, is managers talking to each other. “Hey, are you seeing what I'm seeing? Can we do something about this? Let's get together. We don't have as much power as the VP of Engineering, but the two of us, if we both say, Hey, this is really important, maybe we can get some movement there.”

Moderator: Thank you. So we have time for one more question. And this has been a hot one on the upvoting, so there's a big desire. How would you deal with an organization where many people have been over-leveled, and have title inflation?

Moderator: Yeah. Has that happened at all around here? I'm not sure.

So I think it goes back to one of the other questions, I think, on the board, which is that the naming, and you can have conversations with people like, "Hey, you've probably noticed that this is something that we do here, and I actually wanna help you as your manager,” or “I wanna help the team,"

And I think that this is actually a problem, and I would be self-referential in that moment. You say, "Look, if I have a title that's beyond my skill set, it's a source of discomfort for me. I don't feel like I have my feet on the ground. I don't feel grounded. It's not a good feeling, while I might sorta like the title in some way.

So I can't do anything about the titles, they are what they are, and maybe the market here in San Francisco, or the Bay Area, is causing some artificial inflation, but let's be real with one another because that's how I can best support you as your manager, or as your leader, so that I'm not gonna try to manage to that thing, 'cause if we can both acknowledge there's something a little bit off about it. Maybe you're six months away from that. Maybe you're a year away from that. I don't care. That's not that big a deal, but let's be real with one another. Let's talk about the things that are gonna help you feel really settled”

Sstart by asking them, "Hey, so your title is this x, I'm wondering how you feel about that title? Do you feel squarely in the center of it? What are the skills that you think a director of products should have that you don't feel totally square with right now?”

Use it as an opportunity to build that contrast. “Great, thanks for being honest with me. I really appreciate that. Let's work on that together.”

So be real. There's so much BS out there, about great places to work, and culture, and all this nonsense, right? It's about people being real with one another. It's about being willing to say to somebody else, "Hey, look, that's out of our control, but this is. Can we get together on that?"

And if you'll be real with your team, that's the best way to do that. And also, one last public service announcement, if you just took over a team that you used to be on, it's a great moment for transparency. Hey folks, this is weird for me. I used to be on this team and now I'm leading it. I've got other responsibilities, I'm getting other data, I just gotta acknowledge, it's a little awkward. And I'm gonna have to live into that title. I don't expect you to think, "Oh, he or she is totally there right now." I'll get there, and I need your help.