On today’s episode, Ka Mok joins us to talk about how to effectively enter and navigate teams. Ka has been in the industry for four years and is currently a software engineer consultant at Stride Consulting. Working in teams is a reality as a developer and a consultant, which means that the way you enter can set the tone for the entire experience of being in that team. Rather than entering and immediately pointing out issues that need to be fixed, it is best to enter as an observer and build rapport and trust with your team members. Once trust is fostered, changes can be suggested. It is important that trust and rapport continually be built between the person entering the team and those already there, as there is always room for improvement. Rather than competing against one another, it is always important to realize that by virtue of being on a team, there is a common goal that everyone is working towards. This should be remembered when people have suggestions and ideas that are different from yours and disagreements arise. For some tips on how to enter and navigate teams, join us today!
Key Points From This Episode:
Transcript for Episode 119. Efficiently Entering and Navigating Teams with Ka Mok
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea Manhattan. I’m your host, Michael Nunez and today, we have no cohost, we have no producer. They’re travelling somewhere in the globe right now and we’ll be hearing from them soon and when we do, they’ll be back and ready to record, but I’m here, holding the fort, by myself, let’s go.
So, the episode that we’re talking about today is effectively entering and navigating teams. Now, the good news is, I’m not alone here in the room right now. I have a special guest. Today, we have Ka Mok. How’s it going Ka?
[0:00:38.5] KM: I’m good, how are you?
[0:00:39.6] MN: I’m doing all right. Not alone, which is good. Ka, tell us a little bit about yourself?
[0:00:44.2] KM: Yea, my name is Ka. I’ve been working in the industry for three to four years, I’ve entered teams, exit teams and today, I’m here to talk about how to efficiently enter and navigate the software teams that we find ourselves in.
[0:01:00.0] MN: I mean, especially as a consultant, we enter a team, it can be two people, it could be 10 engineers and whatnot and it can be a wide arrange of like amount of people in a team. So, every time you enter a new team, it’s going to be completely different. We’ll talk about the most effective ways to enter and navigate within a team. So, Ka, what do you see or do you have a definition for a team in this particular context?
[0:01:26.5] KM: I think I want to take a step back and look at the team in terms of just a collection of people and having a common goal that they try to strive towards. And I kind of analyze teams and with the lens of systems theory, where you have agents or stakeholders and you have a goal in mind and you have pressures and deliverables.
I want to talk about teams and dead lens.
[0:01:52.7] MN: Okay. We had mentioned, we had used the word efficiently or efficiency. Let’s define that before we actually get started on how do we enter this team and do it efficiently?
[0:02:05.0] KM: If you think about a team, say you’re as team working for some product and your goal is to deliver value to your customers. So, how do you achieve that, it’s up to you. I think efficiently, how I define it is you put in the least amount of effort and you get the most amount of results. That’s efficiency.
[0:02:28.7] MN: Right. Less energy, most results is the most efficient way to do something. We enter a team, like everyone at some point in time whether you’re starting a new job or you’re contracting at a new place, you have to enter the team. What is the first thing that you would want to do or you would tell people to do when you enter the team?
[0:02:51.2] KM: The first thing I would do is to take the old saying, where it’s first impression is important. Ideally you get context of what kind of people that you’ll be working with before you enter. And you want to talk, think about how do I want to present myself? I think in general, you want to be a listener, an observer, a spectator, before you begin exerting your influence.
You want to have people trust you. So, you go in there, you stay quiet, you observe.
[0:03:19.8] MN: Then like, right, because you don’t want to step in day one and start pointing out problems and like figuring out ways to fix things because A, you don’t have the full context of things and B, people may not listen because you’re like the new person. And who are you to come in and make these changes or ask for these changes?
You mentioned like being an observer where you just like, quietly observe the things that are happening around you and then kind of keep a mental note as to what are some things and patterns that you may see and introduce them at a later time.
And when you do that, the amount of – as you’re observing, you’re still building trust with the team, you’re letting them know that you’re an ally, that you’re also here to help. I feel like as a consultant, that’s more difficult. Like, when you’re a new hire at a company, you know, they see you as someone who wants to introduce new changes and that’s fine, but as a consultant, people may feel like you’re there because you want to point out all the bad. But you also need to do this observer stage and kind of look at things and letting them know that hey, “I’m also here, I’m part of the team. I’m also here to help you, us all in this situation that we’re in.”
[0:04:31.7] KM: Yeah, I think it makes sense beyond being a consultant. I think in general; it doesn’t matter. Let’s say you’re a new CEO, you’re being brought in to this company to as they call it, fix things. I don’t think you should even be, even if you’re in the position of power and if you have to authority to do that, you shouldn’t do it. Because I think entering teams is about building relationship and you said, you don’t want to be the guy that’s, ‘yeah, that’s wrong, that’s not good, this is not good enough.” you don’t want to be that Debby Downer kind of guy, right?
[0:05:08.9] MN: On the first day, right? That’s a bit much.
[0:05:12.2] KM: It’s like archetype actually. I think there’s like plenty of articles online talking about this.
[0:05:16.9] MN: Awesome. Yeah, you mentioned first impression is important and you know, just observing as a way of being a part of the team, just like knowing what’s wrong, what can be fixed. So, let’s say we have a new person and Bobby’s been observing for some time and finds a couple of things.
Is there a time like do you have a time limit as to when Bobby can start introducing new changes or is it like based on the team like what would have to happen first before any suggestions may come about?
[0:05:48.7] KM: I think a good way to do this is to first find out what’s important to the team. This goes back to the systems idea. What is the goal here? I think you should know that everyone here is of the prime directive. Everyone’s here to do their best. It might seem like they’re hindering you but everyone is trying. You have that framework in mind, you say, “okay, what is the one thing, one small or big thing that I can recommend that can help us achieve our goals?” Start from there.
And it’s about knowing that you have the social capital with the people that you work with to say these kinds of things. That’s where the trust comes in and that’s where your experience comes in.
[0:06:36.4] MN: Yeah, trust, political capital, I think you mentioned before and experience all like we’ll give you a gauge of when to start doing said suggestions?
[0:06:46.2] KM: So, I think, I want to dig a little more into that how you can know that you have enough trust is, it’s really organic. I think one good measure is that people are willing to come to you about things on their own, if they’re asking for advice. If they’re asking your opinion on things. You not try to give opinion if you’re not being asked.
[0:07:08.2] MN: Right.
[0:07:10.3] KM: And there are times in the software industry where we can do these in the retrospectives. That would be a good place to start. But not too many changes, one thing at a time, and see how it’s received.
[0:07:22.2] MN: Right, I think like the more changes that a person introduces that are successful, the more likely that people would trust that person on the next suggestion that they have. So, it becomes like a snowball of trust that built and compounds.
We spoke about trust and building trust and having trust compound is important. Now that I have all this trust, what could I do with it? Now what?
[0:07:46.4] KM: You have more freedom to make mistakes I would say. You can experiment more, you can put yourself out there more and you can try new things, that is not about just efficiency anymore. It’s about your own happiness as a person, going to welcome, you know your team has to reap back, that they trust that, even if you fail that you’re trying your best.
[0:08:09.0] MN: Right, then the idea of contributing is like fulfilling as a human being? And you have more opportunities to do that when you have the trust there from your team. If you didn’t have trust, what do you think would be the outcome if you wanted to instil change without trust?
[0:08:25.3] KM: Yeah, if you're the archetype, comes into a team and starts scrutinizing people’s way of working, you will have a negative reputation and then what happens is even if you’re the best developer in the world, you will make mistakes eventually.
[0:08:41.1] MN: Not me though. I’m kidding.
[0:08:46.3] KM: Your successes will be downplayed. Let’s say you have a really cool solution, people will recognize it, you won’t really get the full appreciation from it.
[0:08:57.2] MN: Yeah.
[0:08:57.1] KM: And your failures will be magnified because people do not want to help you, they didn’t want to look at you in the positive light.
[0:09:03.7] MN: You’re more likely to be seen in, yeah the fact that you came in and made all these changes and people don’t have the trust or the comfortability to back you up. Now, when you make a mistake, it’s like, “yeah, you see? It’s because Bobby over here wanted to make this change.” And now it’s like this whole big thing.
As you mentioned before, if it would have been positive and you have positive energy and like trust from the team, that mistake would not have been as like, “Bobby made a mistake, it’s fine, we’ll fix it.” That kind of thing. It’s important, you don’t want to work with the person, who has like negative reputation that’s causing all these changes and you also don’t want to be that person because you want to have the support from your team in the first place when you want to make these changes.
[0:09:49.2] KM: Yeah, I think in general it’s just like, you want people to like you. Everything’s much happier and better if people like you work with you.
[0:09:57.6] MN: Right. I think one thing that I do when I joined a team is, I try to identify like a key person that has, that already has the influence of the team and try to get that person’s trust is like something that I find that I do. I think it’s like almost like subconscious, it’s just like in my nature to see like all right, “who has the most rapport with everyone and if I can get a seat at the lunch table with that person, that person’s going to introduce me to everyone. That’s the person that I need to talk to.”
Do you agree? Is that a pattern that you see work for you?
[0:10:32.3] KM: Yeah, that’s a good sign of there’s a person like that on the team. If you can get their buy in, in terms of the way you think and if you can identify how they think, it will be much easier to convince others any ideas that you might have.
[0:10:50.0] MN: Yeah, it’s like, that person doesn’t need to be like a manager or like a high ranking individual, it could be something who with a lot of tenure, it could be someone with a lot of experience, it could be – if it’s the, either the tech lead or like a engineer, who is coming up or who really has been for some time.
It could be a wide range of people and there are different criteria’s that you want to look for when you want to build rapport with someone.
[0:11:16.9] KM: Yeah, I think it depends on the team. A manager might not be the best person to get buy in from. It could be a lead developer that everyone loves to work with because he might be a nice guy, he might be really smart, he might be helping others when they need help.
So, we have to use our own judgment and identify people like that. I think like you said, this is natural human thing to do anyway. But this is just putting more framework into how you think.
[0:11:47.7] MN: We’re hired to build software, but we build software well when we can work with our team very well, I think it’s like the idea.
[0:11:55.4] KM: Yeah, I think a phrase that I like to use is you fail and you succeed as a team, not individually.
[0:12:02.3] MN: I totally agree to that. Whether you’re succeeding or you have failures on the team, that can cause all sorts of internal pressure amongst the team, you know, you’re not hitting your current velocity, it’s been going down and it depends on how the team is like, believes in each other and how they see themselves because if they see themselves very negatively and there’s no trust amongst individuals, that might be just a lot more difficult to deal with than if everyone has a positive energy to say hey, “there was just that one week. We had a lot of bugs, production was down and we’ll turn it around this week kind of thing.”
I think that that trust is important when you are thinking about how to make things better. It all starts with like that rapport and that trust building and political capital, all sorts of stuff.
[0:12:49.9] KM: Yes, so I think if we dig back into external and internal pressures, external pressures are much easier to identify if you have deadlines for the product that you’re trying to hit, if marketing is breathing down your neck and so that is external pressure. Internal pressures require a little bit more observation. Like you said, if things go bad in the retro and people don’t talk about issues, that’s internal pressure, right?
Somewhere along the team, people are afraid to speak up. So, identifying these kinds of patterns can help you identify the stakeholders. I mean what’s going on in this team? Why are people afraid to speak up? Why is the mood damp? And identifying these opportunities, if you go to the person that helps the team solve these kind of problems, of lack of trust within team members, then you’ll be a much more valuable player and you have much more social capital in the future.
[0:13:49.8] MN: All right, so we enter the team. We got trust and political capital. We have identified into it individuals who have a lot of trust within the team already and people like us. Now we have to navigate through the team. Now that you are able to navigate, what could you do with that power?
[0:14:08.9] KM: Well these are – I don’t want to frame it as, “okay, I am here and within a month I have trust.” I don’t want to put it that way. I want to put it more like it is a continuous process. It is like you are hitting a minimum threshold. And then as you keep navigating teams keep working, you are starting to gain more and more social capital. There is like, “oh that guy is the oldest developer or the longest developer in the project.”
That is kind of social capital. I think one thing I like to do I’ve been hit on when entering the teams is to first identify the stakeholders and then just getting coffee, getting lunch as soon as possible. You don’t want to wait a month before you start doing that. I think the sooner the better.
[0:14:53.0] MN: Right, that way because the earlier you do that the faster you can build a rapport with those individuals. All software engineers that I work with love coffee. So definitely shell out the $5 to go out for the coffee for individuals. The company may even allow that to be as part of the budget. So feel free to use that, if not its $5. Like go to a coffee shop, take people out to coffee, people love it. Do you prefer the morning or the afternoon? This is just a side question that I have for you.
[0:15:25.9] KM: No preference.
[0:15:27.8] MN: No preference. Yeah. I find that the afternoon coffee anything around 3:30 I might have some then I don’t sleep, but I still do it anyway. I think it’s important regardless of people’s schedule. I mean you should respect people’s schedule and then go off from there, whether it is in the morning or in the afternoon.
[0:15:45.1] KM: I want to talk about what happens when you’re in an existing team and a new person joins. It could be a manager, it could be a developer, it could be a designer.
[0:15:56.1] MN: Yeah, that was you at one point in time and now someone new is coming in.
[0:15:59.6] KM: So, you have an advantage as in if you’re the person that makes contact, if you are the guy that introduces this person as standup. I’ve had teams where new engineers have joined and no one knows who they are. They’re just a standup and then they feel bad because no one introduced them and you want to be the person that looks out for them. So, this is an opportunity when the new person joins.
[0:16:26.3] MN: We were mentioning before like that was you at one point and so you know how that feels. So when someone new comes in, you want to ease them into the team gracefully so that that person will then have trust in you that you would do that you would look out for them and have their back and then that kind of stuff. And as more people come in and you do that for them, then those people will do that for other new people and then it becomes a positive way. The team becomes more positive for new people to come in the first place.
I think that when we join teams, you often forget that that was once you. Or you are so caught up in the work that you are that you don’t give time to do that and I think that is a great thing to remind people like hey, introduce people into the team, try to make it as nice as possible because it is always you join a team and then you want to forget those times because it is really hard to enter a team.
Or try to build a rapport but helping someone out and navigating them makes it a whole lot easier, it takes a lot less time, take that person out to coffee and tell them the ins and outs of how things work. That way they have trust in you when they need something done and vice-versa, right? Because that person could be a manager and you introduce them to the team and they will definitely appreciate it. People appreciate you looking out for them.
[0:17:47.9] KM: Yeah, I think I will even say that this is probably the most critical point of your relationship with this person. It’s just the beginning sets the tone for everything. If you get the beginning well, everything is easier. If you get it wrong, if you don’t do these kind of things then you have a little harder time.
[0:18:09.0] MN: I think that we should all just remember when we first joined the team and how that felt and figure out ways that we can better enter in team. So that when new people enter our teams that we’re in, we can definitely help them do that. Yeah, identifying individuals, build a rapport with the team, coffee is always good, lunch if you got the money and the budget for it, is always good. People love to eat, people love coffee, it is always good.
You enter the team, you’ve been able to navigate, you have introduced new people to the team, everything is all positive and people enjoy joining this team. Really quick, let us talk about a situation where you may have to expend some political capital, right? Like say, you and the team lead don’t see eye to eye on the way that this new feature should work or should be designed, right? You may have a different output on how it should be designed architecturally versus the tech lead.
What are your thoughts on the conflicts that may arise within the team and how do you navigate through that?
[0:19:15.0] KM: I want to pull back a little bit and don’t think of it as me versus the team lead. Any decisions that you make as a team should be made with everyone’s consensus. The key that I think most people have to recognize is not about being right. Being right is funny to say to a software engineer, it is not about being right. It’s not about being the best design. It is about people knowing that the solution that was developed was with everyone involved and the people’s input were listened to.
That is a very crucial thing to do because let’s say you optimize an algorithm for this design that is a little bit faster and if people hate you for it. Is that really worth it?
[0:19:57.5] MN: That’s true, yes. So, listening to people’s opinions and being courteous to other people’s thoughts in bringing up reasons why you may want to design it a particular way is much better than just making the algorithm work half a millisecond faster, right? Because then everyone is going to look at that piece of code and know that what came from it was like this was a conflict that was a lot more friction than it needed to be.
So are you implying that we should be more careful in giving answers or in clashing with individuals even if you are “right?” It’s hard. Like you mentioned before, it is hard for a software engineer to not choose the right way to do something.
[0:20:43.6] KM: Yeah, so I want to dig into this a little bit. Let’s say you have an opinion and another person has an opinion and they bring it up and you know that they’re not quite accurate. You don’t want to just throw facts at them and say, “no you’re wrong. I am right, here’s why.” And the reason you don’t want to do that is because then they will just say, they’d just think, “oh I’m not as smart as this guy. I can’t challenge him. I can’t have a conversation with him.”
It is especially problematic when the person is right. You don’t want to set yourself up for that pedestal almost, right. Because that is also isolating you from the rest of the team.
[0:21:23.9] MN: When you should be bringing them up together, in a sense.
[0:21:26.6] KM: Right, so for example what I will do instead is put it like a question like, “oh do you really think that this is how it should be, why?” You let them find out why they’re wrong with their own investigation. You don’t just tell them.
[0:21:41.1] MN: Right, rather you tell them “hey, you’re wrong. Here is why.”
[0:21:44.0] KM: Right, this is almost like a poor request. You don’t just say, “this is wrong, you should add more test.” Or this is an efficient way to do things, you ask questions. It is about being like a teacher, right? The teacher asks questions and if the student does not understand then this is the failure of the teacher.
[0:22:02.1] MN: I do have a strategy and it might be kind of the opposite of what was just mentioned. To say that I have an opinion on something and someone just says, “no, we’re not doing that.” I like to then have break up my opinion with articles or things that will show why it would work and if I get two no’s then I would let it go and I really try my best to bring up and have this opinion that I wanted. I don’t like to keep driving it in like, “oh here’s more things. Here’s why I am right.” Whatever.
At that point that I don’t think it’s just an agreement that we were able to do then it’s just like the little battle that we had and I just brush it off because the bigger thing is rapport with individuals at the end of the day. It’s not like, “oh, I found all of these articles. I see why I am right and you are wrong.” Because that is just mean. But I would want for them to take into account information that I have about this particular thing. Whatever happens from there I just roll with the punches.
[0:23:01.8] KM: Yeah, you don’t want to win the battle by losing the war, I guess.
[0:23:05.5] MN: Yeah, exactly because when you do it then you just have a bad time on the team that you have spent so much time trying to build rapport and trust and stuff like that. There’s a lot that goes into just joining a team. It is not like, “oh, I joined the team last week and then I am over it,” right? You work on it every day when you are constantly joining and navigating through the team.
[0:23:26.4] KM: I think eventually you get into a sweet spot where there is a high level of trust. People are cracking jokes all the time in the office, people are happy to be at work, people come up to you and give you positive feedback and when things are wrong, they actually say it, right? These are the kind of Zen moments that I want to reach when I work in a team and not just in software but in general.
[0:23:52.5] MN: Right and I think that is what the conversation that we discussed definitely touches all of those points and gives people an idea on how to do that efficiently. So, Ka, how can people contact you? How would you like for people to contact you?
[0:24:06.5] KM: You can visit my GitHub, github.com/kamok. K-a-m-o-k
[0:24:12.8] MN: K-a-m-o-k.
[0:24:14.7] KM: Yeah and you can contact me. I am happy to chat and have a coffee if you are in the city.
[0:24:19.7] MN: Yeah, if you are in New York City, Ka’s the guy. He’s willing to chat.
[END OF INTERVIEW]
[0:24:23.1] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode. Subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
