Google recently launched it’s NFC-based payment solution, Wallet. For a company like Google, strong in engineering but less so in design, Wallet was a particularly risky product to build. You can’t half-bake the design of a consumer payments product. It has to instill absolute confidence among its users. Workflows have to make complete sense with a minimum of learning. You can’t do it the same old Google way.
In the face of those risks, the product launched to reviews like this from Greg Kumparak of TechCrunch:
Google Wallet is great, magical, impressive, and all sorts of other positive adjectives
How did Google do it? How did we get good design done in an engineering-driven environment? This article is a record of the strategies I used in my time as UX manager over the Commerce group at Google (which covered a range of products including Wallet).
1. We fished for champions
To get good design work done in a non-design-driven company, you simply must have a champion with decision-making power. If you’re a design leader and you don’t have a champion, you have to get one. Make this your single most important goal. It’s a rare design leader who can charm a hostile audience and bend them to their view of the world. Focus on people who have characteristics that lend themselves to being influenced by the contributions that UXers can make.
On Wallet, Google Commerce VP Stephanie Tilenius was an obvious person to focus on from a pure power perspective, but she also had other characteristics that made her a logical focal point for relationship development:
- She had a passionate desire to force Google to break out of the pattern of mediocre product launches.
- She had the intelligence to understand the value of good design in creating high quality customer experiences.
- She was new to Google… the engineers weren’t completely comfortable with her non-engineering-y leadership style. She didn’t appear to have many allies in the organization. She needed UX as much as we needed her IMO.
How you actually build a relationship with an organizational leader is the subject of another post, or book, but the short version in this case is that, in any communication with Stephanie, I emphasized messages that touched on the characteristics above. “Here’s how we’re going to avoid a Buzz-style launch”, “as you can see, this design makes anything else Google has produced appear average”, “here’s how we can use design review to improve product quality”, “you really need your first product launch at Google to make a big splash, and this design can do that”, etc. This was not about deception. It’s a repositioning of design work and design process to connect with the needs of an individual who is empowered to help you and your team get good work done. I genuinely wanted Stephanie to succeed and in turn for us all to succeed. Cultivating a tight relationship with her was absolutely central to our success.
2. We stopped talking like designers and started talking like locals
To get good design work done in a non-design-driven organization, you have to use the language of the organization. Using the language of design may be useful if you’re talking with fellow designers, or if you’re an agency pitching services to execs. But when you’re in-house, you need to talk in the language of the house. At Google, the house prizes the launch above all else. When communicating with engineers and PMs, I tend to avoid discussing anything that isn’t clearly connected to the launch.
On Wallet, I rarely talked to an engineering manager without expressing my anxiety/excitement/desire to get the product shipped. “Look, I don’t care about blablabla, I just want to get the best product shipped as soon as possible.” And this was true. It’s what I genuinely wanted. But I needed to make sure that my engineering counterparts knew that that’s what I wanted. Because we had this common goal, I had great partnerships with eng leaders Wall, Rob, and AZ.
3. We generated both excitement and anxiety about the vision
To get good design work done in a non-design-driven company, you have to exploit your story-telling skills to paint the picture of what is and what could be. Designers often forget that we have the power and skills to craft a product vision in a form more tangible to humans than a PRD. By prototyping and presenting the user experience vision, and getting engineers excited about the prospect of building such a vision, we create the conditions for our vision to become reality. On the flip side, if a user experience is less than adequate, we can use our story-telling powers to raise anxiety about – and action on – the inadequacies.
In the case of Wallet (and Shopper/Offers), we created – as most project teams do – a presentation of user interfaces outlining the core use cases. We mocked onboarding flows, transaction flows, and movements between applications. We highlighted the clunkiness of app transitions. We highlighted the unnecessary inconsistencies resulting from lack of coordination across disparate project teams. We also highlighted how frighteningly simple and straightforward the Wallet experience was. The presentation told the complete story – warts and gems – of the mobile commerce experience. I delivered it weekly to Commerce leadership. Critically, we printed the presentation and pinned it on the wall in Stephanie’s office, updating it as new designs came to hand. She was able to see the good, bad, ugly of what we were building along with our post-it notes and commentary. We got her and the rest of the team simultaneously excited and upset about our direction. This was a huge help in getting the team focused on solving the most problematic wrinkles in the experience while protecting the good stuff.
4. We didn’t short change visual design
To get good design work done in a non-design-driven company, you have to acknowledge that many Silicon Valley people think that design is only about how products look, not how they work. “You guys make our stuff look pretty”. You can use this to your advantage. To entice executives and engineers/PMs to view your team as a credible design group, present visual design work that blows them away. Wireframes are nice, but high fidelity mock ups are much better.
On Wallet, we were short on visual design talent. Jonathan Yu had his hands full with interaction design work. The talented visual designer Sunkwan Kim was spending more time on Emerald Sea and less with us. We had zero visual design support. I had some contacts at a New York-based design agency. I called them to see if they were available. Coincidentally, the same agency was supporting our marketing team. I put the enthusiastic Chris Nesladek on point for directing their work. As you should expect with an agency, the quality of their work was variable, but the good stuff was excellent. They were able to work with Chris’s direction to develop a tight visual design system across all of our mobile applications. The visuals got our stakeholders excited. More importantly – right or wrong – their visual design work helped raise the perceived quality and importance of our collective design work.
5. We aired bad blood, fast
To get good design work done in a non-design-driven company, you have to resolve conflicts fast. Conflicts between eng, PM, design will arise. They always do. In an engineering-driven company, UXers should prepare themselves to lose most of the battles. Certainly, in a rational company like Google, decisions are made based on merit. But decision makers – unconsciously or not – tend to agree with like-minded people. And that’s more likely to be an engineer or PM, than a UXer. The best you can do is to get all of the affected parties together to air their complaints when conflicts occur. In many cases, when you do so, everyone will realize how stupid the arguments were and will all go back to work. But there will be legitimate gripes. Have everyone air their thoughts. Go around the table. Write down the grievances and start to whiteboard ideas on how to reach a compromise. Show that you want to make allowances. People will reciprocate.
Wallet had some detailed arguments about the fundamental direction of the product. Was it going to be a consumer product or was it a system utility? These decisions would fundamentally influence how the product would be positioned from both marketing and design standpoints. The consumer angle eventually won out, but not without some disappointed people. The good news was that those people got the opportunity to voice their disagreement, were able to make their arguments, and did so to the group leadership.
6. We got the right people on the right tasks
It goes without saying that to get good design work done, you need to have solid talent. But talent isn’t enough. You also need to manage and allocate that talent effectively. Huge projects like the Wallet/Shopper/Offers combo cannot be done by one designer. It takes a team. For that team to be successful, you should have some knowledge of each team member’s strengths, and you need to be opportunistic in assigning those strengths appropriately to get the work done well. This is where the role of a design manager becomes more like a baseball manager. You need to know when to sit your starter, when to bring in your pinch hitter, when to warm up the bullpen, and when to ask the GM to recruit a slugger … if you have a GM. Wallet was fortunate in that we had the right set of personalities at the right time IMO:
- When I started in Commerce, Jonathan Yu and Sian Townsend were the UX team members on Wallet. Jonathan was a very solid, mature, all-round designer. Strong in interaction design, he produced many iterations of the core workflows while the Wallet team was determining the product positioning. Importantly, he had an optimistic attitude and was able to collaborate well with engineers to establish the core interaction and conceptual model for the product. Jonathan was the perfect person to establish a “beachhead” for UX with the Wallet team. Sian Townsend was a technically brilliant researcher who was able to boil her findings down to useful chunks for her audience. She had a keen sensitivity to people’s willingness to accept research, rolled with the punches and got work done in an agile spirit. Yet she was never afraid to raise usability or fundamental product issues that were overlooked. She was a voice of reason.
- Chris Nesladek had been coordinating with Frank Harris on Google Offers but as I spent more time with him, it became clear that he had the most expertise in mobile (coming from Android) and, more importantly, he was the only team member who pushed the broader organization to think about the cross-product implications of their work. Chris was a prolific, detail-oriented designer and had a passionate approach to asserting his vision. He was the ideal person to coordinate a unified design system across Wallet/Shopper/Offers. I recruited him to take on this role, and while it took some time for engineers to warm up to him, he was very effective in forcing discussion and resolution on the most critical user experience issues. He was the change agent that every challenging, multi-team project needs.
- I recruited Alex Cook to the Wallet team knowing that he would be the closer: the designer who could build a team to get the project over the finish line. Alex tends to take big hairy design problems, somehow comes up with rational solutions, then works closely with engineers or directly with code to close out all of the details to get it launched. Perhaps his greatest strength though is in building teams. And that’s what he did. As Jonathan and I transitioned out, Alex came in, recruited and oversaw the team of designers that got Wallet to launch.
So these were a few of my take-aways from the Wallet experience. Not necessarily revolutionary information here – this stuff isn’t rocket science – but interesting to see it applied in a real world context. I didn’t stick around to see Wallet through to launch. That is perhaps one of my biggest regrets re: leaving Google. Still, it’s fantastic to see such a relatively well polished consumer product delivered by a team at Google. It’s a rare thing. Against the odds, we got good design work done. All of us.
This is an edited version of a post that appeared on Graham’s personal blog.
As startups grow and succeed, employees with no management experience are asked to become managers. Some dread the opportunity. Some relish it. But all ask: “how do I get started?” A few high performing designers and researchers – and freshly minted UX managers – at Google have asked me this recently, so here are a few of the techniques I’ve used.
It’s not about you
First things first. Write down your goals, your vision, your fantasies. Write down all of the amazing things that you hope to be as a manager and leader. If you want to be Jony Ive, write that down. If you want to be Dieter Rams, write it. When you’re done in dreamworld, take this list and file it away. You are none of these things, and you won’t be for a long time. But you should dream. You should have a vision. Write it and file it. Come back to it when you’re ready. Your first few months as a UX manager are not about you.
It’s about your team
Next, schedule one on one meetings with all of your direct reports. It’s important to allow a good chunk of time for these meetings, say 1-2 hours each. You may only need to use 15 minutes, but some team members will want to take a full day. My general structure for a first meeting is to focus on projects, asking 2 things for each: what’s working and what’s not. You can get to existential questions in future meetings.
I’ve found that “what’s working?” leads to lots of great discussion. It’s an opening to discover work and collaborations that your team member enjoys. Take special note of collaborations. If there are people from other disciplines that your team members enjoy working with, chances are they are open to more collaboration with UXers, including you. If your team member shares work with you, it’s important to resist your desire to critique. You will have that opportunity in future meetings.
What’s not working?
“What’s not working?” will be their chance to vent or pontificate. Let it happen. UXers are emotional people. They put their work out into the world every day, and every day that work is critiqued by people who have no background in UX and no place critiquing. You know how demoralizing and frustrating that can be. Chances are very good that at least one person on your team is ready to explode. Use this session to actively listen. It will be therapeutic for your team, and invaluable for you. Make special note of problematic co-workers – chances are good that you will need to interact with them or their managers in the future.
Anything else I need to know?
The last thing I ask is if there’s anything else I need to know. This discussion may start quite innocently with upcoming vacations and unfulfilled requests made to previous managers. But you may also uncover some more significant issues, some that may warrant HR (if you have an HR department) or founder-level involvement.
Getting to something actionable – The Top Three
When starting out as a manager, it’s important to get runs on the board early. It shows your team that you get things done, that you’re here for them, that you listen. It builds loyalty. After your meetings – what’s working, what’s not working, and anything else – you’ll have a huge list of issues to deal with. It can be an overwhelming list. To get runs on the board, focus on three things in your first month:
- Issues with co-workers
Paperwork can appear inane – like approving a vacation, requesting a promotion review, clarifying compensation information – but can be extremely valuable to your team members. People tend to avoid dealing with higher levels of management or HR, sometimes to their own detriment. Take care of these issues for them. Be careful to differentiate between what an employee can do for themselves and what you should do as a manager. If you feel like you’re being someone’s admin, push back.
Workload is almost always a problem. UXers are overworked. You should use your judgement to understand whether there is a legitimate workload issue. If you think it is, there are a few strategies you can use. First, don’t allow any more work assignments to your team member. No new projects. Second, take a look at the list of projects in their pipeline. Many UXers feel overwhelmed simply because they have lots and lots of small projects. Context switching is a time waster and productivity killer. If you see anything in their project queue that could be better handled by an engineer or PM, write to the project team and let them know that you’re moving your person off of their project. Ask to meet with them to understand how you can transition your person off of that project. Don’t leave teams in the lurch, but don’t let them take an allocation for granted. Third, make a note of the other projects in their queue. You won’t be able to fix workload in those projects in the first month. Save them for later.
You can’t expect a quick fix when one of your team members is dealing with a problematic co-worker. It will take time. But get the ball rolling now. Meet with that person and their manager. Understand the issues. Get the context. Listen, and don’t try to be a hero. Just injecting yourself into the conversation can make a difference. Many problematic people become aware that your team member has an advocate, and may back off or adjust their behavior. But others won’t. This later camp require more work… and another post.
You need to get to know your stakeholders. Here’s where you get lots of ideas for making a difference and building your influence in your company. That’ll be the subject of a future post…
In sum, when starting as a UX manager:
- Write down your personal goals and file them away for now. It’s not about you.
- Meet with your team members. Understand what’s working, what’s not, and anything else.
- Get stuff done in your first month. Clean up paperwork. Address workload. Start conversations with problematic co-workers.
Most of us know the story. You start your career as a front-line designer, researcher, coder, or writer. You love what you do. You love being a part of the process of making new stuff. Or making old stuff better. By some random series of events – some might say misfortune – someone eventually suggests that you have leadership potential and gives you a team of anxious/ambitious new grads to manage. Or perhaps your freelance work is so successful that you’ve begun to hire junior designers to take on some of the load. Either way, your responsibilities have broadened significantly. Now there’s less time for you to do what got you here in the first place – doing the work yourself. Your calendar is now jammed with meetings. You have little time for yourself. Forget hands-on project work.
It feels like a rat race. But does it have to be this way?
I don’t believe so. The answer lies in how you manage your calendar. Calendar planning tactics seem like an odd topic for a UX manager blog, but for me at least, it’s the most essential tool to enable me to create the space to work … at the level I want to work at.
Here’s a typical week in my calendar:
At a glance, my calendar looks like a mess. But there’s a method to the mess-ness. Before turning to the calendar, I should talk a little about goals.
Start with personal goals
It’s extremely easy to get caught up in the day-to-day politics or firefighting or water-treading of any job that you can easily lose sight of why you’re working in the first place. To prevent myself from getting sucked into this vortex, I have goals. They keep me honest. I’ve written them in Evernote so that they are with me at the desktop or on the road. I don’t look at them every day, maybe once a month. But they remind me of why I’m here, why I’m working. Without them I’d be lost. There’s nothing earth shattering about them. They’re pretty simple: spend as much time with my wife and kids as I can, be the best manager I can be, eat my brussels sprouts, etc. I have about 20 of them.
When planning my calendar, one goal is particularly relevant: I will design.
There’s an aspect of management philosophy here that some will disagree with. I believe that by doing hands-on work, by cranking out design deliverables, by launching projects, not only am I meeting my desire to design, but I’m also gaining a better sense of what my team members are going through – because I’m going through it with them. Hopefully I’m a better manager as a result. The challenge, of course, is to get the time balance right so that you’re able to effectively support your team members, support your stakeholders, and successfully deliver on project work. My calendar is a direct reflection of my attempt to get this balance right. Even if you don’t believe in this approach, or if you believe that UX managers should be purely people managers, you’ll still need to balance time for yourself, your team and their stakeholders.
Let’s take a deeper look at a typical week and you’ll see what I mean.
Every work day, I attempt to maintain 3 time zones: “me time”, “make time”, and “meet time”.
Every morning I have a personal routine. I try to do something that I’m interested in beyond project or management work. I’ll collect articles that my wife might find interesting and forward them to her. For myself, I’ll read about jquery, game mechanics, or baseball trades. I’ll listen to Jon Kabat-Zinn, Amy Goodman, or AC/DC. “Me time” is replenishment time. If I’m going to successfully drive myself through the rest of the day, I need to make sure that I’m personally on a full tank of gas, oil changed, tires rotated, etc. That’s what “me time” is for.
I’m a morning person so I – um – do this in the morning. 6 till 8. You could do it anytime. But I recommend doing it … every day. It makes a huge difference to my level of motivation and excitement about work and everything else.
From 8am till about 11am I have “make time”. This is when I design. It could be conceptual work or detailed production work. It could be a new idea I’m working on or a specific deliverable for an in-flight Google project. It doesn’t matter. All of my design work – or at least the stuff that doesn’t require anyone else – happens during “make time”. I used to distribute this time across my work day – an hour here, an hour there. That didn’t work (although I occasionally still do this when crunched on a deliverable). I need to have at least 3 hours of continuous, uninterrupted time to really get deep on the work and make significant progress or produce something that I can feel good about.
Protecting “make time” has been tough. Really tough. As you can see from the calendar, some meetings end up creeping into “make time”. Sometimes I’ll allow an important meeting to settle into this space, but I try to do so as little as possible. Caving in and scheduling over “make time” can be a sign to others that you’re not really serious about managing your time. It’s a battle, but it’s definitely worth it. Every day, I feel like I’m productive. Certainly some days are more productive than others, but every day is productive in some way, thanks to “make time”.
The rest of my day is dedicated to meetings. Many people, including many Googlers, believe that all meetings are a waste of time because they suck time that might be better spent working. I’m not one of these people. Yes, some meetings do waste time, but this is avoidable – and a topic for another blog article. But if you ever want to achieve anything of a significant size, you need to do so with a team of people. And if you’re doing anything with a team of people, you need to talk with them, which in many cases means meetings. Sorry to be so basic, but not everyone gets this.
There are a handful of “meet time” categories that I allow onto my calendar.
I put a premium on 1 on 1 relationships with my team members, my fellow Google UX managers, and of course, my own manager. So a good chunk of “meet time” is allocated to these 1 on 1s. Right now, I tend to do 1 on 1s every other week – sometimes every 4 weeks – for 30 minutes each. If people need additional time, I have office hours on Monday afternoons. If no one comes to my office hours, I have a 2 hour block to process email. Sweet.
Here’s my 1 on 1 schedule for the sample week:
As I’ve already mentioned, I attempt to make design work a priority. To successfully execute on design projects, you obviously need to meet with business partners from product management and engineering to discuss project strategy and to present and discuss work. So, another chunk of my meet time is allocated to these kinds of activities. These are projects which I’m either directly responsible for or contributing to. I avoid meetings for projects that my team members are working on without my direct involvement. I let them own their work and their relationships and give guidance during 1 on 1s or reviews.
Here’s my project meeting schedule:
If you care about the quality of work being done in the world that you manage, design reviews are a must. And if you care about how your team’s work is communicated to stakeholders, participation in engineering and product reviews can be key. My research partner and I check in on the week’s schedule of reviews every Monday and determine what we’ll attend and what we need to take last-minute action on.
Here’s the sample week’s review schedule. No product reviews this particular week:
If you have a plan on how to grow your user experience team and its members, you occasionally need to check in on how that plan is performing, make adjustments, weed out problems, and such. Management team meetings perform this function. Some are weekly, some quarterly, some yearly. Some are at 50,000 feet level, some at 1,000, and some on the runway.
I have a few blocks for these kinds of meetings:
Working at Google has its perks. But you’ve got to show up to enjoy them. So some weeks, I schedule an hour or two to check out a tech talk or grab a beer at TGIF.
And believe it or not, we actually get to go home at night. I check out a bit earlier than most people because I want to get home before the kids get too sleepy. Googlers can be night owls so I’m sure to schedule my commute time to make it clear that I’m not going to be around.
It works for me
So that’s my strategy for making my calendar work for me. What looks like an insanely chaotic schedule is actually a somewhat-structured plan to maximize my personal productivity while meeting the needs of my team and stakeholders. If you’re thinking about trying a schedule like this, be warned that your colleagues may be quite annoyed by this at first. You’re no longer available according to their schedule. That will be a tough nut to swallow for some. But if you prioritize according to your personal goals, and you make room for some flexibility (with time blocks such as office hours), you can keep your most important colleagues happy while fulfilling your own desires, needs, ambitions. In summ, the plan is to schedule:
- * Me time: get refueled so that you can perform to your potential
- * Make time: continuous, uninterrupted time to design
- * Meet time:
- – for 1 on 1s,
- – project team meetings,
- – design, eng, product reviews,
- – management team planning meetings, and
- – googley fun time.
I hope you find this system useful. And let me know if you have any suggestions for improving it, or if you have a better system.
I’m delighted to be teaching a 3 hour workshop at Adative Path’s Managing Experience Conference. Here are some of the materials I will be distributing at the event:
More details after the event. See you in San Francisco!
In August 2008, we conducted a workshop at Adaptive Path’s UX Week in which participants formed teams to solve key problems faced by UX team managers. Following is a rough summary of the output of one of these teams.
Manager? Leader? Which am I?
I succeed as both
How do we go from being just a manager to being an inspiring leader? Here’s a quick summary of what this team came up with:
* You don’t have to be a manager to be an inspiring leader
* Model good behavior
* Craft a vision with and for your team
* Value your team as resources and as people
How to inspire at the onset?
How to sustain inspiration?
Tools to inspire?
Create a timeframe/structure to implement
Roadblocks: no vision, no confidence, no authority
You don’t have to be a manager
Big picture thinker
Don’t sweat small stuff
Setting a good example
Empowers others to do the details
1. Articulate and communicate the vision – craft a vision statement to from abstract to tangible
2. Cultivate your “emotional ntelligence”
Create transparanecy & trust
Respect for individuals – feel valued
3. Define success critera – lay the path
Create a “success agreement”
4. Think big picture
Assess what you really “need” to do
5. Motivate others – incentivize others; tools to manage over time
6. Identify and manage expectations
Define job responsibilities to individuals and entire team
Clarify how each person fits into big picture
We’ve been a little slow in responding to our great session at UX Week in San Francisco in August. In our 3-hour journey to create a user’s guide to managing UX teams, our brilliant participants agreed on a list of UX team management issues to tackle. We started them off with the first four chapters:
Chapter 2: Career Development
Chapter 3: Performance Management
Chapter 4: Individualization
… and we collectively came up with the following ten:
Chapter 5: Inspiring Leader
Chapter 6: Measuring UX Impact
Chapter 7: Fostering Innovation
Chapter 8: Team Dynamics
Chapter 9: Integrating Process Across Team
Chapter 10: Agile Development
Chapter 11: Working with Distributed Teams
Chapter 12: Evangelizing UX
Chapter 13: Business Conflicts
Chapter 14: UX Seat at the Table
We’ll be sending out our summaries and raw notes from these sessions in up-coming posts. There are plenty of great ideas coming out of the workshop teams, so keep your eyes peeled for updates …
Anyone who knows Margaret knows that she loves haikus. As she says, they’re the original elevator pitch – a fun, yet powerful way of concisely making a point. They also make a great ice-breaker at a “managing ux teams” workshop … and that’s what we did last week at UX Week, where many brilliant haikus were unearthed and unleashed by an inspirational crowd of ux manager types.
Here’s one created by Jenna Langer. Truly a UX haiku for the ages ..
Visit my website
Explore and browse with freedom
No! Do not click there!
More UX haikus to come …
We’re still recovering from our fantastic session at UX Week in San Francisco last week. At the session, we set out to create a user’s guide to managing UX teams, and our intrepid participants didn’t disappoint. They collectively agreed on a list of UX team management issues to tackle, brainstormed best practices for each, and reported their ideas … and somehow managed to squeeze in a haiku or two. Thank you to everyone who contributed. Here are some photos from the session …
We’ll be publishing content from the session here in the coming weeks. Lots of great material.
How am I doing? Most managers aren’t able to answer this question, and the ones that can are delusional … or, if they’re serious about improving as managers, they’re surveying their stakeholders, including their team members. And it’s not just about determining how effective you are as a manager, but how effective you are for the individuals that are on your team. We’ve found that the better we’re able to align our management style to the personalities and strengths of our team members, the more effective we are as UX team managers.
Here are some tips to help you get effective feedback on your ability to lead:
1 Be clear about your goal in getting feedback
If your objective is to get open honest feedback in order to improve as a manager in general, try an anonymous survey of your team. Asking what you should start, stop and continue doing in a freeform text survey works reasonably well. If you’re aiming to tailor your management style to align with team member expectations and needs, you’ll need to have a dialog with individuals. This form is a useful enabler for this discussion.
2 Show that you were listening to the feedback
Distribute the results of your survey or discussions to the team. Rather than summarize, try to be as complete as possible, including even outlier comments. This will show your team that you were listening to all that was said, and gives the feedback process a greater sense of integrity.
3 Make yourself accountable by publicly committing to take action
Developing a list of action items in response to the feedback and send them to your team. Ask for any additional suggestions on ways to improve your performance as a manager or to better tailor your management style to their needs.
4 It’s okay to get a little help from your friends
Some changes in behavior are difficult, but you can stretch to achieve them. Others won’t budge not matter how many manager workshops you attend. It’s okay to hold off on, say, improving your excel pivot table skills. Heck, why not make that a leadership opportunity for someone on your team who has an interest?
5 Track your performance
This is critical. Add your action items to your quarterly objectives and key results. Score yourself (honestly of course) on your performance on a regular basis and send your self-assessment to your team. This will show that you’re truly genuine about making change.
6 Thank your team members
You may think that you’re doing this for your team, but you’re actually benefiting yourself by gaining insights to your own behavior and actions that you would have never captured otherwise. By having these discussions with your team, or by them filling in a survey on your performance, they’re taking time to help you be a better manager. Show them that you appreciate that time and effort.
Need a survey tool? Try: http://www.surveymonkey.com/
Download: Leadership feedback form
We’re all too busy working on projects to spend time arguing about whether people are low performers, high performers, or rock stars in-the-making. Right? Wrong. You don’t need to run a survey to work out that, when team members get feedback and coaching on their performance, they’re happier and perform better. But we do, and lack of feedback and coaching is a top pain point. So taking the time to carefully evaluate and improve team members will ultimately make your ability to execute on your vision that much easier.
Here are some tips to help you set up a performance management process for your team:
1 Be clear about what’s expected
An obvious statement, but how often do we fudge our way through this? Publish a ladder of levels for UX practitioners, with performance expectations for each level. AIGA gives you a summary of the various roles, but you’ll need to add detail that’s specific for your org. Meet (at least) quarterly and set objectives and key results for the quarter based on these expectations and on what your business needs to achieve.
2 Factor in your team member’s career goals
Certainly, work has to get done. But once you’ve set team member goals and expectations that support the business, you’ll need to factor in what the UX practitioner wants to get out of his/her experience with your org. Add these goals to the mix of quarterly objectives and key results. (See Career Development)
3 Get peer and client feedback
It may sound obvious, but when evaluating your team members, collecting data from those who work closely with them is the only way to get rich feedback. Ask your team members’ peers about their strengths and areas of opportunity. Be transparent and share everything you get with your team member (and don’t forget to let their peers know that you’ll be sharing the feedback with them).
4 Use a consistent scoring system
Break down expectations into categories based on the predefined expectations (like “quality of work”, “ability to lead projects”, “complexity of projects”). Taking peer and client feedback, as well as your own observations, score your team members on each category. Once you’ve done this for everyone at one level, compare scores to ensure that they’re well calibrated.
5 Track results over time
Maintain scores and your notes on team member performance over time in one document. This will allow you to monitor trajectory and to catch any areas of opportunity that were previously addressed but are creeping back.
6 Delivering the news
Deliver feedback quarterly. Very important: Write your feedback prior to meeting with your team member, and do so in the context of the expectations and goals that were set. Having a trajectory of scores will help color your commentary e.g. you’re continuing to improve in this area, but have leveled off in this other area.
AIGA’s list of designer role definitions: http://www.designsalaries.org/definitions.html
Downloads: Performance management tool