Delighting your customers – a Charter experience

I sat today in a team meeting, where we talked about our long-term goal of delighting our customers.  It’s an easy thing to talk about, but it’s very hard to achieve.  There’s a reason people always come up with the same holy grails of customer delight (say, the iPad) … there aren’t that many of them!

I ended up speaking some with our senior director about a recent set of experiences I had with Charter Communications.  I recently upgraded my services with them, and have had several small nagging issues that I never thought to call them about.  Just little things that kept me from being delighted.

Continue reading →

The Facebook compromise

If you’re at all active online, you’ve probably seen the recent hubbub about Facebook and privacy.  Every time Facebook changes its privacy settings, the articles start floating around, but this time it’s more serious.  The NY Times has dedicated space to the story, and Facebook itself has called a meeting of all its employees to discuss the issue.  At least one colleague of mine is deactivating his account, and I’ve decided to take an audit on my use of the service and rethink my assumptions around it.

Continue reading →

Ionix at EMC World

The buzz at the office is reaching a high as last-second preparations for EMC World compete with people’s “real work” every hour of every day.  I am sad to report I won’t be attending EMC World this year; I was really looking forward to the coffee at the Bloggers’ Lounge but I’m needed here in Hopkinton (the same reason my blog posts seem to be drying up of late …).  But there are some exciting things happening within my organization that you might want to know about.

Continue reading →

Leadership lessons from Survivor

If you know me, you aren’t surprised by my Survivor addiction.  From its very first episode I’ve been on board, and every new season I dive in and watch as teams of strangers play in this odd mix of competition and cooperation, as social structures evolve and intermingle and new strategies emerge to conflict with the old.

Recently this season (an “all-star” season with returning contestants), I watched as two competitors vying for control of a team gave us an interesting leadership lesson.

Continue reading →

Ask a stupid question …

… get an important answer.

Two colleagues of mine demonstrated to me today a habit which, on its surface, can be difficult to understand.  They really enjoy asking the stupid questions.  We’ll be in a design review, looking at a fairly straightforward diagram showing a few components interacting, and they’ll ask what customer use case this represents and what those components are.

We all know the answer.  It’s fairly obvious. But the person writing the design didn’t label the components and left it open to interpretation.

My first instinct was to jump in, say it wasn’t important, that we needed to get to the guts of the design to review it.  I was wrong.

Continue reading →

Personal update: putting new hats on

A while back I made kind of a big deal about getting back into the technical arena and putting away my manager hat.

Fortunately, I didn’t toss it too far aside.

If there’s one thing I’ve learned in almost 15 years at EMC it’s that change isn’t disruptive to the status quo, it is the status quo.

Everything I said I was doing before, I’m still doing.  I’m wearing a lot of hats right now.  My small development team has grown as it takes on more responsibility, and I find myself playing the roles of Scrum Master, Technical Lead, and Development Manager.  Somewhere in all that I’m trying to individually contribute technically as well, but that is at the bottom of the list.

The other thing that keeps falling off the list is contributing to “the conversation” (both internally at EMC and externally on twitter and in people’s blogs).  I’m afraid that is going to be an uncomfortable reality while I try to wrap my arms around all these roles and make sure my own commitments aren’t being missed. Try not to do too much without me :).

It’s a great place to be, in the thick of the action, surrounded by good people.  I’m never bored, I’ll say that much!

iWorry about our progammers

My first desktop PC didn’t much resemble the PCs of today.  It was a TRS-80 Color Computer II, with 16K of RAM, a single cartridge slot, and two joystick ports.  If you’re like me, you also had a computer like this one — maybe a TI-99/4A, a Commodore 64, or a PET.  Chances are, it booted into an interpreted BASIC command line prompt.  For many of us writing software today, our first experiments in software development came from looking at the prompt and wondering, “What can I do here?”

Me back in 1984 with my Commodore Vic 20
Creative Commons License photo credit: Extra Ketchup. This is not me … but it practically could be!

Continue reading →

EDN puts its money where its mouth is

I got a great email last week from my colleague Susan Shapiro, who works with the EMC Community Network.  The EDN (EMC Developer Network) is organizing a coding challenge for EMC World 2010, with a respectable amount of prize money ($25K total split among several prizes) at stake.  Being the self-centered guy I am, I immediately confirmed that EMC employees were eligible (they are, but only for one of the prizes) before letting myself get excited.

The concept: write a project where multiple EMC developer technologies can be used in a single program.  Bonus points for incorporating other online technologies.  Win money and fame and the adoration of the world.

I’m waiting for the detailed T&C, but you can read up more on it here.  Innovation through contest is something EMC has tinkered with quite a bit, as you may have read on Steve Todd’s blog last year.

Definitely check out the link for more info. I’m hoping I can find some time in between all my “real work” to put a couple of these tools through their paces.

Simplicity is a virtue

You’ve probably heard a variation on this statement from a software developer, made in jest, but containing a nugget of sincerity:

It was hard to create, it should be hard to use (or maintain).

Basically, we worked hard to get this stuff done and we expect you as a user or future maintainer to put the same effort into it.  After all, it took many man-years to write the software, it’s not too much to expect you to spend a few weeks reading manuals and understanding it before you start complaining that it’s hard to use.

As Paul Young recently wrote, though, imagine if wood-chippers took that approach.

Imagine if an author did?  “It took me years to write this novel, you should have to do some research before you read it.”

Some do, I guess.  I’ve read a few novels that require major work to get through.  Sometimes the end result is even worth the work.  But as my fiction writing friends tell me, in general you don’t want your readers to be thinking about your writing, you want them thinking about your story.  Similarly, you don’t want your users thinking about your software design, you just want them thinking about the task your software enables.

I feel the same way about maintaining and testing software.  We want developers thinking about the code, not about the way you wrote it.  You don’t want someone looking at your code, peering at it for a few minutes, and then saying, “Oh, I get it.  Wow, that’s clever.”

There’s a famous quote attributed to a half-dozen different writers (and perhaps originated by Blaise Pascal), that says, basically, “I am sorry I wrote such a lengthy letter; I did not have time to write a short one.”  It takes time to create simple, elegant software.  When we force the issue and compress the time spent on a project, you end up with complex code and complex user interactions.  We should consider this a problem, not a point of pride.

When we present some difficult software to our users, we should apologize to them.  “I’m sorry this UI is so complex.  I didn’t have time to make it easier.”  Instead, we make them feel guilty.  “Ah, perhaps you should have taken the training,” or read the manual more carefully, or attended our seminar.

Think about the people on your team, and ask yourself if they “get” this concept.  Realize, that if they don’t, you’re eventually going to lose your market share to a competitor who does.

First impressions: Google Buzz

(crossposted from a discussion thread at EMC)

My first thoughts on Buzz are that it fails at solving a problem I don’t really even have.

It connects me to people I send GMail to, which is great.  My GMail network is a subset of both my personal and professional networks, basically people I trust enough to give my personal address to.  So it’s a great selection of people for me to start connecting with.   Success.

Then it lets them talk to me/eachother/the world in the same way facebook/twitter does.  And frankly if those individuals want to do that, they are doing it already with facebook/twitter. Failure.

Then it lets them aggregate stuff they post in other areas, which is cool.  I can see what my GMail network is reading in their Reader accounts (except if I wanted to, I could already follow them in Reader, as I do with many of my friends) and what they are posting to their Flickr and Picasa albums (cool).  But…

Then it gets worse.  People can bring in their twitter updates.  So for the subset of my Gmail Network who are twitter-enabled, I see their stuff twice, once in my twitter client of choice, and once in Buzz. And as people comment on those twitter updates, they do so in a fragmented way, some in Twitter and some in Buzz.  So if I want to see the whole conversation I have to monitor my friends twice and spend twice as much time dealing with their twitter updates.  Failure.

So for twitter, it’s made my life harder, not easier, and I can’t afford that.  It’s why I stopped using FriendFeed.

That’s just my first impression after a few hours with it.  Maybe I’ll see more as it grows.