Archive for December, 2009

Social intelligent or just a horrible person

When I used to think about someone with social intelligence, I tended to think about someone who was skilled in social situations. In other words; someone who used social skills to get what he wanted. During periods since the term Social Intelligence was first introduced, Social Intelligence has been seen like just logical intelligence but into use in social situations. As Daniel Goleman points out in his Social Intelligence, studies of the human mind and Neuroscience in particularly, this is far from the whole truth. A truly social intelligent person is an empathic person, who can truly connect to oneself and to others.

But what about my image of that shroud person? Well, he’s better part of what Goleman refers to a part of The Dark Triad. Three personality traits/profiles which might seem social adapt but are really not. Since true empathy is not part of the picture.


The narcissist

This is probably the most common type and many successful leaders have traits from this profile. The narcissist might not be aware of it, but he puts himself first, sees blame in everyone else. Narcissists puts too much value into themselves and sees themselves as superior others.

In a positive sense, a narcissist can bring onto great change and brings self esteem. But it’s a slippery slope to blind eye to one selves bad sides and down sides.

Daniel Goleman points to that narcissists as leaders can make organizations narcissistic, and one cannot help seeing the organization described in Jim Collins Why The Mighty Falls:

  • Hubris born of success
  • Undisciplined pursuit of more
  • Denial of risk and peril
  • Grasping for salvation
  • Capitulation to irrelevance or death

    The Mach

    The profile is named after Niccolo Machiavelli and his concept of The Prince. Here we have someone who on purpose uses social skills to get what he wants. This person strive against his goal and if someone gets in his way, this is collateral damage.

    Goleman does not discuss organizations being Machs, but sometimes when you read horrific stories about companies knowingly putting their staff and customers in peril, you cannot help wondering.


    The psychopath

    Furthest down on the ladder, we find the true psychopath. For this individual, people are just objects, which can be used or should just be removed. Where as a Mach might understand that he’s done something bad, the Psychopath does not recognize this. He cannot see a problem with his behavior.


    The bottom line

    What do you think is social intelligence? How would you feel, working for a company or a leader who is part of The Dark Triad? Would you know? Would you care?

    Since I’ve at least worked for narcissists and narcissistic organizations, I say that for me it was not worth it. To bring passion and your precious time to such an environment is just a waste. In hindsight, you might learn from it. I did, but the price you pay might be high.

    So, how do you build social intelligence? Well, Daniel Goleman points to an inner strength and true empathy as ground for social intelligence. In the short run, The Dark Triad might be successful, but in the long run, you alienate yourself. A bite of narcissism is probably necessary for success, but without that precious empathy true success will probably not be long lived. And you will probably be lonely in those precious moments of your life.

    Categories: Leadership Tags:

    Mistaking group thought for collective intelligence

    Sometimes you become a part of tightly knit team. You seem to almost think the same things and solutions just comes flowing. What you probably have felt is something Daniel Goleman in his book Social Intelligence refer to as Rapport. It’s one of the most rewarding social connections and the ability to Rapport is a crucial part of social intelligence and well being. And often a team with Rapport can be very productive.

    But there are also risks. As James Surowiecki points out in The Wisdom of Crowds, this forming of the tight, homogenous group gives ground to group thought in a negative sense. Surowiecki gives a lot of examples of when group thought stops innovative ideas from being realized or even thought or expressed. The fear of breaking the group thought is perhaps not obvious or even realized, but is there. If you break that precious bond, you lose that comfy feeling. We’ve all been in that situation too. We have that small, tight group and in comes the Outsider with the Outsidish idea. What an idiot. He knows Nothing. We’ve already tried that. But we are the experts. And so on. The outsider must in many cases chose between aligning and thereby just provide ideas which are in line with what is acceptable ideas within the group or stay an outsider.

    What can be elusive is that the tight group might not be without conflicts or debates. The principle is that the alternatives are just within the acceptance range of the group. And thereby many great ideas are never explored.

    According to Surowiecki, it is key to keep groups heterogeneous to harvest the collective intelligence instead of the narrow group thought.

    These books really got me thinking about groups and teams. Agile software development is all about creating the most business value for the least effort and here is probably an important key factor. How to use the collective intelligence and still have the comfort and calm which Rapport brings. And how to minimize the negative effects of group thought. Working with the 7 Habits gives me a lot of tools but I will probably struggle with the Scrum team idea. Scrum teams are supposed to be cross border but how often are they really? And if they become true teams, how homogenous will they not become? Not that Kanban or other methods are better in this perspective.

    Well, I have something to work with next year!

    Never take words for granted

    Since this summer, I’ve been chasing an illusive error source in one of our systems. It’s nothing crucial, but sometimes the error pops up and it’s really annoying. It bugs my tester spirit that I haven’t understood why this occurs.

    When I first found the error, I was told that it was because of duplicates in a list. “We have duplicates of value X in table Y.” But I couldn’t understand this. Duplicates are common in this table and not all of the rows with the duplicates have the error. Instead, the error was sometimes somewhere else.

    Just today I realized that we just used a word very differently. I interpreted the statement as that multiple rows had the same value in the column. For example:

    Value  Text
    1           A
    1           B
    2           C
    3           D
    4           D

    I would say that there are duplicates in the column “Value”. But that was not was the business people meant by duplicates in this case. What they referred to was that multiple rows could refer to the same physical entity. That is, that Value 3 and 4 could refer to the same entity (Text D). So, the error was someone completely different in the system.

    Categories: DDD Tags:

    When the official language is no one’s language

    On my previous position, I worked for a product company, and when we set the domain language of the product, we were pretty much free to set our own terms. We were building a product and while discussing with the customers, we would anyway be using the terms used by the customers. I guess when you work with customers which are part of a more homogenous group, you can set terms which works for all or at least most customers, but in our case, customers used the same term for very different things. The strategy then was finding a term which the customers didn’t use and in that way not creating misunderstandings. But at the same time finding a term which they could relate to. In other case, we tried finding the right synonym.

    So, when I started working for my current employer, I didn’t expect this problem to become an even harder nut to crack. I work for TUI Nordic, which is a Nordic leisure travel company. We have local companies in Sweden, Norway, Denmark and Finland. The company language is English. So, which terms should I use?

    If we just look at our employees that are not overseas (that is on one of our destinations), most of them spend most of the time talking to people in their own country, which means they speak their own language. Some of the time is spent talking to Nordic colleagues, which means that we sometimes speak our own languages and in some cases we speak English. The latter scenario is more common when one of our Finnish staff members is present, since the Finnish language is very different from the other Nordic languages.

    The room for misunderstandings is big for many reasons but one of the biggest is words and the domain language. We most commonly use our local terms for things but when we discuss things we use English terms, which no one uses in other situations. The problem is also aggravated by the fact that the local companies were previously not part of the same company, so the Nordic aspect has been added much later and after the local domain language was formed.

    When you’re having a discussion, you can of course ask someone if you don’t understand. But how do you know that you’ve not understood? Just yesterday I learnt after one year at my job that price reduction is used for something different than discount. I had no idea that I would need to clarify those terms and these were the Swedish terms which I didn’t think to question. But in a conversation there is at least a possibility to discuss these terms.

    When it comes to written material, things are even harder and I often find myself struggling to find the right words. Since the people I work with in most cases didn’t use the word I’m using (this we in most cases use our local language), I must myself choose the right translation. I don’t have a perfect solution right now, so I’m open for idea. What I’m trying to do is that I add the Swedish term in a parentheses. In this way, the business people can see which term I tried translating.

    Categories: Agile