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.

Design at Jawbone

I’ve been remiss at updating my blog. On the day after my last post, I joined Jawbone to help lead the product design team. And today is a special day, because Dan Saffer, my former colleague from Adaptive Path, and most recently Director of Interaction Design at Smart Design, joins our growing team (in his inimitable style).

I was drawn to Jawbone because I could work on problems that I hadn’t yet tackled, except in conceptual hand-wavey ways at Adaptive Path:

  • hardware/software
  • Internet of Things
  • health/fitness

One thing Jawbone groks is that “the future of wearable technology is not about wearables, it’s about analyzing the data” (Guardian article), and we’ve done some remarkable work on the UP platform in this regard, specifically around what we call Smart Coach. Whereas other tracker systems seem focused on charts, graphs, and dashboards, Smart Coach presents your life in more human ways, with natural language, and prompts and encouragement to live better.

Actually, wearables is not even about the data — it’s about you. Our CEO Hosain Rahman refers to our approach to the Internet of You, where we take in all kinds of signals (from our wrist trackers and from partner’s apps and hardware), draw correlations, and provide insights and feedback across all manner of things. It’s hard work, and we’re only at the very beginning, but the promise is huge and inspiring.

From a strict design perspective, this is easily the most fun I’ve had since Adaptive Path. We’re involved in interactions with hardware, software, mobile, web, watches, and more. We have to balance between hard data and engaging copy. We have to make very hard tradeoffs (battery life versus displays; battery life versus size; battery life versus sensors… you get the picture). On my third day I played with a demo that was a legitimate “Wow, this could be the future!” moment. Just last week I wrote up specs for hardware UI.

In future posts, I’ll write more about my experience in designing at Jawbone. In the meantime, welcome, Dan – we’re going to have some fun!

Why I Don’t Like the iPhone 6

iPhone 4

When I got the iPhone 4, I would turn it over in my hand, studying it. It was a remarkable work of design and engineering, an ecstatic product unlike anything out there, and one of the most beautiful things in my possession.

I was wary of the iPhone 5, as I believed the hype about limitations of hand size guiding phone size, but found the 5 to be an improvement — in this case, more pixels were better.

However, I find the iPhone 6 to be a serious step in the wrong direction. Whereas the craft, precision, and boldness of the prior models could have only come from Apple, this is first iPhone that feels like it could have been made by anyone. (Khoi digs into this very thoughtfully.)

Having used an iPhone 6 since a week after it came out, I feel like I have a firm grasp on just what this phone is. And I don’t really like it.

It’s too big. It’s awkward in the hand. My thumb can’t quite reach the upper-left-hand corner, and I’m constantly mis-tapping items up there. That Apple had to give us a hack to make it more usable should have been a sign to someone (Jony?) that however fashionable this size is, it’s still not a good idea.

I’m constantly having to shift it from pocket to pocket because it doesn’t sit well in any of them. It peeks out over shirt pockets. And yes, you’re constantly afraid of bending it.

And I haven’t realized any benefits from the greater screen size. Apps are in no way improved.

It’s too slippery. The curved edges and aluminum back make it quite slippery. I’ve dropped it a number of times. The 4/5 had those hard edges that gave you something to grip. The 6 is just an eel.

iPhone 6 buttonsThe Sleep/Wake button is in the wrong place. Recognizing that size was a problem, Apple shifted the Sleep/Wake button from the top to the side — so you could reach it with your thumb. However, given that this phone is too big/awkward already, it doesn’t matter where they put the Sleep/Wake button, because you’re already compensating for it’s size.

By putting it on the side, they introduced a whole new problem. The Sleep/Wake button is now symmetrical to the Volume Up button. I typically leave my phone in my pocket while listening to podcasts. Due to the vagaries of different recording levels and ambient noise, I fiddle with volume quite a bit. (Do you see where this is going?) Now, because of symmetricality, half the time when I intend to press the volume button, I instead hit Sleep/Wake. A key principle for successful industrial design is that I don’t need to see the product to use it right — physical affordances should allow me to operate by feel.

Also, if you transition between iPhone 6 and an iPad (as I do), you now find yourself feeling for the Wake/Sleep button on the side of the iPad.

I guess what I don’t like is that the seemingly elegant (because of symmetry) and smart (because of hand size) move of the Sleep/Wake button makes me feel stupid because I’m often pressing the wrong button. This is a classic kind of design error that expresses itself as user error, the impetus for Don Norman to write The Design of Everyday Things.

So, ultimately it’s disappointing. The iPhone 6 is the first generation that lacks perspective, personality, and the obsessive care we’ve come to associate with the product. It’s a me-too phone. It definitely has benefits over the 5s (mostly notably processor speed and camera), so, it’s not like I’m going to downgrade. But had they simply placed the iPhone 6’s guts into an iPhone 5 shell, I would have been much happier.

The fear, of course, is that this is the first step in a post-Jobs design direction, and without his tyrannically high standards, Apple once again loses its way. We’ll see. One hopes it’s simply a fashion-chasing misstep that is corrected over time (though, the market response suggests otherwise). We’ll see.

[It turns out, unsurprisingly, Mark Hurst has some very similar sentiments to mine.]

San Francisco Design Agencies Feeling the Squeeze

This morning, Dan Saffer shared on Twitter that Smart Design SF is shutting down. Earlier this month, Adaptive Path surprised pretty much everyone who cares by announcing they were being acquired by Capital One. So what’s going on?

I don’t know the rationale for Smart’s decision, but in talking to friends, and trying to make sense of what’s happening, it appears there are two opposing forces that San Francisco design firms have had trouble reacting to.

The first is the growth of well-paid in-house design teams at money-hoarding tech companies and well-funded startups. I first saw this about 10 years ago, when Adaptive Path lost a candidate to Google because they offered what we thought was an insane salary. A few years later, Facebook and Twitter followed suit, and now every tech company is offering designers 50-100% more in salary than what design agencies can swing. In the past, agencies could say, “Yes, but we respect and value design in the way that in-house companies don’t, and you’ll get to work on a range of things, instead of just one thing over and over.” That doesn’t hold true anymore, and most of the interesting design work is emerging in-house, and designers want to be where the action is. And get paid better to boot.

Here comes the counterintuitive bit. If design is in such demand (and jobs pages at every company suggests it is), why aren’t agencies just charging more, and using those higher billings to pay their designers more, and thus be competitive? That’s how markets work, right?

Well, not quite. What’s actually happening, according to friends at agencies, is that client’s willingness to buy design from agencies is decreasing, and project budgets have been shrinking. And the prevailing theory is that this is happening because companies are building in-house teams, and that’s where their ‘design budgets’ are going. Whereas in the past, a company might spend 20% of a design budget internally and 80% externally, that’s now swapped.

Another way to put it, as companies have gotten smarter about design, and recognized it’s a competency they need internally (something which Adaptive Path promoted in our book), they’ve become less comfortable outsourcing it.

So, San Francisco design agencies are often billing less than before, yet the talent market is able to earn more than before. This is a quandary.

It’s telling that Smart Design seems to be otherwise financially healthy — last month they opened an office in London. Their main offices is in New York. It just seems like they’ve thrown in the towel in SF, and from what I can see — I don’t blame them.

The Why and The How of Organizations that Deliver Great Experiences

As companies embrace the need to take user experience seriously, often their first step is to build out a “UX department.” However, the reality is that user experience is a phenomenon that emerges from an entire organization’s activities, not just the efforts of one team. There are (at least) six components that need to be aligned throughout the organization, which I’ve grouped into “The Why” and “The How”.

The Why


What do you stand for?

An organization must have a clearly articulated set of values, and if you want to deliver great experiences, those values most include humanistic qualities of customer-centeredness and empathy.

Values statements from Apple, Southwest Airlines, Target.


Where are you headed? 

Everyone must have a shared sense of where the organization is going. This vision must be concrete and inspiring. Bulleted lists do not comprise a vision, because it allows team members to have very different interpretations, which will undermine their efforts to deliver a great experience. At Groupon, before we launched our redesigned website, we created an internal-only “north star” that illustrated what our experience could be in 2 years time. It helped orient everyone in the same direction. Deborah Adler’s “SafeRX” prototype embodied a vision for a new pill delivery system better than any list of requirements could.

Jared Spool has written good stuff about vision: The 3 Qs for Great Experience Design, The 3 Steps For Creating An Experience Vision.


How do we know when we’re successful?

At Adaptive Path, my favorite question to ask client stakeholders during the initial discovery phase was, “How do we know when we’re successful?” It seems so obvious and innocent, but as I worked with more companies, I grew to realize just how few organizations had a clear sense of what success meant to them. However, if you’re not clear about goals and success metrics, it’s much harder to make decisions throughout your process, and your efforts lose focus.

Christina Wodtke’s discussion of OKRs is a good place to go deeper.



How do we encourage desired behavior within the team?

Incentives might seem a highly specific tactical matter compared to the others. Thing is, it warrants being called out as it’s where the best laid plans of delivering great experience get bound up in the legacy behaviors of an organization.

How is performance assessed? What criteria drive rewards (raises, bonuses, promotions)? What behaviors get lauded and evangelized? 

I’ve worked with numerous financial services organizations, where people were rewarded based on the performance within their business unit (banking, brokerage, insurance, loans) or their channel (in store, by phone, online). Such incentives are anathema to great experiences, as it discourages internal cooperation, even though customers are engaging across businesses and channels. 

I recently spoke with Irene Au about her career leading UX teams, and a challenge she had at Google is that individuals were promoted based on how much stuff they shipped, and not about the quality of what was shipped. Optimization and refinement was thus discouraged, even though such iteration is necessary for great experiences.


How do we operate?

The first thing to understand — there is no One True Way. No grand process to rule them all. Delivering great experiences requires discarding rigidly defined processes, instead embracing a toolkit, a set of techniques that can be used as needed to solve specific problems. 

However, there are characteristics of organizational operation that typically lead to the delivery of better experiences.

Work as a cross-functional team as early as possible. Waterfall approaches, where one functional group hands off to the next functional group, deliver poorer experiences. The complexity of the problems you’re trying to solve, the components that need to be marshaled and coordinated in order to succeed, requires input from the entire team from the outset. And not just at a kickoff meeting, but throughout throughout definition, design, and development.

Upfront, qualitative field research reveals opportunities, leads to insights, and sparks creativity. Engaging prospective and active users at the start of a project, understanding their current behaviors, and revealing the motivations and emotions that drive their actions, will lead to insights that in turn identify new opportunities for delivering customer value. 

Design and prototyping are activities that support the entire process, not discrete steps in the process. You can use design and prototyping techniques from the beginning of the process. (For more on this, read about The Double Diamond Model)

Bias towards building and making, not thinking and documenting (though some thinking and documentation can be quite helpful). Companies that deliver great experiences are constantly crafting those experiences, refining and refining them.


What skills are necessary?

This question is the hardest to answer generically, because it’s so dependent on the specifics of experience delivery. That said, there are a couple of newish roles that organizations serious about great user experiences must consider.

Strategic designer. As design gets brought into earlier parts of the process, it’s important that designers are comfortable with strategy and planning. Not all designers excel at these discussions, so it is important to have designers who can engage with and are excited by strategic concerns, and who can hold their own with business analysts,  product managers, and engineers.

Prototype engineering. Engineering is typically seen as a production exercise — creating code that is ready to be deployed. In this new era of iterative design and prototyping, a role has emerged for those who can quickly cobble together interactive prototypes with no concern as to whether the code created is reusable. 

This capability comes from one of two places — technologists who are comfortable being nimble, or designers who are comfortable prototyping their designs. Either way, it’s important that your team can quickly prototype new solutions in such a way that users can experience them and provide meaningful feedback, which will then inform subsequent iterations of the solution. 

I’m Sure There’s More

While I think this is pretty complete, it’s doubtless not exhaustive. I’d love feedback on improvements, be they amendments, refinements, or removals.


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):


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:

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.


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.

Teams are the key to ongoing design success

When presenting my philosophy of design organizations, I show this slide: voltron_teams.051   On the left, comprised of 5 robot lions (stay with me…), you have super robot Voltron, Defender of the Universe.  On the right, 5 unicorns. The unicorns refer to the “design unicorn” a designer skilled at interaction design, visual design, and front-end development. They’re “unicorns” because some believe they don’t exist, though others are betting that they are very much real. For the sake of argument, let’s say that design unicorns are real.

My concern is that all this talk about unicorns, on thus on design at the level of the individual, is misguided, and potentially even harmful to design as a field.

Companies want a unicorn because she can be the lone designer on a product team, working with product managers and engineers to deliver features. On the face of it, this seems great – you get a lot of bang for your buck.

However, in my experience, design is best considered at the level of a design team, and the point of the slide above is that a coordinated team of 5 designers (of varying skill sets) can out perform 5 identically-skilled unicorns working in isolation.

When I joined Groupon, product designers primarily acted on their own in product teams. And what I saw is that the scope of their efforts was quite constricted. When you’re asking one person to deliver interaction design, visual design, and front-end code (or at least something prototyped), it leads to designers focusing on narrowly defined features — a single web page, or augmenting an existing flow.

Among the first things I did as VP of Design was relax our requirements for product designers. They no longer needed to be technically savvy, and, they could have an emphasis in interaction design and IA or in visual design.

And much of my own initial effort was on hiring strong design leads — directors and senior managers. This turned out to be key. About 9 months into my tenure, I organized the 40-plus person Design Union (what we called the whole design team) into a series of teams, each with a lead. This proved transformative not just for design, but the for the company. With these teams in place we could deliver on larger scale efforts like Groupon’s first-ever website redesign (a prior effort, before I had joined, had failed), or DealBuilder, a self-service tool for merchants to launch a deal.

Another short-coming of focusing on design unicorns is that it reduces design to an execution function (I’ve written about definition and execution in my post and presentation on The Double Diamond.) Approaching design from the orientation of teams, with strong team leadership, not only allows designers to tackle broader problems, it also enables them to move “upstream” into the decision-making behind product definition.

Team Structure

Through experience, I’ve arrived at a sense of what seems to work for the structure of design teams (again, these are teams within a larger design organization, not the whole organization itself!).

Teams should have 4-7 members. Any larger than that, and team coordination gets unwieldy.

Teams require strong singular leadership. This Team Lead role is perhaps the most challenging in the whole design organization (even moreso than a VP of Design). The Lead must:

  • Manage down – getting the most and best out of their team
  • Manage across – collaborate with cross-functional partners
  • Manage up – presents to executives and other stakeholders

Pivoting between detailed delivery within your team, coordination with peers in product, engineering, and marketing, and communication to executives can induce a kind of whiplash that not everyone can handle (in fact, I would say it’s rarer than the ‘design unicorn’). But if you find folks who can handle this successfully, your design organization can be surprisingly effective.

These teams should be organized around business problems (supporting a line of business) or aspects of the customer experience, not by function (interaction design team, visual design team, etc.)

And within these teams should be located a spread of skills — user research, strategy, planning, interaction design, information architecture, visual design, and prototyping. And this suggests another reason to Think Beyond Unicorns, as no one could be expected to excel in all of these areas. Instead, hire folks who excel at a couple of these but can productively collaborate across all of them. (I’m not in anyway advocating the hiring of single-minded specialists.)

There’s an alchemy that happens with great design teams, where the whole is greater than the sum of the parts. My understaffed teams were able to deliver far more than could have been reasonably expected because they could leverage their team-ness for greater effectiveness.

When I next write about teams…

Something that I’ve realized is that the ideal level of scope for a design team is different than that of a product and engineering team, and designers are currently constrained by working within an organization optimized for the latter. When I have time (and after I do some doodling), I want to talk about bridging that gap.