Some weeks ago I began my reverse survey of RAFM practitioners. For ten consecutive Wednesdays I will write about one of ten issues we face and then rank the importance of the topic by observing the response in terms of page views, social media shares, and so forth. This latest addition to the series asks a question that goes right to the very heart of our work: what skills does a practitioner need? More specifically, to what extent should RAFM practitioners develop their information technology skills, or should RAFM job descriptions share more in common with those for data scientists?
The Technology That Was
We cannot deny the importance of information technology skills to RAFM functions. For many telcos, their software and data reconciliations were developed in-house. Finance teams adopted control objectives which could only be fulfilled by recruiting staff with the ability to write code or queries. Like square pegs in round holes these people had no real opportunity to be promoted by the finance teams they worked for, though they may have subsequently taken IT jobs elsewhere. Accountants brought their numerical and auditing expertise to bear on the work being done, but much of the detail was handled by people whose work education was primarily focused on IT. And even to this day we still see too many preposterous job descriptions that ask for the ability to write SQL queries alongside the ability to influence c-level executives, as if it is normal to expect senior decision-makers to take advice from individuals tasked with tightening nuts and bolts.
But as technology evolves, so do jobs. As vendors of software seek to provide ever more powerful tools which shift the emphasis from coding to configuration, and boast superior interfaces, this begs the question of why RAFM teams would need to retain so many IT skills in-house. Why should they write code for themselves, and suffer all the headaches of maintaining that code, when systems with standardized and flexible functionality can be bought from a supplier who can realize efficiencies by investing in developing that code on behalf of many clients? And why would an RAFM function want to stick with an in-house approach to development when the natural progression for so much business software has been to gravitate towards the purchase of systems developed by external firms?
Technical, Not Technological
One reason I am delighted to provide a platform for Michael Lazarou’s reviews of data science MOOCs is that it points towards a brighter future for RAFM professionals. Instead of trying to compete with external software developers, or being an oddly-positioned niche IT function within their own telco, they might develop skills which have obvious application to the RAFM team but will also be more easily transferred to other tasks within the same and associated functions. Instead of being absorbed by the minutiae of how to write SQL queries, the application of data science gives RAFM professionals the mandate to ask themselves why and how they query data, and what inferences to draw.
The problem with this rosy potential future for RAFM professionals is that some may not want it. Bosses with no affinity for RAFM may prefer to rely on old job descriptions, and so keep work focused on low-level manipulation of IT rather than investing in technology to free their staff. And existing RAFM professionals may be discomforted by change. The history of software shows us that some people will continue to mine their existing knowledge for as long as they can. Not every COBOL programmer decided to revamp their skills just because COBOL was superseded by other languages. Their vested interest was in maintaining the COBOL software already in use, and some will have discouraged the replacement of that software just because their niche skills retained a value so long as their business did not alter their approach.
At the RAG Summer Conference it was observed by some that RAFM professionals should have better statistical skills than they do. I was pleased by this observation; it is one I often make, and I was glad that others made it, sparing me the burden of repeating myself. Data science is to statistics what IT is to basic computer literacy. Statistics opens a window on how we might deliver much greater value for our telcos, and also on how we might generalize our work so it can be applied to other businesses too. But grasping the basics may require a degree of retraining that an older generation will resist, or never be encouraged to undertake.
It is notable that Michael Lazarou is from a younger, newer generation of RAFM professionals, whose opinions were not formed during the initial wave of delivering RAFM in telcos. I sense that there are also an increasing number of managers who feel removed from those initial battles; they are not obliged to continue the fight for RAFM by using the same tactics that worked in the past. They need not care if IT skills were crucial to the initial deployment of RAFM, because they now take it for granted that those skills can be purchased as and when needed, without needing to have dedicated staff. The new wave can step back and look at the challenges in a more abstract way – and that lends itself to the way data science uses abstraction to look at the world.
Old vs. New?
So will there be a battle of skill sets between the old school, who gained their RAFM jobs through having the right IT skills, and the new school, who will try to position RAFM more generally, and rely on purchased technology to support their technical application of data science? That depends on two factors: whether old dogs can learn new tricks, and whether telcos will invest in the technology of data science. I think the latter is likely, though RAFM may not be targeted as early adopters of this technology if RAFM managers do not push themselves to the front of the queue.
As to whether older RAFM practitioners will want to change, that is a much trickier question. Human beings are naturally conservative; they like to stick with what they already know and understand. People see risk in investing in the new, especially when they are nearing the end of their career anyway. But the people who started RAFM were trailblazers too, with an openness of mind that led them to do new things and develop new practices. The shifting balance of skill sets demanded in RAFM will hence be determined by how hard the current practitioners will fight for change. Data science is the future, but we cannot say how soon it will arrive in practice. It is my belief that RAFM will eventually embrace that future, but we cannot generalize about how readily each practitioner will welcome its arrival.
