Symphonious

Managers and HR type people are big on setting objectives and identifying a key metric to absolutely, without doubt determine whether or not that objective was met - usually tying bonuses to that metric. The problem with this is that people then game the system. If the key metric is lines of code per day, then people write excessively long, complex ways of doing things because that's what will get them rewarded. If the metric is defects per thousand lines of code, people stop reporting bugs. For any given metric, there's a simple way to game it and whether or not people realize they're doing it, they will trend towards gaming the system. Overall, this leads to a net loss for the company because people are concerned about their bonuses, instead of focussing on working well as a team and doing what's best for the company.

I'd always considered that bonuses and other incentive plans were just ineffective for engineers because they tend to have more of a build cool stuff value proposition rather than a make lots of money value proposition. It seems however, that incentive plans just don't work in general - Incentive Pay Considered Harmful is one of the articles that adds to the viewpoint that engineers shouldn't be given incentive plans, but it links off, sadly via a broken link, to the writings of Alfie Kohn for the Harvard Business review. Alfie fortunately, seems to have written a number of articles on the subject, one of which is available freely on his website: For Best Results, Forget the Bonus.

While rewards are effective at producing temporary compliance, they are strikingly ineffective at producing lasting changes in attitudes or behavior. The news gets worse. About two dozen studies from the field of social psychology conclusively show that people who expect to receive a reward do not perform as well as those who expect nothing. This result, which holds for all sorts of rewards, people and tasks, is most dramatic when creativity is involved.

Personally, I view rewards as punishment - when I get them, that's expected, when I don't that's punishment. Worse, when the wrong metrics are selected to judge whether or not to give the reward, or the circumstances change between the setting and receiving of the reward, the reward may be withheld because I focussed on doing what was best for the company instead of what is best for getting the reward. In whatever job I do, I consider it my professional duty to do my best and to achieve the best results I can for the company. I find it insulting that someone would question that level of dedication and professionalism by suggesting that dangling money in front of me would make me work harder.

Instead of using rewards, why not focus on improving the work environment so that people enjoy their work more - enjoyment is one of the strongest motivating factors in people. Feeling like an important part of a team is another key motivating factor, so focus on building both good team spirit within departments but also a team spirit company wide - we should all feel like we contribute to more than just our little unit in the business, we are building the company each and every day. Ephox pulls off miracles of engineering on a regular basis and we do it by enjoying the work that we do. Every member of the engineering team is dedicated to improving the business and genuinely wants to see the business succeed. That's because we work as a team in a friendly, happy environment with carefully picked professional employees. We don't work for incentives or money, we work because we love what we do and take pride in it. The money has to be there to pay the bills and be able to do what we want to outside of work, so it's important to pay your employees well, but it's not the driving focus that makes us come to work everyday that managers tend to think it is.

If you think your team isn't working at 100%, then look into how much they are enjoying their work, how well they gel as a team and how much the company is listening to their ideas, comments and feedback to make them feel like part of the company's team, then improve those areas. Dangling a carrot in front of them is more likely to demoralize them and cause them to game the system.

So Google, the company that does no evil, seems to be learning a few tricks from the evil empire of Microsoft. With the release of Google Checkout, Google have effectively implemented Microsoft's failed passport initiative but with a purchasing spin. Most of the similarities I've seen compare it to PayPal1, but my first impression was that this is single sign-on for web stores and that's more along the lines of passport than PayPal.

PayPal is set up as a replacement for banks and credit cards on the web, allowing it to theoretically help prevent fraud2 and allow micropayments. From the brief impression I have of Google Checkout, it appears to be more about allowing you to use your credit card on the web more easily via single sign on.

So now, Google knows what you search for, what email you get, who you chat with about what and when, what meetings you've got and what your plans are for the weekend, it's running your local soccer Mum's support group mailing list, publishing your blog, managing your photos, searching and indexing every file on your computer and every web page your visit and it wants to know your credit card number, all your personal details and everything you buy. Not all of that information is submitted back to Google, but it is a little scary at how quickly and how much Google is invading our personal lives. Then again, anyone's who bought a Mac is probably in the same situation with Apple. Microsoft, RedHat and Debian are probably in similar situations, given that the OS controls your computer so even if the apps you use aren't from the same company, the OS still knows all.

Perhaps more interesting though, is the tie-in between Google Checkout and Google Adwords. Adwords are a huge success for Google, so anything they release that can leverage off that success has a tremendous advantage in the market place - just like Microsoft's integration of IE into Windows gave it a huge advantage. If Google can get enough exposure for Google Checkout and convince the average user that it's safe and easy to use, it will become almost essential to use Google Checkout if you plan to advertise with Adwords. There is one important difference between Microsoft and Google though, Microsoft is a convicted monopolist and Google isn't. Leveraging your monopoly to gain a foothold in another market is illegal, leveraging a popular product to do the same thing isn't.

All that said, I'm not sure Google Checkout is evil, it seems like a good idea and if you're paying with credit card you clearly don't care if some big company knows all your purchases anyway so it will probably make life easier. Keep an eye-out for one-click patent infringement lawsuits in the future and a whole lot of complaining from companies who are "forced" to use Google Checkout or their AdWords will be less effective, but it's probably not a bad thing for users who just want to buy stuff on the net. Also keep an eye out for Google to extend their single sign-on scheme beyond just purchasing and into more generic identity management, most likely one area at a time rather than a full on assault at single sign-on like Passport was.

Update: And of course now that I finish reading through the morning RSS, it seems Google is offering a single sign-on type general service, focused at giving web-apps controlled access to a user's data stored in a Google service. (via O'Reilly Radar3)

1 - Which some people consider more evil than Microsoft anyway↩

2 - How successful it is at this is really quite debatable, given that to steal someone's paypal account you just need their username and password↩

3 - And let me take a side-swipe at FeedBurner for obnoxious referrer links while I'm at it.↩

There seems to be a trend these days that whenever you link to some external site, you do so via a redirect script on your own site so that you can track who's following the link and steal some google-juice in case anyone happens to blog about something you pointed them to. I'm not quite sure why, but I just find this obnoxious - maybe it's because I've been frustrated a couple of times when the referrer script was down, thus breaking the link - even though the actual site was up. Maybe it's because I resent the couple of extra seconds it takes to follow the link due to having to make two separate HTTP requests. Either way, is it really gaining you anything to put your users through this?

I find it most amusing that Planet HCI actually uses this technique - despite the fact that it makes for a lessened user experience. I just hope that Google is smart enough to pick up these fake links for the spam that they are and doesn't increase a site's page rank because of them.

Jensen Harris has an in-depth look at the customization choices made for Office 2007 and why they made them. I've always been a proponent of getting the UI right in the first place and only providing limited or no customization abilities. Mostly this stems from Raskin's The Humane Interface:

The central point of this issue is that if we are competent user interface designers and can make our interfaces nearly optimal, personalizations can only make the interface worse. Therefore, we must be sparing and deliberate in offering user customizations. If a user can, by a few judicious choices, really improve the interface, we probably have done a poor job.

The exception in this case is also notable:

On the other hand, if a program's interface is as dismal - to voice an opinion - as that of Microsoft Word 97/98, the situation is reversed. Almost any change the user makes is an improvement, to exaggerate only slightly.

The statistics that Jensen quotes shed a very interesting light on the benefits, or lack thereof, of customization:

Looking across a hundred million or so people using Office 2003, here's what we found:

• In fewer than 2% of sessions, the program was running with customized command bars.
• Of the 2% of sessions with customizations present, 85% included customization of four or fewer commands

So despite all the vocal demands for customizable software that you hear, and that no doubt will turn up as comments to this post, less than 2% of people actually use customization features and of them, the vast majority only customize four or fewer commands. Jensen goes on to note that most users who do customize tend to make the same customizations. This of course indicates a defect in the UI design, rather than an argument for customization - if the design is corrected an even greater number of people will have no need for customization.

I also found it interesting that Office provides an XML format for customizing the layout of the ribbon, RibbonX. This is actually an approach that I consider has an awful lot of merit - it is the same method used to provide customization of the UI in EditLive! for Java.

The key advantage of using an XML format instead of a UI as in previous versions of Office is that the customization features are effectively hidden away from all those users who don't care about it, but available for system administrators and company-wide policy makers to change things to suit that particular organization. For EditLive! for Java, this is mostly used to remove functionality from the editor to restrict what user's can do. For example, removing the font face and font size controls is common to encourage or force users to use CSS styles and more semantic markup.

Finally, Jensen also touches on another common area I seem to argue about a lot - floating windows:

The story with floating UI is similar. Floating toolbars in Office 97-2003 caused a lot of problems, primarily because they were forced on people as the primary means of accessing many features. As a result, toolbars were always popping up over top of what people were working on, needing to be dragged out of the way, or mistakenly docking to the side of the screen.

Our design mantra for Office 2007 was that default feature access wouldn't rely on floating things popping up on top of the document; the UI would be in a single, consolidated, consistent place.

Amen to that.

One of the most common things touted about XP is that it allows for rapid change. The client can change the requirements on the fly for a very low cost - they can add features, changes features and drop features regularly as the product is developed without incurring a massive cost of change. When you work on in-house applications or custom built software, that provides a really big benefit, but when you develop off the shelf software that means that the final release may contain a mish-mash of new features and be generally unmarketable.

So how do you take advantage of the ability to change that XP provides while still maintaining focus in your product development? Essentially it comes down to having a client, usually the product manager, that keeps track of the long term view and makes sure that while a few little features can be added, and things are improved to be the most useful for end users, on the whole the release stays on track to deliver a cohesive set of new features that user's will actually appreciate.

To a large extent, this means that the client, with the assistance of the rest of the business, engineering team and support team, plans out the aims for the release on a high level, and probably drilling down to some specifics before development starts. It's important to write down those aims so that you can bring them with you to each planning game to make sure that you're on track.

In XP terms, those goals are the yardstick by which you measure value. Each story needs to be evaluated against those goals to see how much value it brings to the release as a whole. The same approach comes out when doing in-house development since you tend to switch over sections of your processes to the new product at a time, so you are inclined to get each section fairly right instead of having a wide spread of largely useless features.

The flexibility of XP will allow you to suddenly add a key goal for a release because of competitive pressures, or to slip in that particular feature to close a big deal, but with some up front planning and an attentive product manager, you can still keep focussed on delivering a solid release.