I’ve wanted to write this article for some time to chronicle my own journey in design leadership, and some of the issues and adjustments that I’ve faced personally. This is the information I wish I would have had when I first made the transition to a lead role. However, leadership doesn’t have to include a management role or title. Leadership is about serving others and filling gaps in your organization or team to help build value, and support your team’s efforts. This can include creating processes where there are none, adding tools, templates, and guidelines that help build team cohesion, consistency and grow the collective knowledge-base.
“However, leadership doesn’t have to include a management role or title. Leadership is about serving others and filling gaps in your organization or team to help build value, and support your team’s efforts.”
Currently, I serve a team of 18 researchers, designers, content strategists and UI devs as UCD Lead on a large government project. I say serve, because they are the rockstars and I am the backstage manager and stage hand. Your job as a leader is to help the team do the best work they can do through guidance, mentoring, process improvement, and clearing obstacles that might slow or halt their progress. You want them to be successful, to try, fail, learn, grow and become their better selves. In a leadership role, you can help facilitate that growth, which means you have to give them room to try new things, and grace when those efforts fall short.
If you do have the honor of stepping into a leadership role with the title, logistics, resource management and all of the other day to day activities that come with it, you will find yourself in foreign territory with new challenges and opportunities for which you were not prepared. In this post, I will outline a few of the many challenges you may face, from corporate politics and expectations, to resource management and process. I will also address ways to approach these new hurdles, so you can form a plan of action to work through them. I can only hope that the lessons I’ve learned from my successes and failures can help you along your own journey from creator to facilitator.
Always the Diplomat
When moving into a leadership role there will be a new political landscape to adjust to, new expectations, and quite possibly a lack of support from your peers or leadership. People from the product teams on up to senior leadership will all have varied experiences with UX and its practitioners, some of which may not have been positive. Likewise, there are still many people who know very little about user-centered design. Before you can be successful in your new role, you will need to educate leadership, and quite possibly the entire organization.
When trying to build a user-centered culture, you can approach it from the hard way or the soft way. Some people approach it from a combative position, which becomes an “I’m right, you’re wrong” scenario, in which no one wins, as no one will give ground. Choose to be a diplomat, rather than a dictator. Find common ground with opposition and work outward from there. You will have much more success selling the value of UX, and find people are much more open to change when they do not feel threatened.
“Find common ground with opposition and work outward from there. You will have much more success selling the value of UX, and find people are much more open to change when they do not feel threatened.”
What do you do when the opposition has dug in their heels and refuses to give an inch? What do you do when you’ve exhausted all of your diplomatic options? There is a time to stop selling and start showing. I’ve been in this position many times and had no options left. In one instance, I set out to show them the value by applying research, design and iterative testing to a smaller project that was thought to have less value. My team was able to make a seemingly small and insignificant project into a game-changing tool for our users. The results were profound in this instance, but even if your results can show business metrics they care about (e.g. reduced development cost, improved adoption or retention, etc.) you will build the support needed. This will certainly not happen overnight, so you must be persistent.
Partner with Leadership
UX has worked hard to get a seat at the table, but we often lack the business experience and acumen to be truly effective. To begin with, we don’t speak their language and they don’t understand ours. Which means from the start we are not even communicating on the same level. In order to be successful, you need to partner with business leadership, educate them on the value of user centered design, and learn about their world. You need to be confident enough to build those relationships, help them understand the value in terms they can comprehend, and be humble enough to partner with them and learn from them, as well.
How should you go about learning about the business and bridging the communication gap? Apply your UX skills to your relationship with leadership. Research business leadership, as you would any other customer or user. Understand what motivates them, and what challenges they face. Learn their language and nomenclature, and help them understand yours. UX professionals often forget that others do not understand terms we use daily, and often alienate people as a result. Business leadership are the “keepers of the keys” and without building that relationship and making the bond strong, your efforts will fall short — or at the very least, not be as effective as they could be. At the end of the day, you are stronger with them than without.
Management 101
It has to be said… you are not just a creative leader, but also a manager of people. You’ll need to juggle resources, timesheets, budgets, software procurement, licenses and a host of other logistics. None of which is why you got into UX in the first place. That being said, you will still mentor, guide and help lead processes throughout the product life-cycle. Leading a team of researchers, designers and content strategists should be a rewarding experience, if not overwhelming at times. Your main goal is to facilitate and support others to do their best work. There are a few key areas to focus on when serving a team, beyond operational issues of scale: People, processes and outcomes.
People
At the end of the day you are dealing with people. Fragile human beings with real problems at home, work, their health, relationships and families. It is important not to objectify them as resources, and to know and understand them on a personal level. This is especially true when critiquing their performance, as it is always easier to hear feedback when you feel it is coming from a positive, constructive place. Establish that relationship early and let your team know individually that you are there to support them and help them grow. Let them know your feedback will always come from that position of support.
People also have strong opinions, which can lead to conflict. Sometimes a difference of opinion can fester and become large obstacles that ultimately affect the team’s progress and company culture. Outcomes suffer as a result and the finger pointing begins. Research blames design, design blames dev, and dev blames everyone. Essentially, walls go up and communication breaks down. This needs to be addressed immediately.
How can you prevent or mitigate conflicts on product teams? You must address the issue early and not let it grow. Before discussing as a group, hold one on ones with individuals to gain a better understanding of the issues. If the issue resides with one individual, a discussion with that person could possibly resolve the problem. If the problem has become more widespread, a group discussion in the form of a retro can help. Remind people of the product team’s goals and objectives. Make sure everyone is on the same page. As with any conflict, look for common ground and work outward from there. Remember to always come from a place of support, as the goal is to rectify the situation, not to demean anyone or show authority.
Processes
One of the biggest misconceptions when coming into a larger corporation or larger UX team is that they are doing things right. Teams often get caught up in circumstance, group-think, UX or Agile pageantry, and lose sight of the goal, produce gaps in learning and collaboration, or simply fail to gain a deeper understanding of the end user. Ask if what you are doing can be done better, more efficiently or effectively. Find the gaps. Ask your team if they have a solid understanding of the user(s), their journey and the problems they are working to solve. Are you testing enough, or iterating enough before committing to code? Do you have the tools and resources available to test and learn on a deeper level? Are you relying solely on quantitative research? Are you integrating UX with Agile effectively? Are their trade-offs? At what cost? Never stop asking questions.
There are so many issues that can arise from poorly defined processes. Communicating process or changes to the process is critical to keeping the entire product team on the same page. If your UX team is a shared services team or embedded within a cross-functional team, a clearly defined and communicated process will help to reduce issues and conflict down the line. There is no one size fits all process. Depending on the constraints, team makeup and level of UX maturity, you will have to find out what works for your team(s), and constantly look to improve and refine along the way.
Outcomes
“Outcomes over output.” Never will those words be more important than when you are leading a team and dealing with a business that confuses results with how much working software can be pushed out the door. Everyone from the business to clients will often know just enough to be dangerous after reading a book on OKRs, Agile or UX. Their lack of understanding or misuse of that information can create unrealistic expectations, which can soil good research and design. Be prepared to defend your team, their work, and the outcomes on which they are focused, as you help to reshape the collective understanding. Business people understand objectives and measurement. Given the right information on why user behavior should be the metrics to measure, they will get it. Which takes us full circle to partnering with the business and understanding their language. The more you understand them, the greater your chances of shifting the narrative from output to outcomes. Which is better for the user and the business.
Keep Calm and Lead On
Just like your experience working as a contributor in UX, the transition to leadership will require trial and error. You won’t get everything right in the beginning. You will fail along the way, learn, iterate, and do great things for your team and organization. Don’t expect a pat on the back, as most of the work you do to support your team will go unnoticed. The reward has to be the results your team produces. If we are not elevating those around us, we are failing them.
All of your success will come down to relationships. It’s about understanding people, their processes, problems, vernacular and expectations. Applying user experience to these relationships will help you better relate to and support the people around you. All of which require the important soft skills: communication, collaboration, negotiation, and conflict resolution. Maya Angelou said, “People will forget what you said, people will forget what you did, but people will never forget how you made them feel.” If you approach your design leadership role as a servant rather than savior, diplomat rather than dictator, you will succeed in making people feel they matter. This will make them more open to new ideas, new ways of looking at things and new ways to measure success. This is true if you are a leader, regardless of title or position.
written by Shane Close, originally appearing here