Creating a customer obsessive culture

I read a post from Harvard Business recently that was so head spinning I have to share. I have subscribed to the HBR Ideacasts (easy to add to your iPod via iTunes) for a while and listen to them on my commute to work. They are both insightful and quick and easy to understand. I have access to their published components through work and the electronic lead ins provide a great way to focus on the stuff that actually matters.

An example of that is a post titled Why Zappos Pays New Employees to Quit - And You Should To. The idea of giving people a $1000 bonus to quit sounds absolutely insane when you first look at the surface of it. Especially when you consider the high cost of talent acquisition, nut then when you think a little deeper it starts to make sense.

The people who would take such a bonus and leave are people who are asking themselves the question of "what have I gotten myself into". They may be thinking, "this is all well and good but is this really for me?" In most situations when you start a new job you are so focused on pleasing everyone you hardly stop to think if the fit you thought was there really is. As an employer you are also focused on trying to make sure someone fits and gets all the opportunity to succeed they may need. The perception of someone leaving is so very negative that no one wants it.

By taking this approach Zappos short circuits all of those negative items. It becomes not just ok, but encouraged to consider your fit. It becomes not anathema but perfectly acceptable to call it quits when there is not a fit.

It may not be something that every company goes out and does right away (or potentially even should ever do) but I certainly applaud the Zappos team for thinking differently and realizing how to get to their real goal of excellent customer service with fanatical employees.

Brilliant.

A time management observation

Have you ever noticed how critical decision meetings have a tendency to be scheduled at the end of the day? I have noticed this as a trend recently in several of the streams that I am working on.

My first thought was that this was due to the need to work through the day to get the information together in preparation for that meeting. Anecdotally (meaning stuff I have seen, done or messed up myself but may not be statistically significant to the world at large) this seems to be the case in 20-40% of the high criticality meetings that get scheduled. This leaves a gap of 60-80% that could happen at other times in the day.

At the end of the day you are tired. At least (anecdotally) I am since the day has been spent making decisions, digging into problems and hopefully doing real work. So my next thought was why do we push these important meetings to late in the day if we are actually going to be less well equipped to handle them?

The answer (or at least my version of it) came to me as I thought about the tasks list and task list management that I do. Each day I follow the process below.

1. Review a list of tasks. I assign each one an A, B, or C. This roughly amounts to A - MUST DO, B - Good to do, C - No chance I am getting to this, I could schedule it forward now but then that would take time from getting to the A and B stuff.
2. Assign a number to each task starting at 1 for each letter category. (Yes, I never even bother with C)

Now when I do this I can say A1 is more important and I should work on it first. Great! Only my human nature kicks in (chances are if you are reading this you have one of those as well. We tend to keep them in closets and they can get dusty but they do peak out at the worst of times) and suddenly I find myself drifting down the list to item A4 or (say it isn't so) a B1... because it's easier. My little human nature side lives for that little endorphin rush of the check mark so... hmmm... off I go.

With meetings I think we do the same thing. We schedule some simple meetings up front. Easy discussions, standing team meetings etc etc. Then we postpone some of those really important, hard meetings and conversations to later in the day.

So I am going to try to move my important meetings earlier. When I find myself setting up one of these meetings I will catch myself and ask the question "would this be better in the AM? Or now?"

Am I nuts? Is this just how business is supposed to work? Have you seen this? In a global economy with companies getting more global in audience as well as employee base these types of behaviors become not only self-pain inflicting but they don't even make sense given global time zones and the fact that the sunlight moves.

Do you sleep work?

Have you ever gone to bed wondering how you would solve a difficult problem and dreamt up the answer? Apparently you are not alone. A recent survey found that 51% of those surveyed dreamed about work and nearly 70% of those put those dreams into action.

I have always slept with a notebook and pen on my night stand so that I could write down what I thought up while not sleeping or dreamed about. It is interesting to me how many people apparently do the same.

This is of even more interest when you think about it in terms of the "work 40 hours" credo in Extreme Programming. (Really more of a manage your spikes in hours and avoid death marches but I digress). The core of the reason behind that is if you are well rested and fresh you do your best thinking and are best equipped to handle what gets thrown at you.

So next time you have a tricky problem to work out, think about it before bed, write it down as a checklist to complete (leave it on the paper so you can actually sleep) then dream up an answer. (Remember you are still limited by the fact that you won't sprout wings extra heads or anything along those lines so it is likely best to discard those dreams... in fact probably best not to talk about them either.)

A case for the Designated Scapegoat

Have you ever considered why it is that when we consider systems we assign it attributes such as he or she or "misbehaving" or otherwise letting us down? I have. Why you ask.... darned if I know, I have a lot of random things float through my head and some of them are actually are entertaining. Hopefully this is one of those.

It seems that we as humans have a fundamental psychological need to explain things. So in order to explain them we put attributes either internal or external to explain why things happen. Maybe it is because from the age of "really small" we ask why? (and those of us who have children know the number of times we answer that question becomes numbing.) In psychology this is referred to Attribution Theory.

External attribution is things like "the devil possessed the machine and crashed it" or the ever popular "the data center is on a burial ground of some kind and it causes the servers to crash". It may not be true, but it helps us to deal. Or certainly to laugh at our misfortune.

Internal attribution is, in essence, blaming yourself. The easy example is things like "I am a sinner, please forgive me." We see this a little less in technology though it does pop up as well with the occasional person who perpetually places blame on themselves.

This fundamental psychological need is why I am suggesting the role of Designated Scapegoat on all projects. If a designated scapegoat is assigned at the beginning of any project we can simply move on to the fixing of problems since don't have to waste time in meetings deciding who or what is at fault. All of the posturing, political planning, set up, stonewalling, denial etc can cease and we can simply move forward. All blame can preemptively be assigned to the Designated Scapegoat and productive work can begin immediately. My experience with this role suggests that your Designated Scapegoat should be someone who is generally a good natured, understanding and who everyone knows in their hearts is beyond reproach.

Imagine how instead of a two hour meeting where people discuss why it is not their problem you start the meeting off with "Gee Chris, that was a mess up, I can't believe that you crashed the servers across the globe all at the same time." Chris then responds "Yeah, you know in Project Manager school we learned that the best way to crash a system is to push the button really hard, right in the middle." Then blame and attribution discussions are done and conversation can move to actual observed behaviors and problem resolution. What a time saver!!

So as a productivity aid for your next project assign a Designated Scapegoat up front, save yourself from Attribution Theory and all those unnecessary meetings. Focus on fixing problems, root cause analysis and long term fixes. Jump right past the blame game with this easy step.

Friday Link Day - Microsoft to buy Yahoo!?

News has started to come out that Microsoft is looking to resume talks to buy Yahoo! I think someone has Google envy.

Along the lines of the silicon related post from earlier this week... IBM announced that they have devised a way to create vacuum spaces in chips that will allow them to use less power and run faster. The chips even "assemble themselves" to a certain degree.

Getting tired of the laws of physics holding them back with silicon Intel is working on Laser chips now. NEC is saying that laser chips could power petaflop-class chips. Optical chips may still be a few years away but the idea sure is fun.

How do you get work life balance?

I was reading through some blog posts and stumbled onto a presentation I wanted to share. Stuart Levine, author of "Cut to the Chase," provides a downloadable PDF manifesto entitled Reclaim Your Life: A Two-Week Challenge to Help You Regain Time It has 11 great tips on how to get to the point, and get the time you need to really make a difference. He starts with a quick review of work life balance and how it's easy to say and not so easy to do. Check it out... make the time.

It works on my machine...

It's been a while since I have done a Friday Link Day so I wanted to throw together a quick one and pop a few of my favorites out for this week.

It works on my machine. What technologist has ever existed who has not used these words? Well now you can stamp that application with all of the recognition that a single threaded one time test deserves. By following the criteria outlined in this Blog post you can use the logo below and show the quality of your app.

Next, in the news of the truly cynical at heart, check out this article on Job Cuts for Fun and Profit. Short Circuiting Circuit City decided that 3,400 of it's workers were making just over 50 cents more an hour than their own determined average acceptable salary for a sales associate... so they are laying them off to hire cheaper people. So the next time you are looking for help and wondering why you can't find anyone who knows as much as your 7 year old you can remember how saving 50 cents an hour in employee costs got you an extra 25 cents off a computer. The article, one pulled together as part of the Knowledge at Wharton effort from U Penn Wharton School of Management, actually makes many good points on a number of topics and is worth a read if you get a chance.

Drag Racing vs Rally Racing

Some of you that know me outside of my Uptime Blog posts know that I am a fan of Rally Racing. In part it is because I drive a Subaru so I was drawn to watch. (Yes, a blue STi with the handle on the back so that God can reach down and shake me when he thinks I am doing something dumb is mine.) But also I like Rally racing because it takes a real world car (granted, they gut the interior and up the strength a bit on the components) and drive it like fiends through corners, over dirt roads, through snow and over jumps. It is a real test of driver abilities and a lot of fun to watch or even play on a game console.

So what does this have to do with technology? It has to do with optimization and how optimized you can make a system, either people or computing. If you take the example of a Rally car they need to have horsepower yes, but that is not enough. You need to have torque, suspension flexibility, handling adjustability the ability to turn and to stop is just as important as the ability to go. In one stage you may be racing on a mostly strait asphalt road, in the next over a switch-back 180 degree turn infested gravel road through a forest. The ability to handle that change is very important to build into the car. Conversely if you look at a drag race car the need for handling, turning, even suspension decrease. What you need is horsepower and pure strait line speed (and hopefully the ability to stop, though if you look at some of these cars a parachute is what is used). How boring.

I maintain that business is much more like a Rally race than a Drag race. You never know what curve a competitor is going to throw at you next. The ability to handle those curves, stop on a dime, turn in the other direction and then go full bore ahead again is critical to business survival.

Sometimes though we seem to optimize our ability to go fast and go strait. We focus only on the immediate goal in front of us. Cut out items that are not critical to our achieving that strait ahead goal. We optimize our "people load", "trim the fat", etc. to keep everyone as utilized as possible moving towards the strait line goal. Then a change comes up... and we discover we can't turn as fast as when we started and we are surprised to find we even have a problem changing our direction simply due to momentum.

This is why things like Non-Functional Requirements are critical to a project and a companies long term success. They maintain the ability to turn and stop and give the slack necessary to allow a shift one step to the right. If we are all pushing so hard to go forward in a strait line even adjusting slightly to the side is difficult. In planning this is Risk Management. It's accepting that planning "if all things go right" is not going to really get you there.

Getting the right strategy means you have to assume your competitors are damn good, or at the very least as good as you are, and that they are moving just as fast or faster. When it comes to peering into the future, you just can't be paranoid enough.

- Jack Welch