When I worked at Signature BioScience, there were ten other software developers, all of whom wrote better and more sophisticated code than I did. Yet I survived through multiple layoffs as Signature spiralled into bankruptcy, and I was the only developer re-hired by MDS Sciex when they picked up the pieces from Signature’s carnage. Seem peculiar?
It was actually an easy choice for Sciex. At the time Signature went under, I had written the vast majority of the code actually being used by the company. The difference was that the other developers went to the biologists, asked them what software they needed, put together a specification based on what they were told, and coded to that specification. Yet somehow, even though they delivered code that did exactly what was requested, it never did what what the biologists wanted.
My skill as a software developer was not in my programming skills, but in my ability to identify and fix the underlying problem. When a biologist asked me for software that did A, I’d talk to them, realize that they were actually trying to solve problem B, and give them software that solved problem B by doing C. When I worked as a consultant, one of my clients said in admiring bewilderment, “You never give me what I ask for, but it always does what I need!” Similarly, the biologists at Signature eventually said “Eric just reads our minds!” when asked why they used my software over the software delivered by other developers.
I was thinking about this recently because identifying and solving the underlying problem seems to be a general concern of management. To take a concrete example, if sales aren’t meeting expectations, what’s really going on?
Is it that
- salespeople aren’t working hard enough to generate leads?
- the product doesn’t meet the needs of potential customers?
- the wrong customers are being targeted with this product?
- the advertising campaign doesn’t appeal to the targeted customers?
- a competitor has better features?
- a competitor has a better advertising campaign?
As a manager facing this situation, it’s important not to dive into fixing the problem without first determining which of these possibilities apply, because you could end up like those developers at Signature, doing a lot of work with nothing to show for it. It’s also important to not to get too attached to a single solution (like making your people work harder), because that’s the “everything looks like a nail” situation.
As an aside, I think this is the idea behind the theory of constraints in manufacturing, as described by Eliyahu Goldratt in his books The Goal and Critical Chain, but I haven’t read those yet.
This idea of first identifying the real problem also applies in the softer side of management. When somebody isn’t doing a task assigned to them, what’s going on?
- They don’t have the technical capabilities to do the task.
- They’re waiting for somebody else to finish a prerequisite.
- They’re doing other things they think are more important.
- They don’t think it’s a good idea, so they’re just not doing it.
- They’re having issues in their personal life.
It would be easy to assume any of these and take action, but picking the wrong one could exacerbate the problem.
As an aspiring manager, I believe it’s impossible to distinguish between these various possibilities without actually talking to the employee in question. All the project management software in the world won’t help you figure out what’s really happening – such software can only provide an idealized abstraction of the situation. Five minutes of conversation can often identify the obstructing issue, and make it clear what the appropriate response is. I also believe that such conversation shows interest in the employee and makes it clear to them they are valued, but that’s a personal bias.
The difficulty of identifying the underlying problem is why the characteristics of reflection and thoughtfulness are so important in a manager. It’s too easy to jump on the first solution presented and spend resources without having any impact on the problem. You can tell the companies that do this – they unquestioningly adopt the meme-of-the-year from Re-engineering to Six Sigma to Total Quality Management to Agile Programming, hoping that this time it will solve their problems.
So when faced with a problem, don’t assume you know what’s going on and immediately start yelling out orders in an attempt to exude authority. Take the time to talk to everybody associated with the problem, figure out what they think is going on, get agreement on the problem and possible solutions, and go from there.