Problem-solving styles in management

Working over the last several months, I’ve encountered several management styles as part of my duties as a data scientist. It’s impossible to do everything by yourself, and so managing other data scientists is something that inenvitably happens. Let’s talk about problem solving approaches.

My technical manager was very good, technically speaking. Technical people, when presented with a problem, like to solve it with a technical solution. This is a good thing if the problem demands a technical solution - analysis of a certain kind to answer a new question, producing new visualisations, creating new variables to explain previously unexplained factors in the data. There are several problems with this, however. Firstly, technical people tend to interpret the problem in a certain way, usually with a technical bias. My manager would interpret problems posed by the client by reshaping them to fit a technically consistent viewpoint - making elements of the problem concrete through technical definitions, setting strict conditions for successfully solving the problem - which makes for a technically tractable problem. This is great, but sometimes my manager would forget to check if the problem we ended up with was really what the client was after. Secondly, technical people tend to fixate on technical solutions - but solutions don’t need to be technical. Sometimes, we would address questions from the client by simply restating what we already had, but in a different light. Other times we would rephrase the question to actually isolate the intention behind the posed question - sometimes the intention was easier than the initial problem. This would be less trouble for me as a data scientist - no need to write code - but a perfectly valid solution.

Non-technical managers, being non-technical, obviously don’t suffer the above deficiencies. Thinking out of the box is more natural for them, but there are problems if they don’t have an idea of the box in the first place. My non-technical manager was from a business background. These people are good at framing questions in wider perspectives, and we would eliminate problems early by checking if they needed to be answered. However, the lack of technical background can hurt. Data science is a field littered with precise statements with specific intentions. There are intricate systems and details which are important, and failure to grasp these can hinder communication. Non-technical people don’t tend to grasp these well (with certain exceptions - more on that) and so tend to spout lots of ‘business speak’ - improperly using technical terms, stating implications which don’t make sense, asserting statements out of context - which I then had to clear up or intervene.

It’s certainly not necessary that everyone needs to be technically minded. It’s actually sufficient that non-technical people grasp the conceptual mechanisms and processes the technical people are employing.This could be understanding what are the inputs and outputs to black box algorithms, knowing how the systems behave at a qualitative level, and understanding what is and isn’t relevant in a discussion. Such people may not understand the technical implementations and the details but they will make correct statements about the system - correctly state limitations of processes, know if a required input is missing for a procedure, and understand what the deliverables can do.

It goes without saying that technical people need to communicate this in a way that non-technical people can understand, at the correct level of abstraction, without losing themselves in the detail.