IT Stockholm Syndrome

Share Button

Random thoughts on a Friday afternoon…

We’ve all got problems. More to the point, every IT department or team has problems of some kind. It’s why we hire consultants, buy products, start long and arduous journeys into the great unknown depths of root cause analysis, and so on.

What fascinates me is the level at which we come to identify with our problems. When I’ve gone into an environment to deliver recommendations, the conversation usually goes something like this:

The Power of Nope

The reality is of course that there are going to be issues…perhaps budgets are tight and new servers are rarely if ever an option. Or a QA refresh takes days so we all know we’ll never get one into a project timeline. Or we never had the chance to set up security properly on a new application and we know that the developers all have DBA access and can’t do anything about it. The list goes on. What’s interesting (and slightly amusing) is these problems are announced with almost a sense of pride, as though the manager or IT administrator is showcasing their new big screen TV or manicured lawn and not a debilitating architectural deficiency.

The Power of NoIn short, through constant business growth and changing requirements while languishing under the limitations of budgets, infrastructure, time, and staff many IT professionals have begun to accept that the answer will always be “no”, the system will never be perfect, the problems will never be fixed, and there is absolutely nothing they can do about it. After a time of this torment, the IT professional not only begins accepting these limitations but embracing them, parroting them, defending them, and reveling in them during meetings and water cooler sessions.

Why? Perhaps it is like Stockholm Syndrome, where Wikipedia explains “One commonly used hypothesis to explain the effect of Stockholm syndrome is based on Freudian theory. It suggests that the bonding is the individual’s response to trauma in becoming a victim. Identifying with the aggressor is one way that the ego defends itself. When a victim believes the same values as the aggressor, they cease to be a threat.” Or perhaps Romans 5:3 has the right of it: “Not only so, but we also glory in our sufferings, because we know that suffering produces perseverance.”

Whatever the case, it is a breath of fresh air when I work with companies that are more focused on finding solutions than reveling in problems. Everyone says they want to find solutions of course, but it’s rare that folks are actually willing to put in the time and thought process to do so rather than come up with reasons why it can’t be done.

So what can we do? Deploy outside the box. Figure out the best path to solve performance problems. Stop taking things like security concerns for granted. Keep learning, because sometimes the “fix” might seem like an erroneous approach until you understand it better. And always, always, always look for solutions instead of focusing on problems.

Now with that being said, enjoy your weekend and forget about those problems for a bit! Unless you’re on call of course.

Share Button


  1. I know exactly what you mean. I’ve heard this sort of thing too many times. You’re looked down on, sometimes with the attitude that “you’re just a ivory tower consultant, we’re in the real world now sonny boy where we don’t always have access to all the disk space we need or the QA processes you think we should spend money and time on”.

  2. In a big corporation the DBA can feel like a crusader in the midst of shrinking budgets, lengthy red-tape and excruciating change approval processes and it should be no surprise that some decide to just float in the current instead of swimming against it. Not that one should give up, though, but tremendously draining on morale to be one trying to correct flaws that nobody else seems to care about.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.