Diving deep into a domain and interfacing with a subject matter expert goes a long, long, way. We've been building custom data products for enterprise for about seven years, and a lot of the work is listening and grokking large amounts of content about whatever domain we were helping with in general, and the specifics of our clients. Retail, banking, telcos, energy, communication.
Having a background in acoustics, reservoir characterization, telecom networks, opens up clients because you 'get it' or at least you work hard to get it, which improves buy-in of the experts to sit down with you and answer your questions. You did your homework.
If you don't and just storm in talking about something something neural nets, they'll see it as a waste of time, won't bother explaining nuances, will delay sending data you desperately need. You won't have their cooperation even if you have executive support. There's no data in CSV form or an API to hit in most real world projects, so you need their help getting data, and their expertise to understand it.
Another major point is specifying the metrics. The real world metrics, not AUC or F1 scores. You need collaboration to get there, too.
There's so much to be done before there's data to work with, let alone good data. And there's so much after the model building step.
It can drive people to quit. One reason is that when you storm in and consider that people are morons, you get frustrated rapidly.
It should be taught. Lack of humility almost cost us a project. In that instance, humility unscrewed the project and unblocked 400k by simply sliding a sheet of paper and a pen to the client across a table, and asking them to draw the dataflow they thought we were going to build. A couple of boxes and arrows made it clear what the problem was. We drew the actual dataflow. The security person said "Oh, I thought... OK.. if it's like that then we're good to go". Legal said they're OK with that. Data people said OK. A dozen people were relieved.
The previous person on the project, although brilliant technically, thought they were "idiots who didn't understand crypto", as if it were the end goal. All it took was to keep quiet for a second and listen to what they had to say, and let them talk about what was problematic, instead of snark.
I am actually starting to believe that (too) smart developers can actually be a hindrance in the wrong circumstances. We have a prima dona on my team and while smart, he doesn't make things easy to follow for the next dev.
Having a background in acoustics, reservoir characterization, telecom networks, opens up clients because you 'get it' or at least you work hard to get it, which improves buy-in of the experts to sit down with you and answer your questions. You did your homework.
If you don't and just storm in talking about something something neural nets, they'll see it as a waste of time, won't bother explaining nuances, will delay sending data you desperately need. You won't have their cooperation even if you have executive support. There's no data in CSV form or an API to hit in most real world projects, so you need their help getting data, and their expertise to understand it.
Another major point is specifying the metrics. The real world metrics, not AUC or F1 scores. You need collaboration to get there, too.
There's so much to be done before there's data to work with, let alone good data. And there's so much after the model building step.
It can drive people to quit. One reason is that when you storm in and consider that people are morons, you get frustrated rapidly.