CIO Manifesto It's seven years on from the great crash and IT departments are moving from the bunker mentality of keeping the lights on and maintaining legacy VB6. But what does that mean for the way we manage tech teams?
We invited an eclectic mix of senior IT execs to our own well-appointed bunker underneath a central London hotel to try and work out what we need to do with the people on our IT teams to make them relevant to a changing technology and business context. It's all part of our CIO Manifesto program.
One way you can spot senior leaders is that they are unusually skilled in disagreeing politely with their peers. So when we entered upon the topic of staff attitudes to change, the ten IT execs present managed to have at least ten shades of grey between experiencing stonewall intransigence to finding teams who desperately want to change, but who’ve been prevented by the culture and processes of their employers.
People and Culture are different
Actually the IT execs regarded “culture” as a bit of a lame excuse for not thinking of their staff as people, each of whom has their own set of ambitions and perceptions of what needs to be done. As one put it “you’re not dealing with a firm or a culture, you are dealing with this person”.
Most of them had at some point inherited a dysfunctional team and a common pathology for non-delivery is that many IT pros haven’t really been told what the real business objective was and more than one has ended up working really hard to achieve things that weren’t really wanted.
Setting expectations for how staffers can contribute was seen both as getting them to prioritise the right things, and as fixing morale, which is a bigger thing for senior IT execs than the footsoldiers often realise. At this level, the time they spend in any given job is often a lot less than the rest of the team and it’s not going to shock you to read that often the reason you have a new guy in charge of IT is that the rest of senior management want IT changed and they want it changed quickly.
[Yes I did say the “guy” in charge of IT, aside from chairing Reg round tables my role is to recruit senior IT execs to share their insights which includes getting female ones and frankly I haven’t done all that well, so if you are (or know) a woman who runs a substantial IT function, point her in this direction.]
The “flat” management structures that some firms believe make them more agile and meritocratic weren’t all that popular amongst the execs who ran larger IT functions. That’s because without a visible progression path it’s harder to retain good people and for larger and/or more ambitious projects the lack of leadership shows much more than when you’re just keeping the lights on.
If you’re not building team leaders, project managers and others to actually manage your programmes then the only option can be to TUPE the whole damned mess to an outsourcer who at least has managers and structures. Though this means you’re effectively buying in a management team.
Larger outfits are usually already layered, and the trick is to disrupt the layers just enough to get them to support change without imposing anarchy.
The overwhelming majority of people are found to be at least a bit resistant to change because they have a position that could be worse, have built up a way of working and relationships, and change offers uncertain rewards for them. Unsurprisingly the longer they’ve been in one post, the lower their perception of the upside/downside ratio.
Contrary to what most IT pros think, the execs we met are extremely reluctant to fire people. Few execs get off on this and of course partly that is a legal thing. Firing people usually requires a long death march of telling people they’re doing it wrong, writing that down, offering them realistic objectives, and checking to see if they’ve made progress. In the state sector this has to be repeated a few times.
No, they prefer training, motivation or what has become known as “a quiet word in the lift” where we gently let someone know that their role has more yesterdays than tomorrows. This is easier on the management and in the long run, the employee will likely have a better outcome if they look whilst employed than after a degrading experience in expedient headcount rightsizing.
That can interact in interesting ways with firms who have an “up or out” culture, since people may just leave anyway. The problem is, they're not necessarily the right ones, even if you can expect higher levels of commitment when the rewards for “up” are attractive enough. This is not a good or bad thing as such. The execs see this as a structure that they must quickly adapt to and work with, just as a DBA must deal with Oracle’s “preferred way” because he ain’t gonna change the DBMS himself.
IT execs seem to be dividing these days into those that “keep the lights on” and those who are effectors of change, the second role being far more fun and better paid because the management team want us to implement new controls and empower employees to do new more useful things. Still, change can be a pain, and if you’re not in a firm where the management want to change the longer term prognosis for the firm and your job in particular isn’t so hot.
Cargo cult Agile
This was a new term to me, but apparently is what the cool IT execs call the bad habit of applying the A-word to pretty much any process that doesn’t have the word Waterfall printed on the cover. It is often an excuse or synonym for not planning things and the wiser end of the interim CTOs now have this as a thing to be wary of (or be paid to fix) when looking at new assignments.
In fact, the word “toxic” came up several times as we covered how IT groups and sometimes whole companies apply what they perceive as Agile with little specific training and often simply see it as an excuse to kill “slow” processes like testing. Toxic Agile can create a mindset or even a culture of only ever taking easy decisions that look good short term, which is of course one reason why the time in post of top IT execs is rather lower than you might expect.
Of course our IT execs have encountered BOFHs who willfully obstruct or who have built code and systems that only they understand. If anything this problem is worse that it has ever been. When we were all in cost saving mode (and most of us have been in recent years) we tried to ensure that we have no spare people or unnecessary overlap and of course sometimes we were too successful and find ourselves too dependent upon individuals who often just get in the way.
The irony is that most of the holders aren’t happy with this “power” either. The consequence of being too critical to lose is that they get stuck in roles that they probably didn’t want in the first place and certainly have ambitions to move past. This means that the most realistic way of fixing the BOFH problem is with the BOFH’s cooperation, broadening their skills so they can upgrade and sharing their knowledge so that you can let them move.
But an axiom of taking over an IT group is that the best team for what you have to do next is the team you have now. All our CTOs agreed that you have to make tough decisions about how much in the way of short term deliverables you are prepare to trade for those you need a year or more from now.
There are those we need to move along a vertical business axis and those who are most suited to a horizontal move along the technology. Of course it isn’t always as smooth as that sounds. Developers often make tragically bad operations staff and vice versa.
However, as we see DevOps grow as a stream, and it does seem like the better people are gravitating towards it, either because they like the new way of doing things or because management are deploying smarter people to newer, important projects.
Part of the challenge is, surprisingly, how many people want input into the overall strategy. Any number of staff may want to offer random opinions about issues and opportunities, with fewer being prepared to colour in their own part of a formal strategy based upon their insight into local conditions. That local but deep experience in each area is critical if the overall picture is going to have any chance of working.
Although the IT execs talked a lot about motivating people as individuals, larger teams don’t give much time for one-by-one touchy feely interactions.
So a good part of people management (nobody called it man management, perish the thought), is just working out where people are in various bell curves for tech ability, business knowledge, commitment etc. The job is then a mix of moving staffers to the most suitable slot or occasionally along the curve.
We then went into the vexed subject of money. At this point there was a little banter between the “rich end of the table”, such as those in financial services, the public sector leaders and those in startups. The cultural gaps were laid quite bare, even if there was a consensus.
First was the idea of visible fairness in pay and conditions. None of our attendees was naïve enough to believe that individual pay was as secret as modern business culture like to officially pretend. It is a regular source of friction. Having individuals who get special treatment is seen as especially toxic, not just when they earn more, but when they are seen to not be pulling their weight even if there are good reasons for it.
Although they can be a straitjacket for keeping good people, the highly structured pay systems of large enterprises were seen as an advantage since they are more transparent even when they are wrong. They are at least perceived as not unfair, though there are some tweaks around things like promotion, where instead of paying extra “acting up” money for people who take on extra responsibility, they get more when they’ve succeeded at the new level, this costs about the same but provides a better motivation.
Of course this requires a degree of trust that a successful IT leader needs to build up and maintain, since it is too easy to say “we’ll see you right afterwards” then “forget” that a verbal commitment was made. We’ve all been there haven’t we?
Money wasn’t seen as a particularly good motivator for those away from the rich end of the table and that was partly self selecting. People gravitate towards the reward structures that suit them and if you have people who care mostly about the quality of the work, or achieving things, buzz, cool tech, the social context or whatever, then you must grasp that which can be a real challenge.
They are poorly defined terms that exist in the minds of your team, rather than the objective facts of money, which for all its problems is simple. What is “interesting” work for each of your team?
One interesting view that emerged was that money could work for “doing” but was bad for “thinking”. A clearly defined objective works well with a financial incentive, but the more you want people to come up with new ideas or take risks, the worse a motivator money is.
Gamification is becoming trendy and has always been an informal part of many successful IT teams. Having some objective metric for success like transactions processed or calls handled gives people a little edge to behave better.
This of course needs a deft touch to do well, because if imposed from above it can feel very patronising. To quote the late, great Terry Pratchett “they had such contempt for the staff they actually had an employee of the month award”.
You also need to make sure the simple metric encourages the right behaviours. All incentive schemes, whether money or kudos-based, can be gamed or misunderstood, encouraging selfish behaviour or sharp elbowed attempts to get credit for each goal attained.
One tactic that does seem to work well is a drawer of “dinner for twos” where you catch the staff doing the right thing (teamwork, trying hard, dealing with a viciously unpleasant user with a smile) and you buy them a decent meal.
This is made harder by the fact that the business often wants things to be project oriented. This has never really matched the way good IT is delivered and as we move more online and more mobile and more directly engaging with customers and suppliers makes the easy option of setting rewards of “if we deliver X you will get Y” both the easy option and the worst one.
People aren’t constants
Each worker's motivations changes over time. The need for money has peaks around life events. They learn that skills are getting hotter and cooler and can feel they are being seriously underpaid. That’s getting harder to monitor as the number of different skills only ever increases, which means you need a good relationship with the right bits of management to do buybacks, which are a lot more common since regular automatic pay rises for IT people aren’t much of the new normal. (Oh you didn’t know that? You thought that if you just kept doing your job well enough, they’d up your pay? No.)
As people get better paid or more experienced or have kids then the extra value of a bit more money goes down and here you need to have a good hard constructive talk with your HR director. You have to look at things like extra annual leave and flexible working, which will be valued more and be cheaper.
This is a real competitive advantage for retaining and motivating people, since too many firms still have a “presenteeism” culture where more hours at your desk is seen as always better than fewer, meaning that you can give things that the people trying to poach your staff can’t.
Yes, before you ask this does mean you keep your female staff longer, and that will usually help you sell it to HR. But blokes have kids too and it doesn’t have to be domestic. Being able to dodge the evil rush hour at London Bridge station can be worth more to some staff than a pay rise. But as above, flexibility must not be seen as favouritism.
The toxic cultures created by some HR departments by fawning over “parenting time” (which just happens to coincide with HR people having kids) doesn’t help cohesion with staff who aren’t parents one little bit. Shirkers, whether real or imagined do far more harm than just their lower output.
Part of the “fairness” challenge is that job specs in our industry are a mess. We lump together disparate skills sets, “rank” job titles are simply there to get people paid the right money and in some firms they reflect a technology structure created 20 years ago, and which isn’t even in use any more.
But I learned that there is a rigorous structure for job titles. You can see it right here.
Did you know that? How about those from the BCS. Have you read them?
No, me neither, and they may or may not be good. But aren’t we both just a little embarrassed that we hire people, spending hundreds of thousands employing them for years and upon whom our own careers are dependent without a spec as detailed as we’d expect for a bit of VB that wasn’t used much?
So that’s one reason the IT execs were scornful of the way interviews are run: random tech questions; a bit of “gut feel”; and an attempt to believe their CV. The idea that recruiters, especially the clueless RPOs, could even try to do any useful filtering was the idea that got the biggest laugh all evening.
That being said, the one-hour interview, maybe with a bit of checking the candidate has an acceptable number of heads by HR, is still the norm. No one had any constructive ideas of how to make this very much better. The nearest I can get to a positive spin on this for you as a reader is that you shouldn’t feel too bad at the shambolic process you use.
HR (aka “Human Remains”) got a lot of stick from the IT execs with some HR units, especially the outsourced ones, seen as relics of the bad old days of management: frustrating change; spending their time making policies that no one wants let alone reads; generally being a waste of space. But as one of the execs said, “if you swap HR for IT, a lot of firms would say that about us”.
As the laughter from that faded, the consensus moved to the point that individual HRs do get it, offering self service tech for evaluations, appraisals, succession planning, managing vacations and cover and helping choose good recruiters rather than those who bought them nice lunches.
In the best firms HR really is now a strategic part of getting things done, even offering useful advice. Realistically their role as bag men when you need to lose people means they are never going to be loved, and without the pay and benefits structures they create, there’d be a lot more ill feeling amongst the troops.
So what did we learn?
A lot. This is less than half the insights and anecdotes covered in our session. Clearly successful IT execs can’t just see themselves as “part of the management team” and issue orders. Debugging defective people and cultures is like debugging code.
It is an up close and personal thing which cannot be done at a distance. You have to be smart about identifying the right motivating factors and agile enough to change them as your people change. You must be trusted, and without that no one is going to believe that delivering better is good for them personally.
HR departments are an amplifier for what is going on. They can make bad worse and better become excellent. If they get it, so you need to get them on-side as part of your initial bedding in when you take on your next leadership role. ®
If you’re disappointed to have missed this Roundtable, you should have registered when we told you about it. But this is a series, so if you have a senior role in IT and want to learn from your peers how to do it better, register for our next roundtable here.