Should You Be Hands or Brains?

Jared Spool

January 14th, 2012

[This is part 2 of a two-part post. For this article to make sense, you probably want to read part 1. This article was originally published on JohnnyHolland.org.]

In the last installment, we talked about the distinction between Hands contractors and Brains consultants. Hands are brought in by the team as an extra resource to complete work the team already knows how to do. Brains are brought in by the team to provide expertise and insight on the best way to do something the team is struggling with.

Hands and Brains require completely different skills, have different approaches, and run into different challenges. Knowing which you want to be is important.

The Role of Hands

The UX professionals who make great Hands are passionate about producing stuff. Whether it’s a pile of wireframes or a boatload of usability test sessions, they can crank through them. More importantly, they tackle every single piece of the project joyfully and proudly.

The thing to remember is someone who signs up to be Hands typically doesn’t get to say how the project is done. The team decides that up front, often before the project is started. It’s up to the Hands to match the work exactly, making it impossible to know which elements came from the Hands and which came from other team members.

When it comes to how the work is done, creativity and previous experience aren’t playing big roles. In fact, they are frowned upon. While the team focuses on getting everything done by the end project, they don’t want to step back and take the time to rethink what they are doing.

The Hands will get management’s attention if they have tricks and techniques for speeding up production, while keeping the results indistinguishable from what’s been done so far. An experienced Hands contractor brings speed and agility, while playing the chameleon to match the work of their temporary teammates.

Bring in the Brains

This is a complete opposite to the Brains—who aren’t about production at all, but instead about strategy. The Brains, when at the top of their game, are the sheriffs, coming in to clean up the town. When a team is stuck and not making progress, and it feels like they’ve tried everything without results, they call in the Brains.

Unlike the Hands, the Brains doesn’t make a good producer. Their value is squandered if they spend the bulk of their project time churning out similar items. Of course, if the team is struggling with what to produce and how, the Brains can get them started, showing them the technique and coaching them through the work. But, in this scenario, the Brains quickly backs away, as soon as it’s clear the team members can produce their own results. (Some Brains will bring Hands into the project at this point, working jointly.)

Instead, the Brains’ real value is in strategic understanding of the situation. The Brains looks at the entire scope of the project, studies the goals, and assesses the team’s capabilities and flaws.

Then the Brains suggests a new plan. They get the team started on the plan. They train the team on the tricks and techniques that will get them through that plan. Then they leave town, just like the sheriff, to go off and clean up the next team’s mess.

Why The Difference Matters

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

The Brains aren’t challenged by production work. Once they’ve done one screen or conducted one test session, they’re ready to move on to something completely different. The Brains love the variety of the tasks—coming in to something new. The Brains love seeing problems and solutions nobody else seems to see. The Brains are energized when those problems are particularly gnarly and the solutions are deviously elegant.

The Hands struggle with strategy. They always feel they’re the wrong people to ask—that someone else should’ve figured this all out by now. They thrive on having a set of constraints, a schedule, and a near impossible pile of similar things to do. They love to crank through the work, seeing the Done Pile grow while watching the To Do Pile shrink. They don’t mind their work blending with the rest of the team’s—their contribution becoming invisible to anyone outside the team. They are energized by completion.

In other words, Hands thrive on walking into a project that’s well defined while the Brains thrive on walking into a project that’s poorly understood. That’s why it’s difficult to be both. It’s a very rare person who thrives on both definition and chaos. For everyone else, they need to choose one or the other.

I’ve seen managers who have tried to have one individual contributor play both the Hands and the Brains. Often this is because of resource constraints or not realizing there’s a difference. Unfortunately, this inevitably ends in disaster, because of the opposing strengths and weaknesses of Hands and Brains. Don’t fall into this trap.

What do you thrive on? What energizes you? Where do you get frustrated? Understanding this will help you figure out if you are suited for the Hands or if you ought to be the Brains.

One Response to “Should You Be Hands or Brains?”

  1. Christine Says:

    Jared,

    A very insightful article. This comment in particular struck a chord: “It predicts why some smart employees struggle in some jobs while others thrive.”

    My current position is predominantly ‘Hand Work’. I’m mainly responsible for cranking out volumes of detailed wireframes and part of how I am evaluated is the speed at which I produce. I am not particularly fast, because the repetitious nature of the work bores me to the point of procrastinating its completion.

    What really energizes me is generating new ideas and thinking about different approaches to solving problems. I thrive on the dynamic chaos and collaboration of the ideation phase.

    As far as ‘getting out of the deliverables business’ is it possible to influence an organization steeped in heavy documentation to take a more agile approach?

    Thanks,
    Christine

Add a Comment