Chapter 9. Successful Interaction with Other Disciplines
In Chapter 2, we asserted that design can play a role in each stage of development from idea to final offering, and that it should be woven into every aspect of the service from marketing to product to customer support. The challenge is that most organizations are structured and run in a way that keeps design as a phase in a production chain, as opposed to an activity that permeates the business. Designers are typically hired or added to a team too far downstream in a product or service lifecycle, and funding models don’t take into account the need to hire designers who aren’t specifically aligned to a product or service. In fact, most enterprise funding models are structured to support individual lines of business, further siloing designers and discouraging cross-lines of business collaboration. In the past, designers subsumed their work to cater to how other disciplines operated. In order to be most effective, design must collaborate with other disciplines and needs to maintain its own identity and practice.
Cross-functional teams have become ubiquitous because companies must accelerate speed to market; it’s essential that leaders pay attention to the way these teams are set up and how well they work. Yet, in a 2015 Harvard Business Review article, Behnam Tabrizi shared that of 95 teams in 25 leading corporations, nearly 75% of cross-functional teams are dysfunctional.[27] They fail on at least three of five criteria:
The main reason why most cross-functional teams fail is because silos tend to perpetuate themselves. However, projects that had strong governance support—either by a higher-level cross-functional team or by a single high-level executive champion—had a 76% success rate.
For design to succeed cross-functionally, it must have clear leadership and be seen as a peer. This means both organizationally—directors of design working with directors of product management, engineering—but also in terms of the specific people doing the design work. While the field of design has a deep history, its broad involvement within enterprises is recent. Because it’s not a mature internal discipline, its practitioners are generally less mature, which can make engaging with product management and engineering as a true peer exponentially challenging. Often outnumbered within cross-functional teams where there’s an acute focus on shorter iterations, it can be difficult for a lone designer to advocate for seemingly minute details, like animated transitions, that impact the experience. Great design is difficult to achieve in a reductive process or environment that is keenly focused on speed and efficiency.
So how can collaboration with other disciplines be approached in a way that is achievable, sustainable, and impactful?
The initial step has been the subject of this book up to this point—solidifying and elevating the design organization to ready it for making significant impact. Now it’s time to leverage all of the foundation, output, and management qualities in place to focus on successfully interacting with other disciplines. Plenty has been written about “how product teams should work,” usually with an orientation around a mindset and methodology such as Agile or Lean. We believe that every project should have an end-to-end accountable leader; clearly established goals, resources, and deadlines; and built-in review cycles to measure progress and plan for adjustments. That said, we are purposefully not delving into processes and methods (Scrum, standups, backlogs, sprint planning, burndowns, file management, specifications, etc.), as addressing them in detail warrants its own book. For our purposes, we focus on principles and practices that support strong cross-functional work, from the perspective of the design organization. Examples include:
Reinforcing the goal of defining and delivering a great experience from the customer perspective
Ensuring that design recognizes its role on the cross-functional team and demonstrates humility and equality
Developing, adapting, or following an agreed-upon design process best suited to objectives and the product/service
Acknowledging openly and often that organizational structure is perhaps the number one challenge for cross-functional teams and making an explicit goal to embrace this constraint
Phase 1: Achievable
Don Norman, widely known for his books on design, particularly The Design of Everyday Things (Basic Books), and his advocacy for user-centered design, has said “Complex things can be made understandable; that is the role of good design” and that “Managing this complexity and producing the things to tame complexity takes partnership.” At this stage, it’s crucial that design leaders work with business and technology leaders to wrangle organizational complexity by making agreements about business and experience goals and priorities, roadmaps, and funding, and identify and clear any potential roadblocks before the cross-functional team can get to work. This process of influence, negotiation, and definition is essential at the outset of any cross-team initiative in order to determine that the work to be done will be achievable.
The Definition phase of the Double Diamond framework addresses the steps needed to articulate a strategy and develop a plan for the offering. Perhaps most importantly, this phase relies on cross-discipline collaboration in that everyone (or, at least, product management, design, and engineering) is in the mix together, tightly collaborating to define the vision for the product/service. Because this cross-discipline work can feel quite messy, particularly when team members have not worked together before, make time to establish the team’s working relationships, paying particular attention to the four areas we’ll now discuss.
Clear Decision Making
Leadership of the group can be a significant challenge with cross-functional teams, and in large organizations, a governance model may be required. At the outset, and any time the focus of the work shifts, ensure that there is someone responsible for making decisions and articulating the rationale. At Adaptive Path, we utilize stakeholder maps (Figure 9-1) at the outset of an initiative as a scoping and planning tool to define core, direct, and indirect stakeholders as well as understand business needs/value and customer needs/value.
We’ve found this simple tool effective in driving the conversation and decision about who will ultimately be responsible for approvals. It’s also useful in identifying gaps in knowledge or alignment. If significant gaps are identified, that signals that the program isn’t ready for kickoff.
Design Team as Gating Function
We have worked at companies that tried to do too much with the teams they had. As a result, designers were spread thin, projects were half-baked, and once something was launched, it was then neglected. We’ve also seen improbable ratios of 20 product managers to 1 designer assigned with a never-ending backlog. Instead, focus on what’s achievable by examining the design team’s skills alongside the constraints of time and budget to focus on what’s achievable. Design’s role in the planning process should have three key elements:
Bring an empathetic perspective that understands what customers will find desirable
Use design methods such as sketching and prototyping to make the requirements concrete
Focus and scope the work
In order to focus, the design organization must have mechanisms in place for saying “yes,” “no,” or “not yet” to the work itself. Kristin spoke with a design leader who, when she first joined her new company, had a team of 14 designers. In her first few weeks, she observed that a single designer was assigned to support, on average, 5–7 “technology pods,” each led by a product manager and a development lead, and composed of developers and testers. At the same time, the frequency and variety of additional requests for design support overwhelmed the number of designers on the team.
She soon hired two design program managers to focus on intake (qualification, prioritization, pipeline) and capacity planning. Over the course of eight weeks or so, they met with each business leader to better understand their roadmaps and top one or two priorities. They then led full-day, deep-dive sessions to understand the problem space, human and business objectives, and stage(s) of work. With this data in hand, they could assess skill sets needed and align design talents to formulate a design portfolio plan.
The plan, easily captured in an Excel file to enable collaboration and revision history, included top-level initiatives, value to the customer, value to the business, a team-based approach and clearly defined team structure, skills needed, timeframe, and a hiring plan. By modeling human-centered design practices to better understand and scope the work with partners, they were able to articulate and support the #1 and #2 priority within each business group, enable and improve the partnership between design and product management to frame problems to focus on both the business and human value, align the right design skill sets paired with the right project(s) at the right time, and provide transparency across the business of the highest priorities for which design was aligned. This effort, while substantial, took about four months but allowed them to see connections and make better informed decisions. And in taking the time to understand the problem space and phase of each initiative, they were able to cover more with the same team.
Maintaining Quality
While quality is everyone’s responsibility, it is the designer’s responsibility to articulate, demonstrate, and uphold what quality means for the experience. This can run counter to the behaviors and processes that non-design team members—accustomed to being valued for delivering with speed and efficiency in their roles—bring that can discourage the quality of the experience.
Quality can be broadly interpreted to mean a standard of something as measured against something similar. In the design organization, it’s easier to define and assess quality against other designs. But when in a cross-team setting, each team will bring their own definition and standards for quality. Take the time to ensure that everyone on the team understands what is meant by quality.
Ideally at the outset of the project, define what quality means by giving everyone on the team something to reference. This simplistic approach is especially important for teams working toward common goals, but from different disciplines. In our experience, we’ve addressed quality in several ways. We collected examples of high-quality design on our Basecamp site. The working space included an area for examples. And we included quality assessment as a lever for moving work from in-progress to ready for production.
Defined Roles and Expectations
Clear goals, aligned leadership, focus, skill sets, and quality standards are essential for successful cross-team collaboration, but perhaps most important is the definition of roles and expectations for participation. Once the team has been identified, spend some time getting to know one another. Margaret Gould Stewart, now VP of Design at Facebook, created a set of attribute cards to use for setting expectations for individuals on teams. At Adaptive Path, we often used these sets to guide a “what we want from you” exercise to help set expectations about roles.
In the set there are 15 cards (Figure 9-2), each with an attribute and a description. At the outset of a project, the team would discuss and select the top 1 or 2 attributes we expected from each team member. We’d capture images of each team member holding their selected cards and post them somewhere prominent in the project space or via our project management site (Figure 9-3). Ideally, this exercise sparks conversation that flows to interests, strengths, and opportunities for growth and better collaboration. This can be especially useful on teams where people may not have yet worked together, and come at the problem from very different perspectives. Whatever the activity, it’s important that teams have the opportunity to meet one another as people, rather than just showing up to play a role.
With clear goals, decision making, and roles and expectations defined, a clearer plan will evolve for the cross-functional team. It’s during this stage that folks have a better sense of marching orders, and more typical design and engineering processes come into play.
Phase 2: Sustainable
In our conversations with Bob Baxley, he highlighted the importance of taking the time to “design the machine that designs the designs.”[28] While the plan assumes that everything must fall into place in order to deliver, not explicitly stating how the work will be coordinated and facilitated across multiple workstreams and initiatives can prove disastrous. And simply inserting experience design methods into a development process will not improve the experience. To support the plan, it’s essential that designers and the design team have clear direction and guidelines to protect maker time, communicate effectively, understand when and how to escalate issues, and gain insight into one another’s work so that they can best map design tasks to the overarching schedule and roadmap.
Protecting Maker Time
In discussing design team culture, we mentioned the importance of protecting maker time within the design team. When a designer is working on a cross-functional team, the frequency and volume of meetings can increase exponentially, as the designer is inevitably juggling being part of both the design team and the cross-functional team. This can lead to zero time for actually doing the design work. As a team, take the time to decide how to structure each week. Refer to the cadence we discussed in Chapter 8 or look to other teams who may already have a good solution. Identify blocks of protected time for doing the work and blocks of time for reviewing the work. For meetings that affect the team’s work, but don’t require designers to share out or collect feedback, send the design leads who can make decisions on behalf of the team and bring back information. Most importantly, ensure that the rest of the cross-functional team understands and respects the cadence of “making” versus “meeting” time, and that there is someone on point paying attention to and resolving any tensions that may arise.
Design leaders must remember to have frequent conversations about drawing boundaries, taking time to recharge, and setting a strong example of what proper work hours look like. Teams and individuals need to know that it’s acceptable and encouraged to have a balanced work life.
Operating Agreements
Consider using an operating agreement to outline how to interact with one another and think about problems, and productively escalate issues for resolution.
Example of topics to include in an operating agreement:
How we’ll integrate as one team
Communication plan
Availability of key staff for work sessions
How we’ll work with the Insights group—access to key insights, and for new research, timing, recruiting, protocols, and field research
Stakeholder approvals and timing
Process for escalation and issue resolution
Assumptions for deliverables—timing, type, and fidelity
To create an operating agreement, facilitate two sessions with the full team. In the first session, brainstorm ideas without judgment or discussion, then discuss ideas and build an affinity diagram. Let ideas rest for at least a day, then reconvene to review the work, discuss and modify any ideas or categories, and finalize the list. Finally, publish the operating agreement alongside or within your team charter as a one-pager or slide in a deck.
Communication
Key to successful collaboration and healthy team dynamics is keeping everyone in the loop. Even if the updates are brief, daily or semi-daily communications through a project management tool like Basecamp go a long way to provide insights and confidence to other team members and stakeholders spread out across the organization.
Ensure that everyone on the team can speak each other’s language. In large organizations, jargon can take on a life of its own, so encourage everyone to clarify terms. Create a document to capture terminology and frame discussions around goals and objectives.
When a design organization grows beyond 40 designers or so and is spread across different geographies, the challenge of staying connected grows exponentially. To address this, be explicit about expectations around insights and knowledge sharing. Designate a team to create and manage a shared insights repository for customer research. Create or carve out a role dedicated to “communications” or “storytelling” with responsibility for things like consistency of voice and tone, internal blog posts, guides and checklists for facilitating cross-team shareouts, newsletters, and internal event planning and coordination.
Phase 3: Impactful
Taking the time to establish a solid foundation focusing on achievability and sustainability will enable the team to be up and running, gaining velocity through growth and learning, and, ideally, delivering on the roadmap. At this stage, it’s not just a matter of following a specific plan. Instead, continuous monitoring and adjustment to the plan is essential. It’s also crucial that someone is assessing and addressing overall project health—team satisfaction, partner satisfaction, risks, success—on an ongoing basis, not just the progress toward milestones.
A design leader should reinforce that successful cross-functional teams think in terms of programs, not just projects. It’s natural for participants on a team to focus on just their work streams and deadlines. The product lead and technology lead will present progress against business or performance metrics, and it’s the design leader’s responsibility to consistently frame discussions, meetings, and feedback through the experience lens. This means participating in customer research and bringing in research findings from customer interviews and call center transcripts to reflect back the experience that customers and potential customers are having.
At this stage, there should be a clear understanding of the design organization’s maturity and the value that it provides. Roles and gaps have been clearly identified and a clearer path to get there will be evident. To ensure that cross-team collaboration is as impactful as it can be, we recommend these activities to monitor the team’s impact:
- Survey the team
Ask everyone on the team two simple questions: What’s working well? What’s not working? Identify the top three in each category, as well as the overlaps, and put a plan in place to address them. Assign owners and small teams to lead initiatives. This should happen at regular intervals and any time a major milestone is completed.
- Make a plan
Analyze the survey data and map the results to business and customer value and use examples from other organizations both inside and outside the company. Call out any previous efforts and their results as to what worked and what didn’t. Create actionable 30-, 60-, or 90-day plans for each initiative that outlines activities, outcomes, and support needed. This can be a one-sheet containing three columns for the timeframes and three rows for the activities, outcomes, and support.
Conclusion
Working cross-functionally should feel a little different than working within design. Remember to:
Respect others’ opinions and listen to everyone’s points of view
Challenge assumptions, but don’t challenge individuals
Articulate a rationale for design decisions
Build the plan to account for high-friction milestones like handoffs between teams and on- and off-boarding team members
Don’t take things personally, but also don’t tolerate negativity—address it directly
We believe that great teams design, build, and deliver great products and services. No one person, team, or organization should hold responsibility for the outcome. We also recognize that there will be innumerable challenges in getting to the ideal state when interacting with other disciplines and that none of the things we have outlined will be achievable without strong leadership and considerable peer influence. Consider our approach a north star, taking into account the conditions for success and challenges that exist, and adjust as needed to effect the desired outcome.
[28] Bob Baxley’s talk on “Designing the machine that designs the designs” can be found here: https://vimeo.com/166885565.