Communication 101: Be Clear and Direct

Episode 6

Have you ever wondered why people can’t just be clear and direct? In this episode of the Programming Leadership podcast, we’re going to discuss this problem, identify some possible root causes, and learn how we can be more simple and clear in our communications.

 

Show Notes

• When you become a manager, you may find yourself using jargon without much forethought. Don’t let yourself go there. You’re only puffing yourself up and making your communications less clear.
• In conflict, incongruence tends to occur. This is when our insides don’t match our outsides. As a solution, communicate clearly with your team what you are processing internally. Talk about what you really mean and use simple language. The other person absolutely deserves it.
• When navigating how to break down a work problem for your team, don’t just break it up into chunks for them. Together, try a decomposition exercise where you each sit down to talk about the strategy and ways to decompose the problem, then let them solve it. This allows your team to learn, trust you more and take pride in their work.

Links:

• Sponsor: GitPrime
• Book a group workshop with Marcus!
• Email your questions to marcus@marcusblankenship.com.

Transcript

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

 

Marcus: All right. I’m Marcus, and this is the Programming Leadership podcast. The back of my neck itches like crazy because I just got a haircut, so this is going to be a spicy episode. Have you ever heard the useless, business speak like, “streamline,” “let go,” “open the kimono,” or, “we’re going in a different direction”? Have you ever wondered why people can’t just be clear and direct? Today on the show we’re going to discuss this problem, identify some possible root causes, and learn how we can be more simple and clear in our communications.

 

Marcus: Let me pause and thank today’s sponsor, GitPrime. GitPrime’s platform allows you unprecedented visibility into your development team. For too many years, I’ve had to guess at the status of projects without any real data to make decisions from. Oh, I have tried everything. Story points, velocity, burn down charts, burn up charts. You name it. I’ve tried it. Worse yet, I’ve made the mistake of promising my boss when something would be done only to be disappointed. When I dug into things with my team, I was always surprised between what the charts show and what’s actually happening. Now, it’s not like anyone’s messing up, but things are happening that I have no visibility of, which meant I couldn’t even discuss it with my team. GitPrime changed all that. With GitPrime, you can leverage git level analytics. That’s where the real work is happening. It provides deep insights to help you have better conversations with your engineers and your whole team. See things better, build things faster. Learn more and sign up for a demo at gitprime.com.

 

Marcus: Look, I first heard this kind of talk at Jeld-Wen when I became a manager. No, scratch that. It was before I became a manager, because your managers say it all around you. Not sure why, but this disease actually infects managers worse than programmers, but I’ve noticed a big uptick in programmers talking in this language, and we’ll get to some examples here in just a minute. Over the past five years, I’ve seen this shift, and it’s almost worse when they’re like me and you, like we’re technical leaders because now, we can draw on two areas to be really unclear about, okay?

 

Marcus: So, look, I became a manager at Jeld-Wen, and all of a sudden, I found myself using this kind of crazy talk. It’s like somebody gave me a new dictionary except they didn’t really give it to me. I just started noticing it more. As I was in meetings and other people would use it, of course, I felt like I should use it too. Frankly, I got pretty darn good at it too. When I used that language, other people would just smile and nod. Ugh, like the penguins on Madagascar, that silly movie, where they don’t really understand. They just smile and nod.

 

Marcus: Of course, outside the office, people probably thought I was mentally impaired. They looked at me like I was crazy. I feel like this talk is the secret language of the Managers Club. So you know what? If people looked at me funny, I just smiled and thought, “Oh, you must not be in the club. You’re not that cool,” and I’ll be honest. After I left that big company, I started my own little company and the language it came with it.

 

Marcus: Yeah, it wasn’t long before everyone at the company was using it, and we all sounded like idiots. Now, look, you might be thinking that HR has a corner on all this lingo with talking about letting people go rather than just firing them, but you’d be wrong. Software engineering has plenty of it including classics like atomic, moving parts, bells and whistles, repurposing, leverage, bandwidth, top-down, and my new favorite, optics. If you’re not using the word optics regularly, good. I don’t think you should be.

 

Marcus: Look, in my opinion, this language does two things, and both are really detrimental, okay? First, it puffs us up. It makes us feel important as though we’re real business people, real professionals. I’ll be honest. I don’t have a college degree of any kind, but I could sound like a freaking MBA when I sound like this. Okay, at least I think I sound like an MBA. To others in the Managers Club, maybe I do. Maybe it shows I’m in there. But to my wife and maybe my mother and my kids, I sound like a pretentious guy or even worse. Turns out I sound pretty pretentious to everybody else, I think, when I talk like this.

 

Marcus: Now, psychologists call this impression management, and this is the process in which we attempt to influence the perceptions of other people about people, objects or events. For some reason, managers are particularly susceptible to this disease. I think it’s because we’re among other managers we need to impress. At least that’s what it was for me.

 

Marcus: Second, and I’ll be honest, I think this is actually worse. I believe you can disagree and leave a comment, but I believe this language is intended to make communications less clear, not more clear. Yeah, if you want to say something without really saying it, business speak is perfect for you. So why in the world would we want to talk in a way that makes communications less clear? Isn’t talking about software hard enough already? I believe that building software, like any complicated endeavor, often leads people into conflict with each other, and whenever you find conflict, you’ll find people acting incongruently.

 

Marcus: Whoa. New word alert. Ready? Get your dictionary. Grab a pen. Incongruent. Of course, that’s a math term. You know what that is. Two triangles are congruent if they have all the same angles and all that good stuff. Congruent means to think about it as going in the same direction like two lines or to be in harmony, to be integrated. So, if something is congruent, it is whole, and it is harmonious. If it’s incongruent, it’s not.

 

Marcus: Let me just give you an example, okay? This has happened to me many times. I’m going to have changed the name in this example though. So, let’s imagine this. Joe, your senior programmer, proposes a brand new design for the turbulator module that the team is starting on. He diagrams his idea. He presents it to the team. The team is a little surprised. They assumed the turbulator would use a design shared by many of the other components of the system.

 

Marcus: When they ask questions or in business speak, they push back on Joe, no actual pushing occurred. He goes off about scalability, maintainability, innovation, and he claims that this design embraces the ilities of good software architecture and best practices. He talks about how his idea better represents the team’s core values. The team, confused, nods their heads, and stops asking questions. That night over dinner, they probably told their friends that Joe is introducing change for change sake.

 

Marcus: So what’s really going on here? Frankly, it’s hard to tell. We could guess at why Joe was doing what he was doing, why he was using this language. But it seems that the language came into play when the, quote-unquote, “pushback,” the conflict occurred, and I see a lot of leaders doing this when they don’t want to answer questions about something, because I feel like they’re trying to proactively prevent conflict or questions.

 

Marcus: By using this kind of business speaks silliness language, what they’re really doing is they’re really hiding a lot of the intentions. They’re hiding their rationale, and all that hiding comes through, but it sends the signal, “Look, don’t ask too many questions. Also, of course, maybe if you don’t get it, you don’t belong here.” Have you ever felt that way? If you didn’t get a phrase or a concept or an idea that maybe people were looking at you like, “Maybe you’re not part of this club. Maybe this isn’t the right place for you. Did we make a mistake in letting you into our secret club?” I’ve certainly felt that way.

 

Marcus: Okay, so instead of Joe verbalizing that he exceeds the conflict, and he has some valid reasons for doing it, and he wants to enter into a rational discussion. He incongruently puts up his defenses, and he uses this kind of business language. Now, again, where does incongruence come in here? To any sane person outside the room, Joe and the team are not in conflict because they’re just having a simple conversation, and people are drinking coffee and generally ignoring each other.

 

Marcus: Yet, this is what conflict looks like on technical teams far too often. Our insides feel stressed out. Our stomachs hurt. Our face flushes. You know what? It’s funny. Our bodies know when we’re in conflict, but we force our mouths to use like, Technical words or these business words, so that we pretend we’re not acknowledging the conflict we feel. This is incongruence when our insides don’t match our outsides. Have you ever noticed this? You’ve been talking with somebody. You’re in a discussion. Maybe you’re just giving them some feedback, and all of a sudden, it looks like… Well, darn it. If their words don’t reflect it, but their tone of voice, their posture, their flush cheeks, their pupils, maybe their stance reflects that they’re having some emotions. But their words are so mechanical and precise. You get confused. You’re like, “Wait. I’m getting two signals here.” When you see that whether it’s about somebody who’s got unhappy insides or very happy insides, and as crazy as it is, I’ve seen people who would not reveal when their insides were ecstatic about something. They just kept it very business, and they talked about things having to be top shelf.

 

Marcus: We need to be on the same page, and not only is it dull, but it’s a way of lying, okay? So, I just want to point… This is my core point here. Acting incongruently is something that you can spot, and not only is it not healthy for you, but the reality is it’s faking it, and other people know it. This is my hypothesis. When the team looked at Joe talking about the ilities, the scalability, the maintainability, and the core values, they immediately knew what was happening.

 

Marcus: Oh, Joe, and then because they saw Joe was hiding, this is the part they didn’t know about. They didn’t know why Joe was hiding, so they made up their own reason. I just saw this exact situation at last week’s workshop, okay? We had a participant. A team was asked to build a four-foot tall house of cards. Well, all the teams were. One of the teams failed. They could not get their design of house of cards to four-feet tall. The other three teams succeeded.

 

Marcus: The team that failed looked pretty discouraged, and at lunch I saw Jim, one of the people on the team, sitting alone, sketching and bending cards and really intently, like thinking about, “What would we do different?” It wasn’t hypothetical. They were going to build now an eight-foot-high house of cards. So, this person, Jim… Well, he was really stressed out about it. Now, let’s just reset the whole situation. Four teams. Three teams made it. One team did not, and everybody after the time limit was up, could walk around, and we had a beautiful discussion about architecture, about teamwork, about problem solving, about ideas, and everybody looked at each other’s house of cards.

 

Marcus: So, Jim has three examples of other designs that work, and there are no rules that say he can’t copy or at least steal best practices from… There’s one of those words, right? Best practices. That he can’t take some of those ideas about what worked. But Jim is sitting there, and he is rolling the cards in a way… I’ve done this exercise many, many times. I’ve never ever seen anybody roll the cards quite this way, and he’s trying to come up with this very complicated thing.

 

Marcus: So I drop by, Jim was alone at lunch, and I said, “Hey, Jim. Hey, what you working on? It looks like you’re thinking about the next phase of the project.” He says, “Yeah, yeah. I think I got this. I think we can get seven-and-a-half inches of vertical rise with this card in this design, and that is about 60% more than anybody else can.” I said, “Okay, Jim. That’s great. Now, last time you failed. I’m just curious why wouldn’t you use one of the other designs that were so simple that everybody else used the same type of design?”

 

Marcus: Jim looked to me, and I could see he just paused for a minute, and he said, “Well, that goes against our core values,” and I said, “Okay. All right, Jim. Well, I look forward to seeing what you’re doing,” and I let him be. As I was walking away, I thought, “Core values? We didn’t talk about core values. That team had existed as a team for less than 45 minutes. They had no time to talk about core values.” I think what Jim was actually saying was I have an internal need to be innovative, to be seen as different. Those are my core values, my values as I understand them, and probably what I learned when I was a little kid is I’m smart and unique and innovative.

 

Marcus: So therefore, Jim, this is my hypothesis. This is the meaning I made from Jim’s comment because I didn’t ask him about it. Jim was then using some of this business speak about core values essentially to mask what was really happening within him, which was I could see it on his face. He was spending his lunch alone working on a new design. It was stressful for him. That’s part of the reason these workshops are so beautiful. It’s because they’re stressful over silly things. We can laugh, and at the end of the day, we recognize that there’s nothing on the line when your house of cards falls. Well, nothing except your own ego maybe.

 

Marcus: So, in this case, I immediately saw that Jim was trying to build something. He had gone away from his team. He wasn’t involving them. He was viewing himself I think as a unique kind of person. Then when I asked about it, he… It was fine. If he had said, “I like to be innovative, and design matters to me. Beauty and aesthetics really matter to me.” I think if Jim had said that, he would have been more congruent, and I think he would have felt better.

 

Marcus: It actually turns out we were debriefing with another instructor later, and that person said to me, “Jim has a background in visual design,” and I just smacked my head like, “Oh,” to Jim how it looks, and the fact that it’s unique and elegant and visually appealing is as important to him as the stated goal of stacking cards four-foot tall from the floor or eventually eight-foot tall.

 

Marcus: Well, you might wonder how the whole thing turned out that the short answer is, is that as Jim had grabbed one other person on the team and was painstakingly and extremely time-consumingly, which isn’t a word, trying to roll cards and slot them together that the pace was very slow, and the whole design was extremely unstable. The team actually split in half, and another group built the bottom five-and-a-half feet of the eight-foot structure using a traditional method that all the other teams were using, and that Jim’s piece, which got to about two-and-a-half feet, was carefully set on top. There’s no way Jim’s design would have gone to eight feet, but he got to add that piece, and the team applauded.

 

Marcus: So what am I really saying here? I’m saying that maybe there’s an opportunity for you to be a little bit more congruent with your insides and your outsides, and one step towards that is noticing when you’re feeling that conflict, that flushing of cheeks, and that heart beating a little bit more, and then you find yourself using this business speak.

 

Marcus: Maybe you’re trying to impress someone. Maybe you’re trying to communicate something that you’re not. Like if I try and sound like an MBA, I’m doing that because I feel conflict, impostor syndrome, stress, pressure, whatever. But also maybe sometimes I’m acting incongruently because I don’t want to face the conflict with other people. We do see this a lot in HR. HR is the conflict experts, right? We don’t fire people. We let them go. We go in another direction. We take a different approach.

 

Marcus: There’s lots of words for firing people. But at the end of the day, those people don’t work here anymore. So, I will tell you one final lesson about congruence and language. When I worked at Jeld-Wen, there was a president of the company named Barry, and one time Barry told me this. He said, “I used to be a plant manager, and I had a very good employee that worked for me except he was regularly late for his shift, and this employee’s name was Bob. Bob would come in, and he would come in late, which threw off the whole plant schedule. Manufacturing, you got to be there on time, ready to rock, okay?”

 

Marcus: So, Barry had to pull Bob aside and say, “Bob, you’re good at this job, but you’re coming in late, and that doesn’t work for me.” Bob said, “Okay, I got it.” Bob was late two days later. Barry calls him into his office. “Bob, I’ve got to tell you. You were late again today, and that’s not working for me. We’re going to have to go in a different direction.” “Okay, Barry. I got it. I got it.” Three days later, Bob’s late again.

 

Marcus: Barry calls him in. “Bob, I really don’t know what to do here. I’ve tried to get… We just are not on the same page about that, and that’s a problem. I don’t know how to solve it.” Bob said, “Okay, okay.” Four days later, Bob comes in late. Barry calls him in and says, “Bob, I’m sorry to say this, but I have to let you go.” Bob goes, “Okay, all right. Wait, what?” Barry said, “Well, Bob, you’re fired for tardiness. I’ve had five conversations with you.”

 

Marcus: Bob says, “That’s what we were talking about? All of that?” Of course, Barry and I laughed because it’s a little ironic, but poor Bob because Bob didn’t understand, and Barry said to me, “Nothing is more important in a hard conversation than to be completely direct.” He said, “There was something,” he said, “in future conversations I learned to tell people. If you are late again, I will fire you.” He said that produced a shock and then an appreciation, and it was perfectly clear what was expected.

 

Marcus: So, Barry learned that people get hurt when we’re incongruent. They don’t understand what we’re really saying. Bob was in danger of losing his job and did not understand it until it was too late, and he had already lost it. So, if you’ve got people on your team that you’ve been giving hints to about, “I’m not sure we’re aligned. Maybe we’re not on the same page.” If you’re one thinking, “Maybe this person isn’t working out.” I want you the next time you talk to them or maybe to have a new conversation where you are completely congruent.

 

Marcus: You use congruent words with what your inside and your outside are the same. Talk about what you really mean and use simple language. The other person absolutely deserves it. Oh, and when you see other people, which probably in the next hour, if you’re listening to this, and you’re on your way to work, you’re going to hear some people using that language. Call them on it. Say, “Could you explain that more clearly? What’s behind that? What’s the reasoning for that?”

 

Marcus: Be the one in the room who’s willing to say, like Columbo, “I might be a little bit dull here, but could you explain how this design could contribute to our core values or maybe just remind me which core values support changing the way the turbulator is built?” Be the person in the room to not just let things go by, but to just ask those questions. It will be a little uncomfortable, but everyone will benefit from it because you’ll actually start communicating better.

 

Marcus: All right. We’ll see you next time, and we will take your questions. So, if you’ve got questions, mail them to marcus@marcusblankenship.com. I look forward to hearing them, and we’re going to do a question now.

 

Marcus: All right, let’s take a question from the audience. David writes in. “My number one biggest work problem right now is creating a strategy and technical vision for the teams, and breaking it down into chunks that can be handled.” That sounds vaguely familiar, David. Thanks for writing in. Let me see what I can say about this. First of all, this isn’t a little bit of a red flag what you said to me. You’ve got this big strategy and vision. I get that. I’ve had that. I’ve built that. Very common, right?

 

Marcus: But whenever I sit down to break it down into chunks that the team can handle, I find myself designing software, to be frank. I’m just trying to use… That’s the word that comes to mind. I end up doing this decomposition of the big thing into many small things. Now, of course, I get all fired up in my work here, so I begin to become attached to the way I decompose things, which is probably fine, except that’s not actually the way the team probably will build it as I’m not the one building it.

 

Marcus: So let me see if this sounds familiar. You have a big idea. I’m remembering a particular client project in this case. I was actually a domain expert, and shockingly enough that the client needed some software built, so I sat down, and I did an architecture, a technical vision, and I decomposed it. I said, “We’re not going to go all the way to stories, but let’s go to epics and modules. Let’s do some UX, some wire framing. We’ll understand the major parts of the systems, how many servers, the big picture.” Stuff, right?

 

Marcus: Well, I’m the boss, and I used to be a programmer, and that’s what I love to do. So, not only is it maybe my job, but more importantly it’s my right. This is actually what I thought, like I’m the best to do this, so I stayed late many nights, many nights. So finally I brought it to the team, and I had what I thought was a pretty beautiful decomposition of a big thing into a small thing. The team did not care for that, and here’s what they didn’t care for in my opinion. They wanted to talk and look and understand the big thing.

 

Marcus: I had spent so much time with the big thing that I only really wanted to focus on the little things, and I can remember one particular engineer, Thomas, who was like, “Okay, so let me understand the goals again of the project.” I was like, “Okay, look, Thomas. I get it, like goals are important. The why. Start with why. But I’ve already broken it down. The why is the client wants it, and here’s how we’re going to do it because I broke it down,” and he looked at me, and I don’t think he spoke again the whole rest of the meeting, which isn’t very surprising.

 

Marcus: Now, I handed my beautiful designs over as business owners often would do, and then I frankly moved on. I had other things to do, and I felt like I’d really contributed to the team. I’d help them out. I put the project on the right path. But when I checked back with that team a mere week later, nothing looked like when I was there. They had gone back to some of the original ideas, and re-decomposed it. And of course, it was actually much better. They had maybe made a few assumptions, but generally, the five people on the team did a better job than I did, decomposing it, breaking it down.

 

Marcus: I was thinking about this like an assembly line. It wasn’t intentional. I never knew about Taylorism and Ford’s assembly line at least not too much at the time, but I was taking the whole car and saying, “Oh, this is the whole car we want, and now let’s decompose it into all these parts. Let’s create stations.” That’s what Ford did with the car, right? If you’re familiar with that story, it’s worth understanding. If you google for Taylorism and Henry Ford. In fact, the Henry Ford Museum has a whole bunch of letters online. It’s really pretty sad.

 

Marcus: So the way Henry Ford built cars before the assembly line was he would get maybe a dozen craftsmen of different overlapping disciplines together. They would swarm around a car until it was perfect. They would put the engine in. They’d do the wiring, the electrical, the seats, the steering wheel, the tires. I don’t even know all the other parts of a car. But these mechanics would put everything in, and they would make sure that this thing started and ran like a top, and the tolerances were great. The quality was amazing.

 

Marcus: They would do one car per day, but they did a very good job, and they were very happy doing it. So, Ford comes in, and with the help of, like I don’t know, lots of other smart people with those kind of material studies, splits up the work, installs this assembly line, which runs at a constant rate and then stops at a given time for at each station. For example, however long Henry Ford thought it should take to put on four lug nuts, that’s how long it stopped at one station maybe.

 

Marcus: And of course, he started building cars and getting between 20 and 40 cars a day, and the workers unsurprisingly hated this. They wrote in the letters, to him, begging him to go back to the old way, saying, “The quality isn’t there. I hate this job. I used to love working for you. I felt like I was part of something bigger, and now I stand in this spot, and I tighten lug nuts, and I hate my job, and it’s causing me back aches, anxiety, intestinal problems, leg problems.”

 

Marcus: If they had all these health issues related probably to standing on concrete, but also to just doing the same, repetitive… And of course, now, today, we get repetitive stress injury over and over and over again. So, David, it could be that the best thing to do here is to actually sit down with your team. Get them together or at least key members, and I really advocate for everybody, and sit down and talk about the strategy and technical vision. Then start experimenting with different decompositions. Let the team do it.

 

Marcus: Don’t tell the team, “Okay, now, you need to decompose it perfectly.” Instead say, “We’re going to have three hours to decompose this, and this will be… We’re just going to do it so we really get the feel of the project, right? Then we’re going to throw it away.” It’s a prototypical decomposition. It’s a decomposition exercise. I guarantee that their act of decomposing it will not only reveal new ideas.

 

Marcus: If you have them do this two or three times, they will learn and come up and learn to evaluate, learn to feel more in control, learn that you trust them, and they’re going to be so much happier and excited and enthusiastic and driven internally. You’re not going to have to drive or force the solution on them. It’s going to be their solution. They’re going to be excited, and you can be there to ensure it meets the requirements and help them understand the pros and cons.

 

Marcus: So, I think that technical leaders would do well to use their teams much more often in decomposition. I finally learned this. I got a lot better results. Don’t make the same mistakes I did and go into your ivory tower and decompose it and say, “All right. Here are the stone tablets of architecture.” That will just cause stress, headaches, repetitive stress injury, and back aches, and really frustrate your team.

 

Marcus: All right. Hey, email your questions to marcus@marcusblankenship.com, and we’ll take them. In each show, we’ll do a question at the end. In the meantime, this has been the Programming Leadership podcast. Thank you for listening, and please share this and give us up votes and all kinds of love.

 

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

 

Announcer: This has been a HumblePod Production. Stay humble.