Finding Design Practice - Partnerships Fit

In our previous lesson about Model-Practice Fit, we explored the importance of aligning design teams with the business models and strategies for which they are working with/in. However, even with great Model-Practice Fit, the level of maturity in the partnership plays an outstanding role in how quality is defined.

In my experience (and hearing from others), every design leader will be faced with situations where cross-functional partners operate at different levels of maturity, prioritize operations over innovations, or make decisions based on gut feel rather than business 101.

This brings us to our second fit: Design Practice-Partnerships Fit.

There are five essential elements required to examine Design Practice-Partnerships Fit:

1. Understanding who your partners really are (beyond the org chart)
2. Understanding your partners' perceptions of success
3. Understanding the practical implications of achieving Practice-Partnerships Fit
4. Identifying strong indicators of having Practice-Partnerships Fit
5. Recognizing that Partnerships run on a spectrum, and the need for design maturity will be different with different partnerships

The wrong way to do it

When I first moved into Senior Management (my first time at EA), I was hired to lead a team of designers, researchers, front-end developers, and program managers. We were responsible for creating in-house enterprise software as it related to Customer Support. We worked along side a brand new engineering team as well, and that partnership was solid from the start.

I leveraged all the skills I had learned at Apple, and began to bring these into the design practice at EA. We had what I thought was a solid design practice: strong processes, talented designers, and a clear vision for improving the user experience.

However, we kept running into resistance from our partners in HR, IT, and frankly, my boss.

I thought we were doing our job well by advocating for users, testing, validating, and creating polished designs. We did this because this is what I believed I was asked to do. After all, my boss even said, “EA needs what you did at Apple.”

What I failed to understand is that I was no longer surrounded by the same types of partnerships, skills, and beliefs that I had at Apple. The team I was leading was five steps ahead from what my new partners at EA had experienced before. As a result, some partners were confused or hostile, while others were energized and excited.

I was treating design as a binary, one-size-fits-all approach and could not see where this approach was working and where it wasn’t.

I had fallen into the trap of thinking that our only job was to create "good design," rather than understand that another job was to help our partners succeed. I had fallen into the trap of believing my way was the right way to succeed, and that failure led to predictable results: delayed projects, missed opportunities, arguments, compromised designs, and frustration all around.

A better way to find Practice-Partnerships Fit

Later in my career, during my second time at EA, I took a radically different approach.

Instead of thinking about partnerships as a separation of skills and responsibilities, we started thinking about them as relationships we needed to nurture and strengthen. We started thinking about them in a similar way that customers adopt new products and services. There are some who are early adopters (they follow the new trends), while there are others who adopt late – often begrudgingly.

This time, we examined four key elements:

1. The Range of Success Metrics: We started by understanding what success looked like for each functional team. For Engineering it was velocity, technical debt reduction, maintainable code, reasonable sprint commitments. Game Studios were looking for feature delivery, consistent brand experience, and new competitive advantages. For HR, there was a strong focus on improving employee communications and perception. And for Customer Support, it was always cost savings, reduced ticket volume, and improving satisfaction.
2. Perception of Value: As they say, perception is in the eye of the beholder. Despite many of the teams we worked with having stated goals and metrics, quite often the senior leader of those teams made decisions that were personal. The senior HR leader for example had “owned” EA’s intranet for years. No amount of data letting them know that their tools were unliked and weren’t be used convinced that leader that they were making poor decisions.
3. Flexible Engagement Models: I have never seen or have been successful in having a single engagement model for how partners engage with the design team. IMO, the conversations on whether to work like an agency or be embedded leaves out two important factors: money and maturity. In the past, I’ve worked at several companies like EA where the design team worked on projects that came out of my boss’s budget as well as projects that came out of other departments. How a project or initiative is paid for greatly defines the engagement model. Many times, I’ve worked with Senior Leaders who needed help from the design team, but whose organizations did not need world class results in order to meet their goals. In this sense, it’s important to meet the appropriate level of maturity as it relates to the context.
4. Value Exchange: We clearly defined what each partner would get from the relationship and what they needed to contribute in order to get that value. Our focus was to clearly articulate the reciprocal flow of expertise, resources, and benefits between teams… write them down, and communicate them frequently throughout the project. By highlighting this give-and-take between teams, and recognizing both tangible deliverables and intangible benefits, it helped us assess and communicate the pros and cons of each proposed change.

One example of this fit was observed when we partnered with the VP of Customer Experience:

• Who: The VP of CX
• Team Success Metrics: To reduce bill-back costs to game studios
• Perception of Success: CX is the hero of the story
• Engagement Model: As the work was coming from their budget, we would act like an internal agency. They owned the prioritization, goal definition, etc. We owned the delivery, would deliver within their scope, and clearly inform them on what they would (and wouldn’t) be getting.
• Value Exchange: We would provide key skills and capabilities. Our skills and capabilities were only as good as their clarity on goals, priorities, and budget.

Team Success “Metrics”

In working with the VP of CX, we identified several specific challenges that influenced how we structured our partnership:

• Time constraints: The CX team was under pressure to reduce costs quickly, which meant the priority was to deliver value in shorter cycles
• Resource limitations: Like many support organizations, they had limited resources, primarily in building digital products and budget restrictions
• Technical legacy: The existing support systems were complex and interconnected, and not easily replaceable
• Business pressures: Each game studio was pushing back on support costs
• Organizational dynamics: The CX team needed to be seen as proactive problem solvers

Perception of Success

What made this partnership particularly interesting was the importance of perception. While the stated goal was reducing bill-back costs to game studios, we quickly learned that the VP of CX needed to be seen as the hero of the story. This meant:

• Ensuring the CX team got credit for improvements
• Creating narratives around cost savings that the VP could share upward
• Positioning changes as CX-led initiatives
• Making sure game studios saw CX as a strategic partner, not just a cost center

Engagement Model

Based on our understanding of both the metrics and perceptions of success, we customized our engagement model. Since the work was funded from their budget, we operated like an internal agency:

• They owned prioritization and goal definition. We owned delivery and execution
• We adapted a Service-Level Agreement format, a traditionally used document that defines the level of service expected from a vendor, laying out metrics by which service is measured, as well as remedies should service levels not be achieved. It is a critical component of any technology vendor contract.
• We provided clear scope boundaries upfront related to the priorities. If they changed the priorities, we informed them of the consequences
• We established regular check-ins using their preferred format. In this case, they operated using two-week sprints, so we incorporated two-weeks sprints of our own for the engagement.

This model worked because it:

• Gave the CX team control over their budget
• Allowed us to define quality standards within their budget, timeline, and goals.
• Created clear accountability on both sides. Matched their maturity level and needs.

Value Exchange

With the engagement model established, we created explicit agreements about value exchange:

From the Design team:

• User research via interviews and observations
• Prototyping in the browser
• Rapid usability testing
• Delivering

From the CX team:

• Clear goals and priorities
• Dedicated budget
• Access to support staff
• Decision-making authority
• Timely feedback

This clear value exchange helped both teams understand their responsibilities and prevented common partnership pitfalls like scope creep or unclear decision-making.

The Reality of Finding Practice-Partnerships Fit

Just like Model-Practice Fit, finding Practice-Partnerships Fit is an iterative process. Our work with EA's Customer Experience team provides a perfect example of this reality.

Initially, we thought our primary partnership would be just with the CX leadership team. After all, they were the ones with the budget and the stated goal of reducing costs. However, as we dug deeper, we discovered a complex web of necessary partnerships:

• Game Studios (who were being billed back for support costs)
• Support Agents (who used the tools daily)
• IT Infrastructure (who maintained the systems)
• Analytics teams (who tracked costs and performance)

Each of these partnerships required a different approach because each team had different success metrics, perceptions, and ways of working:

With Game Studios, we:

• Showed how support cost reductions wouldn't impact player satisfaction
• Created transparency in how costs were calculated
• Built feedback loops to understand their pain points
• Demonstrated the value of preventive support measures

With Support Agents, we:

• Involved them in early design decisions
• Created processes that respected their expertise
• Built tools that made their jobs easier
• Showed how improved efficiency benefited them

With IT Infrastructure, we:

• Aligned with their technical standards
• Participated in their planning cycles
• Created documentation they could maintain
• Respected their existing systems and processes

With Analytics Teams, we:

• Developed shared metrics for success
• Created dashboards that served multiple needs
• Built trust in the data collection process
• Established regular review cycles

Design Practice – Partnership Fit is Not Binary

Like Model-Practice Fit, Practice-Partnerships Fit exists on a spectrum. In our CX partnership work, we observed three primary partnership states that evolved over time:

1. Transactional

Initially, many game studios viewed CX purely as a cost center:

• Interactions focused solely on cost reports
• Minimal collaboration on solutions
• Success measured only in cost reduction
• Limited strategic input

2. Collaborative

As trust built, partnerships evolved:

• Studios began sharing player feedback earlier
• Joint planning for major game launches
• Regular informal communication channels opened
• Growing alignment on player satisfaction metrics

3. Integrated

Eventually, with some studios, we achieved:

• Shared success metrics combining cost and player satisfaction
• Deep understanding of each studio's unique challenges
• Proactive problem-solving before launches
• Full strategic alignment on player support strategy

Signals of Practice-Partnerships Fit

How do you know if you have strong Practice-Partnerships Fit? In our CX transformation, we looked for these key indicators:

Qualitative Signals

• Game studios began including CX in pre-launch planning
• Support insights were sought during game development
• Studios defended support budget to their leadership
• Informal communication increased between teams
• Shared vocabulary around player support emerged
• Studios confidently presented support strategies to their stakeholders

Quantitative Signals

• Reduced support ticket volumes
• Increased first-contact resolution rates
• Faster problem identification and resolution
• Higher studio satisfaction with support
• Improved launch readiness metrics
• Decreased escalations and conflicts

Intuitive Signals
The strongest signal was when game studios started presenting their support strategies to their leadership without needing the CX team in the room – not because they were excluding CX, but because they truly understood and believed in the support approach. They had become genuine advocates for player-centric support, not just cost management.

Key Practical Points to Help You Find Practice-Partnerships Fit

To build strong Practice-Partnerships Fit, focus on these key questions:

1. How does your design practice make your partners' jobs easier? (For CX, we made it easier for studios to manage support costs while maintaining quality)
2. What are your partners' primary measures of success, and how are you helping them achieve those? (For studios: launch success, player satisfaction, cost management)
3. Where are the friction points in your current partnerships, and what changes in your practice could reduce that friction?
4. How can you adjust your practice to meet partners at their current level of design maturity?
5. What value exchange model makes sense for each partnership?

Here at CDO School, we help you develop these partnerships through several key frameworks, step-by-step quick guides, and our course - COURSE: Activating Change.

Looking Ahead

In our next article, we'll examine Partnerships-Positioning Fit, where we'll explore how these partnerships influence how Design positions itself within the organization. In other words, how Design will decide what advantages only it can create that are needed at the company.

Remember: The most successful design practices aren't those with the most talented designers or the most refined processes – they're the ones that understand how to create and nurture partnerships that drive mutual success.