I have the same passion for being a UX Manager that I do for promoting good design. I can definitely be happy as an ‘individual contributor’ (warning: business-speak alert) but for the last decade and counting my time has been equally divided between crafting good design and building strong UX teams staffed with skilled UX Analysts and Product Owners who can fly on their own.
I bring this up now because I’m lucky enough to have been a Director, UX; Senior Director, UX; and VP, UX over the past seven years. So when I talk about design, I’ll frequently be talking about projects that I help drive with or through other UX team members. Please keep that in mind as you read on…
Being a good manager is an art in itself. There’s a basic formula I’ve developed for new UXers that’s consistently brought success:
- When filling a UX team position (UX Analyst or Product Owner in my case), give as much weight to the characteristics of a successful UX team member as you do to their resume and work samples. Is the person a good conversationalist? Can he or she size up the role and opportunity quickly and say how he or she will contribute? Did he/she do their homework to research your company / industry ahead of time? Can he or she be honest and own up to both strengths and weaknesses? Can he/she talk about areas of expertise and things they still have to learn? Spending time on getting to know the person as much as their past work provides the real insight into future success. I’ll often make a hiring decision based more on potential and what I see as ‘building blocks’ than on how slick a person’s resume or portfolio may be.
- Start with a solid training and orientation
- Set the person up with a strong support system including peers and other team members.
- Setup a series of 1:1 meetings for the first 4-6 weeks, then ask the person if he/she would like to continue?
- Back off at that point and trust the person to do good work and know how to leverage his/her support system, and when to escalate things to me for additional input.
Managing over a duration of time is another topic altogether. I could go on… Ask and I’ll be happy to do so.
Now the other part of ‘Teams’ that I want to talk about is team work: as in working as a team.
Long before Agile development got hot and took over the industry I would preach to anyone who would listen about what I called my “Big Brain Theory”. The idea was simple: Designers, or any other technology role for that matter, should never work in a vacuum. They are always better off work-shopping their ideas with others to see how they are interpreted (or misinterpreted) and to learn about what thoughts their ideas spark in others.
I like to bring my research and prototypes for review with a full cross-functional development team that included architects, developers, QA analysts, and yes, even technical publications. It’s pretty common for someone to see something I didn’t see or ask about something I didn’t think of or offer some new angle that I hadn’t considered. I take the feedback and go back to the drawing board then work-shop it again. And soon, after a couple of cycles, I end up with something that feels really good; really solid. Or – wait – more accurately, WE have something that we all feel good about.
That was the ‘Big Brain’ at work. It was the collective brain of the team.
Yes, I’ve heard about the ‘too many Chefs’ metaphor, but there are ways to avoid that. And I understand that you don’t have to workshop everything with everybody all of the time. But as a rule, getting team feedback is a good thing and I’ll stand by that.