Conversations from the Field: The Fall of the Geek

Regarding commentary that I wrote on an upcoming assignment where students are to explain the benefit of describing technical information in graphical terms. More ideas on my utilitarian principles of IT; IT as a ubiquitous utility.

The visual representation of processes and components allow the technical professional to transcend geekness and talk to a business person. People who do this well stay away from acronyms and dizzying technical specifications because they can confuse an audience.

Meanwhile, insecure technolgists feel compelled to introduce technical terms because it reinforces their own ego in a room of decision-makers. Combined with a form of social anxiety rooted in their own lack of self-confidence, the traditional geek struggles to both understand big-picture concepts and relate them in a way that makes sense to functional managers.

I’ll give you some of my experience on this. Aside from consulting, I’ve worked as a technology manager, director, and VP of IT. When I make presentations to a functional management team, I talk processes. I use their own roles, terms, and business processes to illustrate how technology will improve these processes. I stay away from technical acronyms or specifications. I’m dressed as my functional peers, I’m standing, presenting, taking charge of the room to relate core ideas in under ten minutes. Anyone will tell you that if you don’t dress the part, nobody will take you seriously, and dragging a presentation beyond 10 minutes is an attention-risk. People will start whipping out their Blackberry’s doing whatever they can to ignore you and to remain productive.

How future technology professionals address this problem really represents the value we place in technology pros who’re smart yet also communicative; technically-adept yet understand the core business; can drill deep into a problem but can understand the broader business process implications. This breed of geek is difficult to come by and you pay dearly for them. They are often generalists when it comes to technology, choosing to understand a broad array of technological areas rather than niche themselves in a single area like databases, programming, hardware, or networks. Where they sacrifice street cred with their technical peers, they make up in seeing broader pictures where technology can be applied. These are the people who make great senior managers, directors, and executives because they can susinctly communicate complex ideas in a way that relates to the problem of business.

And that’s what our case is struggling with now. Functional IT managers who’re really good at managing IT problems are being asked to pitch the value of the call center and the software package you’re responsible for. As a tactical decision-maker in IT, this is a learned skill: the CEO is right to have you consider what happened and how communication could have been made more effective. In fact, I’ve done this before with tactical and operational employees in my organizations where, after a confusing meeting, I’ve pulled them aside and discussed how it could have been better handled and what was important to the audience. Without such mentoring, I feel my subordinates would suffer from an intolerable malaise of being unable to communicate with others, lowering their own self-confidence and creating a cycle of fear for dealing with end-user constituents. On the other hand and far worse, as a strategic-level director, I couldn’t delegate – internal constituents would always want to talk with me instead of my management team, and that’s a real problem. I needed to establish trust in the tactical levels of my staff so relationships between my managers and, say, the purchasing and AP managers could grow. And even as a tactical manager, I had the same concerns for my operations staff: there had to be a willingness on my part to mentor the technical employee to overcome their self-confidence issues and deal with the public. I think this is rightly what we see here in the case.

When we don’t see this, we see IT and its operations/tactical team become isolated and autocratic. They don’t deal with the public because it intimidates them, worse yet, they could arrogantly believe because the public doesn’t _understand_ the technology that dealing with end-user consituents is a waste of time. This causes the technology climate to belittle users. Perhaps you’ve seen some of this in your own professional experience?

In my opinion, adding a program manager only adds another layer where you hope to delegate the communication role to somebody else. In my opinion, why aren’t you – the tactical manager responsible for implementation – grappling this problem on your own and improving your own project management skills? Indeed, when you go about describing what skills and abilities this role should have, should these be _your_ abilities? In an era where the IT organization is considerably flatter, where there are fewer tactical decision-makers, we _need_ more facilitators – not managers – and it appears to me that you’re almost trying to hire your replacement!

So I’d like to get you to think about the skills and communication ability and perspective of a program/project manager because those skills are what you should be improving upon as well. Additionally, consider for a minute the rationality of hiring somebody to do _your_ job in an age where downsizing is so totally fashionable. Is that approach good for the company, good for end users, good for you?

A couple of areas in the reading to pay attention to on this. Look at the technical vs behavioral approach to IT on pages 26-27, and Laudon’s own approach called Sociotechnical Systems. Take a look at the challenges facing information system management issues on page 28 – what kind of skills will be needed to tackle these problems? Take a look at page 75, Organizational Politics, organizational dynamics on page 82; pages 85-87 on IT decision-making; pages 102-103 on opportunities and management challenges. Factor these ideas into your discussion.

R

——————————————————————————–
From: (Student)
Sent: Fri 11/17/2006 6:27 PM
To: Russell MicklerSubject:
RE: IT460-2 P1T3 Commentary

I find your article very interesting and encouraging. I have been at my first IT job since March. I am in Customer service, and I don’t talk geek. I often feel inferior when around my peers, but when I am on the job, I am complimented for all I do and how I do it.

Although I am Customer support, I work as a separate entity from my department where I am like my own boss. I serve around 200 users over 5 locations for Indiana Army National Guard Aviation. Because of this, I dabble in many areas beyond customer support. The guy who recommended me and I replaced, left this position to go as a consultant.

Reading your article helps put me at ease in not knowing specific details about a particular subject, but knowing general details about many. It kind of gives me a bigger picture of where I could be someday.

Thanks

***

Well, thank you, sir.

There are, of course, places in the IT organization where we need the die-hard geek. This will always be true. However, has much of the complexity of IT is stripped away and IT becomes of an appliance, or, a utility, the role of the die-hard geek is greatly diminished.

The real challenge comes, then, not in how technology is architected, built, setup, or maintained, but in how technology is used. How can we translate the needs and ideas of the business into tangible, meaningful results using a tool like technology? This changes the ball game. The more important players in this IT world of our future are people who understand how tech can be creatively applied to solve business problems, and, can communicate their ideas honestly, openly, and specifically.

We feel this today in our employment numbers. Huge drops in IT “grunt” work (programmers, engineers, systems management, operations) because a lot of this work can be either automated or outsourced; large rises in analyst and middle-management idea people who can talk geek with grunt contractors, and, communicate ideas effectively to peers and senior management. In my experience, the most prized employees I ever had weren’t superior technologists (I can buy those) but understood sustinctly how business processes could _benefit_ from technology. Idea people in IT = more importance than grunt labor.

Keep that in mind. Your buddy who left to become a private consultant saw value in sharing his ideas with others and felt he could capitalize on that. You, too, can do the same. Best wishes -

R
www.micklerandassociates.com

Name (required)

Mail (will not be published) (required)

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.