I.T phone home.
Data is such a common term in modern business these days. I’ve been very fortunate to have been able to be part of the industry and seen the changes day to day, year to year.
From the early days of a few people in IT who had access to a database, to the more modern full scale department under the Chief Data Officer (CDO). I’ve worked for many companies who all had different views of data, how it could be used and how important it was.
One thing I’ve seen is the rise of the importance of data and with that, the role of Chief Data Officer.
I was recently at conference in London and there was a lot of conversation about where should data live? Should the CDO report to the CEO, or to a COO? Or to a CFO or CTO?
Where should data call home?
It was an interesting topic for me, hearing from the different opinions. There were two clear points that were coming out.
1) The “right” CDO structure was not really consistent to anyone
And
2) Data should not be part of a Chief Information Officer (CIO) remit.
This last part was what really grabbed my attention and got me thinking. Is being part of “IT” really so bad?
From the comments of panels and discussion groups – yeah it was.
I was really surprised by this negative viewpoint of Data leaders of being branded with an IT label. What was causing this? No one could really explain it or give a good reason, other than being grouped with IT gives an impression that data is just about tools.
I can understand this challenge. It’s hard for one of the newer formed C-suite roles to create an identity and being typecast as a glorified software wrangler isn’t what you had envisioned. A new CDO feels pressure to show the business that data is important, and that there is value to be gained from using data correctly.
So why distance from IT?
I’m not saying that data should be with IT, but Data as a function enters a phase of almost going full circle, there are lots of lessons we can learn from IT.
When I say “full circle” I mean, data started in IT, with a handful of people accessing a database and creating some reports for the business. Those days are hopefully long gone, and Data is much more independent entity.
The completion of the circle is that now the business depends of data. A lot of the value that is generated from data in the form of models that power CRM activity or ML algorithms or even daily reporting or real-time tracking.
Data has emerged and created its own identity. All these data products mentioned above create better customer experiences and help business units make informed decisions on a daily basis. Data is now very much depended upon.
So why would we shun our IT past?
As we are now creating data products that can actually drive revenue, we put ourselves into risk of failure. In many companies lots of these processes are run by individuals or on a computers or server somewhere. There might be limited or no documentation. It could only be a matter of time before the process fails.
IT departments have had decades to learn from mistakes. To develop solutions and methodology to deal with exactly these type of scenarios. When a company depends on you – to make sure the service can be returned to normal as quickly as possible, minimising the impact to the business. Isn’t that what we in Data are also doing? Providing a service to an organisation?
We have emerged as our own unique function in a business we should be learning and working closely with our IT counterparts to make sure that what we have built does not come crashing down.
The rapid rise of big data and ML/AI comes with dedicated roles such as data engineering who support the work that analysts and data scientists do. To ensure the data products and service run each and every day.
I’ve been able to learn so much from my colleagues in IT, from treating my stakeholders as customers, automating processes As well as creating robust test and release plans. I’ve become more comfortable understanding other aspects of a business like user authentication – which most people take for granted.
I’ve seen many data practitioners and data leaders make mistakes by trying to show a business what “data can do” but not implement the contingency plans to mitigate risk. They try and do too much without the fundamentals in place.
Working closely with IT has given me a better understanding of what is best for the company and how to achieve it. I don’t pretend I know better, I ask questions and look for help to improve my knowledge. With that knowledge I can then create better data products to achieve my vision for my company.
Data may not exist under the IT function anymore, but it doesn’t mean we shun our past. We should remember where we came from and learn from our friends in IT.