How to Level Up Your Design Team

Problem

Recently, my team members told me how they had difficulties owning their work and how they were concerned with the external perception of their commitment. To be able to own their work and further improve, they were looking for the direction from product management that wouldn’t always be present. They were spinning in circles doing research and competitive analysis and exploring design alternatives. As a result, they were not delivering.

I knew that without sufficient context and clear objectives, they were doomed to fruitlessly keep spinning in circles. As a leader, I was not only responsible for helping them find their way but showing them the way.

Actions taken

To help my team, I applied a three-part approach:  

Providing context

As a leader, I tried to provide sufficient, adequate and relevant context for my team rather than having them waste their time trying to figure it out by themselves. In fast-growing startups, you can’t afford to be spinning wheels for a couple of months until you explore all possible parts of the problem and solution space. Design teams are too time-constrained to research the competition or send out surveys to the users who would fail to provide actionable data. Spending time on these activities would slow the design team down and make them not trustworthy and out of step with rapidly moving Engineering and Product counterparts.

Clarifying objectives

Providing clear direction often means clarifying vague or inexact objectives. Lacking a clear direction, there was reluctance on the part of my team to explore options that were perceived as too far out by Engineering and Product. This is where I stepped in to encourage them to go and do it. If you want to change the perception prevalent among stakeholders that your team was not delivering on its objectives, you have to put yourself out there. Sometimes you would have to come up with work that would make people in Engineering and Product uncomfortable. They may push back to the vision that’s more far-reaching than what they are used to. But, eventually, they should be accountable to deliver on that vision.

Leading by example

I put my IC hat on and designed a prototype following the direction from the leadership that demonstrated one particular UX enhancement that no one from Engineering or Product would be comfortable with. However, there was a uniform agreement that it would be a significant win from a UX and product adoption perspective. I put together a few mockups that persuasively illustrated that vision. My leadership provided me positive feedback, which helped my team see not only where we should be heading but how.

Lessons learned

• As a leader, if you can’t deliver on your own commitments and can’t walk your talk, you have an inherent credibility gap. This doesn’t necessarily mean putting your IC hat on, but you should offer your team something concrete, beyond words, that will clarify the vision and set their expectations.
• Managers often understand their role to be s**t umbrellas that should protect their team from the leadership and stakeholders swooping in, delivering random feedback and erratically changing direction. Not surprisingly, there is certainly value in that. However, if leadership and stakeholders’ feedback is clear and consistent, it doesn’t make sense to shield the team from it. Instead, you should help them better understand how they are perceived and they will learn to appreciate that. If you keep shielding the team, they will be unaware of how their performance is perceived and thus unable to improve.
• I have a personal tendency to over-index on being humane and empathic toward my team members. But leadership is contextualized — there’s a time and place to be a caring listener, and a time and place to be a candid guide who will push the team outside of their comfort zone. Sometimes you will have to switch between these two modes rapidly and it is essential to master both.