Scaling Design through Relationship Maps

Scaling Design through Relationship Maps
Michael Polivka, Director and Chief of Staff for Experience Design at Autodesk

From the Design Operations Summit website:
Design groups are no longer fringe in large corporations. We’ve grown up, and our numbers have multiplied; which is exactly what we wanted. However, we now face the challenge of integrating—at scale—with our organization’s cultural and operational fabric. Understanding which stakeholders are most needed to support our DesignOps ambitions is a great place to start garnering influence and yielding intended outcomes. Relationship maps are a powerful tool to humanize the process and chart the course.

Michael capitalizes on interconnectivity to promote design at scale.  He empowers designers to do their best work through communication, toolsets, and team dynamics.  He thinks of himself as a systems thinker – he likes connecting dots.  He wants to tell us how he does that at Autodesk.  You can follow him on Twitter at @michaelpolivka.

Historically our tools were quite different than they are today.  There was Rubylith was film, razor blades, and tape.  Later there was Quark.  And now we have computers helping us design and print.  One of the great tools in that period was Director.  It was a big deal for him, because it allowed him to make interactive experiences on the screen without developers.  Up until then, all the tools were about craftsmanship.  But look at our portfolio of tools today:


The big thing that has changed is that communication and collaboration runs through all of this – it matches our roles and responsibilities.  This is true the context of Agile, and not just in engineering.  We’re influencing processes all across the company.


We have more designers with ore responsibility, and more budget.  The Design in Tech Report (2017) shows that Facebook, Twitter, and Amazon have grown their UX teams 65% in the past year.  We now have designers represented in executive leadership.  This was unheard of five years ago.  But now we have Kristin at Capital One, and Maria at Autodesk.  Experience and design are now part of our corporate bands, they are away of differentiating our companies.

We do have growing pains, and the ways we work today will not help us achieve scale.  Design Ops is a gateway between designers and the company at large.  Yes, we need some buffer from the company, but we need to start bringing the rest of the company into our space, too.

This is a still from a video created by the Autodesk research team:


This is a circular org chart, with the CEO is at the center.  The team he is in has 18 people in an organization of 8K; the product part of the organization is 4K.  Design is decentralized, but we rely on volunteer armies because there are ~150 product teams.  They are a horizontal team that provides vision and leadership, programs, and design ops into the product teams.  They work outwards – their job is from the inside, out.


Maps help us navigate complexity.   We need relationships to get things done.  Think of this as a mash up of stakeholder map and strategic plan.  This is particularly useful when teams are small or you are working alone.   It is a good way to get people to take ownership.   The org chart is formal reporting, and the relationship map is about networking.


People are the key ingredient in relationship maps.  Design is no longer on the fringe, we need to integrate better.  We need to increase professionalism and not lose our sense of play.  We have some relationship debt to work through.




There was a campaign from Apple in the 90s that spoke directly to creative and designers.  Now one of their spokespeople is The Rock.  He is about broad likability and influence – which is what we need to be focusing on as designers.

This is a case study for rolling out InVision.  They chose it based on their needs.

Their designers were working in silos, disconnected, solving similar problems in different ways. Design was behind the curtain.  That ran counter to the goal of having a cohesive family of products.  He assembled a Tools and Resources Taskforce.  Those that volunteered wanted to change the culture of design for their own reasons.


An org chart wouldn’t help him – he needed to create purposeful connections to get things done.  He had three major steps.  The first was to create the map by connecting the dots.  With his role in design management, he could recruit across the company.  Second, the vision must be clear and easy to communicate.  Finally, he started to identify and bring in those who can own aspects of the effort, and get things done.

He was the only one on his team working on this.  There were three teams in the task force, fifteen people in total.  And there are two executives, our finance business partner, and procurement.  He hadn’t ever worked with some of these people before.  Legal and was involved, and also IT for things like SSO.  So he proactively worked with them, for the first time.  Finally, he involved in the InVision support team.  The sales experience was good, but the transition from sales to support was unknown territory.


This initial map was maybe 50-60 people – it is too much, and not sustainable.  So he needed to create something manageable for himself.

He focused on program manager, Christina, and there was also a team captain so Christina could oversee a couple of teams.  Maria helped him understand how to communicate Amar in terms Amar would understand.  He picked a single person from Procurement who had a lot of accountability, and he built a good relationship with Jon in Legal.  With IT he had a point person who owned the SSO team.  Lauren was their customer success manager and their primary contact for InVision.  And just like that, he has a manageable relationship map:


Establish common ground.  How do you create win-win situations for people who have other responsibilities?  What are the areas of mutual benefit?  How can you really get in there and create something of value for them as well. If people are giving 10% of their time, how can we give something back to make it an even detail.  We also need to agree on the definition of success – clearly stated for everyone.  He tried to ensure that his asks were aligned to their interests, and he worked hard to build his brand and his legacy with each person. He came to understand what was important to each member of that core team.

Express gratitude.  This work can be thankless, and every single inch is earned.  They are supporting something that you are responsible for – acknowledge that, appreciate them.  He communicated, gave recognition in their Applause tool, and he took people out.

How did he ultimately affect prototyping, design, and production?  People went to a URL and their account was created on the fly.  They now have 1900 employees using it on 1800 projects.  They have created 40K screens, and 25 new projects a week.  The number of people is way larger than the 400 designers!  Even executives are now looking at what’s going on in design.  So now they are focused on fostering adoption, driving the change.  They are working on integration with Slack, Sketch, and Abstract, and then they also need to find a way to bridge design to engineering.



You mentioned Amar is a numbers guys.  How did you make the quantitative case?

He wanted to show cost savings in quantity, discounted through volume purchase.  And then broadening the usage as well across more product teams – ultimately they hope the ripple effect will help to drive participation.  Costs were driven down by number of users and a multi-year contract.

Wondering how you established the taskforce.  What were the roles of the people?

It evolves constantly.  He has been there a few years, but he took ownership of it after being there 6 months in. He grew it to 12-15 people.  It is a lot of work – he had to find people that were interested, and it was a manual effort.  It wasn’t just designers, it is front-end developers and a program manager from a totally different group.  We keep people for awhile, and then they get pulled into product, so we lose them briefly or permanently.  It is inefficient, but it is the only way.

Did you come across any political barriers in terms of ownership over teams and team members?  If so, how did you deal with that, or facilitate communication between teams that are siloed. 

Amar didn’t mandate it, but he endorsed it.  But they didn’t pull that card.  Some groups want more autonomy than others.  Some groups were migrating, others were starting for the first time.  So they focused on having leadership explain the benefits.  And, it was a free tool for them – that helped as well.  His team was totally owning the change, but not taking anything away.

When we have new tools coming out every day, every week.  How do you decide what tool to use, and for a company of this scale?

That was a tough decision.  The team was mostly designers that had a point of view.  At the end of the day, we just had to make a choice.  Just lock down and do it.  Adobe XD was coming out and there was a lot of hype.   Right now they have a one year agreement with two-year price lock.  Other teams at the time were looking at new tools, constantly evaluating new things, and his group has done some pilots as well.  Change happens, if InVision is not the answer in a year, so be it.  That’s capitalism for you.

The slide where you outlined the outcomes.  What impact did those outcomes generate?

It take some time to affect product, especially for teams that have never worked in this way before.  He is looking at some metrics, he’ll be able to share them in the future.

Liked the description of how you initiated the process.   How do you address when more groups come to you for help, and how you choose where to engage?  If you have created a taskforce and more groups want your services, how do you then say no – if too many people come, how do you pick and choose?

He hasn’t had that problem yet – he will take all sorts of volunteers.  He has a high rate of turnover, so he hasn’t crossed that bridge that.  If it doesn’t, he would create a specific team focused on an issue, within that same structure.

At American Airlines they are a centralized unit, and they have so many teams looking for service, we can’t sustain it.  

Design is decentralized, so we don’t have resources that go out, just efforts that go out.  But they do discuss priorities within their taskforce.

In addition to using relationships maps to gain an understanding how to work with others, how much do you socialize it to help other people achieve the same level of understanding?  

The three main people he shared the map with was Maria (his boss) and Christina (program manager).  Most of the designers don’t care that he’s working with Finance, Legal.  If he wanted to be more self-promoting … but it’s pretty much a thankless business.

1 Comments on “Scaling Design through Relationship Maps”

  1. Pingback: Дайджест продуктового дизайна, ноябрь 2017 | Юрий Ветров об интерфейсах

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: