Last week I was interviewed by Keith Robinson of Ammonite Data, with a topic of managing data science teams remotely and all the challenges this brings. We had a much more wide ranging conversation where I looked at challenges of communication and even the impact on models that the current extraordinary events will have.
I’ve been speaking at several events recently giving practical advice on getting started with AI projects. There is a huge chasm between high level inspirational business pieces on all the usual sites1 that business leaders read and the “getting started in AI” guides that pretty much start with installing Tensorflow. There was nothing aimed at the non-AI CTO who didn’t want to fall behind. Nothing to indicate to them how to start a project, what talent they’d need or even which problems to start with. Sure, there are a lot of expensive consulting companies out there, but this knowledge shouldn’t be hidden.
This time last year, I sat down with David Kelnar of MMC Ventures and we talked about why so many AI projects don’t succeed. He asked me to contribute some ideas to be included in the new State of AI report for 2019, to which I gladly agreed. It soon became clear that to do this justice, it was more than just a chapter, and the MMC AI Playbook was born, which we recently launched. Contributing to this amazing publication took a lot of time and research, and this blog was the thing that had to give.
If you are trying to find the right time to start your first project and need help on where to begin, please take a look at the playbook. Here’s a taster, based on talks I gave at Austin Fraser’s #LeadersInTech event and the Barclays AI Frenzy event both in July 2019.
It’s not often that I feel the need to write a reactionary post as mainly the things that tend to inflame me are usually by design. However today I read something on LinkedIn that caused a polarisation in debate within a group of people who should really appreciate learning from different data: Data Scientists.
What was interesting was how the responses fell neatly into one of two camps: the first praising the poster for speaking out and saying this, supported by nearly an order of magnitude more likes than the total number of comments, and the second disagreeing and pointing out that it can work. What has been lost in this was that “can” is not synonymous with “always” – it really needs a good team and better explanation than many companies sometimes use. What irked me most about the whole thread was the accusation that people doing data science with agile obviously “didn’t understand what science was”. I hate these sweeping generalisations and I really do expect a higher standard of debate from anyone with either “data” or “science” anywhere near their profile. Continue reading Agile Data Science: your data point is probably an outlier
I read an interesting thread this morning that really resonated with me. I am continually ensuring that my team have a great work-life balance, encouraging them not to work too hard and ensuring that they have time with their families. There are occasions when things go wrong and everyone needs to pull together but this should always be the exception. I’ve written before about the expectations of some tech companies in excessive hours as the only way. However, I have got to where I am by working as hard as I could, being determined in what I wanted to achieve, using my evening to improve and learn new things so I have the knowledge and experience for each new step. I pushed myself really hard, because I knew I could always do more, do better. I still do. Continue reading Constant learning, commitment and determination
I love choose your own adventure books. I read The Warlock of Firetop Mountain when it was first released and then pretty much every single Fighting Fantasy book released after it1. I also credit one of these books with improving my French reading and vocabulary after finding “La Malediction du Pharaon” in a charity shop2. One of the themes that run through all these books is your statistics: stamina, skill, and luck3. As you use these abilities they deplete. Use them too much and you will likely come to a sticky end in the books.
I chaired a breakfast meeting for Women in Data Science recently, and one of the topics for discussion was how to retain talent. While demand is outstripping supply and the market is going crazy, it’s enough of a minefield finding good people in the first place.
Add to this that even after you’ve made an offer to someone, recruiters will be contacting them regularly to try to tempt them away to other roles. It’s impossible to prevent this. I’m a big believer in not playing games with recruitment – I know what I can afford and won’t get into a bidding war. If I’m paying a fair salary and they go elsewhere for money, then they are more likely to jump when a recruiter calls regardless of how well you incentivise them. This isn’t a big company or small company thing, if you want to keep hold of your team after you’ve done the very hard job of hiring them then you need to understand what motivates them and either make sure that you continue to provide those needs or plan to be hiring again in the next 12-24 months. Continue reading Incentivising data scientists
Sometimes being part of a minority gender in IT is really beneficial. There’s always plenty of people wanting to talk to you at conferences (and never a queue for the toilets!) and it can be quite nice being a novelty. Also, on just about every business trip I go on, I’m reminded of the fact that when people see me, they don’t expect me to be in IT, let alone have a senior position. Today, I had to laugh as a couple of businessmen on the table next to me gave me a lot of detail about their company confidential research that is directly useful to what I’m doing.
Fistly, I didn’t need over 5 years as CTO/CIO to learn the basics of business security. Anyone in the industry knows that you don’t go blabbing confidential information in public, or do they? It’s one of the easiest ways of social engineering – hang around in bars, coffee shops etc near an office that interests you and overhear what you can. Some of it may be useful.
I’m currently building a team for my new secret project and far more of my time than I’d like is spent with the recruitment process. However, every minute of that time is essential and we’re at a point where none of it can be handed off to an agency even if I wanted to1. So getting the recruitment process right is essential.
One of the basic principles of management in any industry is that if you set metrics for your team, they will adapt to maximise those results: set a minimum number of bugs to be resolved and you’ll find the easy ones get picked off, set an average number of features and you’ll find everything held together with string, set too many metrics to cover all bases and you’ll end up with none of them hit and a demoralised (or non-existent) team2. The same is true of recruitment – you will end up hiring people who pass whatever recruitment tasks you set, not necessarily the type of person the company needs. While this may appear obvious, think back to the last interview you were at, either as the interviewer or interviewee – how much relation did the process really have to the role?