Learn How To Speak The Language Of Technology

Attorneys are from Venus, technicians are from Mars

By Mischa Kischkum on 2.27.2009 - 5:00 amComments (0)
  • PrintPrint
  • Email Email
  • PDF PDF
  • Text:
  • Increase Font Size
  • Decrease Font Size
About The Author

Mischa Kischkum has been helping people leverage technology for decades. In his current role as the Information Technology Trainer for the New York offices of Reed Smith LLP, one of the world’s largest law firms, he offers training and performance development to hundreds of attorneys, paralegals, secretaries and staff. He speaks regularly on technology issues.

Contact: Email
Website: Visit
View all entries by Mischa Kischkum

Does it sometimes feel as if you’re speaking into a vacuum? Ever read a software upgrade proposal and think nobody listened to your concerns? Project planning meetings with information technology (IT) staff can be filled with secret acronyms, industry-speak and unusual terminology, making it nearly impossible to communicate effectively. Although we can’t control how IT staff speaks to us, we can improve the ways we speak to them, specifying our desire for straight talk without technical terms, for example. Read on for some tips on how to speak to technology professionals, whether you’re requesting a desk-side training session or planning a major rollout.

Many people brag about their Luddite sensibilities when they’re actually too intimidated to adopt new technologies. Some claim they are more productive than their technology-savvy counterparts when in truth they harbor a general distrust of new technology they secretly wish they could overcome. “I’ve had my cell-phone for five years; I don’t need to type messages on it, thank you,” or “My associates create all the presentations; I just dictate content” may each be valid claims, but if you’re curious about leveraging technology in your favor, it wouldn’t hurt (or at least it shouldn’t) to reach out to a staff member already in place to support you.

Find Your Voice

Before reaching out to Information Technology, “find your voice” by considering the means of communication as well as the job description for the person you contact. If you want to schedule a training session to sharpen skills in a presentation software (like PowerPoint), then asking your assistant to leave a voice mail with the Regional Director of IT might be greeted with more urgency than warranted. Conversely, if your software is frozen and your deadline is in twenty minutes, sending an eMail to desk-side support’s shared eMail account probably won’t garner the quick results you require. Be sure to reach out to the right person on the team and to include a suggested time frame or deadline so recipients can gauge their responses appropriately.

Don’t Be Intimidated

Be specific in your request. If appropriate, communicate any apprehensions you may hold. If you said to me, “I liked the last version just fine and don’t know why we had to switch, but now I feel like it’s taking me too long to perform the same tasks,” I’d understand that you’re resistant to the upgrade and that you might respond best to a “Was/Is” session, during which I demonstrate how tasks used to be performed and how they’re performed now.

If you’re aware of your learning style, say so, and include details: “I can’t sit through a class; I learn by doing. Can we work for fifteen minutes at most? I won’t retain anything if we try to cover too much.” This would alert me to the fact that you’re concerned about content overload and might lose attention if I demonstrate tasks instead of asking you to perform them.

But your interactions with IT might be of a broader nature. Perhaps you are requesting a new intranet-reporting tool or want to implement a collaboration software. Here’s where things can get complicated.

Know The Game

If you’re in a smaller firm, chances are you manage IT resources in a consultant relationship to control costs. It’s likely you are wearing many hats—as the end user, hiring manager, and contract negotiator. Without getting into the complicated process of cost analysis, software selection, and systems upgrades, I’d like to focus on your approach, perception, and communication with IT professionals.

I imagine the relationship between an IT department and its consultants as one in which you’re “dating” someone who’s exceptionally attractive: given the smallest reason to move on, your “date” can easily find another company to “go steady” with instead. As a free agent, your IT consultants can call many of the shots, and you should be cautious and clear about your staff’s needs, hard deadlines and cost limitations. Approach a consultant relationship as one that needs nurturing, plenty of communication, and carefully managed expectations.

If you are responsible for reviewing a project proposal, ask the IT consultant what sorts of problems have cropped up unexpectedly on similar projects and what unseen costs were involved (“Can we project costs of dependent upgrades?”). Perhaps you could take steps together to more fully vet your systems to expose any weaknesses before the project suddenly demands additional outlays (“How reliable is our testing environment in exposing risks?”). Explain that you don’t like surprises because they often delay completion, adding costs. Explore a bonus structure only if target dates are met and costs kept in check.

Ask the consultant about project adoption after completion. Here’s an area where planners sometimes overlook additional costs resulting from reduced productivity or time spent with support staff troubleshooting issues (“What hidden costs of adoption can we avoid?”). Perhaps the consultant can recommend changes either in training or in support documentation which could help your team properly integrate your IT project. You may prefer the consultants stay on an extra week to assist in any transition.

ITs In The House

If your IT department is in-house, then team rules apply. Since you’re on the same team, assume that each of you wants what’s best for the firm, what’s best for your department and for each other (in that order). Keeping this in mind will help you frame requests for IT input and can remind you that your request may not be first in line due to other’s priorities or cost-reduction efforts. I consider this area to be “fair game”—in other words, it’s appropriate to ask your IT team members what else is on their plate and what sorts of sudden issues springing from other projects could impact your project’s timeline and costs (“How do your other projects impact my request?”).

Ask about opportunities to join forces with other planned upgrades (“Is there a chance for my project request to exploit any synergies?”). For example, there may be a time when remaining flexible and postponing a software rollout could provide a cost-savings for the firm, which can put feathers in quite a few caps come budget review time.

Maintain The Relationship After The Rollout

Opportunities exist after the rollout, too. Maybe you don’t have the luxury of an in-house technology trainer but need to improve the efficiency of your support staff after reducing their numbers. Let them know you appreciate the additional duties they may have recently taken on by setting up targeted training sessions for them. Perhaps once each quarter they could attend a “lunch-and-learn” led by a software guru; or you might prefer to schedule a one-time visit by a needs assessment specialist followed up with individualized efficiency training. This approach is sometimes easier for busy staff members to swallow since many of them look at required training sessions as a chore, not a bonus, and feel the one-on-one session is more respectful of their busy schedules.

Here, the same questions remain regarding scope and scale, costs and expectations. It’s important to manage not only the expectations of the service provider but also of the staff that is undergoing the software rollout or training/coaching, plan. Be sure that your IT staff communicates implementation notifications and training opportunities according to an agreed-upon approach. The tone and tenor of all communications should only include positive terminology (not “It will not be difficult to submit receipts,” but “It will be much easier to submit receipts!”), and it should be clear that general skill sets are not being questioned (not “Brush up training is encouraged,” but “This new interface will require specific training.”). Users who believe their skills are in doubt are much less receptive than users who believe they’re seizing an opportunity to sharpen their competitive edge.

Keeping an upbeat tone, providing incentives like free lunch or door prizes to help increase attendance, and following up after project adoption will all contribute to smoother technology transitions for you and your team.