The Challenges of Inter-team Communication

Are you on the same team as your developers? Your business stakeholders? I hope you at least have similar goals, but how do you know if you’re on the same team?

Collaboration for UX

Software development is a collaborative discipline, and a good UX team is the focal point of collaboration in a software development organization. In this series Andrew Mottaz explores these collaborations.

See all posts

Related posts:

I’m going to break inter- vs intra-team along the following lines:


  • You don’t work in the same building;
  • You don’t meet as part of your regular cadence;
  • Passing things off feels like “throwing them over the wall;”
  • Your role is complete before their role starts (or vice-versa).


  • You see each other regularly;
  • You have regular meetings;
  • Your work on a project has significant or complete overlap;
  • You’re available for questions while they’re working and vice-versa.


These are really two ends of a continuum. But the closer your organization is to inter-team, the more challenges you’ll have with collaboration and creating a shared understanding of development efforts.

I’m going to assert that the main reason that inter-team communication is a challenge is that it’s really hard to create a shared understanding of a project when your only opportunity to do so is in some petrified artifact that you hand off to another team. But there are easy ways to improve this situation.

The main focus needs to be on opening lines of communication. Even if you’re just going to pass a giant spec doc off to your offshore developers, you can find a way to let them see your thinking behind the document. There are lots of collaborative tools for sharing information. Even a simple wiki can help fill the gap. Have your discussions, and document decisions out in the open. Understanding why a decision was made can be just as important as understanding what the decision was (e.g. “we used this layout to minimize clicks because this is the most important function of the site”).

Open up that line of communication to all the teams. What if a question comes up during development that wasn’t documented in the planning stage? As a developer, I can tell you this happens often. Some functionality is implied by the design, but it’s not specified (e.g. “if you want users to be able to customize this palette, you will have to build a separate management function for the palette”). Ideally I’ve been involved early enough to head off this issue. If not, I need a way to communicate it to the right people. Other trade-offs show up during development that need to be cleared with business users (e.g. “this solution will take 6 months to build, this one will take 2”).

Waterfall and the giant spec doc have been pilloried for good reason. The first reason is that no one gets engaged with a spec doc. The second is that for any project of significant complexity, the spec doc will be incomplete. And finally, spec docs don’t communicate the essential questions of the project: why are we doing this? Why did we make this decision instead of another? In short, you can’t create a shared understanding with a spec doc. You can create a shared understanding in addition to a spec doc.

So when you have inter-team collaboration, creating a shared understanding is more challenging. But if you’re aware that shared understanding is the most important output of the planning process, you can improve your work product. Even a brutally long spec doc is more comprehensible if I have the shared understanding created through prototypes, sketches, discussions and presentations. Any development process can be improved by making shared understanding an explicit goal.

Andrew Mottaz

Andrew Mottaz is the Founder and CTO of Site9, Inc., the maker of ProtoShare, a leading on-line tool for “collaborative prototyping.”

No comments yet

Be the first!