About me

I am Andrew Spooner, CTO at Account Technologies Software Limited, and this is a brief description of how I got here. This website is a place for me to store and display my notes to some of the things I have been exploring, be that a new technology I have been playing with, my attempts at photography or just something else I wanted to take notes about. Most of the stuff here is completely self-indulgent, it is my notes about things which I have written down to help me remember how I did things that I might need to do again in the future. I find that writing something down to try and explain it to someone else, even if that explanation isn’t well worded or easy to follow for another party generally helps me to understand, absorb and remember the “whats” and “whys” of whatever I was trying to achieve/learn.

But how did I become a CTO?

Originally my background was in analytics and decision science, not the normal route to becoming a CTO. However, as I was always trying to push the limit of what is possible on the hardware or platform I was building a scorecard for. I would spend a lot of time doing “Ops” type work setting up hardware or environments to build bigger/better (maybe)/more complex scorecards by pushing bigger and bigger datasets for the build, and adding and creating more and more variables, and linking more and more data sources together and then combining the variables in different ways creating compound variables. However, this would sometime lead to the model not building or the algorithms running out of resources, or just the processes grinding to a halt. Solving this would lead to a requirement to understand the underlying code being used to build the scorecard, how it was optimised and how you could be more efficient with variable storage to reduce RAM requirements (generally an issue in R with big dataset) or preparing the data in an efficient way to avoid rewriting data file over and over again (SAS or WPS).

Once you have built a scorecard and managed to get it signed-off, it needs to be implemented. As such I spent a lot of time with the developers to understand how the system worked and to understand the data the system was logging. By ensuring that there was enough audit data to help debug why the scores being calculated are not the same as from the model. The differences were usually caused by the interpretation of the cleaning methods, rounding, flooring and conversion between types. Small edge cases would cause slight changes to a few accounts being scored. To help, I would re-factor/rewrite my own scorecard code so that it instead of running across the entire set of customers it was optimised to run on a single customer and give an output as quickly as possible. This generally meant removing any external analytics tools and relying on pure SQL queries to extract the variables (with the data coming from the raw transport messages (XML/JSON) themselves), applying cleaning/binning, before computing the final score.

The decision science role also requires a holistic view of the entire system. Understanding the data and how it flows from the very beginnings of an application, all the way through to an account being booked and then on through the various customer servicing cycles. This is sometimes called from cradle to grave. Understanding the source of the data, the steps the data has gone through helps to understand what bias may have been introduced. Also, understanding what data is available at points in the customer lifecycle is also important so that the model doesn’t use data that isn’t yet available. For example, payment performance data would help dramatically in initial credit risk scorecard… but if you could somehow see the future you wouldn’t need a model to predict it. Once a scorecard is built, implemented and being used it needs to be monitored and checked regularly to ensure it the scores are consistent and the model has not drifted. If it has drifted, knowing what changes have been made to the platform the could have impacted the data or changed the demographic of the population is important. All this holistic knowledge of the platform/system is very similar the service dependency maps that developers need when making changes. Developers also have requirements to check and monitor the platform.

So when the previous CTO switched out of Account Technologies to focus on a new project, my knowledge of basic development process and code iteration, plus the knowledge of the system and dependencies put me in a good place to bring my analytics based focus to the development prioritisation and management. I could understand the business side of the requests and quickly get up to speed with the development side so that I could give a risk weighted benefit to the prioritisation queue. I had also spent a lot of time with the developers and could interpret what they were saying for the business and visa versa. As such I stepped up to be an interim CTO in 2016 and have been there ever since.

Cover Image

This is a picture of the sun setting over the railway tracks at Tywyn. I was taken when on holiday at my parents caravan.