Friday, May 30, 2008

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.

Friday, May 16, 2008

Data is no longer relational

Ok, so the headline may be a little of an over statement for effect. Perhaps I could have said that data that people are interested in is no longer relational but then it wouldn't have been nearly so pithy.

With much respect to Edgar Codd and his invention of the relational model for database storage I think it is time to move forward. Relational databases are great for things like financial models, personnel data and other Enterprise Systems as well as many other standard, repetitive data. It gave a solid reference point to learn data structures and modeling to several generations of budding Computer Scientists.

When I say it is time to move forward I am not saying we should immediately move all data systems to Object Oriented Databases or otherwise induce data chaos. What I do want to push is the idea of unstructured data. Computers are great with rules, with structure and with fundamentally binary relationships. Algorithms are starting to mature around unstructured data (for an example go search google.) but it is still not widespread or well understood.

New exciting algorithms such as Amazon's Dynamo (Werner Vogels is one of my favorite speakers and bloggers on distributed tech, if you are not familiar with him in this space you should be) database are showing in real world situations that distributed systems and distributed data are a reality.

In a lot of system designs because people are so familiar with relational data structures and systems we find Object Models that look like a relational database design. When asked why it looks like this the answers are fairly consistently things like "this is how the database stores it, for speed we need to do the same" or "it just made sense when we pulled the DBA in to help us with the model."

Objects are not relational! They are objects. Then when you get into full structures of objects or object trees there are relationships but it is not the same as a relational database. Especially as we start to build and mature distributed system algorithms it doesn't make sense to use a centralized data store. If the data can be broken up, distributed and stored with the algorithms that will use it performance will improve.

In fact I would argue that the elusive SLA of a system response can begin to be discussed if we can tie the data to the processing. Granted there are new complexities in this model for synchronization, segmentation and consistency but there are ways to solve them. Similarly consistent access to the same servers is also possible.

What other great examples of distributed computing and distributed data storage have you seen?

Thursday, May 15, 2008

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.