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.

Look at any young and accomplished musician or artist. Or at those twenty-something sports stars. They are obviously talented.

Yet, how much of a role does their talent really play in what they do?

That 12-year-old pianist who is dazzling the audience with her Bach concertos – sure, she has talent. But look closely and you’ll see someone who has been practicing for years. She took classes and sat at the keyboard for hours every day.

While talent is something we’re born with, skills are something we pick up. Study hard, practice often, and given enough time, a person achieves mastery.

In design, this is certainly the case. I’ve met designers who demonstrated their stuff easily, but most of them did that after years of practice. They worked hard to learn the tools, to become literate in the ways of design. They always study the work of others, first by mimicking to master the technique, then adopting it to make it their own style.

It’s true that talent may get them to mastery faster. It might push their mastery beyond that of their peers.

Yet, everyone I’ve met who is really great (and I’ve met a lot of great designers), got there because they worked at it. It wasn’t natural.

Breadth of experience is another thing those great designers all share. Mixing up the projects, mixing up the teams they work with, mixing up the customers they design for – all that brings experience.

Every time they change something up, they have to re-evaluate what they believe to be true. They have to tweak their skills to the new environment. What used to work well now doesn’t work as well. They have to ask, “what do we need to do differently?”

Hang around me long enough and you’ll hear me utter one of my favorite aphorisms: “Good judgement comes from experience and experience comes from bad judgements.” I’ve observed that great designers make smart decisions quickly. They have years of practice at making decisions. They have a breadth of experience. They can recognize important patterns. They constantly practicing their basic skills.

Don’t worry that you’re not talented enough: get out there anyways. Learn the skills. Practice them constantly. Change up your environment to gain new experiences. This is the path to being great.

Talent only differentiates us when we’ve already mastered skills and had a breadth of experiences. What separates the great designers from everyone else today isn’t their talent — it’s their skill and experience. Talent is the least important of those three attributes.

What’s the difference between contracting and consulting? One major difference comes down to whether the job is handwork or brainwork. Whether you’re an “innie” or an “outie,” this is applicable.

Innies are UX professionals who work inside an organization. Even though they are part of the company, they are still consultants. They are brought on to projects with the intent of lending their skills to move the project forward. Sometimes they stay with one project for its duration, or sometimes they juggle multiple projects at once. Either way, they aren’t really part of the long-term team in the same way others are — they move from team to team and are only there when their skills are in demand.

Handwork and Brainwork

Innies and outies have a lot in common. One thing they share is the need to distinguish whether a project is handwork or brainwork.

Handwork is when the hiring team knows what they want; they just lack the right number of hands to get it all done. Let’s say the team needs new screens designed. They know what the screens are and how they should work. They’ve built many screens before, quite successfully, so it’s not a problem of knowing what to do.

The problem is they don’t have enough hands to get the job done. All of their internal resources are otherwise occupied, thereby stalling the screen-production piece of the project. In this case, they hire a contractor—someone who will come in and help them crank out more screens. This is handwork.

But there’s another way the project could go down. What if our hypothetical team doesn’t know what the screens are or how they should work? What if they don’t have the experience of building screens before and lack the confidence and skills to get started efficiently?

In this case, they need someone to help them come up with a strategy for identifying which screens need work and how to tackle them. In fact, once that strategy is set and they understand what the project needs to be finished, they may have, internal to the team, all the resources necessary to complete it.

This is when they hire an outside consultant; someone who will bring in expertise and skills the team doesn’t otherwise have. This we call brainwork.

Hiring Hands and Brains

It’s quite critical, as a UX consultant (whether you’re an innie or outie), to distinguish between handwork and brainwork—yet the distinction is often not discussed. As I talk to people who are looking to expand their careers, what I discover is they are often trapped doing handwork when what they really want to do is brainwork. (Occasionally, I meet someone who prefers to do handwork to brainwork, but that is quite rare.)

Handwork, for the most part, is commodity work. Once you qualify the basic skills, it really doesn’t matter who does it. It doesn’t take imagination. Previous experience, for the most part, doesn’t play a role in the quality of the output.

If the team needs to produce 100 wireframes and they have a pool of 20 people who are capable of producing those wireframe to their specifications, then it doesn’t matter which of those people you hire. Hire the one who charges the lowest rate, has the nicest personality, and produces the cleanest deliverables.

Brainwork, on the other hand, is where your expertise and experience come into play. If the team doesn’t know what a wireframe is or how to decide what they should do, they’ll want someone who can give them solid advice. It they’re smart, they’ll be selective about who they hire, looking for someone with a track record of helping other teams in comparable situations, and they’ll pay top dollar for their help.

Maybe the team’s leadership is mistaken and they shouldn’t be doing wireframes at all? Well, someone hired to do brain work will have earned the respect and authority to say, “You know, there’s a better way to do this” and the team will listen. (Occasionally, they’ll even revise their plans, but that’s another column for another day.)

However, if that same person was hired to do handwork, there’s no way the leadership will pay attention. It’s wasted breath (or worse, seen as belligerence that may result in removal from the project). Handwork is hired for hands, not brains. Please keep your brains to yourself.

UX professionals who do handwork are what we call the Hands. They’re a rare and valuable breed. Find someone who loves being the Hands and you have a production machine.

The Brains are what we call folks who provide great brainwork. Prospective employers have to be more discriminating when hiring the Brains, because their advice will drive the results, either to success or to failure.

Hiring managers should know which they want. Get the right person for the job and you’ll have a successful project. You need to distinguish between Hands contractors and Brains consultants. In the next installment, I’ll talk about the qualities that separate a great Hands contractor from a great Brains consultant.

[Don't forget to read part 2. After this article was originally published, there was a little confusion. I try to clear it up here.]

Fast Forward Four Months…

We’d like to thank you for doing a fantastic job as our 2012 Winter Business Intern. You started with a thorough analysis of the purchasing patterns in our UIE Virtual Seminar series. This led to some amazing insights on how we could restructure the program, which helped us with key initiatives we launched this spring.

At the same time, you put together a marvelous weekly social media outreach strategy. Once you started executing it, we saw a real lift in the conversations we’ve had with our customers, which has had a direct affect on our bottom line.

When you turned your keen attention to compiling the history of our revenue sources for the last few years, you uncovered some interesting patterns about who our customers are and how they like doing business with us. We’ll use those insights to drive new products for years to come.

You also created a database of our marketing partnerships, to help us know who to contact and what they’re interested in. This makes it easy for us to make our partners aware of our latest offerings.

To top it off, you’ve even helped us document our business development process to make life easier for future interns.

Thanks for your energy and enthusiasm during your internship. We know you’ll succeed at your future ventures.

Now Back To Today…

If you’d like this to be your story, send us your resume with a half-page write up of your most significant business accomplishment. While we’re less concerned with your skills and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 24 hours if you have what it takes to achieve something special.

You might even want to check out our web site for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.

Send your resume and write-up to: BusinessInternJob@uie.com

or

Jared M. Spool, CEO
User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845

However, if we didn’t make proper arrangements before we took the job, it’s very likely we can’t show much of our work to anyone. Consultants, contractors, and full-time employees are usually covered (in the US at least, but most other places as well) by a “work for hire” agreement, which means that the people we work for own all the work product we produce.

Wireframes, sketches, and other deliverables are not ours to show. If the final design isn’t publicly visible, such as internal application, there might not be any evidence of what we’ve done.

This puts us in an uncomfortable position when it comes time to show our work to a prospective employer. How do we show what we’re capable of when we don’t have access to our work?

Some have advised that you can put your company’s work files into a “for your eyes only” confidential portfolio, asking the hiring manager to keep what they see a secret. While it’s unlikely you’ll get caught doing this, does it send the message you want to someone thinking about hiring you? After all, it could be interpreted that you don’t take company policies, like confidentiality, seriously and that may not be a great first impression.

Fortunately, a smart hiring manager should understand this dilemma well. They’ve seen others with it and probably have faced it themselves when they interviewed at the company. Those smart hiring managers will look for other evidence of your talents and skills.

What can you put into your portfolio when your work is all locked up?

The simple answer: Fill your portfolio with stories.

When we’ve talked to the hiring managers behind some of the best design teams, we’ve seen that they are less interested in the final products and more interested in how the candidate got to those products. They’re interested in the story behind each design more than the designs themselves.

A good hiring manager wants to hear what the project goals were. They want to hear what you were given to start with. They want to hear the major challenges you faced, and how you overcame them. They’re interested in who else was on the project and how well you worked together. They want to hear about that guy who was always in the way and what you did to work around his objections and obstacles.

A great design portfolio tells the story about your designs, even if it can’t really say much about the design’s specifics.

To prove you know what the work products are, you can fake those. You can create wireframes, sketches, and other deliverables for side projects. In addition, you can mockup what your work would’ve looked like, without giving away the details that your employer wants to keep secret.

But the best designers talk about their journey. And the ones with the best stories are the ones that get hired. Especially when the new job is filled with exciting adventures.

Why you need to be in Boston, November 7-9.

• Invest in your skills

Spend a little money now to increase your skill set. It’s far less expensive for your organization than searching and recruiting new talent with a skill set your team needs. Companies who invest in their employees reap the benefits of your new skills and save money by leveraging your newfound expertise.

• Invest in your site’s experience

Attending UI16 gives you techniques to bring more functionality to your web design right away. The users’ experience will improve which, in turn, brings in more revenue.

• Invest in your attitude

One of the most frequent comments we hear from past attendees is how inspired and motivated they feel after attending the conference. When you return to the office, you’ll be itching to put into action all the cool ideas and techniques you learned.

• Invest in your team

You’re not just educating yourself. You bring back valuable insights, knowledge, skills, and resources that everyone on your team can benefit from and share. A large contingent of attendees conduct formal knowledge-sharing meetings upon their return.

What you and your company get when you attend UI16

A lot comes with the $1,649 registration fee.

• Register now and guarantee your picks for the full-day workshops on Monday and Wednesday (when it’s time to choose them).
• Choose 4 featured talks on Tuesday and be the first to hear a brand new keynote from Jared Spool.
• Receive all the presentation slides and materials from every single workshop and featured talk.
• Get the audio and video recordings post conference from all the featured talks and Jared’s keynote. We encourage you to share these recordings with everyone on your team.
• Share best practices and discover new solutions with fellow attendees and
  speakers at the networking activities.
• Use your new designers toolkit to explore your design ideas.

Learn how UI16 will change the way you work. UICONF.com

“Hi. I’m a designer at [a big deal company] and I’m considering leaving. The problem I have is my employer has made it very clear I can’t use anything I’ve done here in my portfolio. What should I do?”

The work product lockdown is something many designers face, as they grow their careers and try out new opportunities. It’s natural that prospective future employers will want to see what you’ve done. It’s hard to show them when your designs, sketches, and deliverables are locked up behind a corporate non-disclosure agreement.

In future posts, I’m planning on talking about what people can show in their portfolio if they don’t have work products available (or even if they do), and what the best hiring managers look for when reviewing a portfolio.

However, today I want to talk about this from a different angle: Making it part of the hiring agreement.

I think every designer (especially every experienced, senior designer) considering a job at a new organization should ask explicitly about the hiring organization’s policy on including the work in future portfolios. Their answer should be on the table and negotiated, just like salary and benefits.

When should you ask?

In any hiring process, there’s two stages: The first stage is when you, as the candidate, get the hiring manager and company to fall in love with you. It’s all about showing what you can do and how you’ll help them achieve their goals for the position. You’re goal in this stage is to get the company to think you’re the most awesome person ever for their position and they should jump through every hoop to get you on board.

The second stage is when the company gets you to fall in love with them. Their goal in this stage is to prove to you that they are the best place ever.

It’s in the second stage that we can talk about the portfolio, between when they fall in love with you and when you are deciding the job is the right next step. It’s quite within the rules to say, “What’s your policy on employees including screen shots, sketches, and other work deliverables in their portfolio?”

The hiring manager may not know. It may be something they’ll have to ask HR or even the legal office about. At small companies, they have never even considered the question because you’re the first to ask.

However, it’s a really fair question. And, frankly, any answer is a fair answer.

They might say they want to protect their designs from getting in the hands of the competitors. Therefore their policy is to refuse permission to publish work (especially unreleased design work).

Public companies, who have trouble when future plans are leaked, thereby creating a possibility of “insider information” getting out, are very likely to refuse this without including a Safe Harbor statement. (A safe harbor statement basically says that investors shouldn’t use the information as any indication that the company intends to do anything with it.)

Or they might say they have no problem with you putting the documents into your portfolio, but they’d prefer that you don’t put it in a publicly accessible place, like a web site that anyone can get to. They might like you to only show it to people on an as needed basis, asking those individuals to not share it beyond their own team.

Ideally, they come back and say it’s perfectly fine. There’s not reason you can’t take your work with you as you grown your career. (After all, they benefited from your previous employer’s generosity in this matter. Pay it forward.)

Any of these answers are ok. The point isn’t that you badger them into heading in a direction that they aren’t comfortable with. The point is they tell you, up front, before you take the job.

Once you know, you can decide if this is a deal breaker or not. The fact that you asked tells the hiring manager that it’s an important detail to you. That you’re thinking about your long-term career.

(Of course, one argument is that it sends a message that you’re thinking about leaving the company even before you got the job. Personally, I think that’s ok. In this day and age, we don’t expect life time employees. Any company in denial of that fact may not be the kind of place we want to work. It’s good for an employer to realize that each employee has a choice to stay or go.)

As a discipline, our goal is to bring awareness to the hiring companies. To let them know that this issue is an important one for many professionals.

We’ll know we’ve succeeded when hiring companies start putting their openness to including work products in portfolios into their recruiting ads. When they cite unlocked work products as a benefit of choosing them to work there, we’ve arrived.

Then, someday, this will disappear as an issue, as it becomes part of the standard way we all do business.

• Ways to tailor your UX design process to the culture of your organization
• How to conduct research with minimal time and budget
• Techniques to get useful design feedback from stakeholders
• How to make your case in organizations that don’t prioritize design

You’ll be able to put UX principles into practice in any organization, and learn how to make the case for user experience design with results, not theory.

Register with the code UNDERCOVER and add lifetime access
to the recording of this seminar for no extra cost.

The details for you:
UX Design when Time, Money, and Support is Limited with Cennydd Bowles
Thursday, July 21 at 1:30pm ET
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minute online seminar
Learn more about Cennydd’s seminar or save your spot now!

And one last piece of good news! Thanks to New Riders, we’re giving away copies of Cennydd’s book, UNDERCOVER User Experience Design, to random attendees. Winners will be notified within 24 hours of the live seminar. Join us!

Not every job will require that a designer know how to code. However, there are three reasons why learning to code makes you a better designer:

1. You’ll better understand the medium you’re working in. If you know what database queries will be faster than others, you can make the right response time tradeoffs. If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster (and more of them, since development time is a limited resource.) Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.
2. Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.
3. Knowing how to code helps you identify bugs and flaws in the production code. As your team’s designs start to come to life, you can play an essential role of helping the developers isolate interaction problems, which means your end product will be the best it can be.

There’s been a lot of debate as to what languages designers should learn to code in. Based on these three reasons, I think it needs to be the languages used by the rest of the team, whatever they may be.

It’s clear from our research that designers who can code bring more to the team and, in the long run, see more of their brilliant work making it through the development process, to the user.

If you’re a designer, imagine you had a chance to work with two development teams.

Team 1: One team has top-notch developers who know virtually nothing about design. They can code miracles, but the designs of their applications are horrible and frustrating to use. And they show no desire to learn anything about design — how it’s done, why it’s important, and what makes a good design versus a bad design.

Team 2: The second team also has world-class developers, but these guys are hungry to learn about design. They’ve already taught themselves a fair amount and are truly interested in learning more. In addition to producing amazing code, they are regularly producing applications that look good, work well, and delight users.

As a designer, which team do you think would more fun to work with? The team that has no interest in designing or the one that really enjoys it?

Practically every designer I’ve talked to about this choice has told me, without hesitation, they would love to work with a development team that appreciates good design and wants to learn more about it. Those designers won’t be constantly battling for the simplest of design choices, instead be focusing on the hard problems with a group that wants to see the best outcomes.

Guess what? Developers feel the same way. If they had a choice, they’d rather work with a design team that understands development and craves to learn more, than with a team that doesn’t make any effort to learn what development is all about. Not just simple front-end coding either. They want to work with designers who understand the architecture and infrastructure, who can relate to the challenges they are up against and can appreciate it when the team has pulled off something amazing.

Learning to code doesn’t just give you new skills, it makes you a more desirable team member.

Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.

While hiring super designers has always been floating around, the real demand has come recently out of Silicon Valley startups. With a couple of high-profile design successes, like Apple and Mint.com, the investors and entrepreneurs in the Valley now have a new appreciation for the work of designers.

Startups, however, try to run as lean as possible, so they look for talent with a broad set of skills. The thinking among the Valley folk is, if they can get someone who does both, they can get their product from concept to ship with an ideal set of resources. Otherwise they’d have to hire two people. Or do without one.

We’ve proven for years that you can ship a product without a designer. Many companies have done that, and while it doesn’t make for a great result, it does ship. However, it’s much harder to ship a software product without a coder, if not near impossible.

That’s why, right now, there are dozens of startups looking to pay big bucks to find the coding super designer. The demand is high and those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.

What about the non-startup portion of the hiring world? Right now, the established organizations find it easier to have larger teams with separate developers and designers.

Yet, that doesn’t make the designer that can code any less valuable to them. A team with two coding designers is more flexible and capable than a team with one non-coding designer and a non-designing developer. The flexible team can produce well-designed results better and faster.

Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results. Having a team filled with individuals who can both code and design will be more effective in the long run than a team where the skills are divided up.

If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.

You’re eager to attend the Web App Masters Tour. You know you’ll put into practice the insights that Jared Spool, Luke Wroblewski and Josh Clark share on mobile design. Your brain will be full of ideas from Stephen Anderson and Noah Iliinsky’s take on data visualization. The tips and techniques you take-away from the Masters at Faceboook, PatientsLikeMe, SalesForce.com, AARP, and Netflix will prove extremely useful. You see the value in attending the Web App Masters Tour. But how do you persuade your boss to spend the money on you?

Convincing your boss to send you to a conference is not easy. There are expenses, and the time out of the office. Your manager needs to understand the benefits of investing in you.

We’re going to help you. Use these points to help convince your boss why you need to attend the Web App Masters Tour. But besides highlighting these points to your boss, you need to show you really want to go. You need to ask, “May I register for the Web App Masters Tour?”

Invest in your skills—Spending money now to send you to the conference will save the company money in the near and far future. It’s considerably more expensive to search and recruit new talent with a skill set your team needs. Companies who invest in their employees reap the benefits of your new skills and save money by leveraging your new-found expertise.

Invest in your site’s experience—Attending the Web App Masters Tour advances your skill set, allowing you to bring more functionality to your company’s web site. By improving the user experience, your users are likely to spend more time on your site, which in turn, will bring more revenue.

Invest in a motivated, productive, and happy team member—One of the most frequent comments we hear from past attendees is how inspired and motivated they felt at the end of the conference. You too will be eager to implement the new ideas and skills you gain at the conference.

You’ll learn how to communicate your data and content with visualization techniques. You’ll gain valuable advice on how to better map out the direction your company should take with mobile. And you’ll pick up best practices and tips and techniques for your design process.

Now figure out which Tour you want to attend, Seattle on May 23-24 or Minneapolis on June 27-28. Choose the date, take these points to your boss, and ask the question, “May I go to the Web App Masters Tour?”

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Last Stop! Minneapolis

I know you’ve been involved with the web for a long time, so I wanted to ask you a simple question: in your opinion, how useful is a computer science degree for a career in web development? I’m a second year CS major, and considering dropping out because I don’t see the value in it anymore. It’s just taking away my time from learning and doing what I love most–developing web apps. Will dropping out hurt me later on?

After thinking about it, I crafted this response:

It’s an interesting question.

I think the answer depends on what you want your long-term career prospects to be.

If you’re looking for immediate payoffs, then quitting school and heading straight into web-app development could work well. Very little of what you learn in school will contribute to that effort more than just getting experience being out there, solving interesting problems with innovative designs.

However, the computer field changes quickly. New languages, new tools, and new technologies emerge every day. These introduce real challenges for the practicing developer. It can be really hard to keep up, especially if you don’t have the foundations to build on.

Remember, “web development” didn’t even exist 8 years ago and, even from the landscape of 4 years ago, everything is completely different. There was no cloud. There was no Ruby on Rails frameworks. Virtualized systems didn’t play a role. CSS3 and the miracles of the HTML Canvas tag weren’t anywhere to be seen. There was no mobile web, per se. What will be different 8 years from now? Everything.

If you’re at a good CS program, it won’t help you be a better web app developer today. It’ll help you be a better web app developer later.

Take something simple as graph theory — something usually not taught in CS programs until the third or fourth year. This is a completely abstract mathematical idea, which, when presented in class, seems to have no real-world applications. Except in high speed networks, where the base math and algorithms help you identify the best way to route messages through the net. Or in social computing, where you can calculate the relationships between people and objects (such as users & pictures on flickr), to create new features (like the “Hey, this person in our net is connected to all your friends, but not you. Do you know them? Want to connect?” feature of Facebook, Flickr, Gowalla, and every other new social app).

Sounds like you need to decide if you’re chomping at the bit for getting serious development experience under your belt or if you want to make sure you’re prepared for the new stuff coming in the next 20-30 years, ready to tackle what those new innovations are going to bring us.

Hope that helps. Let me know what you decide.

Which generated this response:

Wow! I am so thankful for your reply! You definitely helped me see the value in my CS degree again. You see, the thing that made me consider dropping out of college was the discrete math class I’m taking right now. I saw no value, no real-world application of the abstract concepts we’re learning, and thought I was just wasting my time and money filling my head with useless knowledge I would never again use in my life. I then realized I would be taking many more similar theoretical classes in the next three years. As a result, it made more sense to drop out and learn stuff that I’m truly interested in, like PHP, Javascript, user experience design, etc.

But now I realize that a CS degree will help me build a strong foundation for a career that will prepare me for the many challenges and changes in the near future. I’m definitely staying in school to get my CS degree. And let me tell you, I am more motivated than ever to master my discrete math class and all the other theoretical classes that will follow.

Thanks again, Jared, for your words of wisdom. I respect you deeply and feel extremely honored to receive words of guidance from you.

Nice.

Apparently, I wasn’t the only one to get the query. Here’s Eric Meyer’s response.

My thinking about Hands and Brains have come from a distinction between, in my mind, contracting and consulting work. We get a ton of calls at UIE to help people with usability and design work, but it’s clear after a few moments of discussion with the prospective client that they’re looking for contracting—someone to do the work for them and not for consulting—someone to show them how to get them to the next level.

UIE doesn’t do contracting, but lots of folks do, so I’m always on the lookout for people who are great contractors. Understanding the distinction is really important and I wrote the Johnny Holland essays to help create a language around the two types.

Apparently, I hit a nerve, because a lot of folks have been reacting to the piece in ways I didn’t expect. I wanted to take a moment and discuss some of those reactions.

What If I Do Both?

This seems to be the biggest reaction, by far. Someone who is an information architect, for example, says they are quite capable of doing both the Hands work and the Brains work. So, why should they have to choose one?

It’s true that you can be quite capable of doing both. However, most projects don’t want or need both. They either want Hands, because they don’t have enough resources and need the work completed. Or they want Brains, because they are stuck and can’t figure out how to bring their designs to a new level.

So, it’s important, when talking about a potential project to discover which one it requires, then decide, do I want to do that? Doing one basically traps you for that client—once they see you as Hands, you’l always be Hands to them. Same for Brains. It’s important to make your choice carefully.

Strategy Is Good, But Without Execution, It Fails

100% Correct. But that doesn’t mean the people who do strategy are the ones doing the execution. In fact, almost always, it’s the wrong thing to do.

The strategy has to include how the job will get done. The strategist has to know who will do the execution work.

Many Brains consultants will help find the Hands contractors/employees to get the job done. They’ll help build the team with those who are the most capable.

Execution is key but being the one doing the execution isn’t.

To Be Great At Brains, I Have To Master Hands

Absolutely. Brains have to know how to do the work of Hands. It’s gotta be second nature. They’ve got to understand how it’s done and what excellent work looks like.

However, once you start doing Brains work, it’s rare you’ll do that work again. You need to know what to expect from the Hands who will be working for you, but you won’t do it yourself.

Think of the executive chef in a restaurant. They have to know how to prep and cook every recipe. But that doesn’t mean they do that for every meal. In fact, it’s a bad use of resources and talent.

This is All About the Economics

Doing Hands work takes a long time, because it’s rigorous production work. Brains work doesn’t take as long, to deliver the same value to the team.

Hands work, because it takes longer, charges a smaller hourly rate. Brains work, because it’s shorter, charges more. Often two to three times as much (or more). Where Hands work might charge $50 to $75 per hour, Brains will charge $150 to $300 per hour. (Many really good Brains consultants charge a *lot* more.) A Hand’s engagement could last months or even years. Brain’s engagements rarely go beyond weeks and are sometimes only a few days or hours.

This is why, at the client, you can’t do both. If you try to do both Brains and Hands work on a project, you’ve got a rate mismatch. You’re either charging too little or too much for part of the work you’re doing. (And explaining to the client why you’re changing rates in the middle won’t be easy.)

Even if you love doing both, you need to decide where you’re want to focus. Go for the joy of seeing your work produced by delivering great Hands work. Have the excitement of creative big-picture problem solving with awesome Brains work. Pick your pleasure and go for it.

I was really disappointed with their 1996 approach to the salary survey. The AIGA is filled with talented designers, yet they opted for an impossible-to-use book reader to display their hard work.

Locking the survey up in a proprietary, unusable reader was a huge mistake. It’s hard to use, not lending itself to the richness of the data that’s available. It’s like looking at the entire ocean through a small porthole.

But it’s not just the reader that’s the problem. You can download the PDF (after registering), but that doesn’t make it it much more modern.

The big problem is that the book is all about the presentation of the data, but not about the knowledge within.

The salary data that AIGA has at this point is really rich. They’ve got thousands of respondents surveys, going back to 2000. It would be awesome to really dive into this data.

AIGA is all about graphic arts. But in 2010, graphic arts has a huge responsibility to communicate interactively. How cool would it be to have a Mint.com-style drill-down interface, that would let you compare variables, such as whether salaries in Austin for the last five years have grown/shrunk the same as salaries in Boston?

How about letting people doing cross-tab analysis. For example, how does years of experience play into the salary changes? Does it change for job type? Region? Are there some regions that pay off more than others? And has that changed over the years?

By presenting the data as a flat book (or worse with the silly antiquated issuu interface), AIGA is saying that the understanding of the information is secondary to how it looks when they present it.

I don’t think this is the message that AIGA wants to send about graphic artists. As the premier organization for representing the future of what graphic arts can be, it would be nice to escape flatland and get to the core of communications.

The other big missing piece from the AIGA Salary Survey is the ability to export the data. How cool would it be to pump it into IBM’s Many Eyes project, letting people come up with dynamic interpretations on their own? How cool would it be to put together a student competition that focused on new and novel visualization techniques? Such a competition would accentuate the profession while demonstrating what the new wave of talent can bring to the world.

I get the AIGA is a membership organization and, in such organizations, it’s the volunteers making things happen. But this was a funded survey. (And the AIGA has this weird position of people not doing work for free—despite the fact they regularly ask me to volunteer my time to speak for free at their events.) They should’ve funded the project (or bagged the no-spec-work policy) to get the presentation portion as part of the project.

Overall, I’m really disappointed that the AIGA is stuck in this 1996 view of graphic arts. If the goal of the survey salary is to help promote the profession and demonstrate how valuable the organization’s members are to their companies, the best way to do that would be to take advantage of state-of-the-art thinking in that presentation.

Hopefully the AIGA will see that there are huge possibilities they’ve completely ignored. I’d love to see a state-of-the-art salary survey from them soon.

Subscribe to our podcast via

This week we have our longest, and certainly one of our most interesting episodes to date. Jared and Robert met Joshua Muskovitz on the IxDA discussion list when Josh posted an innocent-enough question to the list: what do you call someone who sits squarely on the fence between interaction design and implementation? How do I market myself while job hunting when I have been in the industry so long that I have a really broad range of skills?

Josh certainly does claim a wide range of skills, from interaction design and usability to front-end development, back-end programming, and business development. That brought up the question an employer might also have when reading his resume… “Is this guy for real? Can he really do all of this stuff well?”

As with most debates that Jared and Robert delve into, this one got messy, fast. But it also became very interesting. I knew I had to find Josh and invite him on Userability. I’m glad I did, as it made for a great podcast. Tune in to hear the debate, and if you have an opening for a man like Josh, won’t you let him know?

Have a serious UX question? Send it in and Jared Spool and Robert Hoekman, Jr. will answer it with a healthy dose of levity. Please send your deep, vexing questions to us at userability@uie.com. We’d love to feature you on the show!

We want to hear your take on this debate. Can someone do all the things that Josh can, really well? Can he fit into a corporate structure, or does he need to find a small operation who can really put all his tools to work? Get the debate started again in the comments

While the successful team needs all of these disciplines, there are more of them than most teams have members. This creates a challenge as teams need to spread the experience, knowledge, and skills across multiple team members, turning them from specialists into generalists.

In today’s UIEtips article, I share some of our recent findings in how teams make the call: when should they hire a specialist and when will a generalist work better? Whether you’re a team manager or someone looking to direct their career choices, I think our findings will interest you.

Read the article – Ideal UX Team Makeup: Specialists, Generalists, or Compartmentalists.

What does your organization do to embrace its failures? We’d love to hear from you. Share your thoughts below.

• Because of the economic downturn (due to the rising fuel costs and mortgage market crisis), some companies are laying off and some are disappearing outright.
• Because executives understand the competitive value of creating great experiences, user experience professionals are in great demand.

This convergence means you should have your resume and references up to date. Even if you’re likely only to change jobs within your current organization, having these prepared can make the difference between having a choice and missing an opportunity.

As a hiring manager, I often find people don’t really know how to prepare their references well. This podcast, from the fine folks at Manager Tools, does a great job of explaining how to recruit, prepare, and share your references. It should be a must for anyone who thinks they’d like to grow into a new job, either in the near or far future.

The podcast blurb:

This cast tells you how to handle requests for your references when engaged in a job search.

Even though “References Available Upon Request” is no longer a good idea, reference CHECKING is on the rise and will only increase in the coming years. It seems like since resumes don’t include the age-old line — the why of which we’ll share — somehow far too many job seekers are caught off-guard by reference requests. Ahh, Horstman’s Christmas Rule!

We’ll tell you how to manage and share your references in this cast. And hey, if you’re maintaining your network, this one is EASY!

Sharing Your References at Manager-Tools.com