Fixing the real problem

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.

9 thoughts on “Fixing the real problem

  1. 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?

    It would be easy to assume any of these and take action, but picking the wrong one could exacerbate the problem.

    Yeah, I’ve been on the manage-ee side of this equation–avoiding doing the job, hoping that all of a sudden, it won’t become a priority/necessary. I guess I’m also dealing with it from the other side, with my coworkers collaborating on projects.

    The remote office guys (working by themselves) are a bit more difficult to interact with; it becomes an intentional call to reach them, as opposed to just wandering by a coworker’s office to shoot the shit and catch up the status on a given project.

  2. “When somebody isn’t doing a task assigned to them, what’s going on?”
    other possibilities:
    – communication crosstalk: another manager has decided it’s not as important as X, and has scrapped the idea without telling everyone else who needs to know [e.g. chain of command is murky].
    – Boss assigns multiple possible tasks. Of these, 2 won’t work. Employee puts off those two until later, because 9 times out of 10 the boss will later decide “hey, that’s not gonna work, forget about it.”
    – the task is more complicated than it appears or has more steps than those known by the assigner of said task.
    – employee is stymied by substandard or malfunctioning equipment that management has declared too expensive to repair/replace.

    Just, y’know, hypothetically speaking.

    From my perspective as a biologist, I am amazed at how much annoying data analysis software is out there. Every wonderful high tech machine comes with a software package that makes me feel like an unwitting beta-tester [multiple tooth-gnashing examples omitted]. A lot of it takes the path of “oh, don’t worry, we analyzed the data and here’s your answer! Don’t you worry about our statistical methods or anything– you don’t need to see behind the curtain!” I’m just supposed to trust that the system in use is valid. I hate that.
    I’ve wondered if there’s a huge disconnect between the scientific biologist mind and the scientific programming mind. Your comments make me wonder if we speak different languages… so further discussion is mandatory for effective communication.

  3. There is absolutely a huge disconnect between the biologist and programming mind. At the company where I was developing software for biologists, it took an entire week locked in a conference room for the team to get on the same page. “Oh, _that’s_ what you mean when you say platform. That’s not what we thought at all!” sort of conversations.

    I’ve actually been thinking I might get back into biotech or drug discovery at some point, precisely because there’s such a huge disconnect there that I’ve already learned to navigate once.

    Re: data analysis software for biology, there’s definitely an attitude among programmers of dumbing it down for the biologists. What I did instead was feed the biologists the raw data in Excel spreadsheets, and then let them play with the data themselves. Once they figured out the manipulations they wanted to do, I wrote them software to do that 🙂

  4. As an aspiring manager, I believe it’s impossible to distinguish between these various possibilities without actually talking to the employee in question.

    How do you propose to interact with people from cultures that strongly believe that the employee’s true feelings should be hidden from management at all times? From cultures that hold that management and labor are fundamentally and irrecovably at odds, and that labor should react to this by trying to take advantage at every opportunity, because, after all, that’s only what the other side’s already doing?

    This is actually not a hypothetical, in my case – I have a coworker who is, by all appearances, in dangerously over his head, but who will not, for either cultural reasons or simply abject fear of being fired, or maybe even because he really is too stupid to live and doesn’t comprehend just how spectacularly he is failing, who will not, under any circumstances, ever accept help of any sort, or admit that he may in any way be behind, except under the most intense duress (and usually then it is immediately followed by a long and generally irrelevant explanation of how far beyond his control the circumstances were that caused him to need help).

  5. The statement that you quote is more of an ideal to aspire to. Note that I’m not in a management position yet (and may never be at the rate I’m going).

    I believe that your questions both depend on developing a level of trust with your people where they feel they can be honest. Our book club at work read a book about technology death marches recently and were discussing the dysfunctions that cause those to happen. I feel that the only way to avoid those situations is developing a culture of trust and honesty within a company. Otherwise, you end up with games of “launch chicken” where everybody knows that the deadline is hopeless, but hopes that somebody else will admit it first so that they take the blame.

    One way to handle such situations is to find somebody who’s considered trustworthy by the employee(s) and make them into a “labor spokesman” of sorts that management can consult to find out what’s going on. While Signature was heading towards bankruptcy, I spoke out on the stupid things management was doing, so people started coming to me when they were having issues with management, and eventually the executive team realized I was a resource for finding out the true status of projects. So creating a chain of trust between you and your coworker might be one thing to try, even if they won’t talk to you directly.

  6. Seen in Scott Berkun’s The Myths of Innovation: “If I had 20 days to solve a problem, I would take 19 days to define it.” Albert Einstein

Leave a Reply to RichardT Cancel reply

Your email address will not be published. Required fields are marked *