ITML IT Leadership Q&A Resource Center:
IT Communication and Influence

Return to the main IT Leadership Knowledge Base page

Table of Contents

• How do I communicate technical issues to non-technical executives?
• How do I get executive buy-in for IT projects?
• How do I present to the board about IT?
• How do I say no to unrealistic business demands?
• How do I build a business case for a new technology investment?
• How do I improve IT’s reputation with other departments?
• How do I run better IT status meetings?
• How do I handle a CEO who doesn’t understand IT?
• How do I lead technical teams?

How do I communicate technical issues to non-technical executives?

Communicating technical issues effectively to non-technical executives requires fundamentally reframing information around business impact and required decisions, rather than technical detail and process, which is often the natural instinct for technically trained IT professionals.

Begin by clearly identifying the actual business impact of the technical issue before diving into any technical explanation. Executives generally need to understand what business outcomes are affected, such as customer experience, revenue, compliance risk, or operational efficiency, before they can meaningfully engage with any technical detail, and many technical conversations fail specifically because they lead with technical complexity before establishing why the executive should care.

Avoid technical jargon and acronyms entirely when possible, or clearly define any technical terms that are genuinely necessary, since even executives with some technical background may not be familiar with highly specific or rapidly evolving technical terminology. When technical concepts must be explained, using analogies to familiar business or everyday concepts often communicates the essential idea more effectively than precise technical language that requires specialized knowledge to fully understand.

Structure your communication around what decision or action you need from the executive, rather than providing exhaustive technical background before reaching your actual point. Many technical professionals instinctively want to fully explain the technical context before making their ask, but executives generally prefer understanding the required decision or action upfront, with supporting detail available if genuinely needed rather than delivered by default.

Quantify risk and impact wherever possible, translating technical risk into concrete business terms like potential financial cost, compliance exposure, or customer impact, rather than purely technical severity ratings that may not translate meaningfully into business significance without additional context.

Practice restraint regarding technical detail, resisting the natural inclination to demonstrate technical thoroughness by including extensive detail that isn’t actually necessary for the executive’s decision-making purposes. Providing an offer to share additional technical detail if genuinely wanted, rather than including it all by default, respects the executive’s time while still providing access to detail if they specifically want it.

Finally, practice and refine this communication skill deliberately, as it typically doesn’t come naturally even to highly capable technical professionals and generally improves significantly with deliberate practice, feedback, and conscious effort to consistently reframe technical communication around business relevance and required decisions rather than technical completeness.

How do I get executive buy-in for IT projects?

Securing executive buy-in for IT projects requires framing your proposal around business value and strategic alignment rather than technical merit alone, recognizing that executives are ultimately evaluating competing investment priorities across the entire organization, not just assessing whether your proposed technical approach is sound.

Begin by clearly articulating the business problem your project solves, quantified wherever possible in terms executives care about: revenue impact, cost reduction, risk mitigation, competitive positioning, or regulatory compliance. Technical projects framed purely around technology modernization or technical debt reduction, without clear connection to these business-relevant outcomes, often struggle to secure executive attention and funding regardless of genuine technical merit.

Develop a clear, credible business case that includes realistic cost estimates, expected timeline, and projected return on investment or other quantifiable benefits. Executives are understandably skeptical of overly optimistic projections, so building credibility through realistic, well-substantiated estimates, including honest acknowledgment of risks and uncertainties, tends to be more persuasive than an unrealistically rosy pitch that invites justified skepticism.

Identify and address likely executive concerns proactively, rather than waiting for them to be raised during your presentation. Common concerns include disruption to current operations, resource competition with other priorities, and risk of project failure or cost overrun, all of which should be directly addressed with credible mitigation plans within your proposal.

Build relationships and informal support before formal presentation moments, seeking input and buy-in from key executive stakeholders individually before a formal group presentation or approval meeting. This approach, sometimes called securing buy-in “before the meeting,” often proves more effective than hoping to build consensus in real time during a formal presentation, where skepticism or objections raised publicly can be harder to address than concerns worked through individually beforehand.

Find an executive sponsor who genuinely champions your proposal and can help navigate organizational politics and competing priorities on your behalf. Projects with a strong internal champion, particularly one with credibility and influence among other executives, generally fare much better than those relying purely on the IT team’s own advocacy without broader organizational support.

Finally, be prepared to make trade-offs and compromises, recognizing that few IT proposals are approved exactly as originally envisioned. Demonstrating flexibility around scope, timeline, or budget, while maintaining focus on the core business outcome you’re trying to achieve, generally produces better results than rigid insistence on your original proposal exactly as initially conceived.

How do I present to the board about IT?

Presenting to the board about IT requires a significantly different approach than typical internal IT communication, demanding extreme conciseness, strategic framing, and comfort addressing an audience with limited technical background but significant business and governance responsibility.

Board presentations should be dramatically more concise than typical internal IT reporting, often limited to a small number of slides or a brief verbal summary covering only the most strategically significant information. Boards generally have limited time allocated to any single topic area and expect executive-level synthesis rather than comprehensive detail, meaning effective board communication requires ruthless prioritization of only the most critical points.

Frame all content around business risk, strategic opportunity, and governance responsibility, since board members are fundamentally focused on their fiduciary and oversight responsibilities rather than technical operational detail. This means emphasizing topics like major security risks and mitigation status, significant technology investments and their strategic rationale, regulatory compliance status, and any major project or initiative with substantial business or financial implications.

Avoid technical jargon entirely, using plain business language throughout, since board members typically come from diverse professional backgrounds and may have limited or no direct technical expertise. Any technical concepts that must be included should be explained through clear analogies or business-relevant framing rather than technical terminology.

Anticipate and prepare for governance-oriented questions that boards typically focus on: How does this compare to industry peers or best practices? What is our exposure if this risk materializes? How confident are we in these projections? What would happen if we didn’t make this investment? Board members are generally more interested in risk, strategic rationale, and comparative benchmarking than technical implementation detail.

Bring appropriate confidence and executive presence, recognizing that boards expect IT leadership to demonstrate command of their domain and clear, confident communication, even when discussing challenging topics like security incidents or project setbacks. Excessive hedging, uncertainty, or overly technical deflection when faced with direct questions can undermine board confidence in IT leadership capability.

Finally, work closely with your CIO or executive sponsor to align messaging and ensure consistency, since board presentations typically represent organizational IT leadership collectively rather than any single individual’s perspective, and inconsistent messaging across different IT leaders presenting to the board can undermine overall credibility and board confidence in IT governance.

How do I say no to unrealistic business demands?

Saying no to unrealistic business demands effectively requires replacing an outright refusal with a more constructive approach that acknowledges the underlying business need while clearly articulating genuine constraints and offering alternative paths forward, rather than simply asserting technical impossibility without further engagement.

Begin by genuinely understanding the underlying business need driving the request, rather than immediately focusing on why the specific request as stated is unrealistic. Often, the specific solution or timeline requested isn’t the only way to address the genuine underlying business problem, and understanding root needs opens possibilities for alternative approaches that might actually be achievable.

Clearly articulate the specific constraints making the request as stated unrealistic, using concrete, quantifiable reasoning rather than vague assertions of difficulty. Explaining exactly what resources, timeline, or technical dependencies make the request infeasible as specified, ideally with supporting data or comparable past experience, builds credibility far more effectively than simply stating something isn’t possible without substantive justification.

Present alternative options rather than only explaining why the original request can’t be fulfilled. This might include a modified timeline, reduced scope, additional resources required to meet the original timeline, or a phased approach that delivers partial value sooner while completing the full scope over a longer period. Providing concrete alternatives transforms the conversation from pure refusal into collaborative problem-solving.

Use data and trade-off framing to make constraints tangible, such as explaining that meeting an unrealistic deadline would require either significant additional budget for contractor resources, deprioritizing other committed initiatives, or accepting meaningfully increased risk of quality issues or system instability. Making implicit trade-offs explicit helps business stakeholders understand that saying no isn’t arbitrary IT resistance but reflects genuine capacity and risk constraints.

Escalate appropriately when necessary, particularly for demands from senior stakeholders where you may lack sufficient authority to unilaterally decline. In these situations, clearly documenting your assessment and recommended alternative, then escalating the decision to appropriate leadership with full context, protects both you and the organization from unrealistic commitments made without proper understanding of the true costs and risks involved.

Finally, build long-term credibility through consistent, well-reasoned communication over time, so that your assessment of what’s realistic carries genuine weight with business stakeholders based on your track record, rather than being perceived as reflexive resistance to any challenging request. Leaders who occasionally say yes to genuinely difficult but achievable stretch goals, while clearly and constructively pushing back on truly unrealistic demands, build far more credibility than those who either always acquiesce or reflexively resist any ambitious request.

How do I build a business case for a new technology investment?

Building a compelling business case for technology investment requires structuring your proposal around business outcomes and financial rigor rather than technical merit alone, recognizing that decision-makers are typically comparing your proposal against competing investment opportunities across the entire organization.

Begin with a clear problem statement that articulates the specific business challenge or opportunity your proposed investment addresses, quantified wherever possible. Vague statements about improving efficiency or modernizing technology are far less compelling than specific, quantified problem statements, such as current system limitations causing measurable customer service delays or compliance risk exposure with specific potential financial consequences.

Develop realistic financial projections, including total cost of ownership over a multi-year period rather than just initial implementation costs, and expected return on investment or other quantifiable benefits. Being conservative and realistic in these projections, rather than overly optimistic, builds credibility and reduces the risk of the business case being dismissed as unrealistic, or worse, approved based on projections that later prove significantly inaccurate.

Consider multiple options and alternatives within your business case, including a genuine “do nothing” baseline scenario that illustrates the cost or risk of maintaining status quo, along with your recommended solution and at least one meaningful alternative approach. This comparative framing helps decision-makers understand why your recommended approach represents the best available option rather than simply presenting a single option without context for evaluating its relative merit.

Address risks and mitigation strategies explicitly, rather than presenting an overly optimistic case that ignores genuine implementation or adoption risks. Acknowledging risks such as implementation complexity, change management challenges, or vendor dependency, along with credible mitigation strategies, builds far more credibility than a business case that appears to ignore legitimate concerns decision-makers will likely raise regardless.

Connect the investment explicitly to broader organizational strategy and priorities, demonstrating how this specific technology investment supports stated strategic objectives rather than existing as an isolated technical improvement disconnected from broader business direction. This strategic framing significantly increases the likelihood of executive support compared to a purely technical justification.

Finally, tailor your business case presentation format and level of detail to your specific audience and organizational culture, since some organizations expect extremely detailed financial modeling while others prefer more concise, high-level business cases with supporting detail available if specifically requested. Understanding and matching your organization’s typical expectations for business case rigor and format significantly influences how favorably your proposal is likely to be received.

How do I improve IT’s reputation with other departments?

Improving IT’s reputation with other departments requires a sustained combination of improved service delivery, proactive communication, and genuine relationship building, recognizing that reputation, whether positive or negative, tends to be sticky and often requires consistent effort over time to meaningfully shift.

Begin by honestly assessing the current state of IT’s reputation through direct conversations with business stakeholders and, if possible, more formal feedback mechanisms like satisfaction surveys. Understanding specific sources of frustration or distrust, rather than assuming you already know the underlying issues, ensures your improvement efforts address genuine pain points rather than assumptions that may not accurately reflect actual stakeholder concerns.

Address any genuine, significant service delivery issues as a foundational priority, since reputation improvement efforts will struggle to gain traction if IT continues to have significant, visible service failures. This might require focused improvement initiatives around response times, project delivery reliability, or communication during outages and incidents, depending on what your stakeholder feedback reveals as the most significant pain points.

Shift communication style toward proactive, business-relevant updates rather than purely reactive, technical communication. Regularly sharing progress on initiatives that matter to specific business stakeholders, using language and framing relevant to their priorities rather than technical detail, helps build perception of IT as a genuine partner rather than a purely reactive support function.

Invest in building genuine relationships with key stakeholders across other departments, going beyond purely transactional interactions tied to specific support tickets or projects. Regular informal check-ins, genuine curiosity about their business challenges and priorities, and visible interest in their success beyond immediate IT-related interactions help build trust and rapport that pure service delivery, however excellent, doesn’t fully achieve on its own.

Create visible wins and success stories, actively communicating positive outcomes and business impact from IT initiatives rather than assuming stakeholders will naturally recognize IT’s contributions. Many IT departments under-communicate their positive impact, inadvertently allowing negative experiences to disproportionately shape overall perception simply because positive contributions go unrecognized or uncommunicated.

Solicit and genuinely act on feedback, demonstrating that stakeholder input leads to real changes rather than being collected without visible follow-through. This visible responsiveness to feedback significantly influences whether stakeholders perceive IT as genuinely interested in their satisfaction versus merely going through the motions of soliciting feedback without meaningful follow-up action.

Finally, recognize that reputation improvement is a long-term effort requiring sustained consistency rather than a single initiative or campaign. Organizations with historically strained IT-business relationships often require sustained effort over an extended period before stakeholder perception genuinely shifts, making patience and consistency as important as any specific tactical improvement effort.

How do I run better IT status meetings?

Running better IT status meetings requires addressing the common failure modes that make these meetings feel like a waste of time: excessive length, lack of clear purpose, information that could be shared asynchronously, and insufficient focus on genuine decisions or problem-solving that actually require real-time discussion.

Begin by clearly defining the actual purpose of each recurring meeting, distinguishing between meetings genuinely requiring synchronous discussion, such as those involving decision-making, problem-solving, or complex coordination, versus pure status reporting that could often be communicated more efficiently through written updates, dashboards, or asynchronous tools.

For meetings that genuinely require synchronous discussion, implement a structured format that maximizes discussion time rather than passive status reporting. One effective approach involves requiring written status updates to be submitted before the meeting, allowing meeting time to focus specifically on questions, blockers, and decisions rather than reading through routine status information that attendees could review independently beforehand.

Ruthlessly limit attendance to only those genuinely needed for the specific discussion and decisions at hand, rather than including broad attendee lists out of general information-sharing habit. Meetings with excessive attendance often become less efficient and engaging, as the larger group size reduces genuine participation and increases the temptation for passive attendance without active engagement.

Establish and enforce genuine time discipline, starting and ending meetings punctually, and actively managing discussion to prevent tangential topics from consuming time better spent on the meeting’s core purpose. Parking lot techniques, explicitly noting topics that arise but don’t fit the current meeting’s scope for follow-up outside the meeting, help maintain focus without completely dismissing legitimate but tangential concerns.

Focus explicitly on blockers, risks, and decisions needed, rather than simply reviewing what has already been completed. Effective status meetings spend disproportionate time on what’s at risk or blocked, since these are the areas where real-time discussion and problem-solving genuinely add value, rather than spending equal time reviewing successfully completed work that requires no further discussion.

Regularly solicit feedback on meeting effectiveness from attendees, being willing to adjust format, frequency, or attendance based on genuine feedback rather than assuming your current meeting structure remains optimal indefinitely. Finally, model engaged, focused participation yourself as the meeting leader, since attendee engagement and discipline often mirror the leader’s own demonstrated behavior regarding punctuality, focus, and genuine substantive engagement with the meeting’s actual purpose.

How do I handle a CEO who doesn’t understand IT?

Handling a CEO with limited technical understanding requires adapting your communication approach while building trust through demonstrated business acumen and reliability, rather than expecting the CEO to develop deeper technical knowledge or becoming frustrated by their limited technical background.

Recognize that a CEO’s job isn’t to understand technical detail, but to make sound business decisions with appropriate input from functional experts, including you as an IT leader. Reframing your expectations around this reality, rather than being frustrated that the CEO doesn’t share your technical perspective, helps you approach the relationship more constructively and focus energy on effective communication rather than futile attempts to build deep technical understanding that isn’t actually necessary or expected.

Consistently translate technical topics into business-relevant framing, focusing on risk, opportunity, cost, and competitive implications rather than technical detail. Developing genuine skill at this translation, practicing clear, concise communication of complex technical topics in business terms, becomes even more critical when working with a CEO who has limited technical background, since your ability to bridge this gap directly determines whether IT’s perspective genuinely influences important business decisions.

Build credibility through consistent reliability and follow-through, since CEOs without deep technical understanding often rely heavily on trust in their IT leadership’s judgment and competence, given their limited ability to independently evaluate technical claims or recommendations. Demonstrating consistent accuracy in your assessments, honest communication about both successes and challenges, and reliable delivery on commitments builds the trust necessary for the CEO to confidently rely on your recommendations even without deep technical understanding themselves.

Use analogies and comparisons to familiar business concepts when explaining technical topics, helping bridge understanding without requiring genuine technical education. Comparing cybersecurity risk to insurance and risk management concepts, or technical debt to deferred maintenance on physical infrastructure, often helps build intuitive understanding more effectively than direct technical explanation.

Proactively provide context and education at a pace and depth the CEO finds valuable, without imposing excessive unwanted technical detail. Some CEOs appreciate a baseline understanding of key technical concepts relevant to major decisions, while others prefer to focus purely on bottom-line business implications and trust their IT leadership’s technical judgment without wanting deeper technical education themselves. Understanding and respecting your specific CEO’s preferences, rather than assuming uniform preference across all executives, helps calibrate your communication approach appropriately.

Finally, find and cultivate relationships with other executives or board members who may have stronger technical backgrounds, who can sometimes serve as valuable allies in translating and reinforcing technical perspectives within executive and board discussions, providing additional support for technically informed decision-making even when the CEO’s own technical understanding remains limited.

Thinking of becoming an IT Managers? Click here to take our free IT Management Assessment!