Welcome back to the Rabbit Hole, the definitive developers podcast. Today on the show we'll be talking about cross team collaboration, understanding why it hurts and why you should do it in the first place. Often times developers will be working on a certain client project or show up at a software engineering shop and suddenly a sense of competition kicks in. The “us versus them” mentality takes over, whether it’s engineers versus product, or designers versus engineers, or dev versus ops, you name it! When in reality, working together and collaborating across teams is a much more effective approach to finding a solution to a problem or simply creating the product that the whole team actually wants to make. Many times the problem is simply bigger than the individual sectors, and clearly needs collaboration in order to be solved. So in today’s episode we are diving into why it is that cross team collaboration can seem hard and why the competitive mindset seems to dominate when it’s clearly not the best option. You do not want to miss this episode, so keep listening to hear more!
Key Points From This Episode:
Transcript for Episode 109. Cross Team Collaboration
[0:00:01.5] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsey, Manhattan. I’m your host, Michael Nunez. Our co-host today –
[0:00:09.6] DA: David Anderson.
[0:00:10.4] MN: Our producer –
[0:00:11.2] WJ: William Jefferies.
[0:00:13.0] MN: Today, we'll be talking about cross team collaboration. Why does it hurt and why you should do it in the first place. It seems often times, people would be placed with certain clients or you show up at a software engineering shop and suddenly us versus them, engineers versus product, or designers versus engineers, or some versus thing.
[0:00:37.1] WJ: Engineers versus other engineers. Dev versus Ops.
[0:00:40.4] MN: Dev versus Ops, all these things happen. When in reality, you should all join together and kumbaya, fix all the stuff that you need to do and to make the product you want to make.
[0:00:52.1] DA: Sometimes you got a problem that’s bigger than one team. It affects a lot of people and it's like, “Well, this isn't my problem. That's not your problem.” It like sucks for everybody, but how do you bring people together and solve that?
[0:01:11.0] MN: We're going to dive into just why is it difficult, because I feel like that’s just easy to start. Let's talk about some of those things. Why is it hard to collaborate? Why do people show up and just have a us versus them mentality?
[0:01:24.9] DA: I've got things to do.
[0:01:26.4] WJ: There is like an in-grouping, out-grouping phenomenon. People naturally tend to develop an in-group. They look around for the people who are similar, or for the people that they have the most contact with and that becomes your in-group. Then the way that people – this is just human psychology. It comes from the way that we evolved. You need to develop a trusted group that you can rely on for support. The best way to do that is to have an out-group, which is everybody else, all the other teams, if you're structured that way.
[0:01:54.6] MN: Right, William mentioned the word trust, that I think that that's a huge part of that. Some people don't trust others as you mentioned. That has been the reason for our survival till this very day is who you trust, who you don't trust, is that person should be part of the group or not? Like that whole bit.
[0:02:14.7] DA: Yeah, but maybe we should get a little bit more concrete about it. Where would that come into play? Say you have a team, maybe you have an infrastructure team that's separate from your actual team, the team that's building a product day-to-day. There's some pain that the product team is feeling about the infrastructure, but everything's working fine. The lights are on and maybe the infrastructure team is like, “I’m, good. I don't need to change or anything.”
[0:02:46.3] WJ: “I have this new feature. It's got to go out. It works on my machine. I don't understand why we play it, it doesn't work?”
[0:02:52.7] DA: Right, and it’s like, “It’s not our problem.”
[0:02:54.7] WJ: This is, ops needs to fix this.
[0:02:56.8] MN: Yeah. That definitely becomes, “Eh, not my problem.”
[0:02:59.2] WJ: “They won't get me access. I don't have access to the server, I can't debug it. It’s their fault.”
[0:03:05.2] DA: Right. That’s the us-versus-them mentality. Like, “Oh, well that's an ops thing. That's not a me thing.” But ops, they're not going to do it.
[0:03:13.8] MN: They got things to do, right? I think, one of the things that ends up happening, trust is one of them, but when you're split up in those teams and you're given assignments that needs to get done, you have to worry about the things that you need to get done. You have Bobby over here saying that he has a feature that needs to be out right now, but if that's not on my sprint board, then I could care less about Bobby. I'm going to finish what I need to do on this side.
[0:03:41.6] WJ: I’ve got to keep this site up and running. Every time that they introduce one of these stupid new features, the site goes down. It’s because they write bad code. If they would just write quality code, then we wouldn't have problems shipping. Then I don't know, I think what's most important here is that we just keep the site stable. So if the developers don't get to ship code, then they don't get to ship code.
[0:04:01.6] MN: But then how do you get the feature? You’re making it us versus them right now.
[0:04:04.3] WJ: I don’t care about the features. I’m an ops. I care about site stability.
[0:04:10.2] MN: Yeah, but you need to have a site that's stable for things that are new. You have to be able to release new features.
[0:04:18.2] WJ: I see where you’re going with this. See, that's not a priority for my team, that's priority for the company.
[0:04:25.2] MN: Yes. That's it, right? It's not just what you have on your board, but what's best – what's the best interest for the company?
[0:04:31.9] WJ: How do we get people to break out of that in-group mindset, where they're just thinking about the success of their team and start to think about the success of the team of teams?
[0:04:43.3] DA: Yeah. I mean yeah, you’ve got to get the right people in the room. You’ve got to get everybody together, which can be hard. The right people might be really busy. They might have a lot on their plate. They have the things to do. Asking them to come through for this other new initiative may be like just another meeting that they have to go to, or like another thing they have to deal with.
[0:05:09.9] MN: Right, keeping engineers away from the keyboard is not a good start for collaborating and sitting in meetings. Try to choose your meeting time very, very carefully, because the more that they're away from the keyboard, the less likely they're able to collaborate with other individuals in the work. That's one of the problems. You have to go to this meeting, “Oh, this thing broke. Let's all group up and discuss all these things that has happened and why,” and that people aren't able to collaborate because they're too busy discussing about what happened, rather than finding solutions as to what happened.
[0:05:41.6] DA: Yeah. I guess, that was just another problem. That's not really how you do it. That was a question you asked.
[0:05:47.7] WJ: Are there other problems?
[0:05:49.0] MN: One that I do think, even the idea of having, bringing people to the room, I feel the workspace of the office is important and I think a lot of the times when you're – when you have the mindset of “I need to get this done”, you can find yourself just putting on headphones and just knocking out those Jira tickets, or Trello tickets, or Clubhouse tickets, whatever ticketing system you prefer. Or physical boards; shout out to those who use physical boards.
[0:06:18.1] DA: 3M post-its.
[0:06:19.0] MN: There you go.
[0:06:20.0] WJ: Shout out to 3M, man.
[0:06:23.3] DA: What a company. What a company.
[0:06:25.7] MN: If your workspace doesn't allow you to be interruptible to help other people in collaboration, then you're not even setting the organization up to collaborate in the first place. You know, you scare people away when you have – when the individual has headphones on, because you don't want to disturb them. How do you collaborate with that person whom could be very important into fixing and collaborating on a particular feature?
[0:06:49.2] DA: How do we fix this? Sounds like the root of it is like people have too much on their plate. There's trade-offs, right? If we do the one, thing then you can't do another thing. If we ship the features, then some kind of ops priority has to fall off of the plate for a moment to help out with that. You might really need to have some help from the big people in the room, like the influencers in the organization, the CTO, or teammates.
[0:07:19.3] WJ: So long as we have these us versus them teams, it's going to be a zero-sum game. If my team wins, then your team loses.
[0:07:26.2] DA: Right. Yeah, that's true. It's just the general cultural mentality and incentives that are there.
[0:07:32.7] WJ: The book Team of Teams does a good job of explaining how to do this, how to solve this problem. It's by General Stanley McChrystal that’s talking about how the United States military had to evolve in order to combat a new type of enemy when they started fighting essentially distributed teams. Because previously most of military history it's been armies matched up against each other and they’re very hierarchical.
[0:07:58.1] DA: Just lining up in a row.
[0:07:59.6] WJ: But in this instance, it was really very much an organically evolved organization that didn't have a central command of any kind. So you couldn't try and take out a top leader. In fact, every time they took out somebody that they thought was one of the top leaders, that person became unimportant and was immediately replaced and they felt it. It was like, they couldn't attack the enemy the same way that they used to attack traditional enemies. So they started copying some of the structure, or like some of the organizational techniques that these terrorist organizations had naturally evolved, and it ended up proving really effective.
[0:08:36.2] MN: That's interesting. I never thought about that military aspect of teams and cooperation. I was just thinking about agile software development.
[0:08:46.6] WJ: Well, what was really interesting to me about reading the book was that a lot of the problems were very similar. We were talking about that conflict between Dev and Eng, or Dev and Ops, or the conflict between product and engineering. In the book, McChrystal talks about the conflict between the Navy and the Army, the conflict between the Air Force. All these different departments within the military, all these different organizations within the military they also have these same conflicts.
So like the FBI is not sharing information with the CIA, is not sharing information with whoever. What they started doing was cross collaboration, cross team collaboration. They had to break down the silos in order to get people talking in a way that allowed them to properly combat organizations that had evolved with a very high degree of collaboration and communication.
[0:09:38.7] MN: You mentioned earlier, to do that, one of the ways was to have an individual from one organization be a part of a team with the rest of another organization.
[0:09:49.3] WJ: Yeah, absolutely. Embedding. You have this problem where all of the army guys hated the Navy guys. So when they were doing drills, they wanted for the army team to do well and for the Navy team to do badly. What they did was they took one guy from the Navy team and they put him on the army team.
[0:10:08.3] DA: Oh, man. Setting him up for failure.
[0:10:11.0] WJ: Yeah. I mean, it’s definitely rough in the beginning. Got all over the worst jobs.
[0:10:15.8] DA: Yeah, getting pants. Oh, man.
[0:10:18.4] WJ: Eventually, that team ended up in a situation where they needed to communicate with the Navy. They had somebody on their team who they knew well and trusted. The leadership had chosen this guy particularly for his resilience.
[0:10:35.6] MN: In the face of pantsing. Yes.
[0:10:38.6] WJ: So he had held up well. Then when the time came for him to act as a conduit, he was extremely effective at it and then the team really valued him. It started to break down the us-versus-them mentality, because now it's not army guys versus Navy guys. It's army guys needing Joe and those other Navy guys. There's Joe, he's a face for the organization, it’s somebody you can relate to.
[0:11:03.1] DA: Yeah. Let's break it down and bring it back to agile software engineering. Your Navy guy, or your army could be or your product team. They’re on the ground, they're fighting things. Your Navy guy who's getting pants all the time, that could be the ops team. I like that idea, just to build empathy with the team to have people with different skill sets and specialties understanding each other, rather than throwing things over the wall.
[0:11:38.1] WJ: Yeah, they took it a step further and they also did entirely cross-functional teams. You'd have a team and one guy would be from the Navy and another guy from the army and another guy from the Air Force and another guy from the Marines or whatever. There wasn't a dominant group. Then all those people bonded and then they formed an in-group and a team, but made up of people from organizations that previously they had low trust with.
Then even after they finished their mission and moved on to another team, they still remembered that person, they still had that point of contact. Later on when they needed another organization, things were easier.
[0:12:14.6] MN: It's like when you have an engineer, a UX designer, a product person and a DevOps person all in one team try to build out this one feature.
[0:12:24.7] WJ: It's an it's a cross-functional team. Oh, my God. Where have I heard this before? Oh, right this podcast.
[0:12:30.0] DA: Yeah, yeah. There is really great documentation too on Spotify's site on their approach for cross-functional teams. I think we talked about this before in past episodes, but they have their like famous graphic where they have all the different slices of their organization at different levels and they have the cross-functional team is the primary unit that is there and getting shit done. Like you’re saying, you have the product UX designer and people are used to those teams shifting over time and it may not always be the same group of people. You have mixing and getting more empathy for different people and different skill sets.
[0:13:14.8] MN: Yeah, cause if you're angry at the situation with the infrastructure or deployment or whatnot, you can actually talk to someone about why that situation exists, rather than just like, “Oh, deployment is broken again. I can't get this feature out because the Ops people don't know what they’re doing.” But like if you had Bobby Ops on your team and have a discussion with him as to why these things can't happen, first off you're not going to be really rude to him because you've worked with him already and you trust Bobby Ops.
When you when you ask Bobby Ops like, “Hey, what's going on?” Bobby Ops could give you a response that would make sense and figure out wait, like, “Oh okay, well all right, I feel bad for yelling at the whole Ops team, because you explained to me what went wrong.” That's kind of what happened. I worked at a team like that where it was an engineering team and we had a DevOps person that was assigned to our team and would work with us, but then had initiatives, like the DevOps also had their own initiatives. It was just really interesting to ask him for – ask him questions about it and he was our point person for the Ops situation, which was really, really cool. Being able to collaborate with someone and know what's happening is a lot – then you know and then you – you do feel empathetic about what's going on.
[0:14:39.4] WJ: Yeah, I think that's the spirit of DevOps. The whole idea is that Dev and Ops should be constantly collaborating. I think that the word DevOps has been co-opted and has now become a term that refers to a set of tools that were developed around the same time as the DevOps movement.
[0:14:59.8] MN: Yeah, according to my tattoos, we did an episode on DevOps with Brian Guthrie, episode number 47.
[0:15:04.9] WJ: That was an excellent episode. We covered this very topic. DevOps is most successful when developers and ops people work together in order to solve these problems. It is your responsibility as a developer to make it work on production, not just on your machine. It is your responsibility as an ops engineer to make sure that this feature can be deployed and works in production.
[0:15:30.6] DA: Yeah, and being able to see the pain that's happening and have a way to get that feedback loop quick around the organization.
[0:15:39.6] WJ: Pair with it, pair with each other. Cross-team pairing.
[0:15:44.2] DA: In the end, you’re going to have more knowledge sharing. People are getting more comfortable with the broader set of the stack. People will know what the infrastructure is and share that knowledge with each other.
[0:15:53.8] WJ: We can take that DevOps philosophy and we can apply it to other areas. You can do the same thing with product. You can do the same thing with QA.
[0:16:00.9] DA: Pairing what the UX designer is, I think, the most fun.
[0:16:05.2] WJ: Because they work so fast.
[0:16:06.4] DA: Yeah, it's great. It’s like, “Oh, yeah. Just change this a little, move this here.” Boom, boom, boom. Done. Ship. It’s great.
[0:16:13.9] MN: I had a lot of fun. Surprisingly a lot of [inaudible 0:16:15.6].
[0:16:16.3] DA: I did like to be as like, I think the UX designers also get them a satisfaction out of seeing the thing that they thought about completed.
[0:16:25.5] MN: Yeah.
[0:16:25.3] DA: The left half and the right half of the brain.
[0:16:28.4] MN: Yeah. Looking at this Spotify chart, one of the words that I saw as I was scrolling through that image, if you get a chance to open that, that image is 22,000 by 22,000. You zoom, and it’s crazy. I scrolled in through one of them, I think William have mentioned it before, but you have to figure – you have to put your ego aside and realize that if you have a us versus them mentality, at the end of the day, the person who loses is not just the other team, but it is the company. You and your team have to drop the ego a bit and realize that you have to work together to get this product built for the organization. I think when egos are not at play, that's when the collaboration is amazing.
[0:17:17.9] DA: Yeah, definitely.
[0:17:18.2] MN: What are some of the strategies that you may know to increase cross team collaboration?
[0:17:26.0] DA: Yeah, so in the same vein of talking about team structure, you might have a problem that is really challenging and meets a very specific people, but is not for a short time. One thing you could do is try to form a tiger team, which was a team of experts, very specific and diverse experience and knowledge, bring them together for a short time and have them solve that problem, and then go back to their normal organization. Just keeping that idea that a team can be a flexible thing.
[0:18:02.9] MN: Oh, so you find individuals that may not be in the same team, but they have a particular set of skills that they can all – and together can solve this one problem and then they'll disband right after, if necessary.
[0:18:17.3] DA: Yeah, somebody used the metaphor, like the heist team, or the Oceans Eleven’s team, where you got the driver.
[0:18:25.5] MN: Hacker man.
[0:18:26.7] DA: The charmer, the hacker man. Exactly.
[0:18:28.5] MN: Does anyone of us know why it's called the tiger team?
[0:18:30.8] WJ: I can Google it real quick. Oh, the metaphor of the tiger comes from the power and agility of the teams and their ability to pounce into action.
[0:18:38.5] DA: Oh, dang.
[0:18:40.2] WJ: There are no limits to their size, reasons, or purpose parameters.
[0:18:43.5] Da: That sounds like a tiger. No limits to their size, reasons or purpose. It’s just a fucking tiger.
[0:18:51.9] MN: Yeah, exactly. That's why they called the tiger team. Crush you like tiger. I don’t know. Tigers are pretty fierce animals and I imagine that that's the perfect animal to describe this team of the best of the best to solve this problem, and then disband once it's over.
[0:19:11.2] WJ: Disappear back into the woods.
[0:19:12.9] MN: Right. Yeah. Right into the forest, or wherever tigers hang out. I don't know where tigers hang out.
[0:19:18.7] WJ: Forest sounds right. That sounds right. I’d buy that. Jungle? Jungle.
[0:19:23.1] MN: Yeah, the jungle. It is the jungle. Yes, I think it's the jungle.
[0:19:26.7] WJ: I think there was a book about that.
[0:19:29.9] MN: This guy.
[0:19:32.3] WJ: I mean, while we're talking about ways of promoting cross team collaboration, I think team rotations is another effective strategy.
[0:19:38.3] MN: Why? I mean, I think the idea of – I mean, if you asked me that, I would think even though we've spoken about it before in time about the joining and storming and when you start after the storming aspect, you start delivering all the features effectively, I mean, there is some –
[0:19:55.7] WJ: Forming, storming, norming, performing?
[0:19:57.5] MN: Yeah, I think there is – I think there is something in constantly – not constantly being in the storming situation, but when you get to hash out certain problems and gain trust with an individual, that's when the work, or the features shine. The more you do that, the more you exercise the ability to gain trust with other individuals, the more likely you're able to work with other individuals, whoever that is.
[0:20:22.8] WJ: You take those relationships with you to the next team that you're on. Then when you need somebody from accounting after you've done your rotation in accounting, you know who to talk to. You sympathize with their problems when you create problems for accounting.
[0:20:36.3] MN: Yeah. Rotating teams is definitely a way to increase cross team collaboration.
[0:20:41.1] WJ: Yeah, don't put me on accounting. How do you make sure that the incentives are aligned in your organization for different teams, so that they're encouraged to collaborate with each other?
[0:20:51.7] DA: Yeah, that's true. I guess, no matter how nice of an environment you're building, or the idea of a cross-functional team that you'd have, if the guy on your team, your ops guy, or your UX guy, or your product guy has vastly different incentives from what you have as an engineer, then you're not going to make progress that you want to do. If you want things to work properly and get people to come together, you want a good same goal for the whole team.
For the product team, or for a team that's developing a product that includes engineers and product people, you'd want the goal of getting the features in front of the users. Not just merging it to master. If my goal as an engineer is to merge code to master, then that may not be aligned with the true goal of making customers happy, or increasing revenue, or whatever. Because I can merge code to master all day and if it's not actually in front of the user, then I feel great, but the organization doesn't benefit.
If the designer’s goal is just to make some pretty mock-ups and throw that over the wall, then that's not going to help either. That has to be making the experience of the user better and actually getting in front of people. I guess more broadly, for something like a large engineering initiative, or what have you, you need to have people higher up who can clear the table of the small things in order to make room for the larger things. So like making sure that you're not on – you don't have three projects that you're trying to work on at once and not getting any of them done properly. Making sure there's one thing that you're doing and that you're focused on it really well, which can be really hard.
Is there any other way to increase collaboration without something as drastic as the team rotation?
[0:22:54.3] WJ: I think that it's the responsibility of leadership to create a good environment for collaboration. I think that there is an older approach to management, where you sort of play chess master and you think of your employees as pieces on a board for you to move around and you were the brain, you are the one in control, you are the one who is going to capture the king. I think that that strategy just isn't effective for modern organizations. Things just move too quickly, we have access to too much information and one person cannot effectively make decisions for teams anymore. It's got to be done in a distributed way.
I think leaders need to stop thinking of their organizations as chess boards and they need to start thinking of them more as gardens. This is a garden that you are tending. Your job is to make it a fertile place for things to grow.
[0:23:50.1] MN: Right. Yeah, kind of like the philosophy of design of workspaces for a place like Pixar, where they would encourage people to go on a long walk to get to the break room, or the bathroom, or whatever. On a walk, you're going to walk past all these people that you just happen to want to talk to, or you may have something in common with, or you haven't seen in a while, just to keep things kind of churning.
[0:24:15.8] WJ: I miss you Steve Jobs.
[END OF EPISODE]
[0:24:19.8] 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 just like you find their way into The Rabbit Hole. 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.
Links and Resources:
