Top

Juggling Multiple Product Teams

Enterprise UX

Designing experiences for people at work

A column by Jonathan Walter
September 9, 2019

Working with multiple product teams can be a rewarding experience for UX designers. You gain exposure to diverse groups of people, work in different parts of the business, and design a variety of products—large and small. This often leads to growth opportunities within your discipline and enhances your reputation within the company for which you work.

However, working with multiple product teams can also be fraught with unique sets of challenges. For instance, most product-team members working in other roles focus on just one project at a time—especially in large enterprise environments—so they have clearly defined priorities and boundaries. One project—whether large or small—is their top priority, so the product teams with which you work might assume that their project should be your top priority, too. Aggravating this challenge is the fact that UX designers are typically underrepresented in large enterprise environments, in comparison to engineers, quality engineers, and architects.

As I’ve experienced firsthand, being the lone UX designer supporting multiple projects of different sizes, scopes, and types greatly magnifies this issue. One project might be designing a mobile application, another installable software for a thick-client application, and yet another a Web application. Designing for each of these platforms requires specific knowledge and poses unique challenges.

Plus, the processes that these product teams follow could differ as well—from traditional, waterfall development; to Scaled Agile Framework (SAFe) methods; to the Lean or agile development methodologies that small, collocated teams favor; and everything in between.

No two projects are alike, and context switching is difficult when you’re dealing with different product-team calendars, meeting invitations, Slack channels, and email-distribution groups. The challenges of juggling multiple product teams can lead to burnout and set you up for failure—unless you take measures to compensate for them before they become a serious problem.

In this column, I’ll share some tips I’ve learned over several years of balancing the demands of multiple product teams, spanning multiple locations and time zones, as follows:

  • manufacturing time for yourself
  • establishing boundaries
  • exposing your workload to everyone
  • choosing your battles
  • getting involved in projects early
  • keeping your manager well informed

Manufacturing Time for Yourself

You cannot contribute to multiple product teams effectively—or a single team for that matter—unless you remove any barriers that would hinder your ability to be productive. As UX designers, digging into our creative reserves to cultivate the best solutions requires dwelling in a problem space. That requires time. However, the distractions of living in interrupt mode—reacting to every notification, alert badge, or @mention—disrupts our ability to engage deeply in our work and get into flow.

Given the speed at which new productivity technology and software solutions are emerging in the marketplace—solutions whose intent is to save us time—this problem can seem paradoxical. However, many enterprise UX designers feel unproductive because they believe they do not have enough time to engage in deep work, which is a big part of their job. With entire worlds now available in the palms of our hands—blurring the line that separates our personal and professional lives—we now face a new set of self-regulation challenges that we’d never before anticipated.

The solution: You must focus your own scattered attention by manufacturing time for yourself. If you don’t reserve time for deep work, someone else could gladly swoop in and take that time from you. Your cognitive capacity is valuable currency and yours to spend. Do not squander it. Schedule time to focus on deep work and nothing else—even if you must do so weeks in advance. You must apply your attention to the right things, and scheduling appointments with yourself helps to hold you accountable for how you spend your time. Do not let yourself down. Do not do email during this time. No instant messages or chats. And especially, no social media. Focus on a single problem during a time block you’ve reserved for yourself, then once that time block ends, move on to your next problem or task.

Keep your calendar up to date by scheduling personal appointments with yourself. The small effort it takes to ensure that you have allocated sufficient time for deep work better enables you to handle simultaneous product-team requests when they crop up—as they will. If, with these personal appointments, your calendar becomes full, honor those scheduled times as much as if you’d filled them with appointments with valued customers. Your own attention is just as valuable.

Establishing Boundaries

Always being available on demand can backfire—especially if you’re working within a culture that expects employees to work long hours or be available during weekends or when on vacation. If you demonstrate that you are constantly available or are willing to work during times that should belong to you, the members of your various product teams might assume that they have your implicit permission to reach out to you during those times and expect that you’ll respond. There is no quicker way of burning yourself out.

While some projects might occasionally necessitate your putting in long hours to make a challenging release date or help solve a serious customer problem, this should not be the norm. Unfortunately, some employees believe that working longer hours means they’ll be more productive. Nothing could be further from the truth. In fact, research has shown that employee output falls sharply after a 50-hour work week.

What should you do? Establish boundaries, setting expectations about your availability. This doesn’t necessarily mean you have to sit down with each of your product teams and explain your expected boundaries. While you could certainly communicate them to your teams, you should always be sure your actions reflect your intentions. For example, do not answer email or chat messages during times of the day or week that you consider to be off-hours.

Whenever you are engaged in deep work during your workday, set your availability status to “Do not Disturb” or “Busy.” All modern communication tools should have this capability. If you work in an open-office environment, as many of us now do, wear noise-canceling headphones even if you’re not listening to music or a podcast. Doing so gives others a visual cue that you’re not available and are engaged in deep work. Or, if all else fails, leave your office or work area and seek a quieter environment that better fosters your productivity.

Casual requests of your time might seem trivial, but they add up. As do useless meetings. Do not be afraid to question the purpose of a meeting, especially if the organizer hasn’t clearly stated its goal or desired outcome. Meetings are some of the biggest time-wasters in enterprise environments. Could a quick conversation sort out the issue? What about a private conversation on Slack, Microsoft Teams, Skype, or some other communication tool? You cannot recover the wasted time you spend in unnecessary meetings. Plus, whenever you get pulled away from deep work, it takes several minutes to resume the work you were doing before the interruption occurred because you need to figure out where you left off and get back into flow.

Exposing Your Workload to Everyone

In addition to talking regularly with your manager—which I’ll get to later in this column—exposing your workload to all of the project sponsors with whom you work usually solves most workload conflicts before they become a problem. Let all of these project sponsors see the other projects with which they’re competing for your time. Create a spreadsheet for each of your ongoing projects and, at the outset of a new engagement with a project, share these spreadsheets with the new project’s sponsor—especially if you anticipate lofty expectations for your level of contribution or availability.

Go even further by demonstrating transparency with individual product-team members as your engagement with a team ramps up. Discuss your competing workloads during Daily Standup Meetings (DSUs) and in recurring communications. While you might not think gaining knowledge about your other work would benefit seemingly unrelated product teams, it does. Being transparent about your workload affects all your product teams, regardless of whether they realize it. Briefly discussing your competing workload might reveal previously unknown insights about cross-linkages and redundancies that exist between projects. Moreover, you can help product teams avoid duplicate efforts. You could save a product team the significant time they would have otherwise spent solving a problem for which a solution already exists.

Plus, if you foresee upcoming time conflicts, immediately share them with all your product teams so you can avoid periods during which you go dark—a problem that can be difficult to overcome. Be consistent. Consistency fosters predictability, which in turn fosters efficiency, which ultimately saves you time and effort. If you do fall behind on your work, you’ll lose momentum, and the time it takes to recapture your momentum can perpetuate a vicious cycle of being behind on your work—unless you work those long hours or weekends that, of course, lead to burnout.

Finally, maintaining transparency with all your product teams makes individual team members more sensitive to your availability, potentially encouraging them to give you more lead time to complete tasks. A win-win.

Getting Involved in Projects Early

As I described in my column, “Choosing Your Battles, Part 2,” when you’re onboarding with a new product team, engaging with the project as early in the product-development lifecycle as possible helps prevent your needing to play catchup or experiencing unnecessary churn. Lacking the necessary context or having to spend time unraveling ponderous design solutions resulting from a UX vacuum—which often happens when product teams don’t engage UX designers soon enough—squanders precious time.

Try to get involved in planning activities with each of your product teams as soon as possible. This enables you to better understand each team’s unique problem space and have a deeper impact on the resulting product user experiences. Moreover, earlier engagement lets you fail faster with your product teams, when risk is lower. If you must help one product team with late-breaking changes or reversing critical mistakes—which often leads to long hours and stress—all the other product teams that depend on you will experience that stress, too.

Choosing Your Battles

We must always choose our battles, but knowing when to acquiesce instead of taking a firm stance is a difficult skill to master—especially if you’re in an early stage of your career in User Experience or are new to your organization and still getting a feel for the culture. As I described in “Choosing Your Battles, Part 1,” you have a finite amount of capital in environments where User Experience is immature.

So don’t dig in your heels on issues that don’t merit that level of commitment. It just results in your own fatigue and contributes to that of your product teammates as well. Earning a reputation as someone who quibbles over minor pixels, but fails to recognize broader business dynamics or engineering realities makes product teams reluctant to engage with you when it matters most. Be selective about which issues deserve your energy and attention. Maintain a broad perspective. This is especially valuable and necessary when you’re working with a diverse set of product teams because you cannot be everywhere at once to fight every battle. Nor should you be. Getting too far into the weeds with a single product team compromises your position as a knowledgeable resource who can provide the higher-level perspective of a user’s journey across multiple products—a valuable vantage point that benefits all your product teams.

Of course, it is fulfilling to feel that you are an integral part of an individual product team. But it is important to avoid fixating on minutia—especially issues that are not related to User Experience, which you can leave to dedicated product-team members. Becoming distracted by such issues would only burn you out.

Keeping Your Manager Well Informed

Regardless of the quality of the relationship you have with your immediate manager, it is your manager’s job to help remove obstacles that hinder your ability to perform your work. Share your challenges with your manager. Don’t do yourself a disservice by suffering in silence if you feel your workload is overwhelming or your product teams are demanding deliverables that you are not qualified or sufficiently knowledgeable to create. Demonstrating candor and a willingness to ask for help are crucial skills in any job, which become especially important when you’re working with multiple product teams that don’t understand the unique challenges you face and may not even be aware of those challenges.

However, your manager should have in-depth knowledge of your project capacity and current workload and be prepared to offer the assistance of a colleague if necessary or even shift some of your responsibilities to someone else. Either would be a far better outcome than letting product teams—and your manager—believe you have all of your responsibilities under control.

If you don’t get help from your manager when you need it, burnout can ensue quickly, leaving you exhausted and dissatisfied with your job. Moreover, this could affect your relationships with your coworkers, family, and friends.

As with the perception that working long hours makes you more productive, the mentality that working with more product teams makes you seem more valuable to your organization is dangerous to your well-being. It can lead to your saying yes to additional responsibilities you don’t have the capacity to take on. While it is true that you can and should manufacture time for deep work, do not make time for things that do not add value at the expense of your own well-being or your performance with the product teams that are already depending on your contributions. Get help when you need it. A brief discussion with your manager is often all that is necessary to stem the tide of overwork. That is your manager’s job.

Conclusion

Juggling multiple product teams can be highly rewarding when you’re doing exciting, fast-paced work with different people across various parts of the organization. Diversity of experience is a core component of a successful UX career, and you should take pride and satisfaction in meeting such opportunities. However, as your portfolio of product teams grows over time, the need to cultivate solid communication and time-management skills grows proportionally with it.

You must manufacture time for yourself to engage in deep work because, without effective time management, you cannot contribute to the best of your abilities. This is especially challenging in our modern world of distractions, where the line between our personal and professional lives is often blurred. Establish boundaries. Your attention and time are precious resources, and you do not have the luxury of wasting them on needless activities that result in your having to work longer hours, which can lead to burnout.

Expose your full workload to everyone on your product teams and all of your project sponsors. If you withhold that information from them, they won’t be able to relate to your workload challenges, which could lead to misconceptions about your commitment to their project. Try to get involved in projects early. Coming onto a project too late and having to get up to speed quickly or having to reverse poor design choices can create unnecessary churn.

Choose your battles effectively. Resolving minor nuisances is not worth your time and effort when you’re working with multiple product teams. Keep your manager well informed throughout the lifecycle of your product-team engagements. Your manager should be in a unique position to understand the totality of your work and help you navigate conflicting or shifting priorities, helping you avoid burning out or failing to deliver on your commitments. 

User Experience Architect at Rockwell Automation

Cleveland, Ohio, USA

Jonathan WalterJon has a degree in Visual Design from the University of Dayton, as well as experience in Web development, interaction design, user interface design, user research, and copywriting. He spent eight years at Progressive Insurance, where his design and development skills helped shape the #1 insurance Web site in the country, progressive.com. Jon’s passion for user experience fueled his desire to make it his full-time profession. In 2013, Jon joined Rockwell Automation, where he designs software products for some of the most challenging environments in the world. He is UX lead for a revolutionary analytics appliance for users on the factory floor. In addition to his Fortune-500 experience, Jon has contributed his skills to a real-estate startup. Jon rounds out his time by writing and reading anything he can get his hands on.  Read More

Other Columns by Jonathan Walter

Other Articles on Teamwork

New on UXmatters