IT folks want to be recognized for creating business value, yet too often they are referred to as people who merely provide technology. It’s frustrating! But consider how most IT professionals talk about themselves and their projects. A seemingly slight change in wording can mean the difference between being taken seriously and being tuned out. 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. It is what you call it 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. SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe Let’s upgrade IT’s language to reflect outcomes. Otherwise, when you describe yourself literally through an operational specialty, you sound like the Angry Arnold meme: “I lift things up & put them down! Aaarrrgh!” 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. Related content opinion 5 risks CIOs must assume in the digital age Are CIOs supposed to avoid risk or embrace it? It depends. For digital programs to flourish and fuel the growth of the larger organization, entirely new behaviors need to be adopted by IT leadersu2014but they each come with an assumed risk. By Mikhail Papovsky Sep 13, 2018 6 mins CIO Risk Management IT Leadership opinion Your first 100 days as CIO came and went. Now what? Sure, the first days in your role as CIO are critical. Advice abounds in books, blog posts and presentations for how to approach your initial 90- or 100-day period. These recommendations are compelling and directionally sound. In reality, itu2019s ra By Mikhail Papovsky Aug 20, 2018 7 mins CIO IT Leadership opinion Traditional or transformational: what kind of CIO are you? You might be a little of both. Where are you on the spectrum? What type of CIO does your organization need, and why? By Mikhail Papovsky Jul 25, 2018 6 mins CIO IT Leadership opinion Agile sprints for better vendor management The benefits of Agile extend far beyond software development. Hereu2019s how Agile can enhance your vendor engagement efforts. By Mikhail Papovsky Jun 27, 2018 7 mins Agile Development IT Leadership Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe