How To Build An Agile UX Team: Hiring

Advertisement

This is the second in a three-part series on how to build and grow successful user experience teams in agile environments1. It covers challenges related to organization, hiring and integration that plague UX teams in these situations. The perspective is that of a team leader, but the tactics described can be applied to multiple levels in an organization.

In part 12 of this series, we discussed what kind of organizational structures and attitudes are needed for agile and UX integration to take root. The third and final section will deal specifically with how to integrate the team. In this section, we’ll discuss hiring. As you build and grow an agile UX team, hiring becomes a central point of impact for the team. Understanding what to look for in designers and how to assess their potential success (or failure) in your agile environment can be tricky. In addition, not all (and potentially none) of your legacy designers will integrate with the agile methodology. Here are a few ways to go about it.

Agile Designers Are Hard To Find

A cross-functional scrum team sketching together3
Anyone you add to your agile UX team must be willing to work collaboratively.

Simply advertising “agile” in your job description will not drive enough interest from designers who actually have experience with the process, mainly because many designers with at least five years of experience have never worked this way. Also, the proliferation of interactive agencies has produced a huge swathe of designers who have partnered with developers but have minimal experience. When you first meet a prospective member of your UX team, it’s critical to get an understanding of how they approach two things: the concept of “team” and problem-solving.

The Devil Is In The Transitions

To assess how they feel about working on a cross-functional team, go through each employer on their resume to see where they fit in that organization, what their impact was and, most importantly, what triggered their departure from the company. The transitions will often tell you exactly what drove the separation between those companies and your candidate.

Handling Criticism

One warning sign to watch for as you probe their resume is difficulty with taking criticism from beyond the design team. This could foretell of potential challenges with integrating with a scrum team down the road. Feedback will inevitably come from non-designers. If there are already signals that the candidate does not take this type of feedback well, then consider someone else.

Hero Designers

Next, keep an ear out for rock-star syndrome. If the transitions in your candidate’s career were driven by “too much criticism” of their work, or an inability to build the designs they came up with, or a propensity to simply leave a job if the chemistry wasn’t immediately there, then you may be dealing with someone who believes they are a hero designer. Hero designers are problematic in agile environments because agile is distinctly anti-hero. It promotes the concept of the team (not the individual designer or developer) as the smallest unit of labor, and it focuses on that team winning and losing together. A hero designer will undoubtedly upset that dynamic by wasting energy and time on unproductive conversations. Hero designers struggle to collaborate and share their work productively.

Job Transitions

Finally, when discussing job transitions, be wary of frequent changes of employer. The risk here is that your candidate is unable to gel well with their teams. If it has happened once or twice, it could simply have been a coincidental matching with bad teams. If it has happened more than that, though, the issue will typically be with the designer. Maintain a line of questioning around those transitions to see if you can notice any anti-team patterns.

Problem-Solving Over Portfolios

Understanding how your candidate solves problems is the next big hurdle. A portfolio can provide evidence that the designer can create an aesthetically pleasing experience, but it doesn’t speak to the problems that those designs actually solved. Portfolios should be treated as conversation starters. The ubiquity of design tools makes it relatively easy for any designer to “draw a straight line.” Ask your candidate to pick the project on which they feel they had the most impact and to walk you through the problem statement, their approach to solving it, their contribution to the project and the result.

Going through the project’s entire lifecycle will show you where the candidate is strong. Do they engage right away at the problem-statement level? This is critical in agile because you’re constantly working to validate your hypotheses for the solution. Can they articulate an understanding of the target audience when promoting a solution? Again, knowing the customer will help to drive more value to that customer faster: a core agile tenet.

Finally, how interested are they in the success of the implementation? If they are comfortable launching a product without wanting insight into how well it’s performing, then they’re likely not a good fit for your agile UX team. Having an interest in the efficacy of their solutions is imperative. In your agile shop, they will be iterating on their work based on this performance data. An innate curiosity here signals a potentially worthy candidate.

Spend Some Time Together Outside Of The Interview

In assessing how well the candidate will integrate with your team, a critical interview tactic is to plant them with their prospective teammates. This could be as short as an hour-long exercise or even as long as a full day. Have the designer join in on the team’s activities, and ensure that those activities include whiteboarding, brainstorming and general team-wide problem-solving exercises. This tactic will reveal as much about the candidate’s skills as it will about team chemistry and likability. Ultimately, as the hiring manger, you won’t be working as closely with this person as the team will, so let their opinions shape some of the process of deciding on the candidate’s viability.

As a final assessment, have a developer interview the candidate. Like the others, this tactic will reveal several things, including the designer’s ability to communicate with developers. Can they communicate effectively with team members from other disciplines and create a meaningful conversation around the problems that the team is working to solve? Can they inspire the developer through a previous team’s win (or loss — as long as the candidate focuses on the lessons learned)? This final interview should shed more light on the candidate’s chances of success in your agile environment.

Conclusion

Agile UX team hiring is similar in many ways to any other UX hiring activity, with some key differentiators. Besides assessing the designer’s skills, it’s imperative to understand how well they work with a cross-functional team. The tactics mentioned in this article will provide insight into the designer’s mindset and can serve as predictors of their success in integrating in your team. What tactics have you used in interviews to understand the candidate better?

You’ve set up the right infrastructure and hired the right team. In the third and final part of this series, we’ll discuss how to integrate these elements into a productive team.

(al)

Footnotes

  1. 1 http://en.wikipedia.org/wiki/Agile_software_development
  2. 2 http://www.smashingmagazine.com/2011/10/18/how-to-build-an-agile-ux-team-culture/
  3. 3 http://www.jeffgothelf.com/blog/

↑ Back to topShare on Twitter

Jeff Gothelf is a user experience designer based in metro NYC. He has spent his career designing engaging experiences for clients big and small. He is currently the Director of User Experience at TheLadders.com where he helps executive jobseekers and recruiters make meaningful connections with each other. Previously Jeff helped shape the designs of AOL, Webtrends and Fidelity. Jeff publishes his thoughts on his blog and on Twitter. Jeff is presenting Lean UX: Getting Out of The Deliverables Business at this year's SXSW 2011 conference and the IA Summit.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Hi Jeff,

    Are you suggesting that in order to work in an Agile team, you now need previous Agile experience? Is knowing the framework right now a requirement in order to be eligible for the job?

    I don’t even think that the word “Agile” should even exist when looking for candidates.

    – pmhut.com

    • 2

      I’m not suggesting that previous Agile experience is necessary. I am suggesting that a team-based mindset is necessary and the willingness to regularly interact with non-designers on design problems is also necessary.

      Design is about solving problems. If the candidate is not willing to work with the team to solve those problems, they will fail in an Agile environment (arguably in most environments).

      [Jeff]
      @jboogie

  2. 3

    Hey Jeff,
    I’m sure you know this (especially given your line of work at TheLadders), but your readers may not: frequent changes of employer is a fact of life these days.

    Long-term permanent positions aren’t frequently offered to designers; look at the swath of 90 day contracts, temp-to-perm contracts, etc. Companies have found they save more by treating designers like interchangeable parts, and with recent economic conditions, particularly in this industry, it’s something a lot folks have to deal with.

    People who are looking to hire designers and notice a number of clients over a short period of time need to do their due diligence: was this person leaving because he or she is a hero or non-team-oriented designer, or simply working a number of short-term contract or freelance gigs where work was available and paid the bills?

  3. 4

    Nice article Jeff,
    We has a small meeting at the morning and we were discussing about how we (deveplopers) can had more voice on the wireframing early process,( and where it normally involves most to the graphic/brand designers, PM’s and client), to minimize the appeareance of too much new unsetted requests once the coding has started and are into an advanced stage.
    Is here we’re my recommendation was to involve more directly into the early prototyping to at least one represent of each area to solve (design, technology, PM schedule/budget guys and client), all of these persons are from different backgrounds, but sometimes some of them share the same goal “focus on solutions not on how rockstar I am.” These kind of skill is what I understand that you said is important, bc we are a team and based on that collaboration we can expect a succesfully and smooth project development process.
    The AGILE concept is not new, most of us has been secretly living with it or desiring it, it just come more relevant and clear these days based on the evolved kind of complex projects that we normally get from the client, and so, it need to be refined to approach it to the maximum.

  4. 5

    Thanks for saying that Chris–you spoke my mind. It goes without saying that we still want to ask a candidate why they left their previous position(s), but don’t instantly eliminate their resume from the stack because they have a long string of jobs only lasting 1-3 years each. That’s completely normal nowadays.

    The longest I’ve ever personally seen a creative continuously employed (at the same creative agency) is 10 years–and he was at the executive/partner level.

↑ Back to top