How do you explain technical problems to senior managers? (2024)

Key takeaways from this article

• Translate into impact:

  When discussing technical issues with senior managers, frame the problem in terms of its financial impact. This means translating uptime percentages into potential revenue loss, which helps them grasp the severity without needing to understand the tech.

• Outline necessary support:

  Clearly communicate what you need from leadership to resolve technical issues. Whether it's additional expertise or more time, make it clear how their support can directly influence a successful and timely solution.

This summary is powered by AI and these experts

• Matthew Lim Project Manager | Scrum Master | Agile…
• Joshua Copeland Cybersecurity Director | Field CISO |…

• Joshua Copeland Cybersecurity Director | Field CISO | Cybersecurity SME | Speaker | Author | Startup Advisor | Cyber and Security NPO Board Member

  • Report contribution
  I have found that the most effective way is to speak languages everyone understands—risk and dollars and cents are universal. You get buy-in when you can tie back the technical problem to risk to the business function. Rarely is a senior leader going to understand the bits and bytes, but they understand the dollars and cents. Five 9s of uptime means nothing to them, but telling them the difference between four and five 9s is the loss of $100,000 in revenue, they now deeply understand the issue without having to understand the technology underlying it.

  Like

  31

• Heather Noggle Integrator -> Technology + Human Effort | Top Writing Voice | Cybersecurity Advocate | SMB Advocate | Systems Thinker and Innovator | Cybersecurity Workforce | Speaker | Learner

  • Report contribution
  Here's the problem or opportunity (in English).Here's the solution (in English). And why.Here's a partial solution, and here are the risks that leaves open. We can phase the work this way, but we should finish the work because of x, y, and z (business reasons). Here are some other options and their pitfalls and/or benefits. Here's why I favor solution x over solution z. Add as much technical detail to this as befits the audience. Keep it fully in English if that's the best path. You'll talk about impact more if that's true.

  Like

  7

• Mihaela PIRVAN Service and Security Operations Manager @ Rexel | ITIL, Kepner Tregoe, Infrastructure Servers

  • Report contribution
  You need to send the most important message first to have everyone’s attention: risk and impact. Not in technical terms, but what I like to call “technical for non-technical”. It depends of the situation. If there’s a root-cause yet, the most important is the urgency: how much money business is losing until the permanent solution. If there’s no root-cause, you always need to escalate to the higher level of experts so you don’t lose time (and money), and sometimes put security at risk. Risk is also important in complex situation and needs to be shared with higher management. It may require a simple agreement or an entire design change, but explaining it from the user experience, is always the best and easiest way for them to comprehend.

  Like

  5

• Mohammad Zeeshan IT SERVICE MANAGMENT || ITIL Foundation || ITIL-V4 || SCRUM ||

  • Report contribution
  The way I trained my team is very simple and officially acceptable1. Describe the problem. Provide a general overview of the problem and show the specific impact it has on work and the company’s goals.2. Identify your solution or approach. Explain how you’ve already tried to solve the problem and what you’ve learned from those attempts. Recommend a specific approach, along with alternatives.3. Explain the implications. Consider the impact that your proposed solution will have on yourself and others, including your manager.4. Discuss the benefits. Focus your conversation on concrete examples of your idea’s benefits.5. Accept responsibility for the outcome. Demonstrate your commitment to ensuring success.

  Like

  4

• Hummad Abbasi Presales Architect | Technical Project Manager | ICT Solution Consultant | Telephony Engineer | Voice Engineer | Technical Lead | Avaya | PMP | Unified Communication | Technology Architect | Business Analyst

  • Report contribution
  When dealing with a non technical managers who are lean towards the commercial side, then we needs a different approachStart with basics, by simply using pen or paper or a whiteboard & share the high level issueIntroduce via diagrams or flowcharts and slowly introduce the technical terms but always make sure to explain it in more in a simple wayShare the impact on the business .i.e. impact on timelines, costs or customer satisfactionRelate it to real-world examples or share any past incidentwe need to be patient and prepare to explain the simple issue by explaining it multiple times so anyone understands the situationIn this way we will not only convey the technical issues but also built the trust and confidence of your manager

  Like

  2

• • Report contribution
  See Also

  16 Common Technical Interview Questions & How to Answer ThemHow to Prepare for Technical Interviews – Problem-Solving Tips + Mindset Tricks to Get You ReadyHow to ace a coding interview even if you can't solve the problemThe 6 Steps to Solving Your Tech Challenges - Big Bang

  “Keep it simple” is generally the best way of explaining cleanly and clearly . senior’s or top management will want to know 1) Impact of the issue 2) Is situation under control or when will it come under control 3) once the situation is handled they will want to know root cause, actual impact of the issue 4) What has been done to ensure the issue doesn’t arise again .

  Like

  16

• • Report contribution
  That cuts both ways - they like to use jargon, buzzwords and things they read in the paper. Judge carefully. Often these people have given up the tech side of the business to become management. This does not mean that they have forgotten it. Yes there are some that don't know a SSD from a 4 iron , but there are some who played with PDP-11's as children. They are the boss for a reason. If you respect that they will respect you.

  Like

  3

• (edited)

  • Report contribution
  The true measure for a person’s understanding of a topic is how well they explain it to others. If you don’t understand something enough to put it into relatable, plain English you should do more research yourself. Memorizing terms to answer a question or just get by with a solution has the risk of haunting you later when you’re asked to elaborate or something goes wrong. People don’t care that “their CPU faulted”. They care that “the piece that does the majority of processing in the computer overheated and has to be replaced.” If you only memorized the CPU broke from what you read, you’re going to look less trustworthy when they ask what you’re talking about and you can’t explain.

  Like

  2

• Kamil Podejma IT Support 💻 | Live Streaming 📺 | First Aid promoter 🚑

  • Report contribution
  The key is to know your interlocutor!If you talk to a non-technical person, use simple, daily analogies - think of it as a primary school math problem where Adam, having ten apples, gives three of them to Sarah and thinks how many he has left.But be aware of speaking like that to a person with a technical background as it might generate more follow-up questions regarding the origin of the problem, leading to bigger miscommunication and unnecessary lengthening of the discussion.

  Like

  1

• Matija Pinko Business developer. Game-changer. Writer.

  • Report contribution
  Plain language is more than just simplifying words. I always focus that the recipient understands the message in the first go.While terms like "memory leak" or "bandwidth" are second nature to a technical professional, they might sound alien to others. Instead of delving into the jargon, focus on the outcome or effect. Instead of "server crashed due to a memory leak", opt for "our system stopped working because it ran out of space to store information." Not all managers have a technical background, in fact, more and more don't. Keep it simple, so everybody can understand the matter in the most simple form.

  Like

  1

• Matthew Lim Project Manager | Scrum Master | Agile Practitioner (PMP®, CSM®)

  • Report contribution
  More often than not, the senior leadership team is looking to know what help they could provide, so focusing on how the issue would be resolved and what is needed (more time, help from SME, etc) are what they would be appreciative of.

  Like

  1

• Omar Al-Qatami COBIT 5, ISO27001, CGEIT, ITIL, PMP, IT Infrastructure Leader

  • Report contribution
  The minute you talk about the process of the resolution you lose the senior manager. They already know that problems do occur and are inevitable. Instead, it would be best if you became the problem-solver professional who they are relying on in such situations. It would be best to focus on why they need to pay attention to the negative impact and then move on to the resolution's benefit to the KPIs they know.

  Like

  7

• Dave T. RTX Deskside Support Technician

  • Report contribution
  As soon as you start throwing out technobabble or going on too long, managers often tend to tune out. I find the K.I.S.S. principle works great here. Keep it short, keep it simple, and use examples they understand and care about (impact and bottom line). Save the jargon for the watercooler.

  Like

  5

• Matija Pinko Business developer. Game-changer. Writer.

  (edited)

  • Report contribution
  Senior managers need a clear understanding of what has gone amiss. But more than just presenting the issue, you must explain its potential impact. How does this technical problem affect the business? By highlighting the direct consequences, you underscore the urgency to address it.Once the problem has been laid out, it's time to transition to the solution. Remember, they are solution-oriented. Enumerate what has been done so far and what steps are in the pipeline. This provides a clear roadmap of the resolution process.Whether it's time, resources, or manpower, offering a realistic estimate helps set proper expectations. If resolving the issue requires additional resources or support, state this clearly.

  Like

  3

• Jonathan Conine Email Implementation Architect | Technical Writer | Trainer | Presenter | Life Coach

  • Report contribution
  Be objective and honest at all times. After you explain the problem and have buy-in for the solution, you can clarify that, "I will work out the process with your technical team, but it should take X hours. We can do it during your normal change window or sooner if desired." Add in, "due to the nature of the issue, I would suggest we start work ASAP," if the problem is causing immediate business cost or impact for them.Find your own way to phrase it, but by listing it out this way you ensure they understand that you are not only confident in your ability to implement the solution, but that you understand their own internal processes, constraints and business needs.

  Like

• Jonathan Conine Email Implementation Architect | Technical Writer | Trainer | Presenter | Life Coach

  • Report contribution
  Drawing the topography of the issue and solution will not only save you time in presenting it, but it will also help the senior manager trust you on the solution you are presenting. It also allows you to easily place your bullet points on both ends of the diagram.Senior and VIP staff have so little time that they will also appreciate the extra effort you put into sharing the issue and solution that you'll immediately build additional rapport, even if the solution is rejected for any reason (such as time or money involved in the fix).

  Like

  3

• Vаdim Rеbrо Teacher,Photographer,3D Modeler,Programmer,IT Engineer

  • Report contribution
  Be careful with this: too much of or unnecessary visuals can make everything more complex to understand. It can also distract from the problem and solution.

  Like

  2

• brandi bickford Digital Pathology

  • Report contribution
  As I managed the new digital pathology core at the hospital on the day to day basis I was aware of the changing and challenging needs of both the physicians, students, and researchers. My supervisor openly admitted that though she felt capable of deftly handling the technical aspects of our computerized systems; understanding and directing her ITP to effectively address our needs, and willing to go into battle with the bueacracy(sp); she understood exactly zero about what that equipment did and why we needed it to do it. We were speaking a foreign language. We needed more equipment and the powers that hold the purse strings didn’t speak digital pathology either. After a 3 page technical paper failed. I sent them a picture. Whew! Understood!

  Like

• Jonathan Conine Email Implementation Architect | Technical Writer | Trainer | Presenter | Life Coach

  • Report contribution
  Be objective and honest. Your goal should be to resolve an issue for the customer, not to make sure they understand it isn't your fault. Being objective also prevents you from taking anything personally, as you are just getting them the data they need to make a decision for their business. That's what the focus should be on these types of conversations: to get the client data they need to be successful.Give them your email address or a mailer you monitor so they can also send feedback, questions and suggestions after the meeting.

  Like

  5

• Irvin Dominguez Lead Cybersecurity and Engineering Support

  • Report contribution
  In most of the cases you will need approval from leadership to perform any activities in the organization. This is why you need to create alliances with senior managers and leadership to obtain, accesses, budget or even people that can help you to have a successful project.Having said this, you will need to communicate appropriately your needs and transmit confidence to your audience and back it up with evidence and projection of what the project will bring to the table.

  Like

• Stacy Gray

  • Report contribution
  Once upon a time I was the IT person at a law firm. Most of the on-premises hardware was out of warranty and antiquated. I put together a proposal to replace and repurpose everything in a three-year plan. I was asked to present my proposal to an audience of over twenty litigating attorneys, including the partners. "You propose we spend $250,000 over the next three years to do this, but our system is running fine. Why should we spend this money when we haven't had any problems?" Staring into the eyes of the managing partner I said, "I have a 1995 Honda Accord with over 300,000 miles on it. Runs great. Wanna go with me on a cross country road trip in it?" They unanimously approved my proposal.

  Like

  16

• • Report contribution
  I would consider using metaphors or analogies when it is suitable. In some scenarios, the audience may need to learn a concept to make a decision.

  Like

  2

• • Report contribution
  🧠 Incident Response process and training is critical. 👉 Inform management regarding impact about business 👉Let them know progress every 30mn / 1hour even if there is no progress 👉 Share a simple, understandable incident report👉 Improve documentation

  Like

  1

• Robert Galliher, MBA Infrastructure Specialist III at Ohio Department of Administrative Services

  • Report contribution
  When speaking to senior management First: Total respect for their position.Second: Explain the situation in a clear the proper wording for the audience.Third: informed what caused the issue.Forth: what is the resolution to prevent any further issues. Fifth: Thank them for their time and keeping them informed on any updates and changes.

  Like

  1

• • Report contribution
  How do you explain technical problems to senior managers? First of all understand that managers want you to succeed. But to succeed together you need to have wonderful open and candid relationships with senior managers to build trust. Be clear on managers needs. If there is something that will impact those deliverables - own fixing them - keep the manager informed (do come with solutions) and seek advice and support ahead of something disastrous happening - don't wait until hell has frozen over to say there was an issue you knew about. Plan for success and plan for when things go wrong - that covers communication and technical actions - to help you perform when things do go wrong - and they will.

  Like

  1