Even though there are a variety of personalities on your engineering team, they probably know how to collaborate with each other. They have shared deadlines and goals, understand the technical nuances of projects, and see that their colleagues’ best work often happens when they’re uninterrupted. The greater challenge is communicating with non-technical teams. Often, these departments don’t know how developers prefer to work. Additionally, they aren’t aware that many of their questions have been answered multiple times. As a result, your developers find themselves overwhelmed by the questions they field from their colleagues, all of whom need their help urgently to get across the finish line. The problem with this scenario is twofold. For starters, when your programmers feel pressure to drop what they’re doing to help a sales or marketing person, the outcome is a massive amount of lost productivity. On top of that, teams across your organization will eventually feel that this haphazard approach is protocol, potentially leading to frustration for everyone. As an engineering manager, how can you remedy this issue? The answer, of course, isn’t to tell your programmers to deal with it for the sake of the company. Instead, here are a few tips to make cross-team communication easier and more beneficial for everyone at your company.
Work With Your Team to Create Rules of Engagement
Again, the solution here isn’t to tell your engineers to help people in sales and marketing at all costs. At the same time, it would be unfair to the entire group if you created guidelines for technical requests without input from the team. While you should have a good understanding of what the team is working on, your developers are even more aware of the projects and challenges that they’re currently tackling. Sit down with your lead engineers to review their current workload. Based on what you discover, ask them to help you create and document rules of engagement for the company to refer to whenever they need help from a programmer. For some teams, that might mean responding to an initial question within 24 hours. For others, these rules of engagement might be far more rigid. The good news? There’s not just one right answer. Will this stop people on different teams from walking to a programmer’s desk for an urgent ask? Probably not. At the same time, this document will help everyone set expectations around cross-team communication—and will give each developer something to refer to when he or she can’t find a way to say no to a colleague.
Appoint Team Leads to Handle Requests and Share Information
Every year, we survey the developer community on Stack Overflow about topics such as their favorite technologies and preferred working environments. This year, over 100,000 developers from around the world participated. The data is widely available to our internal employees, as well as anyone with a curious spirit who wants to explore the dataset. The challenge though is that because we have access to these insights, everyone can think of at least a few ways to leverage them at work. That’s why our Data Team implemented a process for employees to submit requests, while also making it clear who the main point of contact is at the beginning of the process. They’ve also created internal documentation so that everyone at the company knows how much information to include whenever they ask for help. Julia Silge, a Data Scientist here at Stack Overflow, says that these guidelines help her team play a more consultative role. “They enable us to communicate some realities about what we can and can’t do,” she adds. “They encourage individuals to formulate concrete, specific requests, and they give us information that we need to prioritize our own time.”
Keep Your Developers Accountable
While it’s important to make sure that your developers have what they need to handle requests, it’s also your job to ensure that they are empathetic with their colleagues. The concepts in this post shouldn’t empower your team to snap at a colleague whenever he or she is interrupted. If a programmer does lash out at someone, it’s your job to call that out and work with that person on avoiding this in the future. When this happens, you have two choices. You could defend that person by explaining that he or she just had a lot to do. As true as that probably is, this isn’t necessarily the right approach. Over time, it will make it more difficult for your fellow managers to consult you on future issues. If you learn that a programmer has snapped at someone, be sure to address it promptly. Find a few minutes to chat with that person about why it happened, what they could have done differently, and how they can handle similar situations in the future without taking any frustration out on an unwitting teammate. Want to find new ways to make cross-team knowledge sharing even easier? Learn more about Stack Overflow for Teams.