Hi there. I’m now back from my ramble through Scandinavia.

If you were at my seminar in Milwaukee (we had many questions on estimates and schedules), or struggle with bad estimates somewhere else in the world, you’re in luck.

Next week my friend Steve McConnell is doing a free webcast on the ten deadly sins of estimation. As if the regular sins weren’t bad enough, these are the ones that kill. Registration and details here.  Tuesday June 23rd, 10am PST.

And here’s more stuff from Steve’s consulting firm, Construx, on estimation:

• Construx Estimatation tool

• Estimation Poster

• Cone of Uncertainty White Paper

• Software Estimation In-Depth Class

Posted in Management, Software/Web development | 2 Comments »

There’s a new book, soon to be released from O’Reilly called Beautiful teams, edited by Andrew Stellman and Jennifer Greene that i want to give you a heads up about.

I’m a huge believer in teams. Team sports. Team players. Team leaders. It’s all about teams. Show me a great project and I’ll show you a good, or not totally sucking team. Show me a project in trouble and the first questions I’ll ask won’t be about methods, schedules or technologies, I’ll ask about the team.

I’m also someone who hates bullshit. Who gets frustrated by phony stories about made up concepts on how good teams are nurtured and how great teams function. I want the real stories from the people who were there. I want the dirt. I want the scars. I want it all.

So I’m thrilled to tell you O’Reilly is finally publishing a book on teams, with chapters from two dozen luminaries from the software world, on what they learned from the teams they worked on. Tim O’Reilly, Cory Doctorow, Grady Booch, Steve McConnell, Barry Boehm, Karl Fogel, Johanna Rothman, the list of kick-ass names who contributed to this book goes on.

The book is called Beautiful teams: Inspiring and Cautionary Tales from Veteran Team Leaders.

I was lucky enough to be asked to make two contributions to the book. A chapter about my experience on IE4 called “Why Ugly Teams Win”, and an extended interview with Steve McConnell about good teams and how they’re made.

As a kicker, profits from the book aren’t going to contributors, they’re going to charity - Playpumps International to be specific.

You can pre-order the book now at amazon.com.

Posted in Management, Software/Web development | 3 Comments »

Christian recently asked, in a comment on how project managers get power:

“…I only had a job because of the programmers…”

Wow, this is humble, in the good sense! But how did you treat those infamous programmer-jerks? How did you handle rough inner team situations?

The best place to start is empathy. Why is someone acting like a jerk? There are basic psychological reasons for this: Either they are insecure, they are unhappy, or they are angry about something.

Ok, there is a fourth reason, that they are psychopathic hell spawn put on the earth to torture all living things in a 10 foot radius, especially you, but lets assume that’s not the case for a moment.

In all three cases it’s possible they have good reasons for behaving like a jerk. Perhaps they are angry at upper management for the same reasons you are, but they see you as part of management (which, if you’re a PM, you are). Or maybe their last project manager was incompetent. Who knows? Not you. You don’t have a clue.

Odds are good it has nothing to do with you - it has to do with how they feel about what’s going on around them. Starting with a little empathy opens the door to finding a solution. If you start with “Fred is a jerk so I will treat him like one” you are likely perpetuating his reasons for behaving like a jerk, and everyone loses.

That said, there are four assets you have: charm, ability, roles and allies.

• Charm to connect. Being likable goes a long way in dealing with people. I don’t mean false niceness or being a cheezeball. I mean using your sense of humor, your natural generosity, your shared interests with someone to establish some basis for positive interaction with another person. It could be almost anything, but look for it. Good morale events help make these connections happen. If you happen to like Metallica, or Porsches, and they do, you now have something positive to talk about where it’s safe for everyone to share and connect.
• Demonstrate your ability to help . If they love making great software, if that’s really what they want, then you just need to show you can help. Even if it’s just helping meetings run better, or eliminating stupid annoyances in how decisions get made, defusing politics, reducing meetings, etc. There are a thousand easy things a decent PM can do that the programmer will noticeably benefit from. Start by asking “what can I do to make you more effective? more productive?” And listen to their answer. Do some of what they ask, come back and ask if it helped. Even if it’s a small thing, you’ve now built a tiny basis of respect for how you can help them.
• Agree on the roles you both play. More than half the time PMs suffer because people do not understand what the PM is doing. What you need to do is sit down with the programmer and make three lists: what I do (write specs), what you do (write code), what we both do together (triage bugs). Invariably there will be disagreements as to who does what work, but by listing them you’ll find all the sore spots in your working relationship. If you strongly disagree on roles, and he thinks you should wash his car, you should be able to go to your respective bosses and ask for clarification.
• Get help from your Allies. Which programmers do you get along with best? These are your allies. Ask them for input on working with Fred. Get their perspective on the frustrations on being a programmer in your organization. You may be able to see Fred in a different light. Have other PMs worked with Fred? What insights do they have?

Of course if after investing some of this energy you decide Fred is, in fact, demon spawn hellbent on destroying all positive energy in the universe, talk to your boss. If Fred is as bad as you say, others will complain and it will become your managers job to solve the problem (fire Fred, move him to more isolated work, get him a therapist).

Most of the time the real problem is people not sharing goals, and not listening to each other. Two things that your average project manager should be good at identifying and resolving.

See also:

• Why project managers get no respect
• Top ten reasons managers become assholes
• Asshole driven development (Now with 285 comments)

Posted in Management, Software/Web development, mailbag | 14 Comments »

Jurgen Appelo over at Noop.nl put together a list of the top 100 blogs for software developers. My blog, the one you’re reading, slides in at #18, which is surprising given how little I write purely about software development these days.

Happy to be on the list - and if you now realize you hate this blog because of it’s lack of emphasis on making software, you now know where else to go.

Posted in Software/Web development | 1 Comment »

Running a bug bash is a dirty secret of software development. You won’t read about them in software engineering classes, or in agile method workshops. But some managers, when overwhelmed with undocumented bugs and not sure what else to do, demand the whole team stop what they’re doing and get as many bugs into the bug database as possible. This is what’s known as a bug bash, and often they’re a waste of time.

It’s true that a proper QA effort, or test-driven development, minimizes the need for this sort of thing, but few software organizations truly qualify. Hell, many so called “first class” organizations don’t have any testers, or a quality assurance plan at all. I bet bug bashes are one of the most common QA techniques used in the world.

And they can be useful - but the most common mistake is doing them by half. A half-assed bug bash sends the message software quality is lip-service. But doing it the right way can turn a project around, raise morale and sharpen a team’s ability to find and manage issues.

How to run a successful bug bash:

• Don’t create panic. If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot. You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
• Freeze the build. You can not do a bug bash on a moving target: you invalidate repro cases and bug findings. Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash. This should go without saying, but you never know. If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
• Show what good bug reports look like. Remind everyone crappy bug reports create extra work. Provide two bug report examples: one good, one bad. In the good example show well written description, clear repro steps, and a search for duplicate bugs. In the bad, show incomprehensible descriptions, impossible repro steps, etc. If you don’t provide examples, don’t expect people to magically know what you’re looking for. Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
• Have an area or type of bug to focus on . Saying “find bugs” is a shot in the dark. It shows you have no clue what’s going on in your project. Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash. Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
• Clear the afternoon from everyone’s schedule. A bug bash should be an entire team activity and a half-day is the perfect amount of time. Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape. If it’s voluntary, or only half the team is asked to do it, the bash will fail. People will smell you’re not serious about the effort, and will contribute accordingly. Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot. Include details (see below) on where bug bash HQ is, what the prizes are, etc.
• Get support from big shots. Brad Silverberg, my VP on Internet Explorer 4.0, used to file bug reports regularly. When bug bashes started he’d set the tone: everyone gets involved. With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (”If Fred, our best programmer is doing it, I should be doing it too”). Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
• Have a bug bash HQ. Finding bugs can be a social activity: have a bug bash headquarters. Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together. This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper morale event. A case of beer and few pizzas costs $60. Well worth it.
• Keep score and have real prizes. Geeks are competitive. Use this to your advantage. Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time. Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ - give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot. You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
• Create rival teams. If you are totally poor, use ego prizes. Have the designers challenge the programmers, or the marketing team challenge the management team. Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”. If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc. Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other. This rivalry will draw more people in, if only to follow along. Do this once and you’ll have a tradition to build on for the next bug bash.

Posted in Software/Web development | 1 Comment »

Thanks to Brady Forrest and Jen Pahilka for giving me not one but two slots this week in a high caliber lineup. It was awesome to meet and talk to so many folks in just a few days (talking to people is always where the value is). (Photo credit: James Duncan Davidson).

Its been awhile since I’ve been to a big tech conference around a singular theme (web 2.0) during its rise. To see both the promise and the hype swirling around together made for a fun couple of days. Walking the expo floor, where vendors and companies demo and pitch for your pleasure, gave me flashbacks to Internet World in ‘96 and ‘97. Back then, there were a zillion “push technology” companies, services and products. Now it’s “social media” or “web 2.0″, with a zillion companies all throwing the same jargon around and mostly failing to distinguish themselves from one another.

There are certainly good ideas in the mix, and I think Tim O’Reilly and Clay Shirky’s opening keynotes did more than any company I saw to speak for those ideas, or even attempt to describe what substance might surface from all the technology, energy and money bouncing around.

The problem for me is how infrequently people investing their lives making these things can describe how, at the end of the day, all of the potential described gets transfered into value. Or why the value provided is worth the risks and costs of using whatever they are selling (register for this, buy that, use this, etc.) It’s not a complex question, but it is the primary one I’m sure many attendees were asking: how much substance and takeaways can I fish out of the buzz?

I wasn’t surprised, but I didn’t hear anyone mention how many amazing things are made, in 2008, by organizations with little interest in web 2.0 concepts - namely Apple, Toyota, your favorite film director, or your favorite music band. Not to mention all of the great amazing things the world produced before 1994 (the year the web, even in 1.0 form, was born). That’s not to say this alone proves anything - my point is only this: it is possible to achieve amazing things, without -insert name of current trend here-. Thriving communities, tribes, and cultures have existed for ages. If its possible to do well without whatever the new secret sauce is, it suggests there’s an underlying element that’s not being talked about. I’m convinced there is a more refined explanation for what people might gain from buying what the expo vendors are selling, but very few people seemed capable of even suggestion one.

The unspoken nugget / explanation / marketing line that might get me jazzed is this:

We have always been collaborative. Always been social. It’s in our genes and it’s what we have evolved to do well. Good technologies enhance our natural abilities, give us useful artificial ones, and help us to get more of what we want from life. Web 2.0 and social media make the process of collaboration and developing relationships more fun, efficient, powerful and meaningful.

Ok. Now we’re talking. With a statement like this I can walk the halls of the expo, or converse with the greatest web 2.0 pundit, and have a straight conversation. Will this get me more of what I want from life? More of what my customers want from me, or vice-versa? I can make tangible arguments about what I want or my customers need and sort some decisions out. But note that the statement above is devoid of hyperbole like revolution, ground breaking, disruptive or transformative, things that are entirely subjective. If you identify a real problem well enough, you never need those words: the people who have those problems will naturally find what you do revolutionary if you really solve their problems.

Ok, enough industry talk. Here’s some shop talk for anyone that saw me speak: I’d give my performance at my innovation workshop a B and the keynote a C+. The keynote was mostly new material and, surprise, I never found my rhythm. I gave it my best but it wasn’t a great 10 minutes. The other funny thing is that the tech crew warned me the remote doesn’t go backwards - it’s kamikaze style - a warning I shrugged off as I couldn’t imagine in a ten minute talk needing to go backwards. Well, guess what, I did. I could have asked them to go back if I’d wanted but didn’t, it wouldn’t have saved my performance anyway :)

Workshop slides here: How to Innovate on Time

Posted in On Tour, Software/Web development, Web 2.0 / social software | No Comments »

Last week I upgraded to the latest version of Wordpress. I’m a huge Wordpress fan, I love what these guys do, and I was psyched to see what they’d done this time around.

Total time: 9 minutes. This was end to end, from downloading their software, to reading instructions, to the moment I was able to make my first post. And this included an extra 2 minutes where FileZilla imploded and I had to start over.

Summary: Thumbs up. Go get it. Most of the changes are for the positive, the UI is cleaner, my top gripes (text-editor and thumbnails) have been fixed, and there are some new minor features. Top complaints are UI fit and finish, there are some gotchas that should have been caught.

Kudos:

• Text editor is much improved: less buggy, fewer perf issues, and better media support. People spend 80% of their time in WP here so happy to see investments to core use here.
• Site wide search instead of just blog posts - obvious win.
• The UI visuals shows some style love - in many places, like the comments view, the style choices make it easier to scan long lists. Other nice touches include a flag next to the comments tab when there are new unmoderated comments.

  

• Many under the hood improvements that I don’t fully understand or expect to use but feel good about anyway.
• Automatic plugin updates. Nice, though this broke for a few plugins I had. Expect the kinks will be fixed by plugin authors from here on out.
• The install is just a few steps and takes minutes with no special skills required.

Complaints:

• Leap of faith upgrade. Doing hand copying of files is very 1980s. I read the instructions ten times to make sure I had it right, and even then I had the willies while waiting for both the files to be copied, and to see the new dashboard working. The intermediary UI didn’t calm my fears at all. Say what you will about Windows or Mac software, but great relief comes from pushing an “install” button, and watching one little progress bar while the software does all the work. Instead in WP there’s a useless page offering no clue how long it will take, and given my hand-copying of files, no way of knowing if I’d screwed something up. To be fair it did take about 20 seconds, but they were the most stressful I’d had all day.

  

• Admin redesign. This felt not quite finished. It’s definitely improved but has 1 step back for every three forward. It’s a space heavy design, with several levels of hierarchy floating in dreamy soft blues and whites. If it’s really a dashboard it should be more software app like than a webpage, but it feels more like the later. The core problem is 4 levels of UI, with varying left right dominance, creates a visual ping pong (left, right, left). Plus there are mismatches of prioritization: The Write a new post button, the most used button on the page, is off the right, while the text “Right now” gets prime real estate on the left.

  

• Tab confusion. The UI rules for tab are simple, peers share the same tabs so people know what is on the same level as what. But there are three orphaned tabs all the way on the right that turn out to be peers to the stuff on the left. No idea why they’d do this. Similar problems on the top with a dashboard tab all the way left, and three orphans on the right (Help/Logout/Forums)

  

• Settings confusion. Much of the UI in wordpress is config related, but is there really a need for three different hierarchies for Manage, Settings, and Plugins? Some of the UI in each can be compressed (e.g. Privacy has one option and doesn’t deserve it’s own page). Even after a week of use I find it hard to remember which top level category to go to for what.
• My everyday tasks are still hard to optimize . This is my top gripe. I’m a very basic, vanilla user. I post 2 or 3 times a week, text and link heavy, with images and thumbnails in most posts. That’s it. No media streaming, no dashboard customization, no multi-users or anything whiz bang at all. Yet I still find it clunky to add images, check links, preview and review, and worse, despite having done it 5000 times there’s no efficiency path. No shortcut keys or tricks to make my routine faster.

Nitpicks:

• The Comments listing should default to showing unmoderated comments. That’s the primary view people with moderation on need to see when going to the comments page.
• On the home dashboard page, first page people see, the word dashboard appears 3 times, all on the leftmost column. The second one is highlighted to indicate it’s active, so the third one isn’t necessary. If people don’t notice the red highlight means it’s active then change the highlight, don’t add another instance of the word.
• Moving the category field to the bottom of the post page is a huge pain. Most people use categories so they hit this set of checkboxes for every post. The current layout forces two scrolls: one to get down there, and a second to scroll the list of categories. This UI should be in the critical path of the UI design for the post page.
• The add media UI is overkill. First, clicking on that tiny little image button takes over the whole screen. Blam - I thought I’d broken something. It’s a jarring, horrible transition. Going modal is ok, but don’t hit me over the head. There are other issues with the flow in this UI: not sure what use cases it is designed for, but everything seems to require lots of steps (And what does Crunching mean? Downloading seems more accurate).

  .

Even with my complaints, I strongly recommend Wordpress. If you want to give it a spin, you can use their free, hosted, blogging service at wordpress.org. If you’re thinking of upgrading or switching check out this handy guide: How to update wordpress with minimal downtime.

Posted in Software/Web development, ui review, usability | 4 Comments »

Joy of joys, I was asked to do a commentary on one my favorite shows. Marketplace, an NPR business news show, is running a story about the culture differences at Microsoft and Yahoo. Right after the story, there’s a short 2 minute commentary by yours truly (Prepare to cover your ears).

If you’re in Seattle, Marketplace airs on KUOW at 6:30pm today. You can listen to NPR live online here.

Once it’s online, I suspect sometime this week, I’ll post a follow up link.

It’s online now: transcript, summary, and audio.

Posted in Microsoft, On Tour, Software/Web development | No Comments »

Everybody loves to think one little trick can make their organization transform into a super creative powerhouse. With the rise of Google, no single tactic comes up more in innovation circles than their concept of 20% time. Simply put, employees get 1/5th of their time to work on projects of their own choosing.

For the myths of innovation book i spent time studying lots of concepts, models and approaches similar to 20% time, and even talked to a few Google employees about how they see the idea. What follows below hits on most of the erroneous assumptions I’ve heard people make about the concept.

Here’s a short report:

• Google’s 20% time is more of an attitude and culture than a rule. First, hourly time isn’t tracked there, so there’s no way to enforce or even know what percentage of time people are spending on side projects. But more importantly, the entire idea seems to function more as an attitude - that new projects should be spawned by whoever has the best ideas, not who is in what place in the hierarchy, and the culture is based on this fundamental belief. There seems to be way more support for the pursuit of ideas generally than in most cultures, and simply creating a 20% rule doesn’t give you that culture. G-mail, Adsense & Google News are three examples of major offerings initiated by a self-motivated engineer. See Google employee Joe Beda’s blog post for one of better first persons accounts you’ll find online.
• It’s worth noting that people at Google work very hard on their 80% time. It’s not as if every Friday is 20% day and work shuts down on all existing projects so people can do their 20% things. Google culture, much like Microsoft in the early 90s, has a very strong, competitive work ethic, and peer pressure and pride drive many people to work hard. Like many tech companies, the vibe is that, yes, if you have an idea you should follow it, but not to the determent of other responsibilities. Time for 20% projects is protected, but more by individuals than by managers. Managers spend little time tracking engineers (span of control is wide, with managers typically having 10 or more reports, influencing people and code more than “managing their direct reports”). I’ve heard different things from employees in different groups at Google about how this has changed as the company has grown (10k employees and counting) and perhaps the variances in their culture will continue to grow. (Read Steve Yegge’s excellent post on software development process at Google).
• The 20% time concept isn’t new. 3M developed a 15% time rule in the 1950s with the same exact intentions and basic philosophy. Masking tape and Post-it notes are two notable products that were concieved and developed by individual engineers working without formal budgets, plans or management support. I’m sure other companies and organizations in the past have had similiar attitudes about creativity (Edison’s Menlo park lab likely qualifies). For more on 3m’s approach read this short Wired article. Also, the Google founders mention at their talk at TED that Montessori school philosophy influenced their ideas on 20% time (Jump to 8:50).
• Google’s culture has a resistance, or even distrust, of hierarchy - they often use voting, peer review, and debate to make decisions or decide which new projects and features to add. With that structure the 20% time idea makes sense as they want self-motivated creatives putting ideas in the hoper for others to review, evaluate, or contribute to, rather than waiting for executives to spend weeks making big vision documents and marketing plans, dividing things up into smaller and smaller pieces, before allowing creatives to make (creatively constrained) contributions. 20% time complements, or perhaps even depends on, what is a unique culture for a large, 10,000 person company. It’s the lack of dependence on hierarchy that empowers individuals, and this is the thing people at more conventional companies have the hardest time comprehending. 3M also had a strong maverick, anti-structure vibe that made their 15% successful. Giving people time is one thing, but it’s the culture of the org they get that time inside that determines how useful that time will be to the company.

20% time experiment: Atlassian, a software development shop, just announced a serious 20% time experiment, adopting the idea in their culture and blogging about it as they go.

Disclosure: Don’t take my word for it alone - While this is based on some research, and although I have visited Google several times, I have never been a Google employee and if you start with the links above you’ll hear from more authoritative sources on Google management and culture than myself. If you know of others I should read, please leave ‘em in the comments.

Posted in Innovation, Software/Web development, creative thinking | 15 Comments »

Andrew Stellman and Jennifer Greene, authors of Head first PMP and Head first C++, are working on a new book called Beautiful Teams.

The goal for the book is to capture great stories about software development teams in a book, using a format similar to the bestseller Beautiful code. I think it’s a great idea and if all goes well I’ll be contributing a chapter.

If you think you can write about a true story from your experience in the tech-sector, that includes something about the team, and the relationships between people involved and how that helped or hurt the project, contact Stellman & Greene here.

Posted in Management, Software/Web development | No Comments »

I’m volunteering to go to the front lines in Todd Wilken’s war against blackberries in meetings. Lifehacker and the NYTimes have taken on similar issues before, and I’m all for it. Here’s why.

Any real meeting, where decisions are being made (e.g. not a status meeting) should require people’s full attention. If people are voluntarily comfortable half reading e-mail and half-listening, it’s an indicator to me that:

• There are too many people in the room.
• Few decisions are being made.
• I’m failing to facilitate the discussion to keep it on target.
• The information being conveyed is low priority.
• I’m wasting f2f time with information I could deliver in other ways.

If I allow this to go on, I encourage passive attention in meetings, further allowing stupid people to prattle on about low priority things, which further encourages more people to tune out. As as Steven M. Smith points out, the blackberry use is a symptom of bad meetings, not the cause. The person running the meeting is the place to point the finger (who is responsible for answering the question is this type of meeting right for the agenda we have?).

Instead, I believe in making attendance at meetings binary. Either you are in, or you are out. If the meeting is too boring to keep your attention, then it’s a good sign to both of us that you do not need to be in the room - so get up and leave. Most meetings should be optional anyway: you don’t have to come, but don’t cry if we decide something you wanted to have input on.

Moreso, 95% of the time what people claim to be urgent status is stuff that can wait. Call bullshit on people. Unless they’re heart surgeons, or front line web people, the world can wait 20 or 30 minutes for the meeting to end for them to get to whatever it is. The web will wait. IM will wait. It can all wait for you if you have your shit together. This is doubly true for leads and managers: if they’re managing their teams well, they should have subordinates who can be effective for a few hours without their hands being held. Most managers should be embarrassed, not proud, to be in hyper-crackberry panic mode all the time.

However, if we’re talking status meetings, where 15 or 20 people are all crammed into a room, that’s another story. These are often a waste of time, but if you must have them, the arguments for passive attention have more weight.

I like Todd’s list of recommendations - worth a look.

Posted in Management, Software/Web development, art of project management | 7 Comments »

I started my career in usability, but switched within a year for a management role on the same project. Why? I realized that usability is not a verb. For all the data and advice I gave my smart team, I was dependent on them to make decisions. I realized my effectiveness in the cause of ease of use would improve dramatically by taking a management role on the development team, rather than an advisory one.

Around 1995 the usability field shifted and usability specialists became usability engineers. The idea was to both get a verb in the name, and to express that usability could be engineered if you followed the right method. It was successful and the field grew fast.

But the problem is this: usability is still not a verb - it’s an attribute of a well made thing. Sticking the word engineer in my job title did not change my training nor give me new skills. It might have helped get me hired, but at best usability engineers are expert advisers. They’re not executives, directors of product development, or even engineers in any practical sense of the word. It’s true that researching, report writing, and analyzing are verbs, but they’re not as potent as designing, programming or building. And more to my point, if that’s the core activity of their job, why isn’t that the primary verb in their title?

The real question

Who has the most control over how well a thing is made? That’s really what all of us want: well made things. The answer to the question is always either:

A) People who do the making, or
B) People in charge of the makers.

For all their progress, most usability/design folks are still neither A nor B. Instead most are

C) people who try to convince A or B to make things in a certain way.

No matter how talented you are, if you are a C, your talents will often be watered down by A and B. If you want more power, there’s only a limited amount A and B will be able to grant, no matter how much they need and respect you.

For years there’s been more toying with names and acronyms instead of actions. We now have User experience, Usability engineering, Information Architects, Interaction Designers, and on it goes. The name changes have meaning to insiders, but most of the people in the tech world care only about the actions we take, not what our business cards say.

How to get what you want

If you have a specialized skill and want more good things to be made using it, one of two things has to happen:

1. Persuasion, political acumen and advocacy must be core, not secondary, skills. I’ve yet to see a usability/design group at any major corporation make these primary hiring criteria. Can you win an argument with an engineer? With the director of marketing? Can you spot the decision maker in a meeting and earn their trust? In most of the world, a kick-ass advocate with mediocre research skills would do twice as much good over someone with the opposite skill set. Stop going to usability conferences or reading design blogs for a year: instead of learning a new HCI method, study advocacy, persuasion and team politics. The power you get from your existing skills will double.
2. Move from expert/adviser roles to general management. Many former engineers and testers went to night school, got an MBA, and moved into management roles - I bet some of you work for them. They transcended their specialty to take on a larger role in the making of things. It’s the general managers that make progress, by enabling budget, headcount and political capital for UX folks. If you don’t see anyone doing this for you, then stop waiting around - go pave the way yourself. If you have true love for making great things it’s the only way it’s likely to happen in your world. With someone like you in a general management role, the usability/design person you work with will be empowered to do great things.

I advise people who want change to stay with the good verbs. Find the people who are doing and moving, or are able to persuade others to do so. The talkers, the report writers, the complainers, the finger pointers, those are the people to avoid: they’ll be doing those things forever. It’s people comfortable with the positive verbs, doing, asking, learning, risking, reaching, who make change, if it’s going to happen at all, possible.

Anyone who understands design or usability understands problem solving, and should be able to apply those methods to their own situations. The above attitude, or something like it, should be a natural path of thought for anyone who wants more influence and power. As Don Norman once advised (applicable to any kind of expert):

“Designers uniformly complain that they are ignored, that they are called in too late, that people complain that when they make suggestions because it costs too much money or slows down the product. It seems that designers are not applying their own methods to their own problems - that when you find a problem, you need to step back to see what the root causes are. If for years, designers are complaining that they are ignored, well, maybe there’s a reason why. “

Related:

• Why ease of use doesn’t happen
• Why usability is a path to failure (Read the comments)

Posted in Design, Software/Web development, usability | 14 Comments »