One question I’m often asked is what is the ideal designer? – I get this from managers or VPs in tech companies, trying to figure out what’s wrong with the relationship their managers / leaders have with the design staff.
Working with ideals is an interesting exercise: it reveals assumptions and forces opinion as there’s no right answer, and even if there were, this universe rarely grants ideals (at least to me). So here’s my staple answer on ideal roles, followed by some thoughts on reality.
The Ideal PM
The best PMs partner with design in a similiar way to their partnership with programmers. They collaborate (not dictate) with the designers/programmers, perhaps starting with their own seeds, or ones from the business folks, and then delegate as much of the engineering thinking and design thinking as they can. The ideal PM focuses on creating the best environment for all roles to do well: marketers, analysts, designers, testers, everyone. They carefully shift the environment, the power balance, and their direct involvement depending on the project goals, the talents involved, and how far along things are.
Instead of designing, PMs should first use their unique powers to co-ordinate their team with (or protect their team from) management, other project teams, budgets, star-charts, etc. Any other time spent designing should only be: in partnership with designers looking for collaboration/feedback, where designers don’t have time or when quality is low (just like they’d help out test, documentation, or whatever). A good PM is a leader and a results machine: willing to do anything to empower people on their team, including keeping their hands out of the design cookie jar (slap).
The ideal designer
Someone with many design talents and who is a natural thought leader on the team. They not only make wireframes and prototypes, but drive the thinking and tradeoffs behind them, comfortably evangalizing good ideas and staying near the center of important discussions. They are drivers in resolving design issues, solving problems, and making things happen, and people happily come to them for help with decisions. They are communicators and collaborators as much as idea generators, leading design ideas through engineering, marketing and other parts of the process. They negotiate with PMs on when to handoff design leadership and who is best able to represent a decision, a design or a problem to the rest of the team.
Designers should be the tiebreaker in design issues and be granted signifigant authority when ease of use, style and other design traits are important goals. The designer’s opinion on design matters should trump others, just as an engineer or marketer’s opinion would in certain situations. A good product designer earns these powers through the respect of everyone they interact with, as an intelligent, thoughtful, reliable teammate.
The common dysfunctions
I offer these not as inditements of entire disciplines – that’d be stupid. Instead, I can tell you that when there are problems, these are the most common things I’ve seen for PMs & Designers. If what follows pisses you off, find your counterpart: maybe PMs & Designers can at least bond in their flaming hatred for me.
(Hint: Put your lead suits on now)
Common PM dysfunctions
Many PMs know little about design, or worse, believe they know everything – the result is any good designer will be quickly frustrated and turned off by them. Arrogant PMs, particularly from tech-backgrounds, often have limited exposure to designers, or only mediocre, limited role / contracted ones, creating a self-fulfilling loop for their low expectations for design staff. Even if they come across a superstar design talent, the PM will be blind to it, misuse it, or frustrate it to the point that they are rendered mediocre, insanely bitter, or both.
PMs can be tyrants and empire builders (“Here comes Napoleon” is often heard just before PMs enter rooms), comically insecure about their power, who see designers as threats to their fragile sense of power.
Common designer dysfunctions
(Hint: Don’t touch that suit unless you’re adding another layer).
Many designers claim to want leadership roles, but as soon as there is a design tradeoff debate, or a tough business decision, moments where there is an interdisciplinary leadership vacumn that they are primed to fill, they retreat. When their team leaders need to be taught core design principles, brand fundamentals, or any basic concept, some designers sit in gloomy silence, prefering endlessly clever protests in private to stepping forward in mixed company as a true design leader. This kind of passive aggression confirms the team’s perception of designers as (bitter) specialists, and simultaneously reinforces the designer’s frustration with their environment.
Designers often have auteur sized egos without the auteur quality track record of shipped work (At least in the eyes of their team, if not in truth). This gap between how designers percieve their talents vs. how their team values their talents must narrow for relationships to improve, and the designer, in the minority, often has to compromise first but is unwilling to do so.
So how do you fix PM / design relations?
PMs have more responsibility for these issues: so I start there. They are often granted more authority than designers, and have broader responsibility – meaning it’s up to them to delegate authority to design or do whatever it takes to make designers effective. A good PM should see a designer or programmer as both a person and a resource, and their job is to maximize the value of that resource towards the goals. If a PM is honestly trying to make a designer as valuable as possible, collaboration becomes natural and tension evaporates. And if the designer reciprocates (does whatever it takes to help towards the goals), same thing.
But designers have to take risks with their roles – if they want more power or influence that only comes with asking for bigger challenges and delivering: something they have to push for on their own (In old-school Microsoft parlance, you have to step up). These changes make designers feel vulnerable, but growth requires moving out of comfort zones.
In groups with no history (or a bloody one) of pm/design relations, it often takes a pilot effort: pick your most compatible pairing of a PM and a designer, define a new set of ground rules, and give them the cover-fire and resources (by their definition) to run with it. In a month when they can show kick-ass results, highlight them to the rest of the organization as the model to emulate. You need local examples of the new relationship working for people with intrenched opinions to change their minds. (Often you need to pick a trio of PM/dev/design for the pilot to work).
Reward models for Designers & PMs
The Pavlovian answer to all these problems is how the senior manager overseeing everyone rewards PM/designer behavior. If designers are rewarded for stepping up and being visible, they’ll do it more often. If you give kudos to the PM/designer pairings that collaborate best, more people will emulate them. So moving a team closer to ideals has more to do with what behavior is rewarded (promotions, raises, kudos, yachts, mansions, etc.) than what’s said or written down. Writing role definition documents is a waste of time if not tied to the core reward system.
One tricky pattern at many software companies (Microsoft included) is how people are rewarded for features: new features, big features, it’s features that drive how visible people are in their organization. (This is the true reason for bloat: people know it’s bad design, but the system rewards it, so someone always does it). To give designers more power in these environments demands shifting the PM reward structure away from feature design, and towards team building & team results, a difficult culture shift.
Notes and caveats
- Since ideal people are rare, the best you can often do is approximate with a team. If you have 3 or 4 PMs who in conjuction play the roles, you have a virtually ideal situation. In reality this is a better way to use these idealizations that trying to hire perfect people.
- Often it’s the lead position (lead designer / lead PM) that is closest to the ideal in the role that they play: using their own talents, and the talents of their reports, they are most accountable for using the resources in the best way possible.
- It’s synergy at the manager levels that makes all the difference. If the overall project manager is sympatico with the most senior design manager, they’ll naturally pave the way for similiarly healthy relationships all the way down. But if they don’t, that gap will cause all of the organizations problems. Until they admit this and solve it, progress is uphill, on ice, in the dark, naked, while chased by rabid crampon wearing wolves.
- There are many different kinds of design, which means many different relationships and roles. If I knew the details in a particular case (Feel free to offer one) I’d likely offer a modified set of ideals. The roles of visual, interaction, game, and web designers all create unique challenges.
- Where is usability / user assitance / marketing / VP / me in all this? Hey, it’s just a blog post – can’t cover everybody. If you raise entertaining complaints in the comments, odds go up I’ll write about your favorite role pairing next time.
Rather than torture y’all with my first foray into liveblogging, I’m writing live comments, insights, and brlliant notes on each and every session.
There’s a 
As I’m on the home stretch of finishing the 
It’s easy to assume that 
Gutenberg’s major asset in these achievements, beyond