It’s an old chestnut, isn’t it?
Whether we’re trying to retain existing people or hire new ones. In fact,
almost any time we want to do anything with our staff we bump into the
immovable object that is our organisational hierarchy. Of course this isn’t a unique
problem for us in Information Technology, but we do face the complexity of a
wide spread of functions – and some pretty deep technical skills that, at the
top end, often imply seniority even when our org charts might suggest
otherwise.
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.
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.
No comments:
Post a Comment