Giving Thanks… November 25, 2009
Posted by Chuck Musciano in Random Musings.Tags: Thanks
add a comment
Thanksgiving is tomorrow. By all accounts, you should not be reading this. Instead, you should be wrapping things up at work and preparing to spend a few days with those near and dear. But you are here, and for that I’m thankful.
In fact, I’m thankful that you stop by every time you stop by. Writing this blog is a rewarding exercise for many reasons, few of which I anticipated when I started long ago. While I have learned a lot and found clarity of thought in these articles, the greatest part of my experiment has been the wonderful community of people that choose to follow and visit these pages on a regular basis.
In many different ways, many of you have provided feedback that has been enriching and helpful. I’ve learned a lot, met some wonderful people, and discovered all sorts of things I never would have otherwise found. And all because people elected to share a few minutes of their day.
I wish I could say thanks to each of you individually, because I am sincerely grateful for your time and attention. Instead, I’ll have to make do with this more general message and hope it will suffice.
Now, step away from the computer and spend time with people, preferably far from any distracting electronic devices. I’ll be very thankful for the privilege of a visit on Monday, when we’ll pick back up where we left off.
Happy Thanksgiving!
After The Beep November 16, 2009
Posted by Chuck Musciano in Random Musings.Tags: Communication, Voice Mail
4 comments
There was a time, many years ago, when telephone answering machines were state-of-the-art technology. They used little cassette tapes to hold both your incoming and outgoing messages. Fancy ones could count how many messages you had; cheaper machines just blinked to get your attention.
The first time you ever set one up, you were instructed, when recording your outgoing message, to include instructions for the caller. What should they do after the beep? Leave a message, of course, and you’ll call them right back.
Many years have come and gone, and physical answering machines have evolved into voice mail stored on some remote server in the ether. Every single person in every developed country on Earth has both sent and received voice messages. Yet we persist in including those same instructions when we record our message in the voicemail system.
Why are we beholden to instructions that are absolutely useless? How much time is wasted as people wait for the message to play before being able to record their message? Even with the shortest message possible (“Not here. beep“) everyone would know exactly what to do.
Perhaps the worst possible offenders are those voice mail systems that tack on additional instructions, in a smooth female voice, after your message. You’ve heard it a thousand times:
Leave your message after the beep. When you are finished, you may hang up, or stay on the line for more options.
Is anyone unclear as to the next step after leaving their message? Has anyone ever “stayed on the line for more options?”
Of course, many people are fairly gregarious when leaving a message, in a sort of karmic revenge for the long outgoing message. There is nothing more frustrating than listening to some lengthy explanation in a voice mail when all you really want is a name and a number. People ramble on and on, going into all sorts of detail that, truth be told, you are ignoring as you anxiously await the crucial data they might spring on you at any moment.
And when they get to that part? They rattle off their number faster than anyone could ever transcribe it, mumble their name, and hang up. You know what’s worse than listening to a long, tedious message? Listening twice to check the name and number at the end.
I propose that we establish a new set of voice mail rules that will save everyone time and frustration:
- Outgoing messages need to be short and sweet. No extraneous instructions; we know what to do.
- Incoming messages need to be short and sweet. You get no more than twenty seconds to give a reason why you need a return call. State your name and number slowly. Pause and repeat it. Hang up.
Get the message? Together, we can change the world, one beep at a time!
Arbitrary Boundaries November 13, 2009
Posted by Chuck Musciano in Random Musings.Tags: Customer Service, Sales
add a comment
Recently, I received notice that one of my vendors had added me to their online customer portal and made me part of the “Eastern Region Group.” Apparently, this gives me access to certain forums and resources shared by everyone in the East. I’ll confess: I don’t get it.
I understand why this vendor might divide their customers into regional groups. Presumably, they assign local resources to each group to improve response time, reduce travel costs, and increase customer satisfaction in some way. But does this have any value or meaning from the customers’ perspective?
It seems that in this day and age of global communication, sequestering customers by geography is so… last century. The idea that you are doing so in an online forum that transcends time and distance is delightfully ironic.
But it doesn’t just happen online. How many customer receptions have you attended where tables are arranged and labeled by geography? Is it really important that I sit with other people from the East? Aren’t there interesting people from the West that I might want to speak with? Why not just divide us by height, or middle initial? I suspect that’s just as effective in creating good conversation as anything else.
What’s really happening here? An internal organizational tool is being exposed and applied externally, without providing value to the customer. Those internal tools have clear value in managing costs and personnel. Externally, they are confusing and create false divisions in your customer base.
This problem doesn’t just exist in sales organizations. How often do we expose architectural limitations or development constraints, much to the dismay of our customers? Try explaining size limits on email to someone who just wants to send a big, business-related file to a customer. They get annoyed and you look petty.
The root of this lies in our failure to identify with and become champions for our customers, from their viewpoint. While we may have many useful internal mechanisms that allow us to operate effectively, very few of those mechanisms have any meaning to our customers. Instead, they seem arbitrary and restrictive.
We need to develop a service model and world view that makes sense to our customers. We need to interact with them in that model, and never ask them to step outside of it. As needed, we need to translate their requirements from that space to our internal world. Our internal model is probably more complicated than our customers think, and that’s OK. We are supposed to translate from their simpler model to our complex one on their behalf. There’s a special name for that translation: “customer service.”
The Happy Path November 2, 2009
Posted by Chuck Musciano in Random Musings.Tags: Software, Technology, Testing, Users
1 comment so far
In our last episode, I argued for a more consistent application of the 80/20 rule as we design and deploy software. I made an exception for testing, however, which prompted a comment asking why testing gets exempted from this rule.
As the saying goes, testing only proves the presence of bugs, not their absence. The goal of testing is to find as many of these bugs as possible before moving code into production, in the hope that we will avoid inflicting them on our poor unsuspecting users. Unlike a system in which we intentionally design and deploy the first eighty percent so as to get some value to the customers more quickly, we cannot test just eighty percent using a similar rationale. We need to test everything we build as best we can.
There is a limit, of course. You can’t test forever. The trick is to know what to test, and to test those parts thoroughly.
A co-worker of mine often talks about the “happy path.” The happy path is the path through a system where everything works, the data is correct, the system stays up, and the users are well-behaved. We tend to test the happy path first because we understand how the system should function and want to ensure that the basic features should work.
This results in testing scenarios like this
- User selects an item and adds it to their cart
- User enters billing data
- User enters shipping data
- User clicks “Check Out”
- Transaction is processed
If this works, has the system been tested? Yes. Would you move it into production? The right answer is “no,” but I’ve used a lot of systems where the apparent answer was “you bet!”
We need to move off the happy path and wander in the weeds. What if the quantity exceeds stock on hand? What if the user enters too few digits from their credit card? Or too many? Or adds a space, or a dash? What if the zip code doesn’t match the state? What if? What if? What if?
It doesn’t take long to test the happy path. It takes forever to test everything off the happy path. You need to spend a lot of time wandering away from the happy path, and maybe there is a reverse rule for testing: 20% of your time on the happy path; 80% of your time off of it.
For some reason, I was born off the happy path. Even at a young age, I was doing things like sticking Christmas lights directly into outlets (they explode and leave a mark on the wall) and riding my bike with my eyes shut (you hit parked trucks and knock yourself unconscious).
I have developed a reputation as the guy who can break things, much to the chagrin of every development team I have ever worked with. I wish I had a nickel for every time I’ve been told “no one ever tried that before.” As much as it annoys developers, people who can break things are crucial to building solid products. Better that we break them instead of a user.
We need to find and engage the non-happy-path people in our teams, and make sure that they spend a lot of time testing everything we build. Admittedly, you cannot test forever, but having the right people test for as long as possible can make a world of difference.
Infectious Diseases October 28, 2009
Posted by Chuck Musciano in Leadership, Random Musings.Tags: Attitude, Leadership, Relationships, Teams
10 comments
Many years ago, I worked with a group of software developers who were situated in a typical cube farm. One day, a woman came to work clearly not feeling well. As the morning progressed, her conditioned worsened, punctuated with repeated trips to the restroom.
Her cube neighbor was concerned that she might be carrying some infectious disease. Sure enough, as time went by, he began to feel sick himself. Soon he was running to the restroom as well, and by the end of the day they had both gone home.
It turns out that she was suffering from a bad bout of morning sickness. Her coworker, it seemed, had contracted the rarest of all airborne maladies, psychosomatic male pregnancy.
While pregnancy is tough to catch at work, other diseases spread easily. While diseases can usually be treated and disposed of, other infections can be much tougher. These kinds of infections include attitude, ethics, and courtesy.
People tend to mirror those around them. If the workplace is a sad, depressing, miserable place, everyone in it will be sad, miserable, and depressed. Happy, upbeat, pleasant places create happy, upbeat, pleasant people. The prevalent mood spreads quickly, one way or the other.
As leaders, we have tremendous control over what is in the air. Our attitude sets the tone for the team. We need to choose our attitude carefully, because it will be mimicked, consciously or unconsciously, by those around us. While maintaining a continuously Pollyannish approach isn’t going to fool anyone, genuine confident enthusiasm is a good thing.
We also need to be sensitive to the “carriers” in the group, both good and bad. Every group has a few people whose genuine positive spirit is always a welcome breath of fresh air. Their approach lifts every project, enhances every meeting, and brightens your day. These people are treasures and you need to specifically praise them for their good effect on the team.
Conversely, every group has a few Eeyores. These people find the cloud around every silver lining, know exactly why every good idea will fail, and seem to find ways to bring even the happiest person down. These people can be fatal to your organization. Oddly, many of these people have excellent technical skills, so we overlook their attitude to take advantage of their ability. We make excuses for their behavior, hoping that their technical contributions outweigh their social impact. You can do that in the short term, but you cannot tolerate it for long. A person is a whole package, and attitude problems are no more or less serious than technical or ethical ones.
As leaders, we need to remove the infectious bad attitudes from our group and allow the good attitudes to more easily spread. Who are you infecting today?
Blinklist
Del.icio.us
Digg
Furl
reddit
Technorati
