teams

There are 6 posts filed in teams (this is page 1 of 1).

Principles for Recruiting and Hiring Designers [FEEDBACK DESIRED]

[The following is a passage from my book-in-progress on in-house design teams. It’s a (very) rough draft on the principles that should undergird the recruiting and hiring process for designers. I think I believe everything here, and I think it’s pretty complete, but I’d appreciate feedback, commentary, calling of bullshit…]

Recruiting

The recruiting and hiring process warrants the same design attention and intention of any other experience. Do not succumb to your company’s standard operating procedure.

Recruiting designers is different from other recruiting other roles. Recruiters, even those who work with other craftspeople such as engineers, are often surprised to find that what works for other disciplines falls flat with designers. What follows are generalizations, so will not be true in all cases, but have borne out over our careers in hiring. Generally, what we have learned is that designers want to do great work, work with interesting people, and get paid fairly for it, pretty much in that order.

Make the approach humanistic. While no one wants to feel like a cog in a machine, designers are more sensitive than most to feeling subjected to bureaucracy, and some recruiting processes feel like filing taxes or hospital visits–filling out forms, submitting material into a faceless system, uncertainty as to when to expect a response, shuttling from handler to handler. Make sure to provide a human touch at every step in the process. Beware of adopting approaches that make it easier for you, but less personable. Given the competitive talent market, it’s worth feeling some friction and taking on extra work if it makes the experience more pleasant for the candidate.

Money is table stakes, but not a strong motivator. This one is a little tricky, because it can be interpreted that “designers don’t care about money.” While that might be true for a few, most designers want good compensation for their work, particularly where the cost of living is high. That said, throwing money at designers does not guarantee they’ll accept an offer. In fact, many will find it suspicious, wondering what such largesse is masking. (Many designers have an uneasy relationship with money.) Don’t try to exploit designers’ antipathy towards money–they’ll ask around, and if they feel like they’re being taken advantage of, the deal is off. Commit to making offers that are fair for the market, and then spend time and effort on the other factors that will guide their final decision.

Emphasize the work to be done. For most designers, the primary motivation is the nature of what they will work on. Such inclinations vary widely–some designers love hairy content problems, others want to build complex enterprise software, others crave sexy consumer experiences. Recruiting efforts should stress what makes the work compelling from a designer’s standpoint. When Peter was at Groupon, the stock was in a bad place and the company had become a media whipping boy. However, he was able to direct attention to the interesting design probem, which was to figure out how to leverage Groupon’s success with daily deals and create other ways to connect shoppers and local businesses. Designers were attracted by the opportunity to to deliver new features and functionality that created a marketplace, and the meaningful challenge of working with small local businesses at scale.

Explain the context in which that work is done. While some designers are dedicated to solving problems in specific industries, such as healthcare or education, many designers can root out what is interesting in any sufficiently complex problem. So when they’re choosing between job options, they seek to better understand the context in which they will work. Will they be expected to work on their own, or will they be part of a team? Are there opportunities to mentor or be mentored? What kind of authority and ownership will they have over their work? Is design respected within the organization? How does the company treat its employees? No one context works for all designers, so be clear about the characteristics of yours.

Be honest, even frank. Don’t just tell them what they want to hear. Engaging with candidates reveals their preferences and desires. For design leaders hungry for talent, it can be tempting to tell candidates what they want to hear, to get them through the door and at a desk. However, if it contradicts what they then experience, the working relationship starts off on the wrong foot. That person is now less likely to suggest others to join, may themselves be looking for exits, and the effort invested in bringing them proves for nought.

If a candidate makes clear they want to manage others, but there’s no opportunity for that in the foreseeable future, don’t tell them, “Oh sure, let’s discuss that in 6 months and see where we’re at.” Whatever the pain in losing a great prospect, say, “I don’t think we have a fit at this time,” and move on. Bring that person on, even if they have been told there are not management opportunities, and every discussion is clouded by that management desire.  

Be direct and honest about what it is like to work there. Don’t sugarcoat troubles. Don’t dwell on them, but acknowledge them and make clear the steps being taken to address them. The design community can prove surprisingly small and tight-knit, and word gets around. Bullshit is found out.

[There you go. Thanks for reading.]

THE best conference for UX/Design managers and leaders…

…is Adaptive Path’s MX Conference, taking place on March 29-30 2016 in San Francisco.

I’m biased. After a few years away, I’m back and helping program and host this year’s event. We have a stellar line-up, including Bob Baxley (formerly Apple and Pinterest), Hyo Yeon (leading the design charge at McKinsey), Janaki Kumar (VP Design at SAP), Kim Scott (spreading the gospel of Radical Candor, a philosophy I can totally get behind), and many others. Oh, and me (I’ll be co-teaching, with Kristin Skinner, a workshop on “Org Design for Design Orgs”, based on what we’ve been writing in our book).

No other conference packs so much value into two days for folks who are managing/directing/leading design teams.

AND: Use the promotional code FOPM to get 15% off the registration price!

Design Team Leads

My friend Dane Petersen asked on Twitter: “Honest, unsnarky question: If design is thinking by doing and leadership means someone else does the doing, how does a design leader think?”

I’ve written a bunch about this in the book I’m writing. Here is what I wrote about the “team lead”, the person responsible for a 3-7 person design team tackling a problem.

Team Lead

Regardless of size, each design team benefits from a single point of authority and leadership, an individual with vision and high standards who can get the most out of their team. This is the most important role on the team, and the hardest job to do well.

Team leads must be able to:
Manage down. Leads are responsible for overall team performance. They need to create a space (whether physical or conceptual) where great design work can happen. They must coach, guide, mentor, and prod. They address collaboration challenges, personality conflicts, unclear mandates, and people’s emotions.

Manage across. Design leads coordinate with product leads, business leads, technology leads, and people in other functions in order to make sure their teams’ work is appropriately integrated with the larger whole. They must also be able to credibly push back on unreasonable requirements, and goad when others claim that the design team’s work is too difficult to be delivered.

Manage up. It’s crucial that these leads are comfortable talking to executives, whether it’s to explain the rationale behind design decisions or to make the case for spending money, whether on people or facilities. Design leads must present clear arguments, delivered without anger or frustration, that demonstrate how their work ties into the larger goals and objectives of the business.

In short, the best team leads are a combination of coach, diplomat, and salesman. And they are folks who, through, experience, find they can span the conceptual scale from 1,000 feet all the way down to 1 foot. They oversee the end-to-end experience, ensuring that user needs are understood, business objectives are clear, design solutions are appropriate, and the final quality is high. To achieve coherence, they must integrate efforts across product design, communication design, user experience research, and content strategy. They are responsible for articulating a design vision shared not just by their immediate team, but their cross-functional partners as well. No wonder it’s so hard to find such people!

Lessons Learned at Adaptive Path: Project Team Dynamics

Four years ago, as I left Adaptive Path, I wrote a series of emails about things I learned during my time there. One of those was in response to a request from a colleague, “How about some knowledge about managing challenging team dynamics, both on the client or internally. Basically project leadership tips.” Team dynamics is among the most important determiners of project success, but also among the least understood and discussed. What follows is very much consulting-oriented (and at some point I’ll write it out from an in-house point of view), but I still think has plenty of general relevance. Just replace “Client Team Dynamics” with “Cross-functional dynamics” and it pretty much works. 

Internal Team Dynamics
Let me start with internally. I don’t know what it is, exactly, but I haven’t had a challenging internal team dynamic for, well, years. I would attribute this to a few things:
  • I do not tell people *how* to do their work.
  • I expend my effort creating a space (figurative or literal) where great work can happen.
  • I nip negativity in the bud — criticism and expressing concern are good, but when it gets into a truly negative place, where conversation and exploration is getting shut down, I tackle that directly.
  • I acknowledge my faults and shortcomings (i.e., you don’t want me opening any Adobe tool).
  • I don’t take things personally.
  • I’m pretty laid-back in a project environment.
This is not to say I am not super concerned with quality, or I’m willing to let substandard stuff go out, because I’m too groovy to get up in people’s business. But my critique and feedback style, which the Yeti Skyway [a project code name] team saw, is less about, “This sucks, make it better,” than it is, “Hey, I think we all recognize we could push this to a better place. Let’s reframe the problem, and poke at it from a different angle.”
Client Team Dynamics
This gets a little trickier. I’ve been lucky in my last few projects where I’ve had the fortune to work with delightful client partners. That said, I’ve definitely had my share of challenging clients. One key thing, which I mentioned with internal team dynamics is:
  • I don’t take things personally
This is so huge. As Chula pointed out at lunch yesterday, it’s probably the thing that allowed me to work well with all the original founders, even when some of them couldn’t work well with one another.
We cannot let ourselves get caught up in our clients’ shit.
I also find being open and honest with clients has served me well. What have we got to lose? They’ve hired us to challenge them. I sometimes have to remind them that if we’re not making them uncomfortable, we’re not doing our job.
With client team dynamics, I have found that it can be powerful to engage with the emotional aspects of the relationship. Too often we think that because this is a “business” relationship with our clients, we have to shut down those elements that make us human, and be a bit more like automatons, focusing on the work product, and ignoring emotional factors. But emotional factors directly affect our work, and, if handled respectfully, it can be quite helpful to address them.
A key to successful client relations and team dynamics has been to keep the client in the loop. Even if the updates are brief, daily or semi-daily updates, communications through Basecamp, etc., go a long way.
Other Aspects of Project Leadership
Something project leads need to have, and which takes a while to develop, is swagger. Swagger is that confidence in yourself, your team, and your approach. It’s a belief that you are *probably* right (though it’s important to recognize when you are not). It’s a certain charisma that gets the client comfortable with you, and to believe that you’re doing best work for them.
Swagger doesn’t have to be some masculine strut, it just has to be the confidence of your convictions.
The other thing to remember about project leadership is that it is a consulting role first, and a design role second. This is probably the hardest part for folks to understand and embrace as they become project leads. You need to let go of some of the design work, trust the team to do great work, and instead focus on creating the space for great work to happen, and engaging with the client in such a way to make sure they’re supporting the great work.

Lessons Learned at Adaptive Path: Recruiting and hiring designers

Four years ago, as I was leaving Adaptive Path, I sent a series of emails about what I’d learned in my 10+ years there. These were recently brought back to my attention, and I think there’s some hard-earned wisdom still worth sharing. Here’s the first.

So, we’re in a super-active hiring phase right now. This is an exciting time. Recruiting and hiring are among my favorite activities. I love talking to people, understanding where they’re at, how they approach problems, what they’re looking for, and trying to figure out if they’re right for us. Hiring can be a huge time commitment, and you need to be prepared for that. But, honestly, there’s little else we do that is as important to our business as hiring, and it’s worth all the time and effort to make sure we’re doing it as best we can.

My cardinal rule of hiring would be, Don’t hire the best; hire the most appropriate. It’s not enough to be a great designer — you need to be someone who will be great in the context of Adaptive Path. 

The slippery thing about that is that context always changes. Sometimes it’s a matter of what we need at a particular moment — do we need more strategist/thinkers? More maker/prototypers? More people interesting in speaking, writing, sharing with the world? 

I’m a big fan of complementarity. You don’t want a team that all looks the same. You want different skills, capabilities, backgrounds, and perspectives. You want diversity of experience, whether professional experience or life experience. Breadth is crucial, particularly in the kind of Big Picture work we do that requires synthetic thinking. 

At Adaptive Path, I’ve never been interested in hiring people who are passionate about design. I actually think that leads to a navel-gazing-ness that focuses too much on form. I have always looked for people who are passionate about the impact that design can have in the world. Design is a tool — it’s not an end to itself. I think crucial to Adaptive Path’s success, and our distinctive take on challenges, is born of this appreciation. What’s great about it is that you sometimes end up solving problems with non-design tools. My personal favorite deliverable in my past two years here was the SKT Trend Map [a 6-foot tall poster that was mostly words, articulating how the media landscape would evolve over time]. It was the right way to solve the problem, and not in anyway anything you’d think of as “design.” 

The other thing that you get when you engage with people passionate about impact is that they also tend to want to engage more broadly. They want to speak, write, and interact with a community, because their bigger-picture passion spurs them to do so. 

Don’t let people’s quirks turn you off. Given that we’re a consulting company, we tend to get nervous about how someone will present in front of a client. And so we get wary of people who come across a bit differently. I love quirkiness. It has served me, and Adaptive Path well. Embrace some freakiness. 

In terms of recruiting, I would suggest that you not be shy. In this latest wave, I’ve trawled through my email folders looking for people we’ve talked to in the past, seen where some of them are now, and reached out and said, “Hey, I don’t know what you’re up to, but we have these amazing opportunities… And if it’s not right for you, maybe you know someone?” And it has lead to us starting some conversations with great candidates. 

And: LinkedIn. It works, even if you don’t have a paid account.

In the four years since I’ve left Adaptive Path, this still is how I operate. The only thing I can think to add is, “If a candidate doesn’t feel right, go with that instinct and don’t hire them.” While my gut has mislead me on the positive side a few times, where I’m excited about a candidate who then ends up not working out, my gut has never mislead me on the negative side — anyone I’ve hired against my get (because there was some other logical rationale), has never worked out.

If you have questions about recruiting and hiring, I’d love to read them in the comments.

Design should drive product and engineering, not vice versa

[Note: I’m actually wary of “should”s, and what follows is more of a provocation than a call to arms. But I think it needs to be seriously considered.]

In 2007, Jared Spool wrote about the market maturity framework, and how technical product categories evolve from “technology” (where it’s compelling that a product simply does a thing at all) to “features” (where there’s competition that stakes claims based on the number of capabilities) to “experience” (which delivers a gestalt greater than the sum of the parts, and often involves removing features).

Most technical product organizations are still driven by engineering (“technology”) or product management (“features”). “Experience” is where design comes to the fore, but because of its nascency, design is typically subsumed into an existing engineering- or PM-driven org.

This means that many organizations place design within existing product/feature teams, looking something like this (for an imagined e-commerce service):

typicalprod

The vertical orientation is primary. On the left, there’s a leadership team with a Director of Design, Director of Product, and Director of Engineering who coordinate and plan across the teams. Then you have distinct “feature” teams that own different parts of the product, comprised of a product manager, a designer, and 4 (or so) engineers.

At Groupon, and in some other orgs I know, you see an organization more like this:
centralizedpartnership

The design team is distinct and works together. The Director of Design still coordinates with Director of Product and Director of Engineering, and now also with a Product Manager on a key feature team. We’ve introduced Senior Designers who own relationships with two Product Managers each. When a PM needs to know what’s going on with design, the PM talks to that senior designer. And then we have 2-3 additional designers who collaborate with the Senior Designers or Director of Design as needed.

I call this a “Centralized Partnership” model, where design is centralized, but, through the senior designers, there is a real commitment and partnership with product areas. The benefit of this model is that designers can work across multiple features, ensuring coherence of the experience.

However, this is still ruled by “features”. So, maybe we need to fundamentally rethink it?

If companies are serious about focusing on experience, than design teams should be free to work on that holistic experience, which means that they can actually address a whole lot more. At Adaptive Path, I lead a project team on an e-commerce site. We were able to deliver across many more features, because we weren’t constrained by product teams.

designteam_experience

The open question is to figure out how product management and engineering should be structured to support this crafting of experience. But it doesn’t make sense to let legacy organization structures constrict our ability to deliver the greatest possible experience for our users.