Process or talent? Companies can’t focus on both…

“The Most Important Document to ever come out of Silicon Valley” was released last week… at least, that’s what Facebook COO Sheryl Sandberg called it. This Most Important Document wasn’t a cutting-edge business plan, or a product roadmap… Far from it. It was Netflix’s “Corporate Culture” guidelines, a document that is usually quite dry and boring.

Netflix CEO Reed Hastings authored much more than your typical “Respect your employees, treat your customers well” boilerplate: He created a manifesto about how companies should grow, how to trust and empower employees, and how a talent-based company should work in the twenty-first century.

Here’s the Netflix presentation:

One of the most key points in the presentation is a discussion of organizational growth, detailing how large organizations typically start out being talent-based and talent-driven. As these organizations grow and become more complex they shift, becoming process-driven and paralyzed with rules and regulations. This, Hastings states, drives the talented people out and thus when the marketplace changes the company loses its competitive edge (s process can’t respond to a paradigm shift in an industry, but talented people can). How Hastings staffs and grows Netflix is the opposite of that model – he continues to focus on acquiring and keeping the best talent he can possibly find, paying them more than the market rate to keep them engaged and motivated.

This key point is presented matter-of-factly, with no doubt or ambiguity. And when you read it, it’s obvious and exactly right: you can see how institutional processes have hampered and hamstrung major companies over the past few decades (Microsoft, I’m looking in your direction).

Not to say that I want to go to work for Netflix, but after reading this document they are precisely the type of company I want to align my fortunes with – an organization that values talent above process, that lets professionals be professionals.

This article also made me consider my approach to user experience design. In the past I have been very pro-process, but recently I’ve come around to a completely different opinion. UX design is a creative effort, and a good UX designer needs to be versed in a dozen different domains (technical, psychological, commercial, you name it). There’s plenty of people who put “UX” in front of their names, but many of them are developers or graphic designers in disguise. You can have the best design process in the world, but if you don’t have talented people in the right roles working at their best… well, the results will speak for themselves (again, I cast a glance towards Redmond).

Finally, I’ve been very frustrated in my present job of late, and this Netflix presentation gave me a clear perspective on why. The processes and org charts and silos at the company are completely hampering my ability to do my job. I can’t make an impact, can’t “make a dent in the universe” as Steve Jobs famously said. At this company, talent is not important; process is king…. even if the processes put in place make things worse.

I’ve outgrown it.

What happens next… well, who knows? I have some very ambitious goals, both professionally and personally, and I’m looking to go somewhere and work for people who appreciate and support such goals.

And as of this moment… it ain’t where I’m at now.

Build and lead your team, the Dungeons and Dragons way

One of the formative hobbies of my youth was playing Dungeons and Dragons (as well as other “role-playing games”). If you aren’t familiar with RPGs (and if you aren’t, you’re missing out), they are lengthy sessions where you and friends gather around a table playing as characters you have created and as you react to what “Game Master” tells you about what your characters are encountering, you gain skills and experience that improves your characters. Dungeon and Dragons and RPGs like it were the precursors to modern computer games such as World of Warcraft… only D&D was more low-tech, more conversational, and required more Cheetos and Mountain Dew.

I usually took the role of the Game or “Dungeon Master” (or DM), which was great “training” that improved my communication and creative skills. As I started revisiting Dungeons and Dragons with my sons, I realized that D&D provides more than just a fun way to spend a long afternoon. It’s a great way to build and manage your team in a work environment.

My premise is simple: Applying principles and practices from D&D can help you build a better team as well as manage them more effectively. Here’s some of the things that I learned from years of playing that you can apply to your working group:

Build a balanced team (of “adventurers”)

Characters in D&D have core ability levels, numbers from 3 to 18 that represent how good they are at key things. These ability levels are used in saving throws during key situations in the game. The basic abilities are: Strength, Dexterity, Constitution, Intelligence, Wisdom and Charisma. Additional abilities were added in later editions of the games, but the core rules still use these six.

Obviously, in most business environments, Dexterity or Constitution aren’t very important… so these six abilities won’t work. But ranking potential or existing employees using other key abilities CAN help you get a sense of who they are and what they can bring to the team. I suggest the following to get you started:

Communication: How adept are they at writing or communicating? Can they present to your bosses if need be?
Domain Knowledge: Do they know your business? Can they hit the ground running or do they need ramp-up training?
Charisma: Can they charm their way out of a problem or a potential customer?
Problem Solving: Can they solve problems and get things done?
Initiative: Can they take the lead and “own” projects?
Comprehension: Can they “get” something the first time it’s explained, or do they need multiple walk-throughs?

Take these, or define the abilities that are important to you. Once you have, objectively evaluate candidates or current employees against them. You don’t even need to use the D&D scale… keep it simple, use a scale from 1 to 10. Once you identify the key abilities you can look at what your team really needs and recruit accordingly. Look at the experience and other skills, obviously… but defining the short list of key abilities you need can help you build the group you need to get to success.

Treat your “players” differently

Each person in your team has a different background and experience. You can’t treat everyone equally, no matter how much people say you can. Junior people need more of your time and guidance and senior people often need more autonomy and freedom from directing. When you manage a D&D game you often have a group that is a mix of different “experience levels,” with some Level 3 characters and a couple of Level 5 or Level 6 characters.

As a DM, you would never throw a Level 10 monster up against a Level 3 characters… that would be sadistic, and end the fun right away. Use that lesson in real life… don’t give a junior team member a senior project or problem to solve. Give them challenges, to be sure, but don’t give them a herculean task that they can’t successfully accomplish.

Don’t force someone to “level up” if they don’t want to

Though the point of D&D is to “level up” and build your characters skills, power and wealth as much as possible, many players find a happy balance of skills and wealth and stop “adventuring” so much. The same is true in real life, where team-members often become content with their position and stop trying so hard. This is to be expected and a consideration about what to do when resources are assigned to projects.

If you have a team where high performance and continued development is expected, you may need to consider leaving contented team members behind… to guard the Keep, or something like that.

What is your quest?

We all have projects to do, large and small… and many projects involve collaboration between team members or the engagement of the whole team. Just like when you begin a classic quest in Dungeons and Dragons, you should spend some time preparing your team for the adventure.

What is the goal (of the quest/project)?
What do you need (to accomplish the goal)?
Who do you need? What skills in your team are important?

These are somewhat obvious, but important activities to plan out your team’s efforts and help set everyone up for success.

Collaborate on big decisions

When faced with a puzzle that needs to be decoded, or a giant monster that needs to be defeated, the team that collaborates and works together succeeds more often than not. When a big decision has to be made, don’t just do it alone – involve your team in the conversation and get their ideas. As the team leader, be prepared to make the final call, but get as much input as you can when possible.

Tell stories

I’ve written and spoken a lot about the power of storytelling, and I won’t repeat those points here. Simply, we are wired to respond to stories, and explaining situations to your team in the form of stories makes information more approachable and helps people pay more attention. The best Dungeon Masters are master storytellers, painting a picture with words that exceeds any real-world image that could be provided. The best leaders are also the best tellers of interesting tales.

Have fun!

They don’t call it “work” for nothing. Work is… well, work. But you should never pass up the opportunity to make things fun for your team. A Dungeon Master who does nothing but push the group through one unimaginative dungeon after another will quickly bore the players, and many will stop playing. Are you a boss that does the same thing? Well, stop. Freshen things up, give people opportunities to be creative and have fun and you will have a happy more productive team.

What do you need to do to manage a UX team effectively? Some advice…

Well, I've managed a few teams in my time (cue crogety old man music), and so I have some insights that can help your design team run (semi) smoothly. Some of these recommendations are applicable to ALL types of teams, and I list them for the sake of completeness.

Have a (realistic) shared vision and direction. Have a mission statement and a set of principles the team should follow, but make sure its pragmatic and achievable. If you pump up your team with lofty aspirations and blue-sky visions they will quickly become demotivated when the hard fist of reality shatters those dreams.

Set a rigid, yet flexible, process. Set a standard design process, based on best practices, so that junior designers can have a guideline to do their jobs and work from. But be flexible about the details of the process if team members come up with better ideas on how to do things…. keeping in mind that "flexible" is not the same thing as "disposable" – process is important, and a repeatable process will increase efficiencies over time.

Spread the love around. Don't play favorites, let everyone have a shot at the big projects. Even if you don't think a member of the team has the ability to do the job well, you have to give them a chance to step up. Just pay close attention and help them when they need it.

Listen and pay attention. You need to be there for the team, and a lot of that involves listening to a lot of complaints and gossip. Encourage and support, be ready to intervene if your team members need help. And try not to "gossip back" if you can help it.

Allow for disagreements, but don't let them get personal. Design teams are passionate, and they will often wear those passions on their sleeves. Let them debate, but don't let it get out of hand (and get in the way of work)… and don't let people insult each other or their abilities.

"You are not the work." This is one of the most important points I can make, which is that designers have to separate themselves from what they have done, because what they have designed will change before it's finally implemented… and you may find through usability tests that the ideas/designs don't work at all. Continuously reinforce that point to designers in your team.

Don't compete, mentor. As a leader of a design team you should never put yourself in a situation where you are "competing" with anyone on your team. When I say that, I mean don't be working as a designer and a manager at the same time, because that could cause jealousy and discord. If you have to step in and work, do it by partnering with a junior team member and use it as a mentoring opportunity as well.

Set up "peer designing." If you have the ability, partner designers on projects. Having two or more people working together allows for the generation of more ideas, the ability for one designer to support or encourage the other when he/she needs it, and allows for "cross-training" while the work is getting done.

Credit the team, not yourself, for successes. If a design project goes well, give full credit to the people who did it. And if things go badly, don't throw anyone under the bus. You are where the buck stops.

Don't play favors (and don't hire friends). Don't spend all your time with just one member of your team, be equitable with how you invest that time with everyone. if you don't, people will be left out and they may not give their all when you need it from them.

It's very tempting to build a team with colleagues you worked with before, because they are a known quantity and you enjoyed working with them before. Don't do it. In my experience, brining in friends to work for you will end up resulting in bad things happening. Because they have worked with you as a peer they'll not respect you as much when you are the boss.

Appreciate that people are different. You are going to have a mix of different skills on your team, and not everyone is going to be the "perfect designer" that you can just throw at a project and let them go. Pay attention and balance out what people do with what they are good at and the most passionate about whenever possible.

Mentor, don't command. You cannot mandate design direction to your team. They are going to have thier own ideas, they are individuals with their own perceptions of the problem space. You may "know" the right approach is to do A, but sometimes the best thing you can do is let the team decide that A is the way to do it on their own (with a little coaching form you).

Allow for regular personal "research time." Unless you are under a crushing deadline which requires "all hands on deck," give your team time to become better designers and researchers by reading articles and books. Make continuing education a necessary part of everyones time. And allow for time for the team to share what they learned with each other (preferably over drinks at a social hour).

Have fun. Captain Kirk once said that the more complex the mind the more important the necessity of play. User Experience Design teams are usually made up of some very smart "complex minds" indeed – always allow for opportunities to explore and play.

See question on Quora

Tips on how NOT to do a UX design project


I’ve worked on a lot of different projects in my career, and I’ve learned quite a bit. I’ve always said I’d rather learn from someone else’s mistakes instead of my own, but I’ve had ample opportunity to learn from my own missteps as well. I see a lot of UX articles that detail how to successfully execute a design project, but there’s not a lot of discussion on things to avoid. So, based on the mistakes I’ve encountered along the way, and conversations I have had with many of my peers, here’s some ideas on how NOT to do a design project.

The names have been changed to protect the innocent (and my ass).

Start from the “bottom-up” instead of from the “top-down”.

“Just do wireframes,” is what the project manager told me and my team on a high-profile effort, because that is all that we had “contractual obligations” to provide. No analysis phase, no design iterations – just go straight to detailed design. Well, that didn’t work, because we didn’t have a shared “vision” for the design team to follow… and we weren’t allowed to invest the time to develop one. A high-level design wasn’t something we “had” to deliver.

Treat use cases as unquestionable laws.

I like use cases, I really do. I used to write lots of them. But when the use case explicitly directs the design direction (because the business analysts think it’s their “job” to do that) and the management team says “design to what’s in the use case”… well, you’re setting yourself up for friction and potential failure.

Have no user testing.

This one is obviously a bad idea, but I’ve been surprised at how often the need for user testing has to be argued for, even in “savvy” user-centered organizations. Often user testing is cut because of budgetary constraints, or stakeholders say “why should we test, the design team knows what they are doing.” As good as your team is, design testing is far cheaper than designing in a bubble and then investing huge amount of money and time deploying an untested direction.

Have no conceptual or “high-level” design.

As stated above, you must have a direction that all the designers can align to and follow. It can be a set of best practices, a declaration of principles, a conceptual model of usage… But SOMETHING has to exist to ensure consistent and successful work.

Define an inflexible design process.

I once worked with a project manager who was a “checklist” guy. Now, I love checklists, but if you follow your process/checklist blindly and without any flexibility you are going to end up in situation where quality is not a focus… crossing things off your list is. You have to be flexible and be willing to change plans as needed, based on revised requirements, test results, what-have-you.

Don’t let designers collaborate.

If you really want to fail, put designers on separate features and don’t let them talk to each other. One major project started out doing exactly that, and the designers were also under tight deadlines. The result was a Frankenstein’s Monster of a design that was inconsistent and impossible to implement.

Hire arrogant designers.

We all have various degrees of confidence in our abilities; we gain this confidence over time as we get more experience doing what we do. There’s confidence, and then there’s arrogance… and if you want to fail, hire arrogant designers who think they know it all. You will quickly discover that these people will alienate their colleagues and stakeholders and produce work that isn’t nearly as good as they think it is.

Don’t take any accountability.

If you are on a design project that is use-case driven, and the use-case is “the law of the land,” it’s really tempting to just do what the use case says, put in your eight-hours and go home. That’s the wrong way to approach it. The right way is to challenge the assumptions that are in the use cases and produce designs that aren’t “by the book.” Don’t give up, man up.

“Who’s in charge around here?”

One of the first things I ask for is a RASI chart, a list of who is in charge and who the key stakeholders are. That way I will know whose opinions to heed and who I can (safely) ignore. If you don’t have that clearly defined, then everyone’s opinion will “count” and it will turn into a painful a design-by-committee situation.

Have a super-critical stakeholder with bad communication skills.

If you want a design project to fail, then find the most critical person in your organization and make them the person who reviews and approves all the designs. Not only will he or she be negative but because they have poor communication skills they won’t tell you WHY they don’t like it. The result will be demoralized designers (and a revolving door they quickly leave through).

Have meetings without agendas and expected outcomes.

This is an obvious one, and is not just how not to do a design project, it’s how not to do ANY project. The larger the organization is, the more frequently useless meetings pop into everyone’s calendar. A meeting without a purpose is a waste of time and money that can be better spent creating good designs

There you have it, eleven ways you too can experience a horrible design project. Good luck!


What can you learn about management from Star Trek?

Upper management is far far away…

As in, several million light years away. Networking opportunities are rare. The only “face time” that you get is the occassional chat with an admiral, and then it’s usually the typical “there’s a situation on Deneb IV” and “you’re the only ship in the quadrant” stuff. Murder on career advancement.

Communication is often one way.

“Incoming message from Starfleet Command” is frequently the only information you get from management, and then it’s usually in response to a crisis. It’s pretty much the same way management at large organizations here on Earth communicates with their workers – a blanket (e-mail) message.

Middle management usually sucks.

Every time we meet a “middle manager” in the original Star Trek or on the Next Generation (a Commodore or Ambassador – not quite an Admiral, but superior to Captains), they were usually incomptent, evil, or both. Most notable example: Commodore Decker from Doomsday Machine and Ambassador Fox from A Taste of Armageddon. A rare exception was Spock’s dad Ambassador Sarek, though he eventually became non compos mentus….

Certain people aren’t cut out for a desk job.

Captaining a starship was James T. Kirk’s first, best destiny… and by accepting promotion he wasted his potential. He should have been out there hoppin’ galaxies rather than shuffling paperwork.

Even good managers can make mistakes.

Kirk got obsessed with a space cloud and pursued inappropriate sexual relations with WAY too many women. Picard let children on the bridge. The key is that good managers, flaws and all, learn from their mistakes and get better.

Good managers are responsible and concerned about their team.

“I’m responsible for the lives of 430 crewmen!” Good managers care and are “where the buck stops” when it comes to the performance and well being of their “crew.”

See question on Quora