Program Managers vs. Interaction designers
Recently Joel on Software posted about how to be a program manager and he lists UI design as one of the skills program managers should be responsible for. It’s no surprise that people who call themselves UI designers, such as the folks on on the interaction design mailing list, have taken notice and are mostly unhappy.
(Back story: The idea of program managers, roughly a sergeant level generalist who drives projects, is an idea I like. It’s a job role Microsoft started in the late 1980s . It’s a job I had in the 90s).
Which gets to the question of should PMs do design.
The easy answer is yes, if they are good at it. Most are not. Most do not know this because they’ve never met an interaction designer, someone who does it professionally for a living. Simply because Fred is better at it than his peers, he assumes he is good. It’s not his fault exactly. Most computer science programs and business schools never talk to design schools. Certainly not about how much they need to learn from the other. And most program managers in the world are hired from computer science and business schools.
Anyway, the better teams at Microsoft figured this out over a decade ago. They did one of:
- Hired full time UI designers and usability engineers. (In 2003, when I left, there were over 400 of these people employed at Microsoft).
- Created a special role called a UI PM, who was the PM good at design who led the UI work.
- Or both.
VPs that cared about ease of use invested in these assets, and just as important, built a culture around ease of use taking priority over other considerations.
However, in most cases the above investments had moderate impact on product quality because these people never receive sufficient power to overcome the other 20 PMs running around. Sometimes all the PMs are ignored anyway by the programmers but they are in denial about it, so it’s moot until that fight for power gets sorted out.
The program manager model is just one idea for diving up work. It’s a good model, but does have it’s problems. On larger teams it’s too easy for PMs to get lost in their egos and self-interests, each one fighting to make a great feature, inside of what becomes a mediocre product. It’s also a role that depends on culture, you can’t just graft it on and expect it to work as it impacts everyone.
Program management works best on smaller teams, or in organizations where the PM can have significant power. Once you have 15 or 20 of them running around it gets hard to sort things out. Imagine 15 or 20 film directors trying to work on a film together. If you give them enough power, you don’t need many film directors. And if you don’t need many, it’s easier to find ones with all of the talents you want, including the ability to design user interfaces.
The bottom line: program managers are generalists
At the end of the day it doesn’t matter who makes the UI design decisions provided they are good and they ship. If you’re a PM, your primary obligation is the quality of what goes out the door. If you have someone other than you available who is good at design, your top priority should be to get out of their way, just as you would for someone good at programming, testing, or any other role. Find other things to do to keep busy – I’m sure they exist. The value of the PM, or any manager, is their ability to fight for the best use of everyone’s time, including their own.
If ease of use is truly important in what you’re making, odds are it deserves the attention of a specialist or two who can dedicate their energy to it. If nothing else, they can teach you some of the stuff you don’t know you need to know. PMs can rarely dedicate their attention to anything, as their value is their ability to co-ordinate and lead.
The bestselling book I wrote about program management, Making Things happen, has several nice chapters about how to lead design and customer research, and advocates the above advice.