It’s a discussion in meeting rooms, boardrooms, hotel conference rooms, and post-conference cocktail parties: Why isn’t IT working? Ask anyone in a corporate or government job and you’ll get an earful. As I was writing this book, I’d occasionally throw the question out to friends, clients, and beleaguered airplane seatmates. The responses come fast and furious. They don’t speak our language. They’re too focused on resume building and tinkering, not on driving business value.
The New IT
This single quote describes much of the circuit of the world for an engineer. If I spend my time on driving business value, then I’m appreciated by my current employer — at least until they change systems, anyway, and throw me out on my ear because my skills aren’t “current.” If I spend my time keeping my skills current, so I can add business value, well, I’m not driving current business value, and hence I’m “isolated,” a “tinker in the corner,” who doesn’t understand nor care about the “real problems facing the business.”
What’s the solution? A little “bump in the training budget” isn’t going to fix this. Rather, this is going to take restructuring the way IT thinks about business, and — probably more important — the way business thinks about IT.
From the engineer’s side: Start driving business value. I know, your business leaders still aren’t going to see your value, and you’re going to be spending your time at work supporting a COBOL system while spending your “off hours” learning something new so you can hit the ground running when the business folks decide to get rid of that old COBOL system. That’s the way of the engineering life — get used to it. Don’t expect favors from the business folks — to turn the example around, they’re too busy putting their latest sales numbers on their resumes to bother understanding the support they get from engineers in making those numbers happen.
From the IT industry side: Stop playing games with arcane CLIs and 9,438 different ways to solve the same problem. It’s fun, I know, to invent yet another tunneling protocol, but do we really need it?
From the business side: Start treating engineering as an adjustable spotlight which can be applied to a range of problems, rather than as a single laser beam that makes a really tiny dot. Appreciate that engineers aren’t bad engineers if they don’t have the “latest skills,” just like salesmen aren’t bad if they’ve never sold your specific product before. Learn how to spot and grow engineering talent — rather than “talent in the Acme flabbigalitron programming language and all around best business system that’s ever been invented.” There is more to engineering than a programming language or a CLI. Engineering is a way of thinking, a set of process skills, and an way of building and using tools to solve problems.
If we really want to solve this business/geek divide, we need to get both sides to work fixing it. Engineers have to learn to drive business value, the industry needs to figure out how to stop the “let’s build something new because I didn’t any of the stuff that came before” syndrome, and business needs to start seeing engineers as people, and engineering skills as valuable outside a narrow range of what they read in some inflight magazine.