Friday, January 31, 2014

Community managers: The day after

Yesterday I followed on Twitter a case where the community manager for a -well known and with very good reputation- Spanish moving company literally screwed up their reputation.

He/she threatened to sue a customer that was expressing a complaint on Twitter, because the client had used the hash tag "vergonzoso" (shameful). IMO, the customer was not insulting and she was not threatening. Just complaining.

Initially I thought about yet another tactic to be viral. But the reputation of Gil-Stauffer in Spain is completely different. It's the kind of company you would like for a good, incident-free, priced, removal. Sort of a Zappos for Spanish removals. Or that was my impression, at least. After a bit of researching, it seems the incident is not something new. But this time the backslash is going to be very tough.

So you're a CEO of a big company and you discover that the technology everybody told you it would help interacting with your clients, has literally destroy your reputation. I'm sure the CEO did know about the tactics, but now he/she knows this time is different. What to do?

Some possibilities comes to mind:

  • Ignore as if nothing had happened. It has worked in the past. And it's tempting. But it's flawed, because social networks are about communicating. And because this time is different. Next tweet on that account is going to be replied by hundreds of people.
  • Hide it (deleting the tweets). No worth even considering. Everybody has now a capture of the tweets.
  • Rebuild trust.

In my opinion, the only real option in a social networked environment is to rebuild trust.

  • You need to act quickly. Rebuilding trust takes time. But you must start as soon as possible. I imagine the management did know yesterday about the major screw up. But today there is no answer. Which means they don't know how to act. And they're obviously considering the options. But if you don't act quickly, you'll be forced to act later on, but losing the benefits.
  • Apologize. Clearly. Not only for the specific series of comments but also for not understanding the whole social-network issue. Explain you have learnt -where "you" means the CEO- that social networks are a different thing you didn't understand. And that you personally are going to learn.
  • Start listening. There is a customer that has not get a good experience. Change it. Solve her problem. I remember having a bad experience with IKEA that was completely reversed to a great experience thanks to their Customer Relationship department.

Social networks are about interacting with your customers and getting feedback. It's about listening.

It is not a new channel to fill with Press Releases or (worse) to threaten clients.

Update: They finally manage to apologize (and also on the general issue). Late.

Tuesday, January 21, 2014

Multithreading: Warning lights

A few days ago I went to an interview which included a pair programming session. The session was a great experience, but the result wasn't quite as good as it should have been, because of some difficulties understanding on what was being asked. It didn't help it was my first experience working with a Mac.

At one point we agreed on creating a new constructor so that we could pass a service in the constructor instead of getting directly in the method under test.

So I had something like (fictitious code)

  class GreatObject {
    public void calculateAndAddAmount(int length,
          boolean cheapService) {
      int cost;
      if (cheapService) {
        cost=length*3;
      } else {
        cost=length*8;
      }
   
      Service supaService= MegaFactory.getService();
   
      supaService.addCost(cost);
    }
  }

and we had agreed on doing something like

  class GreatObject {
    private Service supaService;
    public GreatObject () {
      this.supaService= MegaFactory.getService();
    }
    public GreatObject (Service supaService) {
      this.supaService=supaService;
    }
   
    public void calculateAndAddAmount(int length,
          boolean cheapService) {
      int cost;
      if (cheapService) {
        cost=length*3;
      } else {
        cost=length*8;
      }
   
      supaService.addCost(cost);
    }
  }

When I was going to do it, something in the back of my mind started to blink. It was a bit subtle and it took me a while to be able to express it. So as an exercise for the future, I'm going to try and express it in writing.

The problem with the change is that we have transformed a local variable into an instance variable. Local variables are local to the thread. Instance variables are shared between threads. So until now we had a thread safe class, but now the class is not thread safe. As an example: What if each instance of the service can only be invoked once and we have two threads running?

I was asked to tell what to do to be protected. I replied I didn't know. The typical answer involves the reserved word synchronized. But as I've told in the past, that is not usually a good answer and almost never the best answer.

Sunday, January 12, 2014

It's great when your idea is a good one. But...

Since I came to London, more than a year ago, I've been travelling a lot back to Spain. I used to schedule trips in advance, and once I discovered I had two different reserves for the same trip (fortunately I was able to change one of them). Soon I realized I needed some tool to manage the trips.

I did a quick search and I couldn't find anything.

Then my wife and daughters finally came here. And I had even more trips to schedule. We needed to plan well in advance, because trips where more than three times more expensive (when travelling with children I cannot afford to wait queues hoping to get a good seat nor fly to a distant airport to save some pounds). Also, people in Spain started to come and visit us, and we also needed to plan that.

So I had my own itch to scratch, which is the better way to commit to something. 

But my own requirements could be expanded to accommodate similar requirements from businesses. And businesses pay. I had a business plan. Not for the next social network, but for a small web application. I also wanted to practice Rails. 

So I started to build it. In my own free time. I built a quick and dirty prototype. And I started to build something more serious

Today I discovered that there is indeed something similar. A quick sign up told me most of the things I envisioned (including emailing confirmations to ease the pain in managing trip status) are already there. 

And it is made by one of the big grands in expense and travel management.

Three lessons learned:
  • Do a proper research.
  • Commit. Commit. Commit.
  • It's great when your idea is a good one. You're no longer a freak who prefers the cloud to a notebook.
And yes. I have other ideas. But ideas are just a multiplier. The question is if I'll be able to commit.