More often than not, we tackle our organisations in an essentially traditional way – and it’s this approach that creates problems. Here are six of the constraints we impose on ourselves by doing so:
· How we draw organisations. We start with a pyramidal chart – one box at the top, many at the bottom – each box joined to one or more others with ‘solid’ lines. It is a rigid framework.
· How we think about organisations. When we look at our org chart, we want to put a name in each box. We don’t think about what people actually do, we think about which box they best belong in.
· We fail to reflect what is important within our business. Very often we don’t consider what IT means to the business we support. We ignore it. We put on our blinkers and draw up our structure based on IT skills, processes, functions alone.
· Driven by command & control need. Knowing that everyone is ‘owned’ by someone else is comforting. It means that our people can be controlled, told what to do. To some extent it absolves us of ownership. Yet it constrains our people too.
· Need to be clear on responsibilities / accountabilities. We kid ourselves with pretty job descriptions and ‘roles and responsibilities’. We pretend. We tell people they are responsible – or accountable – but never give them the freedom (within our organisations) to actually do the job we need them to.
· HR processes demand ‘managers’. And at least once a year (for annual reviews), and increasingly more often than that, we need to comply with HR processes – and HR processes reinforce the solid line, command & control approach of traditional organisation design.
I’m sure much of this is frustratingly familiar. Be great to sweep it away, wouldn’t it? But it’s actually not that simple, not only because it’s difficult to do so, but because we – including our staff too – help to perpetuate the model. Think about what the majority of people want within an organisation and how they measure themselves. Think about what people expect and what self-esteem looks like to them.
They want ‘seniority’. They want to get as close to the top of the pyramid as possible. Some people would sweep the car park or clean the toilets if it meant they could take another rung towards the top. Then many want more money, better benefits, and this almost always equates to the same thing – taking another step up the ladder. We take the Peter Principle and guild it! Not only do we promote people who aren’t managers and make them managers (it’s what they want, after all, and doing so saves a retention headache for us!), we often accept that we are going to lose their core skills in the process. The very thing that makes them valuable to us and our business suddenly becomes of secondary consideration. “Bill was a great Project Leader, but now he does a s*** job running a team – and we’re both really happy about it…”. Doesn’t sound quite right, does it?
At the heart of these problems is the fundamental flaw that our organisations fail to recognise value. They are not based on value. If Bill is a great Project Leader – and the role is an important one – then let’s pay him for the value he brings by doing that job. If we get the benefits element of such recognition sorted, of course, this may mean Bill doesn’t get to run a team – and then we run into the fact that Bill hasn’t moved boxes on the chart. The money’s great, he says, but…
So something needs to change. And it’s not just for us, but for our people too. It’s a cultural shift.
Organisation structures are inevitable. Whether we like it or not, command and control is a fact of corporate life and will not go away. On that basis, we will continue to need to recognise a series of superior-subordinate relationships in our working world.
How we think about organisations; articulate, communicate, draw them. Given that inevitability as a starting point then, we need to change our approach to organisation charts; how we think about them, articulate, communicate, draw, promote and populate them. Hard to do? Certainly. But here are a couple of possibilities. Don’t have one person per box; break that link. And in terms of seniority, don’t have one Management Team (‘top layer’), but have multiple management teams depending/focused on the area/function/thing being managed; that way you can bring more relevant expertise into each MT and allow more people to experience ‘management’.
The roles / boxes within org charts. Stop thinking about the boxes as ‘jobs’ and try to start thinking about them as the things people do – things that are relevant to and add value to the overall business. Make your job descriptions focused on outcomes and values rather than filled with meaningless ‘weasel words’. It will make performance management – good and bad – much more relevant.
Reward mechanisms. Change the reward mechanisms!
Sweep the organisation away!
OK, sounds dandy, right? But in the real world…? Well, come on!! And if this is your objection, you’re right. The vast majority of us don’t have the freedom – or don’t think we have the freedom – to be ‘radical’. We may not have the money, the flexibility. Indeed, our people may not want it. And, let’s face it, we already have org structures, job descriptions, HR processes, the annual review process… We have our uncomfortable ‘comfort blanket’.
Clearly, if you were starting from scratch and setting up a new organisation with new rules and new people, then you have a chance. But, having said that, don’t dismiss the opportunity by just throwing it in the ‘too difficult’ category and going back to the Neolithic ways we run our people structures today. Take a look. Think about it. It might just be possible. What would you need to do..?
1 – Start with a blank sheet of paper; ignore your current org chart. This will be difficult for two reasons: firstly, because your structure might be imprinted on your brain, and secondly because you know your people, don’t you? And you know where they ‘fit’ and what they do… But you do need that blank sheet of paper.
2 – Plan to divorce org framework from benefit structure. Try to forget that traditionally the closer someone is to the top of the page, the more money they earn. Think about the contents of your reward structure – pay, car, bonus – as tools to be used, not things that are pre-ordained.
3 – Think about what the IT function actually needs to do. And don’t think in terms of technical roles if it all possible, but try and articulate what you need people to do/achieve in more relevant business terms. For example, you need to make your systems available across your branch organisation, rather than you need an Network Engineer Grade 2 (you’ll make that connection later). By undertaking this step, you may well uncover some roles you need that your current organisation does not have – and what will that tell you?! [And from here on, I distinguish between ‘jobs’ – the post a person holds – and the ‘roles’ that people perform i.e. what they ‘do’. A ‘job’ may be a combination of ‘roles’, so ‘roles’ are most likely not full-time; a ‘role’ may need to be carried out by multiple people.]
4 – Once you have a profile of the many roles you need performed – and you’ll have to be prepared for this list to be longer than your current headcount! – then you’ll have to moderate your list in terms of the numbers of people, on balance, you need to meet those needs. So, using your judgement and experience, think hard about how many people you really require – and what they need to do – to make your systems available across your branch organisation or to man your Service Desk. Maybe you’ve always had twelve people on the Service Desk in three teams of four, and you know that works – but that may not be the right answer. It could be more or less, depending on your review of what they actually need to be doing. Be careful you don’t over-estimate the size of a role: does a person really spend 50% of their time preparing service reports..?
5 – So, having been hard on yourself, now you have a list of roles and approximate numbers of people you need to perform those roles. You can begin to group roles into jobs. “If I got someone to do this role 50% of their time and these two roles 25% of their time… That actually looks like an interesting job!”
6 – With jobs defined, now you can think about how they logically go together in an org structure. But remember, this org structure is not the end goal; it is merely a mechanism to allow the minimum command and control you need, to maintain HR processes etc. It’s not how you will run your department. And if you have a job that you need many people to do, then don’t draw one box for each job – not at this stage – just one box maybe annotated to reflect multiple job holders.
7 – Now it gets tricky! You need to think about the jobs you have defined – and their component parts, the roles performed – in a variety of ways in order to come up with the rewards for executing those roles and doing those jobs. So you might consider the following requirements:
· managerial skill needed and people responsibility (based on your new draft org)
· decision-making responsibility
· value to business (ideally in ££ or some business metric)
· uniqueness / scarcity of skills
· market rates
· business / technical knowledge
Establish benefit ranges for each role, and therefore for each job. This exercise might also allow you to refine your jobs. For example, you have two roles that require company cars or significant travel in order to be executed successfully – but you find you have split them across two jobs. Can you combine them in a single job and therefore save the expense of that second car or that travel?
8 – At this stage – and we’re well into the process now – we have yet to talk about your people i.e. those who hold posts in your current structure. Well do so now. But not in the sense of the jobs they are doing or the roles they perform, but in their own right; what are they, as individuals, worth to you? There are some fundamental things you should consider, for example: potential, attitude, criticality, productivity, flexibility. Those attributes are worth something, and that something could be concrete. You will have people who are invaluable, but in lower paid roles – this is your chance to recognise that. Undoubtedly – and unfortunately – the reverse will be true too!
9 – So now you have your two critical components: a new organisation more closely based upon what you need to be doing, hopefully with a more value-based assessment of their worth to you; and a reflection of the importance of the individuals in your organisation, independent of their current post. Now all you need to do is to pull the two together! Here, of course, is the greatest problem of all. Whether you can appoint people into roles or need to advertise and go through a process will be driven by your company policy, the size of the change you would need to make, the numbers of redundancies or hires etc. And make no mistake, this is a big deal! So big a deal in fact, that it may just not be possible. But even if you just undertake steps 1 to 8 privately (which you probably should as much as you can), the organisation you come up with, the roles within it, and the rewards potentially attached to your people and the jobs they do, will be far better than the one you are faced with today.
Try it. I doubt it will be a waste of time. You can execute all the way through to step 8 – there is nothing truly stopping you. If you did so, you would learn a lot about your organisation and your people – and the service you deliver to your customers. Maybe undertaking that final implementation piece is one step too far. But it may be simply be that it is too big to tackle in one go – your organisational elephant. If so, it may yet provide you with an aspirational place to strive for, and that could allow you to put in place a plan that will – over time – get you there, and maybe free you from the chains of your current organisation structure.
8 – About the author / copyright
Ian Gouge is widely experienced in business-driven Information Technology, culminating in significant achievements majoring on organisational and process change, and with a proven track record in turning around / re-engineering IT functions. He possesses in-depth experience of change, transformation, IT delivery, customer and supplier engagement, and broad International exposure. Also the author of management books on the topics of IT strategy and project management, the impact on IT of e-business, and the IT organisation.
This material is copyright of Ian Gouge © 2012. All rights reserved. Any similarity to actual IT or business organisations is entirely coincidental and unintentional.
Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following:
· you may print or download to a local hard disk extracts for your personal and non-commercial use only;
· you may copy the content to individual third parties for their personal and non-commercial use, but only if you acknowledge the author and blog as the source of the material.
You may not, except with express written permission from the author, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.