Avoiding Dependency Hell as product teams scale

For EdTech companies, the opportunity to develop single, enterprise-wide products is both exciting and potentially lucrative. But with bigger projects come bigger challenges throughout the UX design process.

That’s especially true as teams grow and become more complex in their structures. We have been fortunate to work with a number of product teams who understand that scaling presents new challenges and have been a part of collaborating on strategies and tactics for effectively helping multiple teams, product owners and stakeholders work in concert rather than chaos.

With multiple UX teams, product teams and engineering teams all functioning separately within the same project, building products at a large scale opens a web of complex communication issues for the teams involved. And the stakes for clear communication are high, not only in terms of efficiency in production (poor communication is a budget buster), but also in terms of the product’s usability and, ultimately, its commercial success.

The Importance of Continuous Communication Across Large Product Teams

It goes without saying that clear communication among teams is important for product design projects of any size. But as your product—and the corresponding number of internal teams, contractors, and stakeholders—scales up, it becomes a prime environment for communication vacuums to form.

We’re very fortunate to work with some of the most talented and effective product teams in the world. The most important ingredient for their success at scale is their ability to adapt their communication style to work across multiple teams. Open and continuous cross-team communication is the key to avoiding unintended dependency gaps that can arise from teams working in silos. Even the smallest UX decisions create new dependencies that impact the course of product development. If you consider how that can be compounded when multiple teams introduce new ideas, the result can be as subtle as a minor visual element not being treated consistently throughout the product—or as glaring as broken functionality. And unfortunately, the end user may be the first person to uncover the issue.

Think of each unresolved dependency issue as a raindrop. Taken on its own, each one may be fairly easy to overlook. After all, no product is perfect –there are always going to be a few raindrops in any new product release or update. But as they gather in greater numbers, they form a stream, and then a river, and finally an ocean.

Once you’re in river territory, the issues add up to an unsatisfactory user experience that undermines the intended use and functionality of the product as a whole. Not only is the quality of the user’s experience degraded, but internally you and your product have now landed in what we like to call “dependency hell.”

You know what we’re talking about. Dependency hell is a meshwork of design and functionality issues that leaves no corner of your product—and the internal teams that support it—untouched. And the only way to avoid it is to proactively and collaboratively map out dependencies as a unified team during the initial design phase and, later, as you work to upgrade and fix an existing product.

The Road to Dependency Hell is Paved with Good Intentions

If you’re dealing with the challenge of scaling up quickly, take a moment to recognize you’re in this position because you and your team are doing a lot of things right. It’s normal and healthy for success to breed new problems to overcome. Communication vacuums are rarely intentional, they are a normal stress point as teams grow more complex. But what may start as a well-meaning desire to respect the time of colleagues on other teams, may actually result in teams falling slightly out of alignment as they pursue solutions on their individual pieces of the product. So while it may feel like the right thing to do, not involving other players may actually result in the need for additional costly reworks down the line as those raindrops merge to form torrents.

It’s important to note that dependency hell can plague a product at all stages of its lifespan, not just the initial build. In fact, it often gets worse as a product matures. It makes sense: when you’re in beta, you can be a little more nimble and exploratory as the design of a product is iteratively refined. But as a product launches and matures, the architecture deepens, creating more dependencies around each new design and functionality decision that’s made.

Added Pressure for EdTech Companies During the UX Design Process

At scale, communication and the usability challenges that follow aren’t unique to any one industry. Product design companies of all stripes can find themselves in dependency hell if they aren’t careful. But, because EdTech companies who make classroom tools must align product releases with academic calendars, it can be harder for them to get out of trouble once they’ve landed there.

Whereas best practice around general product design is to release updates as soon as they’re ready, many EdTech companies must wait for gaps between semesters to make changes. This means they may realistically have three opportunities per year to release and update existing products.

With fewer opportunities to get things right, it is especially crucial for EdTech teams working on enterprise products to proactively develop effective systems around internal communication, mapping out dependencies and resolving problems as they arise.

Solving the Problem Before it Begins

We’ve been fortunate to be a part of many winning collaborations across massive product streams. Success requires a few things, all of which can be addressed with the right systems. To avoid dependency hell, your team needs to:

• Foster clear and open communication between teams by setting up “checkpoints” at frequently occurring, predictable intervals. This includes regularly sharing each team’s “headlines” and status updates, regardless of the perceived relevance to the work of other teams.
• Build cross-team transparency by utilizing public to-do lists. The more insight each team has into other teams’ current activities and backlogs, the better.
• Make cross-team collaboration mandatory–especially in the early stages of product development, when teams have a greater tendency to isolate. Don’t wait until you have a high-fidelity prototype in place to share your work with other teams. Discovery is the time to begin collaborating.
• Create and enforce enterprise-wide standards in design, language and documentation in the UX design process. Providing clear organizational guidance from the top down can help drive consistency at all levels.
• Regularly audit your product for disjointedness using a clear rubric or assessment tool. Your rubric should not only help you to systematically identify issues, but also to grade them in terms of importance.

Fostering better communication between teams during the UX design process will yield benefits across the lifespan of any product your firm produces. The result will be a smoother build—and more satisfied customers.