The Importance of Trust and Communication with Tim Ottinger
Episode 24
On today’s episode of Programming Leadership, we dive into what is needed to establish safety in your own organization. Trust is just one of the key pieces that make up the structure of safety in a work environment, along with actual physical measures, active communication, and regular feedback. The people who make up your organization are an integral part of the safety structure. An exchange of ideas and criticisms between subordinates and superiors should be shared, but boundaries must be in place and commonly known in order for these exchanges to occur safely and effectively. Utilizing all of these components, managers can provide a safe environment for their employees to help limit catastrophes from occurring whether in the workplace or in the actual work itself.
Show Notes
- Safety is defined by the measures put in place to prevent small problems from turning into big ones, but those are not limited to merely physical measures.
- A feeling of safety in the work environment is just as important and necessary to an end product as a software test suite.
- Communication involves listening without assumption and questioning with intent so that decisions can be made with the correct desired outcome.
- Good intentions and taking risks can be seen as good or bad, depending on who’s calling the shots. The reality is – there is no universal safety net.
- Trust can be broken, but it’s also negotiable. Be willing to admit when too much is too much, and ask for help when you need it rather than take on more than you can handle and risk losing trust altogether.
- Learn to recognize a person’s limits, and learn to recognize when those limits need to be challenged or reassessed and raised.
- Jobs evolve just like people. Evaluating a person’s performance shouldn’t be just about how well someone does in the job they were hired to do.
- You have to look at how a person has adapted to their work environment and how they have changed it, for better or worse.
Links:
Transcript
Announcer: Welcome to the Programming Leadership podcast where we help great coders become skilled leaders and build happy, high-performing software teams.
Marcus: Welcome to Programming Leadership. Our show today is on building safety in your organization, and I am so excited to have Tim Ottinger as my guest. Welcome, Tim.
Tim: Well, hey. Good to be here, Marcus. How’s it going?
Marcus: Oh, it’s going great, and as I’m at home alone, I feel relatively safe, although I’m not exactly sure why. So, let’s start with this big question. Psychological safety and safety of all kinds is really a hot topic, especially amongst software engineering teams. Can you give us a working definition that you use for safety?
Tim: Certainly, so I would say that safety, safety itself is um defined by the presence of safeties, which are mechanisms that keep an error from becoming a catastrophe.
Marcus: Mm. Okay. My mind just kind of exploded there, because you took the word safety and then you used it. So, safety, as you’re talking about, a safety is a noun – something you can point to,
Tim: Yes.
Marcus: A policy, a guardrail. That is a safety, and I’ll be honest. I live in rural Oregon, and we have guns,
Tim: Mmhmm.
Marcus: And each gun has a safety, at least it should. And so, that was the first thing that came to mind was the safety on a gun is something that prevents… How did you say? You said it so nicely.
Tim: It prevents an error from becoming a catastrophe. And, in fact, the safety on a gun was one of our first thoughts. Ashley Johnson and I were working on teaching about safety, and we’ve gone with that. The reason the safety is on the gun is because any accident could become a catastrophe, but with the safety on, that’s not going to happen. And, in fact, you know, it may actually even prevent use sometimes. When you intended to use it, “Oh, darn. I left the safety on. Click, click. Okay.” There have been a number of hunters who have missed that prize buck because of that reason.
Marcus: Oh, absolutely. I have not quite been one of them, but my father ingrained to me, you know, “You don’t take the safety off.” There were always a lot of rules. And so, since we’re going down this road, I will say if you’re listening to this podcast, and you’re uncomfortable with guns, I don’t think we’ll be here a long time, but guns represent an item by which a very small amount of force creates a very large effect. So, I think it is applicable that we think about safeties as being especially important in those situations.
Tim: Yeah, and, you know, of course, in some places… You know… The… You live in a more rural area. I grew up in a rural area. I live in a much more suburban area now. I’ve lived in metropolitan areas, and the sense of that is different. Right? When you’re in the country, it’s something you use to protect your livestock from the predators. It’s something you use to keep the ground hogs from tunneling in and causing tractors to overturn.
Marcus: Yes.
Tim: And, so, it’s a tool. In the cities, it is not that sort of a feeling at all. So the feeling about the same item that might have been in the country is now, it’s a device that only exists for the murder of human beings. That you wouldn’t have one if you didn’t intend at some point to cause a person to die. And, so that is a change in context where in the country, it’s perfectly normal to speak about these things. “This is how I keep the coyotes off the sheep.” And in the city, it means something different. So, even bringing up that example is a case where, “Well, this conversation could go horribly wrong in the wrong audience.” So, we need to talk about other kinds of safeties. What are the other things that we do that keep our errors from going horribly wrong?
Marcus: Well, let’s talk about that. What examples… And since we’re primarily talking about software teams and technical organizations, what are some things that apply in those contexts?
Tim: Well, one of the most obvious ones is, we talk about the technical safety, a good test suite. So, a person could have an error. The error could uh you know be a small change, a surprising mistake in some bit of code somewhere that happens to have a bad interaction, and they don’t know that. Um so, because they don’t know it, you know the error could possibly go into the wild and cause someone some kind of heartache or trouble or panic. So, we have a test suite. Right? The test suite’s job is to let us know that there has been an error made recently, so we can correct it. It’s pretty fair.
Tim: Another safety is working in groups… That in the moment that I make an error, or I start to make an error, or I’m making a poor strategic choice, other people can say, “Wait a minute. Wait a minute. Why would you do it that way? What’s your intention at this point, and have you considered this other way of doing it?”
Marcus: That’s a really interesting… One thought I had, and of course, this is live without Annette, so we haven’t rehearsed this, and I don’t know what you’re going to say. But, one thing I noticed was that sometimes as a leader, I didn’t get very much pushback. And, in hindsight, I wonder if an absence of challenging my ideas, an absence of sometimes new or thought of as crazy ideas meant that I hadn’t created a very safe environment.
Tim: Oh, I think that’s a very good one. I think that’s quite lovely. Yeah, in a correct environment, if we have the relationships, that give us safety. Then we should expect to have some challenges. There is certainly a culture in a lot of software shops of, “Do as you’re told and keep your mouth shut,” and sometimes, when talking to a manager, we forget that we’re talking about the work. We think that we’re talking about our jobs. So, when the boss says, “Hey, I think that we want to do this.” Then the answer is, “Yes, sir. I will do that right away,” or, “Yes, ma’am,” as the case may be.
Marcus: As it may be.
Tim: Yes, I will do that. And sometimes, what we’re really looking for is you know, “Do you agree or disagree? You know can you argue with your boss? Can your subordinates argue with you?” is pretty crucial. And if they do, you know what’s the result? Are they not long for the company? Is that a career-limiting move, or is that something appreciated and uh rewarded really?
Marcus: Yeah.
Tim: You know, “Thank you for helping me make a good decision.”
Marcus: Oh, I love that. I think if you… So maybe we could say that if you are not getting… we’ll just use the phrase “argued with” in a professional, respectful… If people aren’t telling you that there are other options, that you haven’t looked at the whole situation, that they have different ideas, um maybe it’s not as safe as you think. And if you are finding yourself dismissing those ideas as, “Well, they don’t really get it.” I hate that phrase, by the way. I talked to managers who say, “My team doesn’t really get it.” So, therefore, they’re not involved with the business decisions.
Marcus: But if you find yourself thinking that your team isn’t getting it, maybe that’s also a sign that you’re not really thankful, appreciative, and seeking out those things, which is possibly part of what makes it safe.
Tim: Yeah, and I think there are a few hallmark phrases that you’ll hear in unsafe environments. Right? When you hear the managers say, “Oh, they’re like a bunch of elementary school children. I feel like I’m running a preschool.” Then you’re seeing someone who is imposing control on the others, and they’re finding the others aren’t falling under their control, and there’s frustration. Right? Their expectation isn’t being met. “They don’t get it. I said this, and they’re not doing that.” That’s not the thing.
Tim: They misunderstand, “Well, if I’m leading, isn’t it my job to share a mission and create alignment and to help people to engage fully in my mission?”
Marcus: Yeah, and I certainly have… I’ve heard all those things. I’ve heard you know even worse, as I’m sure you have,
Tim: Mmhmm.
Marcus: But we don’t have to talk about that. But, if you’re listening, and you’re wondering if this is you, I will tell you that I don’t… I think Tim’s right, going to your people, and he didn’t quite say this, but in saying, “Is it safe here?” That may not yield the information you need, but starting to look at the feedback that you’re getting. Now, what are you taking in as inputs?
Marcus: Um you know Tim, my wife was a nurse on a surgical floor, and the company that she worked for had a self-reporting… A system in place by which if you make a mistake, you’re expected to report your own mistakes. And, if you see someone else make a mistake, you’re expected to report their mistakes. And all of this was done under the guise of patient safety, which probably is akin to software quality in some ways.
Marcus: Um you might imagine that while these were well-intentioned programs, they didn’t actually yield a lot of improvements, and I don’t know if we could talk about, like people who have programs like this in place where they really want these things to work. And I know I’m being a little vague, but what are some mistakes people make when they’re trying to improve safety or they think that they have a safety program in place?
Tim: When you talk with a subordinate in the system, they’re quite aware that their position… You know you wouldn’t talk to them unless there was a question about their work or their position. That’s an assumption that’s begun in most cases. Right? So you are already in a difficult situation. Um and so, in that situation, you know, it’s about how much will people voluntarily shoulder responsibility versus being given to them. Right? You know do they express an interest in doing things, and what happens when they do? But the other part of that is there’s a different piece of invitation that I’ve seen that’s really crucial.
Tim: So, I found a team that just worked beautifully well together, and they loved their manager. They were all… The idea of switching managers to them was a traumatic thought. They loved this manager so much.
Marcus: Hmm.
Tim: So I thought, “Finally, I got this outlier. Why would I not do some research, right?”
Marcus: Right.
Tim: So I ask them questions and digging in, and the number one reason is managers are dangerous. They’re dangerous animals. But they love their manager because if they told him about a problem, he did not try to fix it. Isn’t that interesting? So, he’d established a rapport and a relationship, and somebody would say, “Oh, you know Bob’s driving me crazy. He’s coming in. He’s doing such-and-such, and he’s just making me nuts.”
Tim: And then the manager would listen and, “Well, you know tell me more about that. How does that make you feel? What’s going on? And then at the end, would say something like, “Should I talk to Bob?” And then the people go, “Oh, no. You know he does a great job. It’s not like I don’t want to work with him, or I want anything to happen. I don’t want him punished or anything. It’s just been irritating me, and thanks for listening,” and that actually… You know now, the manager understands the dynamics of the team better. They understand that every time they say three words to him, it’s not going to go cause some severe action to take place that it’s not going to happen without an invitation.
Tim: So, there’s safety in that conversation. I can tell you what’s really going on because I know that you won’t muck it up.
Marcus: Yeah. Boy, my mind is reeling here. Again, if we consider that idea that a safety is a noun, a part of a system that prevents catastrophic little things from becoming really big problems. The manager asking, “Would you like me to help with that?” or some question like that feels like it’s the safety rather than it being the trigger pull. We’re using guns again. But the trigger pull of a large explosion, and I think that’s so true, but yet as the manager… Well, doesn’t it seem like our job, Tim, to go solve problems and clear roadblocks and be all proactive?
Tim: Well, there was this nice piece of paper, little website that was created you know several years ago, and it suggested that there was this, somebody described… There’s only one sentence. It’s on the second page that describes management, and it says, “Build teams around motivated individuals. Give them the environment and support that they need and trust them to get the work done,” which I think was a pretty, pretty brave and wise thing to have written. So, in this, you know the manager’s job is to create the environment, provide the support, give the team the things that the team needs to make that work rather than um a more traditional view of the manager parses the work, assigns it to the individuals and holds their feet to the fire.
Tim: It’s a kind of an upside-down view. It’s more of a servant leadership point of view, and for that to have been in the Agile Manifesto 20-some odd years ago doesn’t even sound radical now. But at the time, that upset a lot of people.
Marcus: Well, I was going to say although it may not sound radical, as you mentioned with this manager that you stumbled upon, and you did your bit of research with. It’s still highly unusual.
Tim: It is that. Relationship might be the ultimate safety, and that’s [crosstalk 00:13:46]-
Marcus: Go a little more with that.
Tim: So, you know psychological safety was you know Amy Edmondson and all those that have written about this, and it’s been a big focus, and people are like, “Well, you know we’re going to be psychologically safe or else.”
Marcus: Or the beatings will continue.
Tim: That’s right. That’s right. “You’re going to feel safe here, or we’ll punish you.” Point of psychological safety is that you can come, and you can take some chances that if you take some chances, they’re not going to spiral out of control. So, I’m going to try doing this in TypeScript instead of in JavaScript. Why? Well, because I think it might work better. The team looks at it. They go, “Wow, I like that. The team does it.” Well, ideally, if that yields better results you know that the work can be done safer, faster, cleaner that it opens up new avenues for them. That probably should be the kind of initiative that you would reward.
Tim: However, I know certain cases where people who’ve done such a thing have taken some small chance like that have been severely punished. In fact, set back two or three months in productivity to go back and rewrite all that code and redo it all, because we’re not going to do that. How dare you? This wasn’t approved by the architecture board,
Marcus: These kinds of things.
Tim: It’s hard when your best work is likely to be something that damages your annual review and possibly cost you a promotion or a raise.
Marcus: Well, that’s probably a risk I would not feel comfortable taking. I mean, and I love organizations I’ve worked in, and I’d like to think I’m a very loyal person and want the best for it, but if you’re asking me to risk my mortgage, my kid’s college account, right? That kind of stuff, I’m not going to do it. The thing I think I want to actually go into here is something that sometimes, I think, the leaders who feel like they’re um just you know watching over a preschool or babysitting. It’s something they miss, and you said it so nicely and simply, and that was the person thinks that TypeScript will be better, so they take a chance, and they use it.
Marcus: And it’s that first part about they thought it would be better. If you have people working for you that are doing things that they don’t think are going to make things better, then you have a real problem, but my guess is is that a lot of the stuff that’s irritating you is stuff done because they think it’s going to make it better. That’s their intention.
Tim: Mmhmm. There’s a nice Don Gray line there. I don’t know how many times Don has said to me, “Well you know, 99% of the time, 99% of the people are just trying to be helpful.”
Marcus: I think that’s a great line. Absolutely.
Tim: And you know respecting the motivation and intention of people to help is a big deal. Seeing it as subordination because they weren’t strictly following the rules is a different, just a different approach.
Marcus: You know I suppose and I think that in our industry, it’s… I don’t quite know how we got here, but for a group of enlightened individuals that work on something so abstract, we have fallen into the very traditional management practices of command and control more often than I think we’d like to admit. Even when we’re agile, our management style is oftentimes still delegate, do, hold toes to the fire, which by the way sounds awful. I don’t want my toes to be burned.
Tim: I don’t want my toes held to the fire at all.
Marcus: I don’t want any part of me held to the fire.
Tim: Yeah, can we keep the fire at a safe distance?
Marcus: Right. The safety, there we go. Um Tim, let’s go back to relationships for a minute. How do relationships create safety?
Tim: Well, there are a couple of important aspects in a relationship that are going to pile in here. One of them is trust. Um a lot of people just don’t learn how to trust, and let me step back one more notch with that. Christopher Avery, who has been a good mentor to me also um through his program, said that he realized that if everyone said, “Hey, it would be so much better if people would just take responsibility,” and then sometime later realized that people don’t know how. People don’t have a good definition of responsibility. They don’t know what it means to take on responsibility, and then nobody’s ever taught them.
Tim: So, he has created a practice to teach people how to become responsible, and there’s a series of practices involved and you know things to learn, and I learned a lot from it. I think I learned a lot about empathy and about responsibility, self-ownership from that. Well, I think the same thing is true for trust. A lot of people just don’t know how to trust other people. They think that it’s um… Esther Derby said that there’s this weird idea people get that trust is a binary point value. So, I trust you, or I don’t trust you, and that’s all there is.
Tim: And of course, you shouldn’t trust everybody. If it’s a binary you know, “Well, this guy’s my heart surgeon. I need to trust him.” So he can go out with my wife and balance my books and do my taxes, right? “Well, no. No, I don’t think so. I don’t think that’s how this works at all.” Alright? Um so as Esther mentioned, there’s gradients, and it’s contextual. She said, and this is my favorite line of hers, that she trusts her husband with her life, but not with her laundry.
Marcus: That sounds right.
Tim: So it opens up degrees of trust and context to trust. So, a safe relationship, it seems like there is a balance on the trust I’m willing to accept in a context and the trust you’re willing to give me in that context. And now, this becomes tricky. Right? So you trust me too much in an area, then likely you’re going to be disappointed. So, what’s going to be your reaction when you’re disappointed?
Marcus: I’ll trust you less.
Tim: That would be great in fact. Now, if you shut off the trust faucet entirely-
Marcus: Ah, the binary part.
Tim: The binary. If the answer is, “I can’t trust Tim,” then our relationship now is completely broken, which means every time you trust me, it puts me at risk. Every time there’s a chance that you might just be disappointed, I might be dismissed, right? So, there’s a negotiation on trust right? If you’re giving me more trust than I want, I have to say, “Listen, I’m not the guy that you want to give that to. That’s more than I can handle. Maybe if you could assign me a mentor to work with me on this, or if you want to give it to Fred who’s really good at that, or Jane is a wiz. Give it to Jane.” You know that’s a negotiation that works, and now you find out how much I’m willing to accept.
Tim: But then if you are disappointed, back it down a couple notches. Don’t shut it off because what you just did is you found the upper limit. That’s a good thing. That’s data.
Marcus: And I’d like to suggest you found today’s upper limit-
Tim: That’s right.
Marcus: Because that may be different than tomorrow’s upper limit.
Tim: Right, and they’re findable.
Marcus: Something you said..They’re findable. I think what you said… I don’t think I’ve ever said it or had an employee say it to me, and that’s the idea of, “Don’t trust me quite that much,” but just in the way that you phrased it that that becomes um something we can talk about. “I can be honest possibly with the person who wants to trust me with their life,” to use an extreme case. For me to say, “I’m not comfortable with you trusting me that much,” or if you are, what safety… you know “I need a mentor. I need a pair. We need to work in groups. What is a safety we can put in place that we can both agree on?”
Tim: Excellent. Oh I love that. Now, the other side of that is tougher though. What happens if you’re under-trusting somebody?
Marcus: We don’t usually talk about that, do we? Like, “I don’t trust you enough. I’ll just, I’ll behave differently, but I’m probably not going to tell you, generally.”
Tim: So you give me a task, and I complete it perfectly well, and then you give me another one of the same sort, and I complete it perfectly well. You give me another one, I complete it perfectly well. Then I quit because I’m not actually getting to use my skills and talents and to grow here. I’m being treated as an underling, and I’m really quite unhappy with it. If you under-trust me, I can easily meet your expectations, and if you leave me at that level, then I’m going to wander off-board.
Marcus: That’s really interesting because it reminds me of um… I’ve talked to managers and I’ve had an employee, or a few of them, who uh we would give increasingly increasing levels of complexity, projects, grow, grow, grow, and then we would find what we perceive to be an upper limit. But here was our mistake. Instead of saying and I hate saying this because it’s… I just hate admitting it. Instead of saying, “Well, this is currently Bob’s upper limit, so we need to apply training. We need to apply mentorship. We need to build skill. We need to be clear.” We would possibly have just said, “Oh, well, you can’t give that kind of stuff to Bob, and the unspoken word at the end was ever.”
Marcus: And so then Bob would never get that kind of stuff again. He would get those lower, less challenging tasks and would kind of start to be pigeonholed. And in fact, when I go into organizations, maybe you see this too. There seems like there’s always one or two people, and then you say, “Well, why isn’t the hardest work being spread around?” “Oh, we can’t really give it to Bob. He’s got a seat on the bus, but it’s at the very back of the bus,” or something like that. I really wish I hadn’t done that. I wish I’d handled it.
Tim: Yeah, well you know, again, who’s out there teaching you how to trust, right? You know when
Marcus: Well, today, it’s you.
Tim: So you have two human beings you know, and trust is a spectrum of spectra, right? So, now, we have to find all of our different levels, and they’re all temporary, and of course, that fixed mindset,
Marcus: Yeah.
Tim: The darn fixed mindset just keeps coming back.
Marcus: I want to take just a moment and thank my sponsor, GitPrime. GitPrime has sponsored the show not just because they’re fantastic people, but because they really believe that leadership and engineering is about people. It’s about conversations, and GitPrime is a platform that allows you to have better conversations with people. Yes, it has lots of other benefits. You can probably plan better. You can see metrics about individual performance, but let’s just take that one idea about individual performance.
Marcus: Whenever I talk with a GitPrime user, and by the way, lots of my clients are GitPrime users. They always tell me how surprised they were at what was really happening on the team. See, it’s really easy for you as a manager to observe generally how people are working. You can look at PRs. You can look at who’s assigned what tickets. You as the CLM, the software engineering manager, you get a notion for what people are doing, but there’s always these beautiful surprises about who is really performing well and who’s secretly struggling, about who’s the person that’s saving everybody’s bacon through fixing a lot of stuff behind the scenes and who is absolutely doing all the PRs?
Marcus: This kind of data lets you move from looking at people as just, “Well, they’re all engineers, and they’re all kind of doing engineering work,” to seeing exactly where each one of them is strong and has opportunities to grow, and that’s why I love this tool so much. I believe that new and surprising conversations come out of data that when you can sit down with somebody and start to understand and intuit why things are happening, you’re going to create even better quality of exchanges.
Marcus: And by the way, you know here on the show we talk about the fact that leadership is what keeps people connected to their work, and it prevents turnover and keeps them motivated. It’s about the relationship. I like to say that GitPrime not only lets you build better software, it lets you build a better relationship with your team members. Start a free trial today at gitprime.com.
Marcus: It sure does, and that book has been so transformational. That’s Carol Dweck’s book, Mindset, where she talks about the fixed and the growth mindsets. Tim, I feel like maybe we’ve read a few of the same books at least.
Tim: I think we might have somewhere along the line.
Marcus: It’s funny because the longer I live, which continues to move forward in life, um the more I see the fixed mindset showing up in the way that we talk about people. Even if somebody has said, “Well, I recognize that I can change, I think the next evolution of that is recognizing that other people aren’t fixed in their position as well.”
Tim: Right. Esther talks about the mechanistic metaphors we have, you know the well-oiled machine, all the parts that fit together, even hiring for fit.
Marcus: Culture fit, yes.
Tim: And so there’s that sense that there’s this whole of a certain shape, and if we found the person of a certain shape that they would work in that hole, and then we’d be done.
Marcus: In some ways, I’ve been thinking the whole idea of the way we have org charts, roles, responsibilities, like the fact that when an organization goes looking for somebody, they are really looking for somebody, and they’ve really defined the shape of that hole in their own mind. But yet in any given organization I talk to, three months or six months down the road, the people who are doing a job say, “I’m doing so… It doesn’t look anything like my job description.” So, clearly, the edges get really mushy once you’re in there.
Tim: It’s just a strange idea. And so that weird-shaped hole we’re trying to fit somebody into, sometimes that’s just, it’s not even a human-shaped hole. You know we’ve got um… Now, I’ve seen several times where somebody’s had this position, right? And they hire somebody into this position. They’re there for three months, six months, less than a year. And it’s like, “Oh, this is the wrong person for the job. We had to let them go,” and then you bring somebody else into the space, and they do a different part of the job, but they’re not doing the whole thing. And it’s like, “Well, this is also not the right person.”
Tim: After a year or two, it’s like, “Well, we just can’t find people who are good enough to do what we expect from them.”
Marcus: Well, that’s true, and in fact, I’ve noticed that all edges of the whole may not be equally important. For example, if it’s a square, the top part of the square might be… Even though it looks like four equal sides is how we define a square, the really important part is the top third. And so, somebody who can do that and isn’t very good at the other stuff could be very successful. And yet even though we describe all four parts of the square as being equal, they’re actually not.
Marcus: And if we pick somebody who fills a different part of the square, we may not understand why they’re not successful. We might just say, “They weren’t a good fit,” which I hate that phrase.
Tim: Yeah, and what if the hole is actually the size of eight puzzle pieces instead of the size of one puzzle piece? I keep looking, and I can’t find the piece that fits in this hole.
Marcus: Right, and it’s not one piece.
Tim: It’s not one piece, so you get the revolving door, right? You can’t find the person who can do that because there isn’t a one person who can do it.
Marcus: In fact, uh this reminds me of… Maybe you’ve seen these situations where you’ll go into an organization, and there will be somebody who is filling a role, and they will say, “If I ever leave, they’re going to have to hire three people to do this job.” That reminds me of like, “Wow, that management thinks about that as a piece, but the person doing it knows it’s not just one piece.”
Tim: Yeah, yeah, and so you were talking about how a person comes in to do job A, but when they’re there, they’re actually doing job B2, and C7, and D9-
Marcus: Right.
Tim: That they successfully integrated somehow. Probably behavioral competency was very high, and they had some different functional competencies than expected. And what they were able to do is carve out a space that fits them,
Marcus: Mmhmm.
Tim: But they left some other space open that still needs to be filled.
Marcus: Mmhmm.
Tim: And I think that’s not an unusual thing. What we think we’re hiring for may not match what we’re hiring.
Marcus: And so, I think when managers look at the puzzle, the picture of the puzzle of their organization even if they don’t have… This is what I’ve seen. Even if they don’t have like open reqs, or they’re not hiring for a specific role, they’ll almost always say, “I have these unmet needs,” and I think those are the places where people haven’t sort of the seams haven’t come together, but they don’t often times know how to describe them. Maybe they think it’s another person, or maybe they just wish somebody would sort of ooze into that part of the puzzle in a more fluid way.
Tim: I need some more… you know you have um T-shaped people and like I-shaped people. Maybe what we need are amoeba-shaped people that just you know, you pour them into the hole. They fill the space evenly. It’s all great.
Marcus: Wouldn’t that be great, right? Well, and in that kind of an environment, I suppose… Uh what we really are going back to our original topic of safety. What we’re really talking about is how roles define safety because the edges oftentimes we think of, “Well, I’m hired to do this job, and in fact, if we talk to people who are frustrated in their work, sometimes they’re saying, ‘This wasn’t what I hired for,’ or, ‘This isn’t my job, and I have to do it anyway.'” Um and sometimes, maybe people want the ability to morph into other things, but it doesn’t seem safe because they think they’re in a particular shaped hole.
Tim: Yeah, the whole thing with… Job descriptions are weird.
Marcus: And lies, possibly. Maybe lies. I don’t know. Maybe not intentionally.
Tim: So I have this reality hypothesis that I often phrase, um and I tend to say it this way. When our expectations and reality differ, we should probably consider which one of the two is true.
Marcus: I like that.
Tim: So, um you know hiring a person into the wrong-shaped hole or too big of a hole you know, you can do that over and over and over. “Well, my expectations aren’t being met. Reality must be wrong. I should fire somebody,” is probably not the right point of view. It’s probably more like, “Oh, well, I expected this. I’ve gotten that.” That delta, this curiosity space we call it, you know there’s something for me to learn in that, right? And so, now you get some people with a job description, and you know we do an annual… We’d use to do it. We tried it for a little while in our company. We can’t make them work.
Tim: Um you try to set up some kind of an annual goal because you want a performance target, so you can measure the person’s performance against the targets and see-
Marcus: Yeah, well, you know who’s good. I agree with that.
Tim: Right. You’re in the rankings, so I need to know who are the good people because we only want to retain the best people and somehow whether that’s important to measure human beings and as a number, as a metric.
Marcus: As a number that we can feel good. We don’t like to be measured though, but we like to measure.
Tim: Yeah and you know the problem is people don’t dislike being judged. People are afraid of being misjudged and with good reason. If I knew that your judgment of me was going to be accurate and helpful and intended for my good, then I’m like, “Assess me, baby. Come on. Bring it on. Let’s do this.” You know show me what I’m missing because I want to learn. I’m a human being. I am a spectrum of spectra, and I can strengthen in various places, and I can choose not to strengthen some and to strengthen others. So, assess me. Tell me you know what you see. Who am I? What am I to you? What’s the best I can do with you? How can we grow together? I’m excited about that.
Tim: But then it’s like, “You know what? Here’s your job description. Oh, you colored outside the lines.” “Well, dude, I could have told you that on the interview. I don’t… I’m not good at staying inside the lines. That’s not what I’m best at.” You know. “We need to have a relationship where we can change and grow, or you’ve expected something from me that you’re not going to get.” The job description and the annual goals, um the problem is that they tend to expire way sooner than a year. So, we tried to figure out, “Well, this year, I’m going to learn these technologies,” and my next client doesn’t use any of them. “Well, I’m not going to learn any of those. Can I cancel those?”
Tim: “Well, it’s kind of in the annual. You probably should try to… “No, it doesn’t make any sense for me to do that anymore. They’ve expired. That plan was too long-term. I need plans for where I am now. I’m in a new place.”
Marcus: Yeah, yeah, I like that a lot. Um somebody was just telling me today that their company did 360 evaluations, and they were excited to get the feedback from all these different people up and down the chain that they’d work with their peers, and then they said… And they compile all that into numeric scores that gets reported to management. Yeah, and I was like, “That might be the saddest thing I’ve ever heard,” because there’s so much important, rich, valuable information.
Marcus: If you want really people to improve, get them to talk to each other about what they see. So, that idea of a circle of perspectives is absolutely exciting to me, but don’t call me a 2.5, um and then don’t base any money or decisions on it.
Tim: Yeah, I’m not a point value. I’ve never been a point value. Um so, at one time, I was so lucky. This was like a great day for me. Um I was so lucky that I got to have breakfast with Bjarne Stroustrup who’s the guy who invented the C++ programming language. He was on tour. This is when the standard template library was out, so now, “Oh look, we have good containers. I wish I’d have done that to begin with,” he said. Um so, I’m at breakfast, and there’s me, and I was a C++ programmer in a telecommunications company, nothing special, just lucky as heck.
Tim: The inventor of the language I’m using and the third member of our breakfast team was an optimizing compiler writer who is like so much theory in his head and understanding of machine behaviors and programming languages and abstract syntax trees and all the things you couldn’t imagine what all he could do on so many different processors. And so, I’m sitting with these two geniuses, and I’m basically there to pick up the tab, I think, and they’re talking about-
Marcus: And honored to do so.
Tim: So thrilled. I would do it again tomorrow, you know?
Marcus: Absolutely.
Tim: If anybody wants breakfast, you’re going to be in the area, let me know. I’ll buy breakfast for geniuses, so I can listen to you talk. Um so, they were talking about benchmarks, and you know okay, the Whetstone benchmark got this, and the Dhrystone benchmark got this number, and they got this number. And Bjarne Stroustrup said, I’ll never forget, “You know when they study stars, they measure the full spectrum of the star. Every star is stronger in some frequencies and weaker in other frequencies, and when they compare them, they compare the frequency charts, the full spectrum spectra of the stars, and then they understand. I wish we could do that for compilers because one compilers would be better at some things than another, and you could choose the one that’s fit for your purpose.”
Tim: And I went, “Oh, man. Point values suck.” And it was years later that it dawned on me that that’s why so many things don’t work in our software world is because we’re trying to reduce a number from a spectrum. So, a classic example just last year, a consultant was doing an Agile transition. I was in to help with some technical stuff. Sometimes, I do that part of it. Um so, they bring me in. They show me this team room where they have charts for everybody, and they say, “You see this team here? This is our top-performing team, and they’re all juniors.”
Tim: And I looked, and I see that they have this high velocity. This team over here, they’re so overpaid. They’re the most experienced team we have, and look how they’re underperforming, and they had a low velocity. Well, I thought, “That’s a judgment, right?” So, immediately, we judge. There’s a number, and we judge based on the number. These teams are over performing. That’s underperforming. These people aren’t paid as much as those people. There’s an inequity involved. There’s something wrong, an inequality, mistreatment. Oh this is evil.
Tim: So when I took a look, the higher-paid team is all the senior people. They’re spending over 60% of their time solving production issues and guiding juniors in implementation and fixing defects that have been put into the code. They’re the ones keeping the company running. Without them, there would be no revenue stream. So, they’re spending more time protecting the revenue stream than creating new features, whereas the junior team had no such distraction because nobody’s going to call them in on the production problem.
Marcus: So, the senior team was a safety for the junior team.
Tim: And a safety for the organization as a whole,
Marcus: Right.
Tim: But the lack of safety came because they were measuring them both on how many new features they produced per fortnight.
Marcus: And that was the one metric that they were using to say good or bad. I always wondered how many companies have accidentally removed the safety, the thing that was keeping them around in the name of optimizing for something that really didn’t matter, like invisible fairy points.
Tim: Yes, invisible fairy points are classic. Absolutely. Jessica Kerr who by the way is pretty awesome. I don’t know if you’ve talked-
Marcus: She is awesome. She’s been on the show, yeah.
Tim: Oh, lovely. Um she talks about, “You know productivity is nice, and I have somebody who’s a 10X you know person. They produce more stuff than other people produce, and that’s nice, um but if I have one of them on a team of 10 people, it doesn’t really help that much.” Then she said, “Generativity is how much better everyone else is because I’m on their team. So, productivity is good. I might be 10X the worst person on the team. But with generativity, all 10 people are 3X. I can’t beat that by myself with my own productivity,” so you get this idea of glue people.
Tim: When they say, “Never fire the glue person.”
Marcus: Yeah.
Tim: You get teams that only work because there’s one person who’s not producing a lot of their own features. They’re not producing a lot of their own work. They’re not taking on solo assignments as individual contributors. They’re making everyone else successful, and we don’t recognize that.
Marcus: No. I think in this old book Malcolm Gladwell wrote called Tipping Point, he talks about the connectors, these people that oftentimes businesses say, “What do you do here?” And they’re like, “Well, I just sort of, you know I’m not quite sure,” but everybody else says, “They’re super valuable on the team.” Don’t let those people go.
Tim: Yeah. And so, again, you get the you know, “Here’s the reality, and here’s the expectation.” I expected them to produce as many points as the juniors at least. Well, do we go, and which one’s true?
Marcus: Right.
Tim: Well, the truth is that they don’t. Well, it must be because they’re bad. Well, did you go look?
Marcus: Yeah.
Tim: There’s a curiosity space. There’s a story to unfold.
Marcus: I like that, the curiosity space. Tim, this has just been such a pleasure to chat with you about safety, software, people, curiosity. Where can people find you online?
Tim: Oh, I’m very easy to find. I’m highly Google-able. Um so, if you want to search for me, you’ll find me everywhere, but on Twitter. I’m on Twitter as tottinge. It’s like T Ottinger with the R cut off.
Marcus: Okay.
Tim: It’s the old-school eight characters. Um also, you can go to the Agile Otter Blog. It’s agileotter.blogspot.com, but one of the best places to go to is industriallogic.com where you’ll find all of our colleagues and so many people that I’m learning from and enjoying and can grow on, and of course, the Modern Agile. Um there’s a whole community. It’s on Facebook. It’s on Slack. There’s a modernagile.org, which is a nonprofit organization, and I think that a lot of people will find that useful too.
Marcus: Wonderful, Tim. Thank you for being on the show today.
Tim: Hey, I’m so glad to be here.
Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcasts 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.
Speaker 4: This has been a HumblePod production. Stay humble.
You may also like...
