Between sales and execution culture

Data science consulting at the Big 4

Vicki’s Note: This is the third part in a series on data science and consulting, a topic near and dear to my heart, since I work in consulting and do data science freelancing from time to time.
Part 1: Selling data science
Part 2: Measuring unhappiness - churn

Previously, I wrote that consulting (of any kind, not just data science), is all about sales:

It’s something I didn’t understand at all until I joined a consulting company, but the ability to convince someone of something is probably the strongest superpower you can ever have in your career.

And every job, really, is at least half about the ability to sell what you’re working on:

I think what’s interesting to me about consulting, though, is that it’s very much about the tension between selling and doing. As I said, if you’re not selling, you don’t have a consulting business anymore:

As a consultant, you have to constantly be selling actual work - otherwise your consultancy dies. An army marches on its stomach. Any given consultancy, whether it’s one person as an LLC, or a company with thousands of employees, marches on sales. If you’re not selling contracts, your company won’t exist, because you don’t have work.

An Astute Normcore Reader wrote that they had very similar experiences as a data scientist at a Big 4 consulting firm (Deloitte, PWC, Accenture, and KPMG), and wanted to share what it was like working on an AI Engineering team for large clients. 

(Vicki’s note: If you have anything that you want to share about working in tech, email me - my line is always open, and who knows, we could get a cool post out of it. )

I’ve only ever worked in small and medium consulting settings, so I was curious as to what that kind of role looked like, and I asked them to describe their job and some of the larger perspectives on the industry. 

 Here’s the interview, edited for length/clarity by me:

AI Engineering is basically "ML systems design and implementation, with people who *really* know about CNNs (convolutional neural nets)."

My role is a combination of systems architect/data science manager/production SME. I am a manager (middle management) in grade/level, and so I’m in this unique position of being able to make the most of my technical/leadership skills, and, at the same time learn how to manage people (as well as computers). 

For work, I use Python/Scala and occasionally R/C++ . R creates nice prototypes but terrible production scripts, and this is mostly the limiter of putting the work I’m given  into production. Jupyter notebooks and R scripts are easy to teach, but hell to turn into a production system.

My usual week on a project looks like this:

* Monday - Stress level amber - look at a client's production system, give it some TLC, work out who is complaining on JIRA

* Tuesday - Stress level red - fight all the fires 

* Wednesday - Stress level red - explain to various boards why firefighting was necessary, and how it can be avoided next time, as well as actually doing some design/data science/management meetings

* Thursday, stress level green - chill out and do some design/data science/management meetings - this is the most productive day of the week for "work".

* Friday, stress level amber - everyone loves having a meeting at 4pm on Friday to discuss defects and release management, don't they? Especially if someone wants to deploy to production on Friday afternoon...

* Sat/Sun - semi-on-call-if-you-really-really-have-to-and-it's-on-fire-and-I'm-not-out-of-pocket

Mixed in with all of this, I travel 10-30% of the time. 

Data Science at the Big 4 is a large church, covering anything from Tableau dashboard analysis to CNN (convolutional neural net) development.

The whole consulting biz is about selling projects and generating revenue, so you have to be able to do the analytics your clients need.

Half the work is understanding the business problems, then half the work is doing/implementing the right solution. Most of the Big 4 do  both the strategy side as well as the implementation.

However, one major  problem is the fiefdom nature of partner-driven firms (for more information, check out David Meister's Managing the Professional Service Firm), and the skills needed to be proficient at management consulting.

In consulting, there are large amounts of people who promote/change/sell the work of others. However, because data science relies on core technologies, you get a lot of people who know a little  (i.e. can "sell AI") and only a few people who can do quant analysis and software engineering. 

The Big 4 firms all realize this problem. Old-style consulting is in decline and revenue from product development/innovation is up, but the conflict in the business comes when you force the pyramidal structure of partner-led revenue generation on top of what should be a flat-ish structure of building out technology. This forces everyone to only care about their pyramid, and causes conflicts between pyramids (and sub-pyramids).

Additionally, because you can go far selling other people's work, there is no long-term incentive to do high quality tech work - someone else will always take credit. 

The Big 4 also cannot retain good people, and have no appreciation of tech skills even if they make the right noises as currently, because, according to the business model, you can't convert tech == money (apparently!). Once everyone gets to middle level, they leave as they realize that their skills aren't valued in the firm.

In my firm,  we’ve worked hard to avoid these situations, and hence created this specialized "AI Engineering" team (our own pyramid) to live the high tech/high value dream, and are part of the way to solving the problem - although there's a lot of work  to go.

I (Vicki) also asked for some horror stories, and was not disappointed to receive them: 

  • I reviewed a project where production had fallen over because the dates had changed from US to English style, and a Pandas merge suddenly took 12 hours. However, all 5 "expert data scientists" on the project had no idea how to debug it.

  • I joined a project that was using a 1TB RAM machine because they would only write R scripts with massive dataframes on a single core. Parallel processing was a novelty.

  • My entire team once hand-labelled 10k images to get an algorithm built, only for it to turn out that a logistic regression could beat all CNNs the project lead suggested.

I was surprised at how much of this rang true for me in my career, as well. One of the reasons I got into consulting was to get closer to the heart of the business and find out how decisions in companies are made.

But, the duality between hiring people who have exemplary technical talent and sales is always real, and for now, people who can sell work are rewarded more, simply through the mechanisms of capitalism.

However, as Astute Normcore Reader notes, this is changing, and consulting firms are moving more towards a blended approach of hiring top technical execution skills, but might not be as good as talking to executives about sales.

This is interesting to me, because what I’ve noticed from the other side, is that technical data scientists are now expected to sell their work in order to be attractive and valued within their company, as well as signal to other companies.

The primary way this is visible externally are blogs and speaking engagements. For example, everyone in data knows the Stitchfix blog. Everyone in engineering knows the Etsy blog. Popular blogs act as sales mechanisms for attracting talented people that otherwise wouldn’t be remotely interested in your company.

Are we getting to a point where people will have both sales and engineering skills? Probably not. It makes sense for consulting companies to separate the promotion ladder between highly technical staff and those who sell the work, even though it goes against the very grain of their existence.

But if you’re wondering about your own career, I can tell you personally that you’ll always have a job if you can do both well, or at least understand the different mechanisms by which both work.

Art: Fishermen Hauling the Net on Skagen's North Beach, Peder Severin Kroyer, 1883

What I’m reading lately:

  1. Shaun is a fantastic source of post-Soviet content:

  2. The responses to this have been…interesting:

  3. As someone from another country, why do Americans have such a highly competitive culture?”

  4. I should write a post on this, but I generally agree with it:

  5. DMVs are selling your data. Surprise!

  6. A really well-done but depressing read:


About the Author and Newsletter

I’m a data scientist in Philadelphia. This newsletter is about tech and everything around tech. Most of my free time is spent wrangling a preschooler and a newborn, reading, and writing bad tweets. I also have longer opinions on things. Find out more here or follow me on Twitter.

If you like this newsletter, forward it to friends!