Cross-Team Communication

About this Episode

Cross-team communication is one of the biggest challenges in software development, and the latest episode of the Acima Development Podcast dives deep into why it’s so difficult—and how teams can improve. Host Mike kicks things off with a humorous but insightful story about botching his son’s haircut, using it as a metaphor for what happens when people act alone instead of seeking input from others. The panel, featuring experts from different departments and organizations under the same parent company, shares real-world experiences of miscommunication, siloed teams, and the consequences of not aligning on tools, expectations, and processes. The takeaway? When teams don’t collaborate effectively, things go sideways—fast.

One of the key topics discussed is how different teams use different communication styles and tools, often leading to misunderstandings. Some prefer instant messaging, while others rely on email or ticketing systems, creating friction that slows down progress. The panelists agree that social capital—trust built over time—is crucial for overcoming these obstacles. Successful cross-team collaboration often comes from learning the hard way, through repeated trial and error. They emphasize the importance of setting clear expectations early, aligning documentation processes, and making an intentional effort to break down silos. Without this effort, teams risk wasting time, missing deadlines, and struggling with misalignment between business and engineering goals.

So, what’s the solution? The panel suggests several best practices, including embedding engineers into other teams temporarily to build rapport and understanding, structuring projects around clear milestones, and ensuring leadership actively supports collaboration. They stress that no matter how well-designed a system is, success ultimately depends on human connection and clear communication. Whether working in small teams or across an entire organization, the key is to acknowledge the real cost of collaboration upfront and commit to the effort required to make it work. By embracing transparency, proactive planning, and direct engagement, companies can turn cross-team dysfunction into a productive, high-functioning environment.

Transcript:

MIKE:  Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today. With me, I've got a great panel, and it's going to be real. I'm going to go a little bit deeper into the introductions than I sometimes have because it's going to matter for this discussion.

First of all, we got Kyle with us from the DevOps team. We've got Dylan from Rent-A-Center, and it's like a sister business, I guess you might call it, you know, we're different lines of business, same parent company. And it's great. We're going to want to do more of this. Our parent company is Upbound, and we'd like to get more participation from across Upbound so we get diversity of opinions.

So, Dylan is with us from the Rent-A-Center side. So, it's great having Dylan. I'm probably going to ask him a lot of questions. We'll get to the topic in a minute, and you'll know why [chuckles]. We've got Molina from application support. We've got Ramses and Dave, who work with lease origination. We've got Eddy who works with our partners, merchants. And we've got Will, Will Archer, who works for an unnamed third-party [laughs] retailer.

WILL: Technically, I’m an independent consultant, but I work for a large retailer.

MIKE: And he’s with us, as he usually is as he usually is [chuckles]. And that’s the group we’ve got today. And I’m going to start, as I like to do, with a story, a story of...in this case, it’s personal humiliation [laughs]. So, a couple of weeks ago, my four-year-old...and I can tell a lot of stories about my four-year-old because four-year-olds provide lots of opportunities for stories. Well, he decided --

DAVID: Content generators.

MIKE: They are. He decided he was going to cut his own hair [laughs], and he did, got a big chunk out of the front of his hair. But it was probably still going to be salvageable, you know, I pulled out the clippers and trimmed around the sides, and it was okay, you know, it was okay. It wasn’t great, but it was okay. And I was talking to my wife about it, and we were working together on this endeavor, this creative endeavor [laughs] of trying to fix the disaster he’d made of his hair.

And we looked at it, and we were like, “You know, it’s okay, but it’s not great [laughs]. We’ve got to do something here.” And my wife suggested, “Well, maybe it should be shorter on top. We need to do something.” And I’m like, “Yeah, you’re right,” then we kind of left it. We kind of left it. Something came up. We got busy. And later that day or the next day, I was trimming my own hair [laughs]. And those of you who haven't seen me, I don't really have hair. So, when I say that, I mean I take off the few scraps that are left around the side so it doesn't look like I'm faking it [laughs] and trim my beard.

I was doing that and in walks my four-year-old. And I've already got the clippers out, and then I said, “Oh, well do you want me to trim your hair?” And see what I did there? I didn't go and ask anybody. I thought, you know what, I'm just going to do this myself. This will be just fine, right? So, I put the comb that you put on the clippers to, you know, make it longer, the one that I usually use for my beard, number four for the longest part, then I use, like, a number two. None of this is important, unless you...but if any of [inaudible 03:40] clippers, you know what I'm talking about.

So, I put all this together, and I started trimming, and I started trimming just a little bit. And I thought, wow, that's a lot shorter than I thought it was going to be [laughs]. And I had a moment there to try to rescue what I had done, and I didn't [laughs]. I didn't. I didn't bring in the team, didn't bring in my wife to say, you know, “Hey, what do you think I should do here” Didn't bring her in initially. I just thought, hey, the situation's here. I'm just going to do something about it, and I just went for it. And I finished, and it wasn't good. In fact, it was terrible [laughs]. It was terrible.

And my wife sees it, and she's like...frankly, she cried [laughs]. It was that bad. I felt so bad. I felt so bad. And that was entirely my fault. There were several places where I could have fixed this problem, and I didn't. If I had brought her in to communicate upfront before I did anything at all, she would have probably given me good feedback. If I had started and saw that there was a problem and communicated, I would have gotten good feedback. But no, I just went ahead alone. I thought, I can do this, and boy was I wrong. Luckily, it's been growing out some, and she came in and fixed it some, and it's better [laughs]. It's okay.

WILL: [inaudible 05:05] give him a Mohawk. Like, a mohawk it always sounds sort of plausibly on purpose.

MIKE: Yeah, it's close. It's almost a mohawk. It’s kind of a mohawk-ish sort of look with a bit of a pointing back. It's growing out. It doesn't look so bad anymore. There's recovery. It was a bad incident all around, and a lot of it is my fault, which is my story of personal humiliation to say, you know, maybe you should involve other people on the team, people on other teams, early and well in your communication process before you do something that's hard to fix. And we're going to talk about cross-team communication today and all of the error cases in that and how to make it better.

That's why this panel is such a great one. We've got people across lines of business. We’ve got people who work in different business, right? And we've got people from various different teams that have to work together in order to talk about this recurring, crucial problem that we have in engineering. And in our pre-call, we talked a lot about this that it’s...this is a [inaudible 06:11] problem, probably in software engineering, and it's not a technical problem. It is a human problem, and it's universal. There is the problem statement [laughs].

And I'm sure you all have some stories about problems that you've run into like this in software, and problems, suggestions, as well as, you know, some things in between, problems, suggestions, and just ideas, right? I'm going to stop talking and let somebody else talk for a little bit and take things in their own direction. So, what are y'all's thoughts?

WILL: You know, for me, I think the most interesting thing, I think, cross-team dysfunction is almost the norm. I think that's almost the default. And so, I'm a lot more interested in hearing about stories when things went well, when things went right. What did that look like? What did that feel like? How were those successes set up? To see if there's through lines and threads that we can sort of, you know, take and put in our back pocket and maybe save for a rainy day, because it's only a matter of time before we're going to have to get some teams together and come up with a good solution.

MIKE: Well said. I've got some suggestions there, but I'm not going to jump in yet.

EDDY: I think it's just important to be honest about what broke and what worked. I think a lot of us like to add sugar saying, “Oh yeah, we met the deadline, you know, it was handed in at the time that we were expected to. There were some bumps, but it's fine. It ended up working.” And that's cool, but I think a lot of the times being able to reflect and do a postmortem and just really be honest, you know, like, what went wrong, how not to replicate that, I think is a really good step.

WILL: Did I misunderstand the question? Are we talking about incident reports, or are we talking about cross-team collaborations that went good? I mean, I'm maybe asking for case studies of, you know, this project and these two teams got together, and it went well, and this is how and maybe why.

MIKE: Yeah, you know, you're right. I think we're talking about cross-team collaboration. I think that Eddy would suggest [chuckles]...well, maybe there is no such thing as a -- [laughter]

DYLAN: I almost have to agree with Eddy here that the best teams for cross-team collaboration often have a long trail of failures behind them, and they've learned to work well together through that.

KYLE: I've got a bit of an example for this. As my organization, we kind of merged together to the greater organization. We both standardly used different tools for communication, we'll go with that, different chat communication tools. And I think this is where a lot of issues come in is people always have preferences on how they use their specific tools. Each tool will breed a different culture. And that was one thing that I wasn't understanding when I was going in on my project with communicating with the other portion of my team over at RAC.

Finally, I sat down with one of the RAC individuals, and I was just like, “Hey, I keep pinging you. I keep pinging your team. I'm not getting any response. What am I doing wrong?” And we had to communicate to say, “Oh, well, we don't use the chat client that way. We use it this way, and that's why we're not seeing any of your communication.” And it wasn't until we had that direct one-on-one communication that I learned how they normally communicate. And I feel like that's how you kind of have to go is one side or the other has to kind of pivot to figure out, like, how does the communication have to happen, and who can pivot, and maybe both sides need to pivot. But who needs to pivot so that that communication channel can stay open?

DYLAN: Absolutely. That's not only with text communications or email communications as well. If two teams are sharing process documents between each other, they may have thought they agreed on some process. And one team says, “Okay, we'll put it in our shared drive for our Confluence,” and the other organization does not use Confluence at all.

KYLE: Oh yeah.

DYLAN: They don't have the same document in the same place, and they don't know what the process is later on.

WILL: Oh, brutal. Man, people from the business side keep on trying to make Teams happen. Teams is never going to happen [laughter]. No one's going to use Teams. It's never going to happen. But they keep on just coming in. They're just like, let’s put...Slack. Why are we paying for two? We get Teams for free.

MIKE: [laughs]

WILL: Don't do it.

MIKE: It's true, and there's a cultural...we should probably do a whole separate podcast on communicating with the business side [laughs] because that cultural divide is deep and vast [chuckles] and hard to bridge.

KYLE: Even the culture of communicating by email that's another one that it’s...engineers, I feel like, and maybe I’m wrong here, but engineers, I feel like, they've developed a culture of communicating over tools like Slack, or even Teams, or Google, even. And there are other lines of the business that prefer email. For engineers, really speaking for myself, that seems to slow the process down to a snail's pace, and it's a hard thing to get over.

MIKE: Exactly [chuckles].

WILL: I've always wondered what it is. Every engineer, I think, I've ever talked to has it: the aversion to email. I don't know, I haven't unpacked it, and I have thought that I should accept it as a given. Like, no engineer will email you, unless extreme pressure has been applied to them [laughs].

EDDY: Well, I think part of that is because, as an engineer, you're expected to hit certain deadlines, and so you need answers pretty quickly. So, leaning towards instant messaging, like, it's even in the word, right? Like, you get messages instantly versus having to wait for emails to come. I'm not saying that one's superior than the other, but I think we work in an environment where we're trying to fetch information as quickly as possible. So, having direct communication with that person via a DM, you know, does wonders.

WILL: Yeah, fair.

MIKE: It violates, like, a psychological contract that we have with each other. When you're talking with somebody in real-time, the timing matters. If somebody pauses for a while, you think, oh, what did I say wrong? It breaks your connection. It breaks the emotional connection badly, and email guarantees that. There's no way you're going to have real-time communication over email. I mean, maybe you could, but it's super awkward. Whereas if you're directly messaging somebody, you feel like, yeah, I'm almost in the same room with them, and it's a totally different dynamic.

KYLE: [crosstalk 13:28] you’re in the same room [laughter].

DAVID: There's a trade-off there that didn't become clear to me until somebody dialed it all the way to 11 in a different direction, which is there's a phrase that came out of agile, back when agile was still called (XP) Extreme Programming. One of the phrases --

WILL: [inaudible 13:50] XP.

DAVID: Oh yeah.

WILL: [inaudible 13:52] to do with that.

DAVID: One of the phrases that they circulated a lot back then was, when you're pair programming, they'll tell you “Never type when you can speak. Never speak when you can point,” right? Literally, it's, like, how much information can you communicate in the smallest amount? Now, pointing is very ambiguous. You have to be in the same context. You have to be physically present. There's all kinds of stuff. But if you have that context, you should use it, right? The last thing you want to do is sit down to pair program with somebody and they pull out their phone and Slack you a message, right?

MIKE: [laughs]

DAVID: Unless they're sending you the shockie to get into something. You’re just like, okay, yeah, I do need that written down, but, yeah, it doesn't make a lot of sense. So, when you see the immediacy and the ceremony...and sometimes you want the ceremony, sometimes you want a Jira ticket documenting that I have opened this issue with you on this date, and this was my request, and y'all better do something about it. Versus just, like, “Hey, we're going to let [inaudible 14:54]. You want to come?” Like, you wouldn't do that with Jira. You wouldn't do it with a ticketing system.

DYLAN: Your Slack example highlights, too, that switching from pair programming to Slack that's a context switch, and it can be jarring. Switching to email is a much bigger context switch because you're not just drafting an email. You're confronted with your whole inbox, and you see a subject line from someone and think, oh, I need to switch gears and reply to this now, too. So, psychologically, it throws you off.

DAVID: Serial access, like, accessing one thing at a time, like, as in messages coming in over time into your inbox, is one of the most inefficient ways to do something. And how is that serial port being used? Every marketer in the world is jamming messages into that serial port. It's...yeah.

EDDY: I want to be completely transparent, and I want to go on out here. I'm hoping other people can agree. But switching between two different applications that have two different interfaces kicks my butt every single time, right? It's crazy. It's crazy.

MIKE: Well, it breaks your flow. Anything that breaks flow prevents effectiveness, right? I think we've talked about flow in another, you know, another podcast before, but getting into that state is hard to get into and if you break it, you lose it for a long time. And anything you add that makes it harder to get into that flow just adds another layer of difficulty.

WILL: You know, for me, honestly, when I think about sending or, God help me, receiving an email, I feel like it is the least likely thing to get me any answer that I need. It's almost always something that I don't want to do that also doesn't matter. And my best-case scenario is I send somebody an email, and I'm like, hey, I have this problem with this vendor tool, and it's doing this thing. And please reach me at an actually productive communications channel so I could work it out [laughs]. The email is sent in getting a Huddle or a Slack message from somebody I don't know well enough to ask directly.

EDDY: I don't fully expect people to really have the answer off the top of their head, but just out of curiosity, like, just a rule of thumb, how productive has the experience we’ve [inaudible 17:27] with emails? Like, have they actually provided any sort of value?

DAVID: I'm going to say yeah.

EDDY: I’m surprised.

DAVID: For me, it's a receipt. You've got something, like, I will pull up my inbox and basically say, “Uh, where's the receipt for this thing? Or where's the confirmation code that I got for this?” And I love that. I've just told you something, though. I've just admitted that I am not an inbox-zero kind of guy. You open my Gmail, and the unread messages is well into five digits. I remember when I passed 20, 000 unread messages and still climbing. And it's because I open up email, I scan, I’m like, yeah none of that's...and then just move on. You know, why bother?

I don't deal and set aside and finish my emails. If that were my working system, email would have a completely different flow for me. For me, it's much more asynchronous. There are times when I will go for a day or three without checking my email, but anybody who knows that I'm living in that asynchronous environment knows that well, we'll send this to him. It will get to him eventually, but it will get to him. Whereas anybody who's tried to Slack me knows that I frequently have my notifications not working the way they need to. And so, I think everyone in this call has gotten a message [inaudible 18:43] “Dang it, I missed this notification. Sorry, where were we?”

MIKE: Well, email, what's right there in its name, replaced postal service delivery, some sort of, you know, human delivery [chuckles] involving somebody grabbing a written document and carrying it or maybe fax [laughs]. And, in that respect, I think, and this may be why it's popular on the business side, it’s like, wow, this is so much better than waiting for the courier [laughs], and maybe it's because people like the paper trail that you get.

But it's not that you don't have that in the other tools. I'm not saying it has no value. There is some value, but we're talking here about collaborating across teams, and we've kind of diverged a bit into the tools. You've got to set the ground rules first. And if your engineer is trying to coordinate on something, email is probably not the way to do it.

WILL: I think email is the industry standard for communicating with people you don't know. I've got a bunch of people from completely different departments. I don't know any of them. I don't know how they work. Are they Teams people, Slack people, whatever people? And we're going to go out and we're going to create, effectively, a document of record, right? So, people you don't know, like, when you're sort of managing up, you're talking to people sort of further up the chain. You can't just Slack, you know, you can't just hit people up like that. You send an email where it’s like, all right, I sent it, and you're going to read it or not. But I sent it, and there it is, and if you have a thing, then you can get me. Anyway, it's not going to be a Slack thing.

And I think that right there kind of segues me into maybe one of my answers in terms of the original question I asked which was, what's a successful collaboration look like and feel like? And, for me, when I have collaborated with teams successfully, and, like, the way I've collaborated with teams successfully, is when one, or preferably both parties, have some sort of social capital with each other.

When I know you, when we've collaborated before, when I know, you know, who you are, and how reliable you are, and whether you are going to, like, whether there is a quid pro quo, whether I'm not just getting bombs thrown into my sprint and then I'm never going to see you again, like, are you a pure [laughter], unadulterated problem for me, or are we collaborators where this is going to go both ways, and I'm going to have a question for you, you know, six weeks or a month down the line and, you know, you're going to scratch my back?

And I think sort of cultivating that is one of the bigger hidden, you know, tidal forces that as you get tenure in an organization, you start to build up those connections where you know people, and you know people who can help you out, who will and who can, versus people who are just going to create problems for you and you must [laughs] be coerced into helping them because you know it's just going to be a time sink. And it's not that you won't. It's not that you won't. If you have a problem, I'm going to fix your problem, but I might solve some other people's problems first, or more thoroughly, or more promptly, because, you know, it is a social capital situation, and not everybody's a good actor.

MIKE: This goes right into what Dylan was saying right at the beginning, which was the collaborations that work well are usually the ones that you've had a few tries first [laughs]. You have to establish that relationship first. And, it goes, you know, if you don't establish some ahead of time, you don't have it. I don't have a relationship with you. I don't trust you. I don't know you. This isn't going to work.

EDDY: Well, it's kind of like I instinctively thought of the analogy of a professional sports team, where, like, you just get a bunch of people who claim they're really good, and they are good in their own right. But if they aren't willing to “play ball,” quote, unquote, things are going to go tough. You have other people who want to do it in one approach. You have another person who wants to do it in a different approach.

They're both valuable approaches, but unless they align, and there's trust between each other, you know, it's going to be rough. It's going to take a really hard time to find that happy ground. But once you do and you've played enough games together, eventually, you start to understand, you know, how other people think, you know, it's easier to come up with game plans when everyone understands the way they play, right?

MIKE: Well said. We don't need a bunch of heroes. We need a team.

DYLAN: That can be both very frustrating and very valuable. Often, when two teams are collaborating, one team is managing software infrastructure, some kind of system that is much more dangerous to mess up than the other team, and often they have more robust processes than the other team. And when the other team joins, it can be very frustrating because they have to go through a ton of red tape to do things. There's a bunch of process they haven't done before. They don't really get why it's important. They haven't been there at the incident management meetings. But being able to integrate that process into themselves also makes them perform better as a team.

WILL: Yeah, and, honestly, a lot of the time, almost all of the time, the collaboration, like, within the teams it's not equal priorities, right? There's a big thing for my team, and I've got a big deliverable. I've got a big project, and this is my thing that I'm going to get out. And it impacts and interfaces with other teams. It's like, oh, I need you to update this API, or I need you to provision some hardware for me, or what have you, right?

This is my main thing, and this is, like, something that you're doing on the side. And that can be a source of some amount of friction because I care a lot, and you care to the extent that, you know what I mean, for better or worse. And that's one of those critical social capital times because I can just be like, “Hey man, can you just get this thing in for me?”

And it's not a big piece of your sprint, you know, no one really is chasing this thing down, unless I go to my manager, and then they go to their director, and then their director goes to the other director, and then the other director goes to the manager. And they're like, okay, come on, let's get it done. There's all those steps, right? That's collaboration across teams, but even as I said it, you can see where it's just like, oh, it sounds like a crime. But if I'm just like, “Mike, do me a solid, you know, help me add this Boolean flag onto my JSON, please, so I can get this thing out, then it's a matter of the day.

MIKE: Well, yeah. You tie it in...I've been thinking about a couple of successful projects I've seen. I'm thinking about a couple of really successful big projects that were related to each other. Well, they weren't related to each other. They're totally separate projects that had a pattern that was related to each other. They followed an almost identical pattern in that they were very successful, and I think for the same reason. And it ties into what you're saying about, you know, you've got to talk to the director. They talk to somebody, you know, that horrible chain of command that makes communication just grind to a standstill and play the telephone game [chuckles].

Where it's really worked, where I've seen this work is when you started with not business stakeholders...business stakeholders, at first, figure out the requirements, and then you have the product team come. You know the requirements really well. That product team that knows the requirements sits down with the engineering leaders who have something to this project, who actually know what they're talking about. And you get the group, small group. I'm not talking 10 people; I'm talking maybe 2 or 3.

The people who are most affected by this project get together with product, and they hash out together the order of operations to get this big project done, so you have a series of milestones. And that gives a roadmap which you can then put timeframes on and then start filling out the specific requirements and teams associated with each milestone. I’m seeing there's a lot of planning involved here, you know. But you've taken this big problem, how do I get from here to the other side of the world, and you've broken it down into smaller pieces. Well, how do I get from here to the edge of my state, or how do I get out of the driveway, right?

You’ve figured out the major milestones along the way, and then you start functioning at the level of those milestones, and you know the teams involved. And then, bring those teams in to solving that milestone, you get that milestone done, move on to your next milestone, and so you have the map right from the beginning that everybody can see. Everybody sees the roadmap. They see the milestones along the way. And then, they pitch in to get each of those milestones done, and then the next milestone. And each of those milestones has the teams clearly identified and the requirements clearly identified to get that milestone done.

So, there's some commonality here, one is the really well-documented and well-created roadmap. You can't just have somebody throw something out there. It has to be agreed on by the engineers who know what they're talking about together with product, so you actually get the right business requirements so we know what you're actually building.

And then, you've broken it into those milestones. I feel like those milestones are critical to make it work because then you're not looking at something so big that nobody cares. You're looking at pieces that everybody can engage with. And then, each of us has a clear deliverable that everybody knows how to get solving. Because then you can get engineers thinking, well, how do I solve this problem? You get each of the teams that care about it engaged with that problem, and it matters to them. Then they can collaborate, reach across teams as necessary.

And before you actually have them collaborate, the teams get together and define the API boundaries. How are we going to communicate with each other? That can only happen...you only get a start with those API boundaries so that they can code to that, rather than not knowing what they're doing, if you've had the road map, and you've identified the teams, and you said, “We're going to get together first.” And that's a lot of overhead up front, and it requires product who's invested and the engineering leaders who are invested in working together. If you can get that, I think you can make it work. But there's lots of places that can fall apart.

WILL: I love it.

DYLAN: The way you put it, setting the groundwork is itself an engineering project.

MIKE: Absolutely [laughs].

WILL: I'd pitch you on it. I mean, I love everything you're saying here. I would pitch you on another thing as well and maybe a tactical, small unit level. I really love engineering embeds, where okay, these two teams are collaborating. And, generally speaking, both teams are not fully tasked. But more often than not, I think 80% of the time, most teams are not fully tasked, but it's like, okay, this team is providing this, you know, subcomponent for this larger project. This is our main baby, and there's this subcomponent. Lend the engineer out. Give an engineer to the other team. They're going to be embedded for as long as their piece needs to be there. They're going to do stand up with them. They're going to sit there. They're going to build that social capital.

And most critically, I mean, maybe two things that I think are going to happen that are really important. One, I think it's very easy when you have a sort of like a [inaudible 31:15] engineer for a couple of days, you know, half of somebody's sprint cycle. It's very easy to underestimate impact to productivity with cross-team friction and collaboration and getting things ready to go. And so, when you're dealing with stuff as an embed, this guy belongs to this team, you know, for such and such, you're going to take that more seriously. And, honestly, I think when you have somebody else's project, it's really easy for that to get kind of short shrift.

And it's also sort of...how do I put it? No, actually, those two things it takes a lot more friction than people get credit for. And this will get people to take it seriously from a planning perspective and fully commit from an engineering perspective, like, I am going to get this thing done. This thing is my thing, and I know these guys. They're not just strangers throwing work over the wall at me, and it's hitting me on the head. They're my team for now. Temporarily, they're my team, and this is our project.

MIKE: Oh, I like that a lot. And it's a little different than setting up with people who are, like, a tiger team, where you say, “Okay, this project, we're going to take somebody from each of these teams and put them together and isolate them from everybody else.” I have seen that not work so well because then you've deliberately isolated people. You've shut them off from the rest. But the way you put it, where you're loaning somebody, where you're sharing rather than isolating, I think that works out really well.

DAVID: I think I've mentioned this before that I've done that on teams proactively without a project, where it's not like...we literally called it the hostage exchange program where we would take a sprint, and we'd basically say, "We want one of yours. We're going to give you one of ours." And after two weeks, we'll go back. And so, literally, the whole point is just to pass this person around the team, let them soak in the environment. They're not going to be super up to speed, but that's okay because your guy over there isn't up to speed either. But after two weeks, you swap back.

And it's so beneficial to be the person who was out on the exchange because now anything that happens with that team's product, everyone in your team will turn and look at you. And you're like, “Hey, you were working on that team, you know, last month.” And the really cool thing is when you want to go drop a ticket on somebody's desk. Like, they've got a ticketing system for how they're going to handle their stuff. But before you do that, you just pop open Slack and you're like, “Are you guys on Kafka 2.14 or 2.15?” It's not worth stopping the whole system.

And the other person, because they've sat next to you for two weeks, they're like, "Oh yeah, 2. 7. We're actually on 17. You're way behind." "Cool. Thank you." And if I need something beyond that, I'll go do the ticket and do the thing. But there's that moment, like, water cooler connection of just, like, "Hey, buddy, where's this at?" and being able to do that.

EDDY: Yeah, Dave, but then you run the risk of becoming the git blame of that, right? And then, everyone just comes up to you and says, "Hey, you touched this code before. What does this do?" You're like, "I was just there. I just --"

DAVID: The reason ticketing systems exist is that people don't have a good defense against becoming the git blame guy, and they're like, I need to get work done. I need you to stop interrupting me. Go talk to the tickets. And that's, unfortunately, that's just replacing one dysfunction with another, but yeah, you're right. That’s a very real problem, and it's bad when it's...

I guess if I'm yelling at you "What version of Kafka are you on? Drop what you're doing. Pay attention to me," I'm not building a team with you. I'm not revisiting a good interaction. It's got to be that water cooler, like, social capital like we've talked about of like, “Hey, how are you with this?” Because half of those conversations are equally likely to begin with, "Hey, is your kid feeling better?" And that's a social capitally valuable, you know what I mean, positive social capital in that communication, because you care about the human on the other side.

WILL: I guess what I'd say, to Eddy's point, when you have that guy, you're the ambassador. You're the liaison between these two teams. You've been over there. You've done the hostage exchange. You have some connections. You have some background. You can get things done. And your job is constantly being looped in to, like, oh, this is going wrong, help me. This is going wrong. Help me. This is going wrong, help me.

A, that is a strong signal that the hostage exchange program needs to not just be continued but expanded, right? And B, think about how badly these projects would be going without you. You're saying, "This is bad. We shouldn't do it.” And I'm saying, "This is good. It's saving your ass, and you need to do a lot more." It only becomes an anti-pattern when you have this unmet demand such that your concierge, your ambassador is just getting dog piled with requests for support from these other teams. That's, I don't know, just another way of looking at that. It's not too much; it's not enough.

DAVID: You could have both.

DYLAN: In a crisis, you end up being very happy that you have someone like that on your team because you don't have to play a game of telephone. When, you know, something goes wrong, support figures out. They call a developer; developer realizes it's a DevOps problem; they call DevOps. If the developers also worked with the DevOps team, then they can start looking at the DevOps side, too, and also call DevOps in parallel, and it saves you time. And if you need to respond to an issue in 5 or 10 minutes, then you don't want to lose that 5 minutes of waiting for someone to respond.

EDDY: So, you're saying when things are on fire, don't use emails.

WILL: No, you don't.

MIKE: [chuckles]

DYLAN: You know, that's important, too.

EDDY: [laughs]

WILL: No, nobody sends an email on fire. They have a guy. And they're like, I have a name, in my head, of somebody who's going to put this fire out. And, you know, from a career development perspective, I'll just say that in my career, like, consistently being that guy has been really good for me. And if you're like, “How do I advance as a developer?” being the name that people can call when things are going bad, it's really good for you.

MIKE: You know, talking about the email, Molina, who was here, had to go, but she does application support. So, she handles the bad stuff. When things are on fire, she's the firefighter [laughs]. And she doesn't instant message me. She doesn't email me. She texts me.

WILL: [laughs]

MIKE: And that matters, right? She knows that she can send me a text message, and I'm going to get immediately on that problem, not just me but a couple of other people that she knows, you know, are critical to solve this problem. And I'm going to jump on that problem because, you know, that's going to happen.

Now, I don't have everybody text me, right [laughs]? But the person who I know is doing that critical firefighting, well, yeah, you're going to get the most direct, and engaging, and immediate sort of communication that I have available, or a phone call even, right? Her and her partner there in application support they'll both do that. Yeah [laughs], that relationship matters.

WILL: Yeah, that's the gig, man.

DAVID: And it's respected, too, though, right? You're not going to get a text message at 3:00 o'clock in the morning saying, "Hey, would you fill out your TPS report sometime in the next week?" [laughter] No. I started work before the internet existed. And we had a saying back then, which was “When they come find you in the bathroom, you know it's serious.” And this is the modern equivalent of that.

WILL: Yeah, what do you call it? I don't know. I keep my phone number on my Slack. Nobody calls me if they don't need me, but it's rung before [laughs]. That's just the gig.

MIKE: So, we've talked about a few things, right? We've talked a lot about channels of communication and how some are better than others. And the more immediate the channel, the better. We’ve talked --

WILL: Not necessarily.

MIKE: Well, that's true. You're right that having a...You're right. I did not state that well, that immediacy is good in many cases, but there are some cases where, I don't know you, asynchronous, keep a record of this is the right answer. So yeah, my summary was a little off.

And we've talked about some successful projects where you have social capital and the deep importance of social capital, both at the, you know, leadership level, at just between team level, any way you can possibly establish it that's critical, and also, the planning. The actually doing the engineering project to build out your milestones, to build out the project plans, and get people engaged before you jump into the project because if you just jump into it and I hope it's going to work, well, it's not [chuckles]. What have we missed?

KYLE: I was just thinking about kind of expanding on what Will had pointed out earlier about integrating a person into the team. And I was thinking...because I think a lot of the examples are, you know, devs from one team going and being on another dev team. And I was thinking about my history in QA, and most of my QA jobs, you had a QA team. And you worked with just all of the developers or, you know, all the support, all the developers. And whenever there was a bug that you needed to have questions answered, you got up, you walked over, and you had to confront that person. Now, sometimes, that person was somebody you knew. Sometimes it was, you know, the grumpy Java developer, and you just didn't want to talk to them that much.

However, I was in another position, which was very jarring, for me, and I didn't understand it when I first got into the job, and this was actually at InsideSales. They distributed the QA individuals. We were on a QA team, but the QA individuals were integrated with the developers. So, now I'm in with the developers. I'm testing this specific product’s app or this specific product. And then, I'm going to their planning meetings. I know all of their requirements. And then, when we're getting together as a group in QA, it's, okay, well, what's happening with this service? And that's kind of how the communications are getting distributed that way.

But that was probably the fastest form of communication in a development style that I'd ever experienced, and that was because as a QA individual, I was part of that development team. Even though I wasn't necessarily directly involved in the code, I was part of the team. And that's something that I don't know that every company gives that kind of credit to their QA or QE engineers, that they're actually part of that development team. And so, I think there's a bit of slower communication because of that. That's just been my experience, but yeah, it's something to add there.

EDDY: I can attest to coming from QA.

DAVID: For me, this all seems to break down to context, right? It's like, if I'm up on stage giving a presentation in front of a thousand people, I'm going to adopt a very general context. I'm not going to tell edgy jokes. I'm not going to make fun of people. I like to tease people. I like to be silly. I like to be fun. But in a universal context, you don't know if I'm absolutely just destroying a person willfully, or if I'm just teasing them because it's funny.

But when you're working with close people, you know, I have a co-worker that we literally did the hostage exchange, and we had a third guy on our team. And halfway through the morning, he was just staring at us, like, mouth open, eyes wide terrified because TJ and I had gone 5 minutes about “Your mom,” “Oh yeah, well, your mom.” And I mean, it sounded like a Call of Duty lobby. And then, TJ had to stop, and he's like, "Matt, just so you know, we are best friends. This is fun for us. We are..."And I'm like, “Oh, yeah, yeah. No, this is totally just a bit. We're just...” And he's like, "Oh my God," just the weight coming off of him.

But that context pays off in both directions. When you have a general context, you have to follow policy. You have to be very strict. It's your ticketing system. You're going to follow these rules. But on the other side of that, if you can move into a higher context with somebody...like with Kyle, if I write you up, "When I test this, I need you to load this app. You need this backing up, da, da, da." I give you these three pages of how to set everything up because I don't know you from Adam. You might not even be in Utah. You're on the other side. You're coming in from the Rent-A-Center side.

So, I've got to give you all the context and all the background, where other times I can hand you maybe a PR and basically say, "This fixes the tax freeze in Montana," and you go, “Got it.” And you know exactly what the problem is. You know the history. You know what to check. You know 90% of the app is going to be untouched by this, so you need to focus here. And if you're in that general context, no, you have to do the test on every single piece because you don't know what the intent was. Having that context, for me, is the key element between stilted receipt-based communication and being able to just very quickly just say, "This is what we want," and being able to strike and move at it.

WILL: Okay, so, I mean, I feel like we're all fairly aligned in that, to the degree that you can, to the degree that it's possible, it's good to have people who know each other. Or, at the very least, you have people who are embedded so that this alien, foreign team they're committed enough to your success, and your project, and your priorities to give you somebody, right? There's a level of trust there.

Like, if you're going to give me a senior developer for a month, okay, all right. I mean, you've taken me a little seriously, at least, and so, that's great. But what about when it's too big to be able to put up a bunch of buddies, right? What happens when it's too big to be, you know, something like that? It's like a cross-organization type thing, you know, where it’s this is a big thing.

MIKE: And that goes down to what I was talking about before. The times when I've seen this successful, you put in the work ahead of time to get the relevant engineering parties together with, you know, the requirements people, you can get it from product, to build out that plan, build out that road map, get the milestones in place, and figure out the teams involved. Take the time to communicate with those teams.

With each milestone, you have a kickoff, right? You collaborate together. You figure out what boundaries you need to establish. What are our APIs going to look like? You know, whatever the case may be. You can't not do that. And I'm going to [laughs]...sometimes you think, oh, I've done this before. I know what I'm doing. No, you don't [laughs]. You don't. It doesn't work that way. It just doesn't. If you don't put in that work ahead of time, it doesn't work. And I've never seen it work, I don't think.

But I have seen it work on the occasions when people really have done it right and put in that time ahead of time and held to it. It helps also if you have a project manager who has the milestones, meet regularly with all of the teams, and talk about how each of those are going. And like, oh, there's a gap here. What do we have to fix?

WILL: You know, I'm over my skis here because I've never done this. I've done, you know, management and team coordination of projects and stuff with developers I could count on my finger. But I would almost pitch people to do the exact same embed thing, except with functional organizational units at whatever level is required. Do I need to have a director and all of their teams embedded in another vice president's thing? Okay, that's that but the full-time commitment to the collaboration.

And so, whoever is overarching this thing, whether it's a VP, or a director, or a CTO, or the CEO, if it's the biggest, baddest thing, maybe, to Mike's point, maybe not on a tiger team, but say, like, okay, this is the thing. We're doing this thing. And I'm going to take you, and you, and you, and you and your organizations, and you're doing this now. You're reporting to this structure for a quarter or maybe a year, depending.

I think based on my, you know, experience with corporate organization and bureaucracy, I think that is a hard order in terms of maybe careerist internal politics. But that doesn't really put me off of it necessarily because you're just saying the quiet part out loud because that's the cost of collaboration on this scale. You're going to need to have somebody applying pressure at that level, with that intensity, or else it's going to grind to a halt, or it's going to take forever, or it's going to fail. And so, I don't know, that's what I would pitch you, you know, the embed philosophy, but you're just embedding bigger pieces. And if you don't want to embed bigger pieces, then you should perhaps question your commitment to an endeavor of this scale.

MIKE: You're saying, if you're not willing to actually create that social structure, then you're saying you don't care about the project because that's how people work is in a social structure.

WILL: Well, exactly, exactly. And so, it's some other VP's thing. And I'm a director, and I want to, you know, move up the thing, or at the very least, I don't want to work any harder. And somebody is applying pressure on me to work. And if no one's going to move me over there for as long as it takes, then you're running into some real serious operational risks, you know?

MIKE: That might be a good place to kind of tie this together. You're saying that...you talked about different scales. It all looks about the same. It's kind of this fractal thing [chuckles]. If you get people working together, it's still people working together. And getting together in the same room or the same virtual room, you know, getting together into the same structure so that they are working together has to happen. And that happens when there's two of you pairing together, or you're putting your stake in the whole company on this huge project. Well, you better have some way to communicate and be working as a team.

WILL: And it's going to have a cost, an intrinsic, undeniable, you know, yeah, it's going to have a cost, and you need to commit to paying that cost. That inter-organization or interpersonal friction it's going to cost you something. And in my view at least, and I know I'm out over my skis here, but whatever, hot take.

MIKE: [laughs]

WILL: I think being transparent and upfront and really, like, grabbing that nettle with both hands is going to get you a better outcome, and it's very easy. And we've all seen it over and over again, where somebody's like, “Oh yeah, this should be fine.

MIKE: [laughs]

WILL: This will be fine. This is no big deal.” I hesitate to think of an example where somebody has overestimated the cost of that functional collaboration. I can't think of a time, ever, you know?

MIKE: Me neither [laughs]. You can't make it go away.

WILL: Yeah, so just, you know, pull the band-aid off fast, and get into it.

MIKE: Cool .Like I said, I think this was a great discussion. Hopefully [chuckles], you walk away with some good ideas as to where to go next. And until next time on the Acima Development Podcast.