Rules of Engagement: Conflict Resolution

This post is part of a series of posts on rules of engagement in the consulting business. I don’t profess to be a guru on all things consulting but the posts cover some of the things that I have picked up over the years.

Consultants tend not to get into conflict situations with their clients that often (but it certainly can happen). The reason is that by nature consultants appear on the surface to be pretty malleable, although behind the scenes they will be gently guiding towards the best possisble solution.

Rather than dealing with conflict situations with clients, consultants are often asked to act as an external agent and assist in negotiations between two interested parties. Even though consultants are typically retained by just one of the parties they are generally given the latitude to explore options outside the clients stated position without making the client look like they are backing down.

Interestingly enough, I’ve found that the non-client party in a negotiation often looks upon the consultant as an ally – perhaps because they are so one eyed about their own solution that they believe that the only rational thing to do is support them – and sometimes they are right!

Now – here is where I think a consultant is different from a straight out contractor. When a consultant goes into negotiate along-side a client they already have a feel for what the optimal situation is going to be – and neither the client or the other party automatically share this knowledge. The trick is to bring both parties together in agreement.

Finally – here are a few rules that I try to live by:

• Keep your eye on the optimal solution; this is not a purest mentality, but in most situations there is generally an outcome that you really really want. Try to move towards it while still consdering each parties needs.
• Know when you are compromised; if for some reason you find you can’t move forward because you integrity has been challenged, step back and consider loosing the ground. This is especially important if you have made a mis-step and revealed one of your own personal biases.

Interestingly – the second situation happened to me recently and I’ve had to pull back, I don’t like it and my teeth grind continuously when I think about it.

Rules of Engagement: Professional Development (cont’d)

This post on “The Ideal Programmer” by Bruce Eckel fits in nicely on my post about the day and night programmer and my earlier post about professional development.

Multi Touch Screens – New User Interfaces

Matty Cosier e-mailed this around on the internal e-mail a few days back with the comment – “I want one of these instead of a PDA”. I think eventually the user interfaces that we have on our desks will be something like this (once LCD displays and digitisers get cheap enough).

One of the challenges for existing UI technology for this kind of user interface is that ability to understand multiple touch points on the one screen. For example – in order to resize an image you need to put two fingers on the screen and move them away from each other.

Also notice that the user interface was all about the data. When he was manipulating photos there were no toolbars or other fancy gadgets on the screen – it relied on natural guestures (if you don’t think they were natural look at the video again and think you would change it).

Very impressive stuff – great find Matty!

The Day Programmer vs. The Night Programmer

This post is a slightly edited form of an e-mail that I sent around internally last year. But it was suggested to me recently that I post it up to my blog to see what people think – am I right or wrong?

Over the years I’ve come to the belief that there are two kinds of programmer in the world, no matter what technology they work with, lets call them:

        1. Day Programmers
        2. Night Programmers

Now – day programmers are the most prevalent in this industry, and you find them mostly in organisations which have historically tolerated a certain amount of inefficiency. Day programmers have the following characteristics:

        1. They are mostly led and seldom lead.
        2. The have trouble coping with complexity.
        3. They cannot visualise a solution.
        4. They don’t load their development tools at home.
        5. Typically don’t participate in the development community.
        6. See programming as “just a job”.

If you are a night programmer, you probably have trouble understanding why a day programmer even entered the industry, and the reason is because they are motivated by different things than you are. The characteristics of a night programmer are:

        1. They mostly lead (or drag kicking and screaming).
        2. They develop deep understandings of complex things.
        3. They can visualise a solution and have a sixth sense around design.
        4. They load the alpha/ctp/beta version of tools at home.
        5. They participate in user groups and mailing lists.
        6. See programming is as vital to them as breathing air.

If you are a day programmer, you look at the night programmer and think that they don’t have a life. And you laugh at them when they come in excited about some cool new trick they can do in the framework.