When someone’s job description is “firefighter,” you know exactly how they can help you. If your house is on fire, they will put it out. We don’t call a firefighter a “long hose operator.” That may be technically accurate, but incomplete and unclear to those of us outside the fire station.
Naming conventions based on consumption make so much more sense than those based on operational or technical specs.
IT professionals want to be recognized for creating business value. Yet too often they are referred to as people who merely provide technology. It’s frustrating. To understand the disconnect, consider how IT professionals talk about themselves and their projects. Common IT titles include software development lead, SAP project manager, or something else referencing their specialty. A lot of project names I see include “cloud migration,” “system integration,” or “upgrade.” If you verbalize what you do through technology, you will be perceived as a technology-centered person.
Let’s upgrade IT’s language to reflect outcomes. Otherwise, when you describe yourself literally through an operational specialty, you sound like this guy:
Refer to Projects by the Benefits They Pursue
Projects should be described through benefits they aim to provide. Instead of naming a project “Hyperion Scorecard Implementation,” I would recommend describing it as a “Strategic Performance Measurement Enablement” project.
You could ask someone to allocate their time to participate in a CLM (contract lifecycle management) application implementation… or to participate in an effort that will cut processing time for NDAs and contracts from 25 steps to 10, and from 12 business days to a few hours. Which of the two do you think will get more support?
Clarity of the expected benefits helps in every phase of the project, from team assembly, scope definition, and design, to testing and change management.
Name Roles for Value They Create
Positions and functions should be described through business objectives. Instead of referring to a function as “SAP finance support”, try calling it “support for continuous improvement in finance.”
You can leave your business card alone. It can continue to reflect your title from the org chart. But, when you introduce yourself to others in your organization, your customers, and even to people you meet at a party, avoid tech talk. (Well, if you want to end a conversation quickly, tech talk is a sure way to do it. Just say, “This reminds me of that one time our redundant server crashed.…”)
Also consider incorporating the outcome-based job description into your email signature. Just place it underneath your official techy title.
Make Your Goals Clear to Yourself and Others
One may think that modifying language is purely a communication technique. Actually, it goes a lot deeper; it is a transformation technique. It compels people to align their actions to the expectations they’ve set.
Some of the outcome-based language may be a mouthful. It will not feel comfortable at first. But it will grow on you. And look, it’s not patently “salesy.” You are simply communicating in non-technical terms to achieve clarity, understanding, and alignment.
Tweet: IT Professionals Should Watch Their Language @MPapov #Abraic https://ctt.ec/81M0T+
