A senior architect spent three weeks preparing a presentation for the board. Twelve minutes in, the CFO interrupted: "So what do you actually need from us?" The architect was on slide 4 of 47.
This is the most common pattern I see in IT teams across global companies, and it has very little to do with confidence or language. It is a structural problem, and one that public speaking courses rarely fix because they solve a different question. After ten years of working with technical teams at companies like Vattenfall. Samsung, Ciklum, Exadel and many more, I've seen what actually works in practice. This article shows you a four-part framework you can use to build real presentation skills in your IT team within 90 days, without sending anyone to Toastmasters.
The real problem isn't public speaking – it's translation
Engineers, architects, and tech leads usually have no problem talking. They explain complex systems to each other every day, they run design reviews, they argue about trade-offs in Slack threads ten levels deep. Speaking is not the bottleneck.
The bottleneck shows up at the moment a technical decision needs to leave the engineering room. The board, the CFO, the head of product – they don't operate in the same logic. Engineers think in terms of systems, dependencies, and trade-offs. The business thinks in terms of risk, cost, timeline, and decisions. Both groups are intelligent, both are looking at the same problem, but they are processing it through different decision languages, and most presentations break exactly at that translation point.
When the architect from the opening story spent twelve minutes on context before reaching the recommendation, he wasn't being unclear. He was being thorough in the way engineers value being thorough. The CFO simply needed a different starting point, and nobody had ever shown the architect how to provide one without feeling like he was dumbing things down.
This is where most presentation training misses the mark. It treats the symptom (someone froze on stage) instead of the cause (the structure of the message was built for a different audience).
Why traditional presentation training fails technical teams
Most presentation programs are built around the idea that delivery is the problem. Stand straight, project your voice, use confident gestures, build rapport with the room. There is a place for this kind of training, but it is not the place where IT teams actually lose the room.
Ninety percent of presentations in an IT team don't happen on a stage. They happen in a conference room with five people, a laptop, and a Teams call to three more on the other side of the world. The stakes are real, but the format is intimate, and theatrical techniques feel forced. Engineers and analytical minds also have a reliable internal radar for inauthenticity, and the moment a presenter starts performing a version of confidence they don't feel, the credibility drops fast.
There is also a deeper mismatch. Engineers tend to be analytical, often introverted, and sceptical of anything that asks them to act differently than they think. A program that asks them to perform extroverted energy is asking them to pay a tax for every presentation they give, and most quietly decide it isn't worth it. They go back to dense slides because at least the slides are honest.
What works for technical teams is the opposite direction. Instead of adding a layer of performance on top of the engineering thinking, you give them a structure that makes their thinking visible to a non-technical audience. The shift is not from quiet to charismatic. It is from internal logic to shared logic.
The framework: four shifts that actually work
The framework is built around four shifts in how a technical presentation is structured. Each shift addresses one of the four most common situations IT teams face when presenting outside their immediate team: an architecture review, a budget pitch, a cross-functional demo, and a request to invest in technical debt.
None of the shifts require new personality traits. Each one builds on something engineers already do well, and reframes it for an audience that doesn't share the engineering context. A team can learn the framework in a single workshop, and apply it consistently within 90 days if the manager reinforces it in one or two real presentations a week.
Shift 1: Decision first, context second
The default structure for an engineer is chronological. We looked at the problem, we considered options, we ran tests, we landed on a recommendation. This is exactly how you'd document a design decision, and it is exactly the wrong structure for an architecture review with a CTO who has six other reviews that day.
The shift is to lead with the decision and the ask, then provide context for those who want it. The first slide answers three questions: what we are recommending, what we need from you, and by when. The next slides exist to support that recommendation, not to justify the journey that led to it.
In practice this means a sprint demo or architecture review opens with something like: "We're recommending we move the payment service to the new platform in Q3. We need budget approval for two engineers and a four-week migration window. Here's why." Everything that follows is in service of that opening. If the CTO has questions, they now have a structure to ask them against. If she doesn't, the meeting ends in fifteen minutes instead of forty-five.
Engineers sometimes resist this because it feels like skipping the work. The opposite is true. The work is still there, on slides three through eight, available for anyone who wants to dive in. What changes is that the audience now knows where they are going from the first sentence.
Shift 2: Three numbers, not thirty
A quarterly budget pitch from an IT team to the CFO usually contains too much data and not enough decision support. Engineers know this intellectually, but the discomfort of leaving information out is so strong that the deck grows back to forty slides every time. The fear is that someone will ask a question the deck doesn't answer, and the engineer won't have the data to defend the position.
The shift is to commit to three numbers per recommendation: cost, time, and risk. Every other number lives in backup slides or in the appendix, and you reference them only if asked. Three numbers is enough for a CFO to make a decision, and not enough to get lost in.
This works because it forces clarity at the preparation stage. If you can't reduce a recommendation to three numbers, you don't yet understand the recommendation well enough to pitch it. The CFO is not impressed by the volume of analysis; she is impressed by the confidence of a well-bounded ask. "We need 240,000 EUR, six months, and we estimate a 20 percent chance of a one-month delay if vendor integration takes longer than planned" is a sentence a CFO can act on. A spreadsheet with eighteen scenarios is a sentence that gets postponed for two weeks.
The backup slides matter, and they should be excellent. They are the proof that the three numbers are not arbitrary. They just don't lead the conversation, they support it.
Shift 3: Explain at two levels – the big picture and the detail
Watch Neil deGrasse Tyson explain a black hole. He doesn't open with general relativity. He opens with an image anyone can hold in their head, something close to "imagine a region of space where gravity has become so strong that even light cannot escape." Once that picture is in place, he can go deeper for the people who want the physics, and the audience who wanted only the picture is still with him.
This is the model for cross-functional demos and any moment where IT explains something to the business. The default mistake is to start at the detail level, because that's where the real work is. The result is that the audience disengages by slide two, and even the people who could have followed the detail no longer have a frame to put it in.
The shift is to always present at two levels on the same slide. The big picture sits at the top, in language a non-engineer would use over coffee. The detail sits below, available for anyone who wants to engage with it. A migration to a new cloud platform, at the top: "We're moving the parts of our system that handle customer payments to a service that's faster, more reliable, and easier for our team to maintain." Below: the architectural diagram, the latency comparisons, the failover strategy.
Both audiences are now respected. The CFO has a sentence she can repeat to the board. The engineers in the room have a structure they can interrogate. Nothing has been dumbed down. The detail is still there, exactly where it belongs.
Shift 4: Show the trade-offs you rejected
Engineers live in trade-offs. CAP theorem, latency versus consistency, build versus buy, monolith versus microservices, fast versus right. Every meaningful technical decision is a trade-off, and the team has usually considered three or four options before recommending one.
In presentations, almost none of that thinking makes it to the room. The engineer presents the chosen option, and the rejected options stay in the design document. From the audience's perspective, this looks like a recommendation without alternatives, which makes it harder to trust. The instinct is to push back, ask for more options, or delay the decision.
The shift is to make the rejected options part of the presentation, briefly and confidently. One slide, three options, why each was considered, why each was set aside. This is especially powerful in a pitch to invest in technical debt, where the team is asking the business to fund work that won't produce visible features. Showing what you rejected ("we considered absorbing this into next quarter's roadmap, we considered outsourcing the refactor, we considered doing nothing for another six months") demonstrates that the recommendation is not the only thing you've thought about. It is the thing you've thought through most carefully.
This shift is the one that engineering teams adopt fastest, because it doesn't ask them to learn a new skill. It asks them to bring something they already do into the room. The reframing is not technical, it is psychological. They stop hiding the alternatives and start using them as evidence of judgement.
What changes when an IT team adopts this
The first change shows up in calendar time. Decisions that used to require two or three meetings get made in one. The "let's circle back next week" pattern, which is endemic in cross-functional IT meetings, drops noticeably within a quarter. Engineers spend less time preparing slides for follow-up meetings that wouldn't have been needed if the first one had been structured differently.
The second change is in how the IT team is perceived. Teams that present this way stop being seen as a department that delays decisions and start being seen as a department that enables them. This matters more than it sounds. When the business trusts that IT will arrive at a meeting with a clear recommendation, three numbers, and a visible set of trade-offs, the conversation shifts from "convince us" to "let's decide". Budget conversations become shorter and more often successful.
The third change is internal, and it tends to surprise managers. Engineers report that they enjoy presentations more, because they no longer feel they are performing a personality that isn't theirs. The framework gives them permission to be analytical in front of a non-analytical audience, and to do so without dumbing anything down. The introverts on the team, who often produce the best technical thinking, finally have a structure that lets that thinking land outside engineering.
How to roll this out
The four shifts can be taught in a single workshop, and most teams start applying them within two weeks. The harder part is adoption – making sure the framework becomes the team's default, not a memory from a training day.
This is where a specialist program changes the outcome. The four shifts are the foundation, but a real implementation includes dozens of additional patterns, language choices, and slide-level decisions that we work through with the team using their actual upcoming presentations. The framework lands faster, deeper, and stays in place longer when an experienced trainer reinforces it on real decks, in real situations, with feedback the team trusts.
Where to start
If you want your IT team presenting like this in 90 days, the fastest path is a workshop run by people who do this for a living. We've built the program around the four shifts and the patterns that surround them, and we've delivered it to technical teams in global companies where the audience is a board, a CFO, or a cross-functional leadership group.
Book a 30-minute consultation and we'll map the four shifts to your team's specific situations, then scope a workshop that fits your timeline and budget.
Piotr Garlej
About the author
Piotr Garlej is a Simple Communication Advocate with over ten years of experience helping technical teams in global organisations communicate with clarity. He has delivered programs for companies including Vattenfall, NBCUniversal, and Escardio, spoken twice at TEDx, and authored Effective Presentations Step by Step. His work focuses on analytical teams in IT, finance, and R&D, where logic and structure outperform stage techniques.
