Process Is For Losers: How to tell when your company has become IT-codependent
Everybody in IT has their favorite war story, about that time when they were presented with insurmountable odds, asinine deadlines and insufficient resources, but somehow managed to live to tell the tale—or at least went down with their guns blazing. They’re often told with pride, as well as a little gallows humor; IT professionals, it seems, are happiest when the obstacles are close to insurmountable.
It’s part of our psychological makeup (well, at least mine). I got into information technology for the same reason I think most of us are attracted to it: I like solving problems. There’s an endorphin rush associated with getting a new application to work, troubleshooting a network problem, beating a configuration problem into submission, etc. Sure, there’s the glamor, the big money, and the girls who flock to you when you talk about troubleshooting IP address configurations. But mostly, it’s the buzz from making stuff work.
The bigger the problem, the bigger the buzz. When you’ve had your department taking heroic measures to solve an emergency business requirement, working an all-nighter to beat an impossible deadline that the business side needs to seal that multi-million dollar deal or meet that compliance requirement, development queue and process be damned, the power rush can cloud your ability to reason. You and your team nail it and save the company’s bacon, and prove the value of what you do to the rest of the company.
But what if everything suddenly becomes an emergency?
What if, after seeing that you can pull off miracles without following that precious IT process you’ve created, business managers come to expect you to deliver on every project the same way?
Congratulations, your business execs have become IT co-dependent, and you’re their #1 enabler.
There’s a fine line between being “agile” and being an enabler of a dysfunctional business model. You’re agile if you’ve got a process that incorporates flexibility and plans for “ship early and often” approaches to problem-solving. You’re an enabler if you constantly have to go back and fix implementations you rushed to make business deadlines so that they’ll scale or to integrate them into your architecture so you can support them…or if you don’t have the time to do either of those because of more rapidly emerging business requirements.
In an agile IT organization, IT is engaged with the business side, and watching the road ahead. In a co-dependent company, IT is always heads-down and reactive, trying to sprint to meet emerging requirement because business managers didn’t include IT in the decision-making process. A sure sign that you’re headed toward co-dependency is when decisions about projects that affect the technical aspect of their implementation are made at meetings that don’t have someone from IT at the table–or the IT representative is so junior that he or she ends up being cut out of the conversation.
There’s only one way to break a co-dependency cycle: You’ve got to be assertive. Sometimes it takes more personal courage and leadership to balk at another “Charge of the Light Brigade” style project than it does to get your team to once again jump into the breach. When you finally say “no” (or the moral equivalent of it), be prepared for a lot of screaming.
But it’s better than the alternative. Because eventually, if you’re not taking positive control over the project demands your team is faced with–regardless of whether you’re actually successful at jumping through the hoops that the business side of the company constantly presents you with–you’re going to have to face the fact that you’re not going to be able to sustain the pace much longer. While agile organizations have no problem with retaining good people, the smart people at co-dependent organizations are trying to claw their way out.
And if being assertive isn’t an option, maybe you should start clawing.