Lately  I've been commuting to a client site a few times each week, and this has given me time to catch up on technology podcasts, which is great. I've also been working the audiobook version of Good To Great by Jim Collins into my rotation. And I'll be honest, I'm somewhat impressed. The material works well as an audiobook. I suspect that I wouldn't enjoy it as much reading a hardcopy; it would be a little repetitive, and the management fluff signal to noise ratio would be unsatisfactory. 

The basic premise of the book is to ask and answer a single question: Can a good company become a great company and if so, how?

 I'm only a few chapters in, but I've already learned a few ideas worth remembering, i.e., writing in my blog. 

1. I've heard the statement "let's get the right people on the bus" numerous times in my career, and I knew it was based on some idea by Jim Collins: First get the right people on the bus, then decide where to steer it.  However, I didn't know Collins was referencing Tom Wolfe quoting Ken Kesey in Electric Kool-Aid Acid Test.That's very funny to me, the Merry Pranksters' anthem being used as a business management mantra.

   The other slight surprise on this topic is Collins also devotes a lot of effort explaining the less-often-quoted second half of the sentiment, "and get the wrong people off the bus." I probably have a bit of thinking before I understand the nuances of how Collins would apply this concept in different situations, but in general, I'm a fan of any approach that encourages companies to focus on the quality of their employees. That's one of my favorite aspects of my company, Dominion Digital; we put a lot of effort into our hiring process to ensure that we're getting talented people who fit our culture. Sure, it can cause some logistical problems when we're trying ramp up a new team on short notice, but it means that I truly respect and trust all of my coworkers. 

   My company very much has a similar mentality to the one Collins outlines:

   Great companies placed greater weight on character attributes than on specific educational background, practical skills, specialized knowledge, or work experience. Not that those attributes are unimportant, but they viewed these traits as more teachable or learnable, whereas they believed dimensions like character, work ethic, basic intelligence, and dedication to fulfilling commitments are more ingrained. [Lifted from page 52 of GTG hardcover]

2. Related to the previous point, I'm starting to feel that there's a lot of overlap or at least complementary ideas between much of Collins' work and standard Agile principles. A lot of the ideas in Good To Great are indirectly stating how important it is to find passionate people who are self-motivated and then empower them for success. Collins also talks about the importance of finding people who are willing to put the success of the company/project above their own professional success, i.e., people who are devoted to the success of the team, even if it means they get less advancement/recognition in the short-term. Those are also components of a successful Agile team of software developers: passion, transparency, empowerment. I think there's more that could be said on this topic, but I'll wait until I finished the book.

3. Collins has a conclusion about compensation, i.e., financial reward,  that is uncannily similar to a belief I've shared for a long time but have been unable to verbalize. To paraphrase, "compensation is not an effective performance motivator for great employees, but it does work well to attract and retain great people." It's straightforward, but I'll elaborate nonetheless. Great employees are passionate and discplined; doing their best is not a decision they can make -- it's just an essential part of who they are. Higher compensation can help attract them and retain them, but great people can no more perform poorly than they can stop breathing. I think Collins takes to an extreme, certainly a bit further than I would, but I wholeheartedly agree with his basic premise. I know it's true for myself and for many colleagues I respect.

   As long as I'm paid what I consider to be a fair wage, my dedication and passion are relatively unaffected by more compensation. To put it another way, I am fully committed to my job/career/projects, and I try to do my very best always and in all scenarios. If management came to me and said I'd get a 100% bonus if I just performed better, I don't think my behavior would change much if at all. Sure, higher compensation could coerce me into working longer hours (for a short period of time), but I think there's plenty of evidence that longer hours do not result in better performance.

So, I guess my overall point is that I'm enjoying Good To Great more than I expected. There are some good chunks of wisdom or at least data that are valuable for anybody in a business or team-based environment.

I started reading xUnit Test Patterns by Gerard Meszaros over the weekend, and I've been really impressed with it so far. I'm having a very similar experience to when I first read Patterns of Enterprise Application Architecture by Martin Fowler. It's the sudden realization that other people have had to face your exact same problems, and they've come up some pretty elegant solutions. 

Also similar to PEA, xUnit Test Patterns is valuable for experienced development teams in that it names patterns you've been using for a while. Instead of saying, "Remember how we had that setup SQL script for that big search test on that one project," you can say, "Let's use the Back Door Manipulation pattern to setup our data." 

I'm only about 100 pages in; I'll try to provide a full review when I finish/decide I've read enough. 

Last night, I had a couple of those experiences that make you remember just how fantastic the Internet is -- specifically how much easier it is now to communicate with people and corporations.

I ordered a couple of books from Amazon (Domain-Driven Design: Tackling Complexity in the Heart of Software and Applying Domain-Driven Design and Patterns: With Examples in C# and .NET -- I'll post about them later), and I didn't realize that the shipping address was wrong until I received the 'order has been shipped' email. Because the items were on my wishlist, the default shipping address was set to an obsolete address associated with that wishlist, instead of my default click-once address. It was entirely my fault for not double-checking the shipping address. The old shipping address is about 900 miles from my current home, and I couldn't make any progress with the shipper.

Thus, without much hope, I tried explaining my predicament to an Amazon customer service rep via email. A few hours later, I received an email from a nice Indian fellow who had completely resolved the situation. He had contacted the shipper, canceled the first order, and created a new order completely free of charge. He even upgraded the shipping to overnight. I have their Prime membership and spend a significant amount of money on their site. But that level of service far surpasses anything I've received elsewhere. I would never expect a giant company like Amazon to go to such lengths to make an average joe consumer avoid some inconvenience. 

The other event is that I contacted Jon Skeet (the author of C# in Depth: What you need to master C# 2 and 3 and community mentor) to share some code I wrote that was based on some of his examples. I also asked him a question about CLR internals. He answered me the same night, despite this being his first week at a new job with Google. He was extremely nice and thoughtful. It shouldn't surprise me, I guess, but it always does. BTW, congratulations on the new move, Jon; I'm sure it's going to be exciting.