Next-gen IT starts with you

“I’m a help desk analyst, not a manager. What does all this next-generation IT stuff have to do with me?”

I hear this or some other version of, “Don’t bother me with all of this big-picture, strategic, contextual stuff. I can’t do anything about it,” quite often. It would be an entirely valid objection, except that (1) you can do something about it — for example, scuttling the whole program — and (2) an important part of next-gen IT is built into most IT jobs.

[ Find out the 10 business skills every IT pro must master and beware the 9 warning signs of bad IT architecture. | For more of Bob Lewis’ continuing IT management wisdom, check out his Advice Line newsletter. ]

First, some reassurance: All the stuff you read that says IT has to be about the business, not about technology, is a tiresome false dichotomy. IT is about the business, by way of technology.

Don’t fall for the false dichotomy and assume you have to choose one or the other. If you do, you’ll help scuttle the program. Next-gen IT is all about collaboration between IT and everyone else in the business. If you have no interest in the rest of the business, you’ll be processing work orders, not collaborating. If you have no technical chops, you won’t add anything to the conversation. Either way, you’ve helped to scuttle the program.

But if you’re interested in the business and how IT can be part of its success, you’ll move the program forward.

Built-into-the-job example No. 1: The next-gen help desk

You’re a help desk analyst? That means you’re on the front lines of making next-gen IT happen. The business/IT relationship is the fundamental underpinning of everything needed for establishing collaboration as IT’s primary way of working with everyone in the company.

Because the help desk has more day-to-day contact with everyone in the company than any other part of IT, it has a disproportionate impact on the quality of the relationship between IT and the business, right down at the one-on-one level where it has the most cultural influence.

If the folks you help trust you, they’ll be far more willing to and interested in collaborating with your colleagues. You’ve moved things forward. If they don’t trust you and don’t consider you a peer with whom they collaborate informally whenever either of you need to work together, you’ve helped scuttled the program.

Built-into-the-job example No. 2: Agile development

The usual phrase is “unless you’ve been living in a cave,” but with agile the proper one is “even if you’ve been living in a cave, by now you know about agile, and probably use it to put your paintings on the wall.”

Agile development is still controversial in some circles. This is unfortunate — when getting the user interface right is a major driver of overall project complexity, agile is just the ticket. While the name “agile” was a good choice from a marketing perspective, had the folks who chose it wanted something that described it best rather than selling it best, they probably should have called it “collaborative development.”

Agile depends on three core team habits: incrementalism, iteration, and collaboration. Incrementalism means building a big system by adding small pieces, one at a time, to an irreducible core. Iteration means not trying to get each piece right the first try, instead homing in on perfection through feedback loops.

Collaboration? Incrementalism could happen without it, but not very well, because in most cases IT isn’t the best judge of what should be the next piece to build. Iteration can’t happen without it either, because collaboration is how feedback loops happen. It’s a matter of frequent, informal, conversational contact between developers and users.

As far as the choice of methodology goes, agile is next-gen and waterfall is, unless you’re very careful, last-gen. The reason: Agile is built around collaboration, while waterfall builds a wall around IT, with carefully constructed and controlled ports through which requirements pass in one direction and finished products pass in the other.

Ready for the punch line? As a developer, if you embrace agile and enjoy its collaborative style, while at the same time the users on your projects trust you and enjoy working with you, you’ve moved things forward. If they don’t trust you and don’t consider you, again, a peer with whom they collaborate informally whenever either of you need to reach out, you’re doing your part to scuttle the program.

Built-into-the-job example No. 3: Business analysis

Business analysts are the heart and soul of the next-gen-IT evolution. When they work with business managers and users to figure things out, there are three possible ways the conversation can go.

The first is the traditional business analyst conversation, which starts essentially with the question, “What do you want the system to do?” The usual unspoken reaction is, “How should I know? You’re supposed to be the expert in IT!” Not a promising start.

The second is the proper next-gen business analyst opening conversational gambit, but without the proper next-gen business/IT relationship: “Let’s work together to figure out how your operation can run better.” The unspoken reaction follows: “Who do you think you are? I’ve spent decades fine-tuning things here, and you think you can just to waltz in and find a dozen streamlining opportunities I’ve missed? Fat chance!”

The third is the same as the second, only starting with a positive interpersonal relationship between the business analyst and business manager. With that in the mix, the two can collaborate. Often, they can figure out solid improvements; sometimes those improvements require changes and enhancements to the IT the business relies on; when they do, the business manager trusts IT to get the job done.

You know what comes next: If you are a business analyst, enjoy learning about how things work throughout the business, enjoy working with business managers and users to figure out better ways for them to get their work done, and have collaborated to figure out what the new IT needs, you trust your developer colleagues to figure out the details via agile-driven collaboration. Only then have you moved things forward.

But if you think your job is to “gather requirements” from business managers and users, translating them into language developers can understand because “they can’t talk to users,” you’ve scuttled the program, too.

These aren’t the only three IT roles that can scuttle the program or move it forward. They’re important, yes, but everyone in IT has opportunities.

Want a good starting point, no matter where you sit in IT? Lose the dumb-user stories. Sure, they’re fun. What’s equally sure is that the “dumb” users eventually hear you and your colleagues telling them — not a big trust builder.

Trust me. Dumb-user stories are an outstanding way to scuttle the program.

This story, “Next-gen IT starts with you,” was originally published at InfoWorld.com. Read more of Bob Lewis’ Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.