Data are sexy. OK. Maybe not in an Edris Elba or Margot Robbie sort of way, but sexy nonetheless. If “sexy” means having rare qualities that are much in demand, then adding data-rich insight capabilities to your CV is a very sexy thing indeed.
The "Data are Sexy" podcast is for aspiring and established business leaders. In short episodes, we focus on extracting insights from the data fundamental to your business. It's a show produced by the US-based Tara Kenyon Group. You can subscribe now for free, wherever you get your podcasts. You can also find us at dataaresexy.com and in the Podfolio at tarakenyon.com.
" Data are sexy. OK. Maybe not in an Edris Elba or Margot Robbie sort of way, but sexy nonetheless.”
Data are sexy.
OK. Maybe not in an Edris Elba or Margot Robbie sort of way, but sexy nonetheless. “Data scientist” is said to be the sexiest job of the 21st century by Harvard Business Review[1]. However, if “sexy” means having rare qualities that are much in demand, “Data Translator” is even more sexy and adding data-rich insight capabilities to your CV is a very sexy thing indeed.
Here’s Why
There's a business story floating around about a large software provider that launched a best-in-class batch application system for big financial services companies.
Batch applications perform high-volume, repetitive tasks for large companies with hundreds of thousands of transactions per day. Batch applications process transactions utilizing something called a “batch window,” which is a period of lower online activity. Hence, all the transactions for the day are processed after business hours to utilize a company’s computing capabilities more fully. Tried and true, the software could process transactions faster than any other batch system in the market and was in great demand.
Except, there was a problem.
In one of the financial services companies, a large bank, the batch process would stop between 8:00 and 8:30 p.m. every night. Started at close of business by IT, the batch application was designed to run through all the day’s transactions during the batch window, and update information, generate reports, print documents, and perform other non-interactive tasks during the night[2]—and get all those tasks done before the next day’s business began.
In addition to the huge software purchase, the company had installed many processors so that the high-speed batch application could run efficiently with grid computing (i.e., partitioning the daily batch job over the processors). IT would verify that the application along with all the hardware were working fine before they left for the day, but when they came to work the next morning, the high-speed batch process had been interrupted during the night…and always between 8:00 and 8:30 p.m. and always within a single processor.
That processor was replaced with a new one. Same break. The coding for that partition was checked to ensure that it was without bugs. It was. Building engineers were called in to check if there had been loss of power to the building. No. The software company had its programmers check the application to see why the processor shut down after two hours of working properly. Nothing. The IT manager ensured that things were working fine before anyone left for the day. They were.
The bank’s managers were apoplectic, understandably. Having spent millions on infrastructure and software, they were ready to go back to their antiquated systems. The software company’s management, too, was in a state. This was its flagship software. Years of R&D had gone into it, and the worldwide sales force was getting traction with other large banks and insurance companies. The regular “breaking” of the application was good for no one.
Finally, an enterprising fellow from the software company volunteered to sit with the bank’s system overnight to be there when the batch process broke. That way, he could be there to restart the batch process if and when it went down between 8:00 and 8:30 p.m.
Ensuring that things were working at the batch processing start, the volunteer and the IT manager stayed on as the IT team went home. Individual PCs were shut down, and the only noise in the now very quiet office came from the refrigerator in the break room and the housekeeping staff on the floor above.
At the appointed hour, they moved into the room where the offending processor was housed to allow the housekeeping staff to do their work in the main work area. They waited patiently. 8:00…8:05…8:10…nothing. Then, at 8:13, a man from the housekeeping staff entered the room with a vacuum cleaner (a “Hoover” for you Brits), acknowledged their presence, then promptly went to one of the electrical outlets, removed the power cord to the processor in question, plugged in the vacuum cleaner and did his work!
Mystery solved.
The Sexiness of the Data Translator
It wasn’t the data scientist(s) that solved the issue. In fact, the assumptions they made at the beginning—e.g., that it was either a software problem or a faulty processor—weren’t valid. It took a Data Translator—the one who looked into something that made no sense—to find an insight into the business and solved a problem[3].
Now, that’s sexy.
_________
[1] “Data Scientist: The Sexiest Job of the 21st Century” by Thomas H. Davenport and D.J. Patil. https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century
[2] “Batch processing.” https://en.wikipedia.org/wiki/Batch_processing
[3] Ramakrishnan, R. “I have data. I need insights. Where do I start?” towards data science. Retrieved from towardsdatascience.com website: https://towardsdatascience.com/i-have-data-i-need-insights-where-do-i-start-7ddc935ab365