Building Cathedrals; or the three pillars of performance management

I'm lucky enough to work with a very committed group of managers.  Part of being in User Experience, is the desire to find better ways to do things, and a drive to make things easier for people.  Our performance management process is thorough, robust, and a little bit of a pain.

Every year we do an employee engagement survey, and one of the questions that gets a relatively low response is the connections between reviews and actionable feedback.   One of our managers took it upon himself to research better ways to do the review and goal setting cycle.  He came across a design agency in San Francisco that was using UX methodologies (card sorting, sticker dot voting, cluster analysis) to help UX practitioners lay out their plans and goals.  This seemed like such a logical step that we set up time with our SVP and VP of HR to discuss using it more broadly.

After laying out our plan and vision and advocating strenuously for the change our SVP asked us a simple question.  "What do you think the goals are for Performance Management?"

We rattled off the standard text book answers, which got us a take-off-the-glasses-eye-rub and a disappointed head shake.  After voicing his sorrow in our rote response, this is what he imparted.

Performance management comes down to three basic (but not simple) things:

1. People want to know that they're building a Cathedral; not just breaking rocks
2. People want to know that they have a manager that cares about them personally
3. People want to know that they acquiring skills that will help the be more employable in the future.

So lets' break that down:

1. Building Cathedrals, not breaking rocks:  The phrase comes from a parable about three labors in a quarry.  The first is asked what he is doing and he replies that he's breaking big rocks into little rocks.  The second is asked what he's doing and he replies that he's making money to feed his family.  The third is asked what he's doing and he replies that he is building a cathedral.  People want to be engaged and passionate about their work.  As leaders, it's up to us to paint the picture of future to which they are contributing, so that the monotonous or repetitive tasks are there in service to a bigger purpose.[1]

2. Care and concern:  From Emotional Intelligence (EQ) to Coaching for Achievement, there are numerous methodologies to help managers get more from their staff.  Rypple (a social performance tool) held an interesting webinar to cover this topic [2].  Their conclusion, "People react and learn best when they are in a positive environment that fosters respect, consistency, curiosity, and attentiveness. Being an encouraging coaching manager will create conditions that allow your employees to maximize their performance and potential, and develop both personally and professionally."

3. Acquiring skills:  Most people want to advance and progress in their careers.  This means that they want to work on tasks that enable them to develop marketable, valuable skills.  This may or may not be expertise (see Malcolm Gladwell's Outliers [3]), but it needs to feel valuable and interesting.

This conversation has come up over and over again.  Most recently in talking to a colleague that I have the privilege of mentoring.  Her department is working on hiring and they were brainstorming things they could do to attract valuable talent.  Using the three pillars as a mini-heuristic, we evaluated each idea:

• Blog by our CTO - Check.  Helps with the cathedral and the skills
• Conference presentations - Check.  Cathedral and skills again
• Logo schwag - Dubious.  Might check the "cares" box, but then again...
• and so on...

Using these as a lens, we were able to focus on the ideas that would (most likely) matter and eliminate the ones that were off the mark.

Question:  Do these ideas resonate with you?  Do you have any other ideas or ideals that help guide your leadership approach?

[1] http://www.fastcompany.com/1737689/maintain-a-startup-attitude-for-a-passionate-office

[2] http://rypple.com/blog/2011/10/how-to-coach-your-team-2/

[3] http://en.wikipedia.org/wiki/Outliers_(book)

Performance Management - Start with Measurement

One of the great things that my work does is to measure employee engagement using a couple of different surveys. Both of them try to get to the same thing; Are you engaged and involved meaningfully at work?

This isn't the same as employee satisfaction or overall happiness. Although you could argue that it would be hard to be either of those thing if you weren't engaged. One set of questions that get to that issue are described in First Break All the Rules, by Marcus Buckingham and Curt Coffman. Working for Gallup, they interviewed thousands of managers and employees to see what separated great managers from all the others. As a part of this process, they developed their Q12 questions. This 12 questions survey was able to demonstrate a solid link between engagement and superior performance.

I'm fortunate enough to be able to participate in a similar survey set twice a year. The feedback I get is instrumental in helping me to understand my team's needs, and in adjusting my style to better serve them in their jobs.

How do you measure your managerial impact?

Returning to writing

I've obviously been on a fairly lengthy hiatus from writing; one that's longer than the duration that I spent actually writing. I have a great job that's been keeping me busy and a wonderful son that takes up the time I have left.

I've been thinking on a number of topics that I intend to cover in the next few weeks to months.

• Leveraging off-shore UX talent to maximum effect.
• Introducing technical design roles into an existing team, and the benefits that can provide.
• Tools for managing scale and capacity.
• Cross-functional partnerships - How IA, Design, Writing and Prototyping all fit together.

Hopefully this will be a beneficial exercise for everyone.

How to handle overflow work

One of the challenges that being Agile creates is the need for dedicated resources for each Scrum. It's wonderful when you're fully staffed, but can be a challenge when you aren't. One of the early programs we instituted in my current position was called User Experience Office Hours (OH). There are many different variations of OH, but this is how ours worked.

Each designer was asked to allocate two hours per week to Office Hours, recurring, on the same day. We booked a conference room every Tuesday, Wednesday, and Thursday from 3 - 5, and assigned two designers and one usability analyst to the slot. We then put the slots on a public calendar and let anyone sign up.

For a 5% investment of a designers time each week we were able to cover not only the 30% of Scrum teams without a dedicate resource, but also other teams that needed some User Experience feedback (Marketing, Operations, Release Management).

Below is the Wiki page I created to outline the program.

---------------

The Challenge

• User Experience is not able to formally support a number of SCRUMS and features
• UE doesn't want to ignore unsupported features
• Ease-of-use is important as a Company.com differentiator
• Consistency helps our users be more efficient and effective
• Small fixes can go a long way

Office Hours

• 2 hours, 3 times a week
• 2 x 60 minutes each day
• Tuesday, Wednesday, Thursday, 3:00 – 5:00 – Halia Conference Room
• 2-3 UE team members
• Unsupported SCRUM teams get preference. Non-Scrum team are welcome (Tech Ops, Marketing, etc.)

What it is

• A way to vet designs and approaches with the UE Team.
• A forum for getting recommendations on implementation and best practices
• An opportunity for an heuristic evaluation
• A means to petition for usability testing or addition design resources

What it isn't

• Not a mechanism to get designs done for you from scratch
• Not a (preferred) way to get extra time with your allocated SCRUM UE resource
• Not a means to circumvent other existing design review processes
• Not a avenue to get icons or images produced

How it works
SIGN UP on the UE Office Hours calendar in Outlook at //Public Folders/All Public Folders/Development/UE Office Hours. Select the time you want and add yourself as an attendee. Enter your topic, and any links to relevant Wiki or Project Requirements pages. Note: Adding attachments to the invite has proved to be problematic in the past, so consider doing a "reply all" to the meeting instance.

Must Have: Before you come, please have the following items ready. This will maximize our effectiveness and your results:

• User Stories – To help us understand who is going to be using your feature, and how it will be used.
• Design objectives – How will your design match up to your use cases
  
• A design artifact (i.e., something visual for us to look at) – Any or all of the following are fine: paper sketches, Power Point, Excel, Visio, web page
  

Nice to Have:

• Page flow diagrams – A chart or sketch that shows how all your pages will fit together
• Similar examples in the UI – Have we done something similar before in the application?
• Comparative / Competitive examples – Has anyone else done something similar before?
• Customer feedback – This can include feature requests, emails, ideas, forum posts, sales input
• Testing results – Have we tested similar functionality before, and if so, what did we say?
• Prototypes – If you have an interactive example to work with, that's great.

Typical Agenda

1. Project review - <>
2. Artifact presentation – 10 min – Show us what you've brought and what you're thinking.
3. Discussion / other examples –35 min – Converse about the artifacts and objectives, and get some of our feedback.

-----------------
Here's the weekly update I send out on Mondays:

Hi everyone -

For any questions on Office Hours, please see our wiki page (http://wiki/Main/UEOfficeHours ), or drop me an email. Feel free to book a slot on our Public Calendar at Development > UE Office Hours. Just a reminder that we meet in Halia on the 8th floor.

Office Hours Schedule - Current
Tuesday: 4-5, Administering Groups/Queues/Territories (Adam Smith)
Wednesday: All Open
Thursday: All Open

==============================

===========

Office Hours Schedule - Last week (75% utilization)

Tuesday, 3-4 Project X (Bob)
Tuesday 4-5 Feature Backwards Compatibility (Susan, Eric )
Wednesday 3-4 Content in the Sidebar Search (Jane, Sally, Fred)
Wednesday 4-5 Open
Thursday 3- 5 UE Team Event

------------------

The program worked so well, that it was adopted by our Documentation team, our Systems Test group, and our Architecture team.

Agile Development + User Centered Design: Some Executional Oberservations

Here are some additional thoughts around Agile Development Execution that came up in my conversation with Marty Cagan at the Silicon Valley Product Group.

Agile Execution

1. Because Agile promotes a philosophy of "Just In Time / Just Enough" there is a push away from heavy documentation specifications. This makes face-to-face communication more vital than ever. It also reinforces the need for a central set of artifacts that everyone can share (User Stories, Task Cards, Prototypes)
2. The daily status meetings are the beginning of the communication process, not the end. There should be a constant stream of discussion about all aspects of the product. Designers should be previewing functionality to the developers and QA. Developers should be showing off completed code to each other, QA and the User Experience team. QA should be identifying potential pitfalls during prototyping, and should help the team make better implementation trade-offs.
3. Proximity helps. Teams that sit together can often have the informal conversations that drive the product forward faster. The one caveat is that those conclusions should be shared with remote team members so nobody is surprised (see bullet 1)
4. Good estimation is the foundation of great execution. It may take a couple of cycles to figure out, but once you know your team's velocity and productivity you can more accurately assess future work and only commit to what you can finish.
5. It's better to under-commit and be able to take on more work, than over-commit and finish a set of impoverished functionality.
6. Agile generally doesn't require heroics. If you find that you're doing 16 hour days regularly (and you don't love working 16 hour days), there's some expectation error somewhere in your process. Either you need to train the Product Owners better on how Agile works, or you need to reassess your estimation abilities and commit to less.
7. Never underestimate the value of a full-team / full-company review. At the end of each Cycle (Sprint) pull everyone together and show off the great work that you've finished. Talk candidly about what you signed up for and what you got done, and then demo.
   
8. Demo your completed code, as well as the prototype for the next phase. Having everyone see what you finished validates your hard work, gives the entire company insight into the product, exposes people to functionality they probably aren't familiar with, and increases consistency by socializing common interactions.
9. Planning matters. If you've done your user validation steps and have built and tested your prototypes, planning should be a snap. As the product owner you have the responsibility of helping to create the "Story" or "Theme" that ties your release together. Based on your theme, you should pick the User Stories that support that theme for your current release. The developers can then estimate those stories for effort and you get to draw the bright-line cut off to say what gets in.
10. Practice continuous improvement. At the end of each cycle, ask what worked, what didn't work, and what blocked your success. If these are in your control - fix them. If they're not, escalate them and/or get more training.
    

Sometimes teams get all of these, and sometimes teams get some. The best process is one that suggests and scaffolds, rather than dogmatically proscribes the steps to follow. Every team is different so you need to find the way that works best for you.

Agile Development + User Centered Design: Some observations

It seems a little strange to jump right in and start a blog with observations on Agile Development Methodologies and Design, but I had a great email conversation with Marty Cagan at the Silicon Valley Product Group that lead to me creating this list.

1. Using Agile is not an excuse for a lack of road-map planning. As a product owner, you still need to have a good idea where you're going or you won't know if you're making progress in that direction.
2. You represent the interest of the user. Users will tell you what they want, business owners will tell you what they want, technologist will tell you things are "hard". It's up to you to decipher what the users and the business NEEDS. This may be very different than what they say they want. (See the iPhone as an example)
3. The best way to get information is to go and ask the user. Watch how they work in their own workspaces. See if they use your product (or competing products) in unexpected ways. Ultimately, if you support their goals, you win.
4. If you have the bandwidth, take your team with you on the user visits, including your developers. You'll be surprised how much becomes "possible" when the engineers have seen your users struggling to complete a basic task with your product
5. Prototype early and validate frequently. You and your interaction designer should be joined at the hip. They should be able to implement your vision early, and should be able to provide you with a different perspective on the problem.
6. Show the prototype to user when you go visit them. Finish off your interviews by soliciting their feedback. Never underestimate the value of collaborative design with highly motivated users.
7. That being said, don't fall into the trap of building a solution for your most vocal user. You need to be able to sell your solution to a number of people if you're going to be successful.
8. As a product owner, the best thing you can do is have clear and un-ambiguous User Stories that your team can build. Your goal is to ensure that development time is fully utilized - you want to get the most bang for your buck
9. Let your engineers chunk functionality as they see fit. They will have quality criteria that the will need to meet each Sprint. It's your job to ensure that there is sufficient functionality to warrant a release to the user. Constant change can be more upsetting to your customers than less frequent upgrades.
10. Get training for your entire team. If everyone understands the mechanisms around Agile, then you can focus on the execution. If people don't understand, you'll get bogged down in the semantics and dogmatic issues.
    

You and your designers should always try and be 1 to 2 sprints ahead of your team. This allows you to validate difficult features with sufficient time to improve them. It also keeps you from getting too dissociated from the facts on the ground. You should strive for at least 90% coverage via usability testing.