How do you give technical feedback and direction without inflicting unwanted help? or change direction without introducing bad feelings?
In Episode 27, Edwin Mak (@edwinthinks on Twitter) shares how to be an effective tech lead. We talk about how to ask the right questions from the right mindset to elicit questions, what to listen for in your conversations, how to recover from failure, and more.
Show references:
- https://diaperbase.org/
- https://rubyforgood.org/
- http://www.lingolive.com/
Transcript
JENNIFER: Welcome to Storytime with Managers, a podcast by Cohere.
Hi, I’m Jennifer Tu, and I’m here with Edwin Mak to talk about hands-on technical leadership. Edwin, can you tell us a little about yourself?
EDWIN: Sure. I’m a software developer. I currently work at Lingo Live, which is a communications company, and we really focus on trying to improve communication in the workplace. And a lot of our clients are engineers, actually.
JENNIFER: Great. Thank you. Recently, you led a team of, I think, eight or ten volunteers over this weekend at a remote event to work on software for a nonprofit. And one thing I heard from everyone who was on that team was that you were really, really supportive of them and you were always jumping in and pairing and just always helpful. And everyone was just giving this glowing praise about how hands-on you were and how much you were able to unblock them and get them doing what they wanted to be doing. And so today, I really want to learn how you did it. Can we start by sort of describing for everyone what your day at this event looked like, what you were doing?
EDWIN: So, the event kind of worked out like this. At the beginning, I got to meet everyone that was interested in working on the project. I was set to lead the project for the Diaper Base and Partner Project. And after I got to get introduced with everybody, I organized and tried to figure out how to explain what sort of work we want to get done. One of the key things that I think is important is organization, which is one of my, I guess like, tricks or things [inaudible] uses. You really want to organize what it is that you’re trying to do and getting that alignment really early on is important. So on the day that we were going to start, that was a Saturday, I sat down with everybody and inside the Zoom meeting because it was remote, I shared with them the projects that we were aiming to do, what was the outcome. And I even went and shared my screen and went through the pain points that we’re trying to solve. By that way, I can show the people that I’m working with that what it is that we’re trying to get done here and let it be open. Be very specific about this is the outcome that we’re looking for. How you get there can be different from what I’m saying right now. And I admit that I don’t really know. This is really the outcome that we’re looking for. How can we get there?
And then more on the logistics about the actual programming, I had each of the developers. We were actually lucky. There were eight volunteers, not including myself. I was able to pair each one off into their own little chat rooms where they compared together and work on the problem. Periodically, I would jump into each one of them and ask how they’re doing, how they’re thinking about the problem and trying to actively listen about where they are at. Once I figure that out, I can assist a little bit and then I jump onto the next one, see how things are, and keep jumping around. And throughout each one, I always say, “If you have any issues or any questions, feel free to reach me,” which there’s another chat room that they could just jump in and ask me any question.
JENNIFER: This is really helpful. I have a question about this, which is I feel like when many of us ask if someone needs help, the answer is, “No, I’ve got it,” or, “I’m okay.” And I’m wondering, what did you do or how did you ask your questions that was encouraging people to open up and tell you what they were confused about?
EDWIN: So I think there’s a couple of things about asking, “Do you need help?” I think ‘do you need help’ is sort of a difficult question to answer. And I think this is partly because we generally don’t like being vulnerable. We’re all very smart people. And admitting that you need help seems a little difficult. And even myself, asking for help seems difficult.
I think a really good way to kind of break that is first show your vulnerability, lean into it, say, “I don’t really know what I’m talking about here,” maybe sometimes. And one thing I found really helpful was just ask questions. Instead of asking, “Do you need help?” Ask, “So, how are you thinking about this? Oh, I see what you’re doing there.” And repeat sort of what they’re thinking and saying, “Did I get that right? Oh, so you’re thinking about connecting this with this? Did I get that right?” And so, less becomes I’m asking whether or not they have a lapse in their information or they have confusion. It’s more of I’m just trying to understand where they’re coming at.
JENNIFER: Yeah, that makes sense. So switch out of your own ‘I am the expert mode’ and into a ‘I’m here trying to learn with you’ kind of a mode.
EDWIN: Exactly. I think that’s a really healthy mindset to have as a software developer. In our industry, things always get changed. And there are so many things to learn. It’s just easier to say, “I don’t know,” and keep that as kind of your baseline. I think that makes every conversation a lot easier and asking for help becomes a lot easier too.
JENNIFER: One thing I’m wondering is when we approach with this collaborative ‘I’m not the expert. I’m here to learn with you’ mindset, if that conversation that results out of coming in with that kind of a mindset, if that conversation is enough to answer the questions indirectly and doesn’t force anyone to say, “Hey, I don’t know what’s going on here,” or if you have to dig in a little bit more and ask and draw out more questions explicitly.
EDWIN: That’s a good question. This is where I think active listening is a really key element here. I think sometimes people that you are helping in having that collaborative experience with, they can sometimes have misunderstandings at some point. And they might come to you with one question, but really, there’s like maybe three underlying questions that you should answer. And you really by listening to hearing them explain themselves, do you get to that point. And I found it pretty successful in being able to get those questions out. Whether I can answer those questions and actually know the technical answer to some of these questions is sometimes, sometimes no. And I think that’s okay.
JENNIFER: How do you get those questions to come out? Let’s say, I don’t know if you’ve got a good example you can walk us through.
To kind of get some of these things out, I generally ask, let’s say, for example, these two are working on fixing up a controller and they’re trying to display some information on a page. I first keep asking more questions like, “So you put this line here, can you tell me what this line is for?” “Oh, I see what you’re trying to do here. But what about this thing?” And it becomes more of like a collaborative question and answer and the back and forth, more of a conversation than a mentor-mentee like relationship.
JENNIFER: Every answer that you’re giving me is giving me even more questions to think about. And one question I’m having now is, how can you tell when you should keep up the active listening and the coaxing out conversation and when you’re inflicting unwanted help?
EDWIN: Good question. I think a part of active listening is knowing that you’re also listening to yourself if you’re talking a little too much or overwhelming the person you’re talking to. So you can get into a dangerous situation giving unwanted help when you forgot about, not forget, but lose sight of what the outcome is. If, say, someone came in and asked about the controller and fixing the controller and then you go and talk about, I don’t know, something in-depth about how Rails is built, that’s a little unwanted. So, one advice that I give is keep track of what your outcome is and stay focused there. If there are lapses in maybe the understanding of the person you’re working with, you can write them down and then bring them up later. There’s no reason to bring it up now. I think that’s really important because you can easily get overwhelmed in software and you really don’t want to do that.
JENNIFER: That’s really helpful. I feel like this is the second time you’ve brought up outcomes where in this case, your outcome is whatever the people you’re trying to help, their desired outcome is. And earlier, you had also talked about sharing with everyone who was on your new team what outcomes you were looking for out of the weekend. And I’m wondering, do you have any advice for how to be thinking about outcomes or how to be adjusting your outcomes? For example, going into the weekend, you might be able to do more planning. But going into talking with a pair, you might not be able to establish your outcome right away. Any advice?
EDWIN: One thing I like to think about in terms of outcome is this is what you’re supposed to be delivering to the stakeholder or whoever hired you to do some work. I think in terms of kind of like how software developers generally function, from my experience, is we get really tangled up in the implementation detail. We fall in love with it and we don’t want to let it go. So, maybe I came into the Ruby for Good with my own implementation details of how to do everything. And if someone has a contradictory or different approach, I have to be ready to let go of that.
One way that I found really helpful was I’m going to imagine I’m not even a software developer at all. I have never touched a line of code in my life. What does the solution, what does the output, like future look like to me? Whether it’s written in any language or how it’s implemented, what does that look like? And that’s kind of like where I start looking at things. I think that opens things up for a higher collaboration. Your people that you’re working with can now have their own inputs on how to achieve an outcome, because let’s face it, maybe I don’t have the best idea of things. I just have some experiences that I think you should follow these things, but don’t fall in love with your implementation details. Remember, you’re serving your customer or your stakeholder. And I think going in there like that is going to be the most beneficial.
JENNIFER: How do you know when you need to keep track of the outcome and not be swerved off too much? What if the people you’re trying to help are really deep into the implementation and you can tell that they’re focusing on the wrong things and it’s not going to be a healthier outcome for the code base or the results that you’re looking for, for the stakeholder?
EDWIN: They’re really interesting questions, and I think this is where it shines having that experience as a software developer and you have more experience in a code base. Let’s say, for example, you see that the people you’re working with is introducing these changes that you think will harm the code base in some form or fashion. I think just being very clear about that. In this case, I would be very clear and say, “There are these things and we’ve made these decisions for these reasons. I highly suggest you do it this way.” I think that generally works as long as you’re clear and you’re not kind of beating around the bush about something that you want to happen. So, being clear and concise is really important here.
JENNIFER: I like the idea of being really clear and also sharing the historical context for why you might want to pick one pattern over another pattern. Are there other things that you can do to make sure that people feel good about having picked the wrong thing or feel good about their ability to contribute?
EDWIN: Yeah, I think it’s very important to highlight, even though like, say, their implementation detail was not perfect or was not going to be committed eventually into the master code base. I think focusing on the positive things that they did is going to be really important here. Say they wrote something incorrectly, just say, “I see what you’re doing here. I think you were on the right track. But so and so here.” This way, it feels less of your reprimanding them for making a mistake and more of, “Hey, this is a learning experience. I like what you did here. Let me see if I can help you a little bit more.” Does that make sense?
JENNIFER: That does. So you want to really focus on the good outcomes and then give a path forward to how they can keep making good contributions.
EDWIN: Exactly. I think keeping your conversation open, speaking in open terms is the best way possible that I found. Being open for saying like, “Things are great,” instead of saying things like, “That was bad. Don’t do that.” That kind of conversation doesn’t really lead to great places.
JENNIFER: Yeah. I want to dig in just a little bit here. How do you have a conversation where you call out what is good and steer away from something that’s going to be high impact on your code base? Let’s say someone’s putting in some n+1 queries or something. How do you show the good but also stop the harmful from entering into the code base at the same time?
EDWIN: This is my strategy. I think you first need to start off with the positives. Be very open about that you saw what they’re trying to do, that they were on the right track, that they put in great effort into it. And then when you go there, you kind of say, “I see this line and it kind of makes me think that it can be improved in this way.” And whether that be the n+1 query, you can say, “I think it’s better this way.” And then you could, depending on how long it can take, you can explain what n+1 query is. Hopefully after that conversation, the person you’re working with understands, “Whoa! n+1 queries, they’re pretty dangerous. I know how to fix them now.”
But then usually when you go from, like, positive and then make a change, that usually leads to a really great learning outcome. And I think the key point is try to stay as positive as possible with your words like improving, say ‘improve’ instead of saying ‘less bad’. Say ‘more efficient’, kind of like those words.
JENNIFER: Yes. Make sure that your language is focused on the positive.
EDWIN: Exactly. Since I work with a communications company, I learn a lot about how words can elicit emotional responses. And not all emotional responses are bad, but there are ones that can kind of like get that Imposter Syndrome coming up. If you hear someone saying, “This is wrong,” it kind of like causes the conversation to not lead to anything productive.
JENNIFER: That’s really interesting. To switch tracks for a moment, logistically, how long were you spending with each pair? And how did you know how long that should be?
EDWIN: It generally depends on kind of like the engagement levels and how warranted my advice is at that given time. So if you’re noticing that after you’ve given advice and they’re not really in the mood for receiving information – and that’s totally fine – and they’re feeling overloaded, then you kind of like back off and not spend so much time. But I think I’d spend around five to 10 minutes kind of like working through things. Maybe less, maybe more, depending on the engagement level.
JENNIFER: Yeah. Are there any signs that you’re looking for around engagement that tell you, “Okay, time to wrap it up,” or these people want a little bit more help?
EDWIN: I think people are generally really expressive when they want more information and they ask. You can sort of notice when people are, how would you say, “Thanks, Edwin. That’s enough for me.”
JENNIFER: [Chuckles] Yeah, I guess that would be a pretty clear point.
EDWIN: “Thanks a lot. I really like what you’re saying, but I actually want to get back to work right now.” I think you notice it. So there’s different modes. I think there’s the text communication one. Since I work remotely, it’s mostly that. And then there’s the video chat one. Usually, people are like, “Uh-huh, uh-huh.” And you’ve been talking for a majority of the time, then that means the engagement level is not right. So, if you’re talking like 75% of the time and no one else is talking, I think that might be a sign. Not always. You might be talking just a little too much. That’s for me.
JENNIFER: What do you do when you realize you’ve made a mistake. Like maybe you realized you’ve been talking 75% of the time and you’re inflicting help. What do you do so that way, people can feel good about it without making them be like, now they have to make you feel better because you feel like you’ve been a jerk.
EDWIN: Oh, I think there’s pretty benign ways to do it and say, “Oh, I’ve been talking for some time. Let me know if you have any questions and feel free to reach out to me.” I mean, you can pretty much leave gracefully.
JENNIFER: I really like this and I like how it’s concise and it’s straight to the point. It acknowledges what you did, and it doesn’t ask for comfort or absolution. It’s just, “Hey, I did this. I’m going to stop doing this now.”
EDWIN: Yep. If you don’t display any negativity towards yourself, then I think you keep a pretty positive environment there. So as long as you’re not reprimanding yourself, don’t take yourself too seriously. Then I think people feel more comfortable reaching out to you anyways.
JENNIFER: Well, I really, really like this of you’re not being negative to anyone, including yourself.
EDWIN: Absolutely. I mean, there’s too many things to be negative about in life. You should just try your best to be positive to almost everyone that you’re talking to, including yourself, which actually is probably the hardest sometimes for some people, including myself. Be less hard on yourself and just take a deep breath saying you just did the best you can and just walk away from it and just move on.
JENNIFER: Edwin, this has been super helpful. Do you have any final words of advice for our listeners?
EDWIN: I think one of the most important things software developers or anyone working in technical or complex fields such as ours, there is an element of communication that is so important, that’s much more important than I originally thought when I first started programming. When I first started programming, I was all about performance. The best language, the coolest, I don’t know, infrastructure that you can use. But I found that you get the most success and you become the happiest developer when you could communicate effectively with others. You can lean in that vulnerability and say, “I don’t know how to do something,” and that’s okay. And learning how to communicate with yourself, meaning don’t be negative to yourself, kind of fend off that Imposter Syndrome is going to make you have a really healthy relationship with yourself. And I believe that also gives a healthy relationship to everyone else you work with, including the people that disagree with you on ideas.
JENNIFER: That’s great. Edwin, if people want to continue the conversation, what’s the best way for them to reach out to you?
EDWIN: You can send an email to me at [email protected] and just mention about this podcast and I’ll be very happy to talk with you about anything.
JENNIFER: Awesome. And is your project Diaper Base looking for more contributors?
EDWIN: Always. There’s plenty of work to be done. Feel free to go to the repository. Take a look at an issue. See if anyone else is working on it. And if not, go and start working in there. It’s a great way to practice your Ruby on Rails skills while also doing something positive.
JENNIFER: All right. Thanks so much, Edwin.
EDWIN: You’re welcome.
JENNIFER: Thanks for listening to Storytime with Managers by Cohere. I’m Jennifer Tu. Our theme music is by Kevin MacLeod, and we are edited by Mandy Moore and the Dev Rep’s crew.
If you like this episode, please think about leaving us a review on your favorite podcast listening platform. This can make a really big difference in helping other people find and start listening to Storytime with Managers. Thanks so much.
