The Duck

Always remember: a duck is a duck and a fish is a fish. Fail to see the difference as a consultant and down you go. Sometimes it seems like a farm or a pond captures more of the essence of our profession than a business school.

In an earlier post about consulting (Open letter to my colleagues incl. myself) I wrote that being in service of the customer means coaxing your customer into ownership of the situation and at the same time staying the background as a coach or a play director.

There are two main pitfalls a consultant should be aware of:

1. The Ego Trap: In the flow of the adrenalin and other boosting hormones that is caused by positive feedback on our rhetoric and initiatives we take, we forget that we are there in service of the customer. Instead of being in service, our ego takes over, we become the star of the play, collect the flowers and the compliments, send a big fat invoice and head off to another customer. Climbing on stage yourself and solving the problem may be nice but the customer did not learn anything and he or she is even more dependent on you for further developments. Consultants on stage solving the customers’ problems have missed the point.

2. Change Agent Readiness: Most of the times there is another dynamic at work. In the lifecycle of the project you are delivering, the sponsor of the project may be ready to climb on stage, but the agents – who are supposed to be ambassadors – may not be quite ready to tackle that job. As a result, you take the easy way out: giving the fish instead of teaching them how to fish. Intelligent consultants know that involvement during the project lifecycle is the key point they should focus on.

About a month ago I was thinking how I could make that point clear in front of a large group of key users who are supposed to take ownership of a project by the time it goes live. I kept thinking about the fishing-thing and I came up with a metaphor that allows me to underscore the importance of taking ownership towards my customers.

First, I make it clear that is not my job to sell this project in the field towards their service engineers, technicians, accountants, invoice controllers, truck drivers, team leaders, etc. I do want to be there to support them, but having me explain the project to their peers and colleagues would be the same as a duck explaining to the fish how to swim.

At best a duck can tell the fish in which direction they should be swimming. But in the context of large change projects, the fish need more support than that. They need another fish telling them how to get there. They need someone who knows their context from within. The duck only knows the water from the surface. Moreover – invisible to the duck – duck-credibility in front of the fish equals zero.

Finally, our job as a consultant – be it external or internal (HR business partners, IT account managers, etc…) – is to become aware of the limitations of a duck and agree on the expectations with our agent-fish upfront: a duck is a duck and a fish is a fish. It is a useful distinction if you don’t like ending up like the duck above.

I have used this metaphor several times already and the feedback I receive is that it sticks. If you like it, you could give it a try and let know if it works for you as well – OK?

  • Bart

    Very interesting metaphor. I like it a lot because it indeed enables to communicate a message.

    One disadvantage is that the future users are “down in the water” and the duck is “up there” and can fly etc. The users might prefer to identify with the duck, rather then with the fish that has to stay in the water.

    And actually, the metaphor can work even better when you switch the roles: the IT people are the fish swimming in the water (=the IT system), the ducks are the end users who float on it but who also can fly away… A fish has more limitations then a duck…

  • Bart

    Very interesting metaphor. I like it a lot because it indeed enables to communicate a message.

    One disadvantage is that the future users are “down in the water” and the duck is “up there” and can fly etc. The users might prefer to identify with the duck, rather then with the fish that has to stay in the water.

    And actually, the metaphor can work even better when you switch the roles: the IT people are the fish swimming in the water (=the IT system), the ducks are the end users who float on it but who also can fly away… A fish has more limitations then a duck…

  • Luc Galoppin

    That is on the spot Bart!
    Yesterday I even got the comment: ‘dear duck, beware of the crocodiles.’

  • Luc Galoppin

    That is on the spot Bart!
    Yesterday I even got the comment: ‘dear duck, beware of the crocodiles.’

  • Luc and Bart,

    I like what you both have to say. Yes, clarity in contracting between client and consultant up front can really go a long way toward a smooth process. So often we contract the work but skip the relationship part, i.e. who has what accountabilities and what authorities.

    Quite frankly, specifying accountabilities and authorities internally is a huge issue for our clients, esecially cross functionally. It’s one of the services we offer – helping clients clarify who owns what in certain processes, who recommends, who decides, when to escalate, and to whom.

    Regards,

    Michelle

  • Luc and Bart,

    I like what you both have to say. Yes, clarity in contracting between client and consultant up front can really go a long way toward a smooth process. So often we contract the work but skip the relationship part, i.e. who has what accountabilities and what authorities.

    Quite frankly, specifying accountabilities and authorities internally is a huge issue for our clients, esecially cross functionally. It’s one of the services we offer – helping clients clarify who owns what in certain processes, who recommends, who decides, when to escalate, and to whom.

    Regards,

    Michelle

  • Pingback: Luc’s Thoughts on Organizational Change » Horror, the Ultimate Learning()

  • Pingback: Luc’s Thoughts on Organizational Change » Raising the Bar for Our Profession()

  • Pingback: Do I need to paint a picture? SAP and Learning! | Reply-MC()