You generally don’t come across many drivers. As a driver myself I have worked with several drivers over the years and in my experience, it can sometimes be like two rhinos locking horns. One of you inevitably has to switch off and move on to get past it. The problem comes when you mistakenly identify someone as a driver - because you tend to see what you are familiar with in people.
When I was first exposed to the social styles model a decade ago, I started seeing drivers everywhere. I couldn’t believe how many there were in the business. It wasn’t true though. These social styles are purely preferences. An amiable can adopt driver traits and behaviours just as much as an analytical can and they can even spend most of their time in a driver like state when under stress (read on later this month for more details on the stress z pattern). But that doesn’t mean they are drivers.
I recall after some management training many years ago, a colleague of mine showed up as a driver in a pop quiz style version of the social style profiling model and I was pleased to hear it. I worked with them a lot on high paced and complex projects and being able to work at pace, delegate at a high level and without having to worry so much about ‘fluffing up’ my emails appealed to my efficient side. I instantly changed my behaviour towards them and made them a primary comms channel back to the business on the large, high profile project we were running. The delivery date got closer and closer and all of our catch ups were ‘yep, all good, what’s the next thing’ and ‘I’ll make sure that gets done, leave it with me’. It felt great to be cruising along and to have time to focus on other things without worrying about the detail. I focussed on other projects and took more on while this project apparently sailed through.
As is the way with waterfall software projects, for a Programme Manager, the beginning and end of the project tend to be the most loaded in terms of need for your time. As we got nearer to implementation I got more involved and started spot checking on the detail to make sure were nearly ready.
What I found was not good. Actions had not been done, decisions had not been made, important technical realities had not been communicated and expectations from the user base were far higher that what was being delivered. Extended user team members had not completed their actions and some of them didn’t even know they had any. The technical delivery was great but the content and user delivery was very behind.
As I investigated and slowly delved in the detail of the project it all became clear. My driver partner in crime was actually an amiable in disguise. They wanted to have the difficult conversations but had defaulted to trying to keep everyone happy (which is impossible in software let me tell you). They hadn’t wanted to give work out toc colleagues so took it all on themselves and couldn’t do it all. They hadn’t wanted to let me down so had said yes to everything I had asked, and couldn’t tell me when they couldn’t get it delivered.
I felt like such a rookie and what a lesson that was. We delivered eventually as we always did, but it wasn’t without its pain points. I have never made that mistake again. I learned that this model is very useful but you must be aware of its limitations. The Z pattern is the big spanner in the works and generalising too much can be dangerous – you must always work with what you see, not what you expect to see. And I also learnt that a more effective way to perhaps give you a hint of what style someone is, is to reflect on what they are definitely not. They will generally fall in to the default style directly opposite them.