Research Tutorial

Presenting to Win: Technical Presentation, Communication, and Ethical Persuasion

A practical research tutorial for engineers, scientists, researchers, technical leaders, consultants, and technology entrepreneurs

Strategic application: IAS-Research.com · KeenComputer.com · KeenDirect.com

Abstract

Engineers and scientists routinely work with complex systems, experimental results, mathematical models, software architectures, simulations, and research findings. Yet technical excellence alone does not guarantee that an idea will receive funding, executive approval, customer adoption, research collaboration, or organizational support.

The missing capability is often communication.

A technical presentation is more than a collection of slides. It is a structured mechanism for transferring knowledge, establishing credibility, explaining significance, addressing objections, and enabling a decision.

This tutorial develops a practical framework for:

Research → Communication → Presentation → Persuasion → Decision → Action

It combines scientific communication, engineering reasoning, business communication, public relations, storytelling, audience psychology, and ethical persuasion. It also applies these principles to the strategic ecosystem of IAS-Research.com, KeenComputer.com, and KeenDirect.com.

The objective is not manipulation. Ethical persuasion means helping an audience understand the evidence, implications, alternatives, uncertainty, and appropriate next step so that people can make informed decisions.

1. Why Presentation Is an Engineering Skill

An engineer normally thinks in terms of:

Requirements→Design→Implementation→VerificationRequirements \rightarrow Design \rightarrow Implementation \rightarrow Verification

A technical presentation should use a similar process:

Audience Requirements→Message Architecture→Presentation Design→Communication VerificationAudience\ Requirements \rightarrow Message\ Architecture \rightarrow Presentation\ Design \rightarrow Communication\ Verification

The audience is effectively the system receiving the information.

If the audience cannot decode the information, the communication system has failed even if the underlying technical content is correct.

Therefore:

Communication Quality=Information Accuracy×ComprehensionCommunication\ Quality = Information\ Accuracy \times Comprehension

A technically accurate message with near-zero comprehension has little practical value.

2. The Three Jobs of a Technical Presentation

Every presentation should perform three jobs.

Job 1 — Explain

The audience must understand:

  • what the technology is;
  • what problem exists;
  • how the proposed solution works;
  • what was tested.

Job 2 — Establish confidence

The audience must understand:

  • why the presenter is credible;
  • what evidence exists;
  • what assumptions were made;
  • what limitations remain.

Job 3 — Enable action

The audience must understand:

  • why the result matters;
  • what opportunity exists;
  • what risks exist;
  • what should happen next.

Thus:

Explain+Establish Trust+Enable Action\boxed{ Explain + Establish\ Trust + Enable\ Action }

3. Communication Is Not the Same as Information

This is one of the most important lessons for technical professionals.

Information

The system uses a distributed RAG architecture with vector retrieval, knowledge graphs, an LLM and an edge gateway.

Communication

The architecture separates time-critical vehicle diagnostics from knowledge-intensive reasoning, allowing the diagnostic system to respond locally while using a larger knowledge base when deeper analysis is required.

The second statement gives the audience:

technology + purpose + consequence.

That is communication.

4. Start With the Audience

Before creating slides, identify the audience.

A technical presentation may have:

Scientists

Interested in:

  • methodology;
  • novelty;
  • evidence;
  • reproducibility;
  • uncertainty.

Engineers

Interested in:

  • architecture;
  • interfaces;
  • implementation;
  • performance;
  • failure modes.

CTOs

Interested in:

  • architecture;
  • risk;
  • scalability;
  • security;
  • cost;
  • strategic fit.

Executives

Interested in:

  • business impact;
  • investment;
  • risk;
  • opportunity;
  • implementation.

Customers

Interested in:

  • their problem;
  • outcomes;
  • cost;
  • implementation;
  • support.

Public/media

Interested in:

  • significance;
  • human impact;
  • credibility;
  • understandable explanations.

The same technology therefore requires different communication layers.

5. The Audience Translation Matrix

Audience

Primary question

Communication emphasis

Scientist

Is the result scientifically valid?

Evidence

Engineer

Does it work technically?

Architecture

CTO

Can we implement it safely?

Architecture + risk

Executive

Is it worth pursuing?

Value + risk

Customer

Does it solve my problem?

Outcome

Investor

Can it become scalable?

Market + technology

Media

Why should people care?

Significance

A strong presenter does not change the truth.

The presenter changes the explanation layer.

6. The Communication Pyramid

Use four levels of information.

ONE SENTENCE Core proposition ▲ │ ONE IDEA Main argument ▲ │ ONE DIAGRAM How it works ▲ │ TECHNICAL DETAIL Evidence / equations / data

The audience should be able to understand the concept at multiple depths.

7. The One-Sentence Test

Before building a presentation, complete this sentence:

"This work demonstrates that __________, which matters because __________."

For example:

This work demonstrates that RAG-based diagnostic reasoning can combine vehicle service knowledge with real-time OBD data, which matters because technicians need both machine data and contextual repair knowledge.

If this sentence cannot be written clearly, the presentation probably lacks a clear central proposition.

8. The Problem–Evidence–Implication Model

A powerful technical narrative is:

Problem→Evidence→ImplicationProblem \rightarrow Evidence \rightarrow Implication

Problem

What is difficult?

Evidence

What did you discover?

Implication

What can now be done differently?

This prevents the presentation from becoming a technology catalog.

9. Ethical Persuasion

Persuasion is unavoidable whenever a presentation asks someone to:

  • fund research;
  • approve a project;
  • adopt technology;
  • purchase a solution;
  • collaborate;
  • change architecture;
  • support a proposal.

The ethical approach is:

Persuasion=Evidence+Relevance+Clarity+TrustPersuasion = Evidence + Relevance + Clarity + Trust

Not:

Persuasion=Hype+PressurePersuasion = Hype + Pressure

The presenter should never deliberately conceal material limitations simply to make the proposal more attractive.

10. The Chandini Persuasion Framework

The framework introduced earlier can be used as a practical mnemonic:

C — Context

What is happening?

H — Human/business consequence

Who is affected?

A — Authority

Why should the audience trust the presenter?

N — Need

What capability is required?

D — Demonstration

What evidence supports the proposition?

I — Implication

What does the result mean?

N — Next step

What should happen next?

I — Invitation

How can the audience participate?

This produces a progression:

Context→Need→Evidence→Meaning→ActionContext \rightarrow Need \rightarrow Evidence \rightarrow Meaning \rightarrow Action

11. Combining Logos, Ethos and Pathos

Classical persuasion can be translated into engineering language.

Logos — logic

Use:

  • data;
  • equations;
  • benchmarks;
  • experiments;
  • models;
  • comparisons.

Ethos — credibility

Use:

  • expertise;
  • experience;
  • publications;
  • prototypes;
  • validation;
  • transparent limitations.

Pathos — significance

Explain:

  • why the problem matters;
  • who benefits;
  • what changes;
  • what opportunity exists.

For scientists, pathos does not mean emotional manipulation.

It means explaining human and societal significance.

12. The HBR-Inspired Executive Presentation Principle

The HBR tradition of business communication emphasizes a critical difference between providing information and communicating a persuasive business message.

For technical professionals, the practical lesson is:

Do not make the audience discover your conclusion. Lead them through the reasoning.

Instead of:

  1. background;
  2. literature;
  3. methodology;
  4. architecture;
  5. data;
  6. conclusion;

consider:

  1. problem;
  2. proposition;
  3. evidence;
  4. implications;
  5. decision.

Technical depth can remain available in the supporting material.

This is especially important when communicating with executives who do not need every implementation detail to make the initial decision.

13. The Pyramid Principle for Engineers

A useful structure is:

Answer first

What is the conclusion?

Supporting arguments

Why?

Evidence

What proves it?

Detail

How exactly?

For example:

Proposition: The proposed architecture can reduce diagnostic latency by moving time-sensitive processing to the edge.

Then:

  1. Edge processing reduces network dependency.
  2. Local preprocessing reduces transmitted data.
  3. RAG handles deeper knowledge retrieval separately.
  4. Experimental measurements support the architecture.

The audience knows where the argument is going.

14. Build the Presentation Backward

Do not begin with:

"What slides should I create?"

Begin with:

"What should the audience understand or decide at the end?"

Then work backward.

Desired Decision ↑ Required Understanding ↑ Required Evidence ↑ Required Explanation ↑ Presentation

This is an engineering requirements-analysis approach applied to communication.

15. The Technical Presentation Architecture

A strong 20-minute presentation can follow this structure.

0–2 minutes — Problem

What is wrong with the current situation?

2–4 minutes — Proposition

What are you proposing?

4–7 minutes — Architecture

How does it work?

7–11 minutes — Evidence

What did you measure?

11–13 minutes — Results

What changed?

13–15 minutes — Limitations

Where does the solution not yet work?

15–17 minutes — Implications

Why does it matter?

17–19 minutes — Recommendation

What should happen next?

19–20 minutes — Conclusion

What should the audience remember?

16. Slide Design

A slide should normally communicate one major idea.

Weak title

System Architecture

Stronger title

The architecture separates real-time control from knowledge-intensive reasoning

The second title communicates the conclusion.

The diagram then provides evidence for that statement.

17. Use Diagrams as Thinking Tools

Engineers understand systems through diagrams.

Use:

  • block diagrams;
  • sequence diagrams;
  • state machines;
  • architecture diagrams;
  • signal-flow diagrams;
  • system boundaries;
  • data-flow diagrams.

For example:

Sensor │ ▼ Data Acquisition │ ▼ Preprocessing │ ├──────────────► Real-Time Control │ ▼ Knowledge Retrieval │ ▼ RAG / LLM │ ▼ Decision Support │ ▼ Engineer / Technician

The presenter should then explain why the boundaries exist.

18. Data Visualization

A graph should answer a question.

Bad:

Here are 17 performance measurements.

Better:

Does the proposed architecture reduce response latency?

Then show:

  • baseline;
  • proposed system;
  • measurement conditions;
  • uncertainty.

Every graph should have an interpretive sentence.

19. Communicating Equations

Do not simply display equations.

Explain:

What does it represent?

Why is it important?

What assumptions does it contain?

What changes if the parameters change?

For example:

Ploss=I2RP_{loss}=I^2R

The equation becomes meaningful when connected to:

Increasing current produces a quadratic increase in resistive loss, making current management important for high-power systems.

The communication is the interpretation.

20. Tell the Technical Story

A technical story can follow:

Situation

What exists today?

Problem

What doesn't work adequately?

Investigation

What did the research examine?

Discovery

What did the team learn?

Solution

What architecture or method emerged?

Evidence

How was it validated?

Implication

What does it enable?

Next step

What should happen now?

This is storytelling without sacrificing scientific rigor.

21. The OBD-AI Example

Consider an OBD-AI system.

Conventional technical presentation

OBD-II → CAN → MQTT → RAGFlow → vector database → Neo4j → LLM.

Technically informative, but incomplete.

Communication-oriented presentation

Vehicle diagnostic systems produce large quantities of machine data, but technicians also need contextual knowledge from service manuals, diagnostic procedures, historical faults, and component relationships. OBD-AI combines live vehicle data with grounded technical knowledge to provide contextual diagnostic assistance.

Now the audience understands:

problem → knowledge gap → solution → value.

22. Smart-Inverter Example

Instead of saying:

"We developed an AI-enabled smart inverter using PSCAD, MATLAB and SystemC."

Explain:

Distributed energy resources increasingly require intelligent control and monitoring. The research investigates how power-system simulation, embedded control, AI, and hardware–software co-design can be integrated into a smart-inverter architecture that can be validated before deployment.

The technology remains technical.

The significance becomes visible.

23. SystemC/TLM Example

Technology statement

SystemC/TLM provides transaction-level modeling.

Communication statement

SystemC/TLM allows architects to explore hardware–software partitioning at a higher abstraction level before committing to detailed RTL implementation, creating an opportunity to identify architectural problems earlier in the development cycle.

The second explanation communicates engineering consequence.

24. Handling Questions

Questions are not interruptions.

They are diagnostic information.

A difficult question often reveals:

  • an unclear assumption;
  • missing evidence;
  • an audience concern;
  • a different stakeholder priority.

Use the sequence:

Listen

Do not interrupt.

Clarify

"Are you asking about scalability or real-time performance?"

Answer

Give the shortest correct answer.

Evidence

Provide the measurement or reasoning.

Boundary

State what remains unknown.

This produces credibility.

25. The "I Don't Know" Strategy

One of the strongest technical answers is:

"We have not tested that condition yet."

Then add:

"Our current evidence covers X. The next experiment would test Y."

This is much stronger than inventing an answer.

Scientific credibility depends on recognizing the boundary between demonstrated knowledge and hypothesis.

26. Managing Objections

Do not treat objections as attacks.

Classify them.

Technical objection

"Does it scale?"

Evidence objection

"How was this measured?"

Economic objection

"What does implementation cost?"

Risk objection

"What happens if the AI produces an incorrect recommendation?"

Strategic objection

"Why should we build this capability?"

Then answer the appropriate question.

27. Public Relations for Scientists and Engineers

PR should translate verified technical work into accessible narratives.

A PR story should answer:

  1. What happened?
  2. Why does it matter?
  3. What evidence exists?
  4. Who benefits?
  5. What happens next?

Avoid turning a research result into an unsupported superlative.

Instead of:

"Revolutionary AI that will transform the automotive industry."

Prefer:

"The project demonstrates a RAG-based diagnostic architecture that combines live vehicle data with grounded service information."

The second statement is less sensational but substantially more defensible.

28. Technical Thought Leadership

Thought leadership is not simply publishing frequently.

It means developing a recognizable body of ideas.

For IAS-Research, themes could include:

  • AI engineering;
  • RAG systems;
  • hardware–software co-design;
  • SystemC/TLM;
  • embedded intelligence;
  • smart inverters;
  • EV systems;
  • digital twins;
  • MBSE;
  • engineering cybersecurity.

Repeated research around coherent themes creates intellectual positioning.

29. Research → White Paper → Presentation

The white paper and presentation serve different purposes.

Research paper

Primary purpose:

establish knowledge.

White paper

Primary purpose:

explain the technology and its implications to professional decision-makers.

Presentation

Primary purpose:

create understanding and enable interaction.

Sales/technical briefing

Primary purpose:

determine whether there is a practical engagement opportunity.

Therefore, one should not simply copy the research paper into slides.

30. IAS-Research Strategic Role

IAS-Research can become the research and intellectual authority layer.

Its communication pipeline:

Research Question ↓ Investigation ↓ Simulation / Experiment ↓ Validation ↓ Research Paper ↓ White Paper ↓ Conference Presentation ↓ Technical Thought Leadership

The presentation becomes part of the research lifecycle.

31. KeenComputer Strategic Role

KeenComputer becomes the engineering implementation layer.

Research ↓ Architecture ↓ Prototype ↓ Software Engineering ↓ Infrastructure ↓ Cybersecurity ↓ Deployment ↓ Operations

The company can translate research into practical customer outcomes.

32. KeenDirect Strategic Role

KeenDirect becomes the technology and product layer.

Engineering Requirement ↓ Hardware Requirement ↓ Component Selection ↓ Development Platform ↓ Computer / Network / Embedded Hardware ↓ Deployment

This creates a direct connection between engineering design and technology procurement.

33. The Three-Company Communication Architecture

IAS-RESEARCH Knowledge & Innovation │ │ ▼ KEENCOMPUTER Engineering & Implementation │ │ ▼ KEENDIRECT Products & Technology │ ▼ CUSTOMER │ ▼ FEEDBACK │ └────────► RESEARCH

This is more than a corporate structure.

It is a knowledge-to-market communication system.

34. Presentation as Business Development

A presentation can move through:

Attention→Understanding→Trust→Interest→Conversation→Assessment→Pilot→ProjectAttention \rightarrow Understanding \rightarrow Trust \rightarrow Interest \rightarrow Conversation \rightarrow Assessment \rightarrow Pilot \rightarrow Project

The critical point is that the presentation should not attempt to force every audience member into becoming a customer.

Its first objective is qualified understanding.

35. The Technical Sales Conversation

After the presentation, ask:

What part of this problem is most relevant to your organization?

Then:

How are you solving it today?

Then:

What limitations are you experiencing?

Then:

Would a technical assessment or prototype help determine whether this approach is appropriate?

This turns persuasion into collaborative problem-solving.

36. The Research Communication Flywheel

A mature organization can use:

Research ↓ Presentation ↓ Discussion ↓ Feedback ↓ Prototype ↓ Customer Deployment ↓ Case Study ↓ New Research

Every presentation becomes a source of new questions.

Every customer project can produce lessons for future research, subject to confidentiality and intellectual-property constraints.

37. The 5-Layer Message

Before presenting, prepare five versions of the same idea.

10 seconds

One sentence.

30 seconds

Problem + solution.

2 minutes

Problem + solution + evidence.

10 minutes

Full technical argument.

30 minutes

Deep technical defense.

If you cannot explain the idea at all five levels, the conceptual structure may need refinement.

38. The Engineer's Communication Stack

Think of communication as another engineering stack.

Layer 7 — Action Layer 6 — Business Value Layer 5 — Implication Layer 4 — Evidence Layer 3 — Architecture Layer 2 — Concept Layer 1 — Problem

The presenter can move up and down the stack depending on the audience.

An engineer may ask:

"How does it work?"

An executive may ask:

"What does it enable?"

Both questions concern the same system.

39. Presentation Quality Metrics

Presentations can be evaluated without judging the speaker personally.

Measure:

Clarity

Can the audience state the central proposition?

Retention

Can they recall the three major ideas?

Evidence

Can they identify what supports the claims?

Relevance

Can they explain why it matters to their work?

Action

Can they identify the proposed next step?

A simple post-presentation survey can measure these.

40. A Presentation Review Checklist

Before presenting, ask:

Message

  • Is the main proposition clear?

Audience

  • Does the presentation address their concerns?

Evidence

  • Are major claims supported?

Visualization

  • Can the architecture be understood?

Narrative

  • Is there a logical progression?

Credibility

  • Are assumptions and limitations disclosed?

Persuasion

  • Is the value proposition clear without exaggeration?

Business

  • Are cost, risk and implementation addressed?

PR

  • Could the central message be understood outside the technical community?

Action

  • Is the next step explicit?

41. The Final Technical Presentation Formula

A practical formula for engineers and scientists is:

Problem+Insight+Architecture+Evidence+Limitations+Implication+Action\boxed{ Problem + Insight + Architecture + Evidence + Limitations + Implication + Action }

The persuasive layer is:

Relevance+Credibility+Clarity+Trust\boxed{ Relevance + Credibility + Clarity + Trust }

Together:

Technical Evidence×Communication×Trust→Influence\boxed{ Technical\ Evidence \times Communication \times Trust \rightarrow Influence }

42. A Reusable Technical Presentation Template

Opening

The problem we are addressing is ________.

Significance

This matters because ________.

Proposition

Our approach is ________.

Architecture

The system works by ________.

Evidence

We tested this using ________.

Result

The measured result was ________.

Limitation

The current limitation is ________.

Implication

This means engineers can now ________.

Business relevance

For an organization, this could affect ________.

Next step

The appropriate next step is ________.

Closing

The central message is ________.

43. Master Communication Model

The entire tutorial can be condensed into:

TECHNICAL KNOWLEDGE │ ▼ CLARITY │ ▼ NARRATIVE │ ▼ EVIDENCE │ ▼ TRUST │ ▼ RELEVANCE │ ▼ PERSUASION │ ▼ DECISION │ ▼ ACTION

The most important principle is:

Do not simplify the science until it becomes inaccurate. Simplify the path by which the audience understands the science.

44. Strategic Conclusion

The modern technical organization needs more than research capability and engineering capability.

It needs the capability to communicate technical knowledge across boundaries.

Scientists need to communicate with engineers.

Engineers need to communicate with executives.

Technical leaders need to communicate with customers.

Research organizations need to communicate with industry.

Technology companies need to communicate with the public.

That creates a strategic role for presentation and persuasion that extends far beyond PowerPoint.

For the IAS-Research → KeenComputer → KeenDirect ecosystem, the communication model can become:

Research→Explain→Demonstrate→Persuade→Engineer→Deploy→Learn→Research\boxed{ Research \rightarrow Explain \rightarrow Demonstrate \rightarrow Persuade \rightarrow Engineer \rightarrow Deploy \rightarrow Learn \rightarrow Research }

IAS-Research.com establishes the research and intellectual foundation.

KeenComputer.com translates that foundation into engineering, software, infrastructure, AI, cybersecurity, and digital transformation.

KeenDirect.com connects engineering requirements with computing, embedded, networking, and technology products.

The presentation sits at the center of this ecosystem.

It connects knowledge to people, people to decisions, decisions to engineering, and engineering to business value.

Final Takeaway

The best technical presentation is not the one containing the most information.

It is the one in which the audience can accurately answer five questions when the presentation is finished:

  1. What is the problem?
  2. What did we learn?
  3. Why should we believe it?
  4. Why does it matter?
  5. What should happen next?

That is Presenting to Win for engineers and scientists:

Think rigorously. Explain clearly. Show evidence. Acknowledge uncertainty. Connect to value. Persuade ethically. Enable action.

References to add

  1. Harvard Business Review. HBR Guide to Persuasive Presentations. Harvard Business Review Press.
    Useful for structuring persuasive business presentations, understanding the audience, developing a compelling message, and moving an audience toward action.
  2. Duarte, N. (2008). slide:ology: The Art and Science of Creating Great Presentations. O'Reilly Media.
    Useful for presentation structure, visual communication, slide design, and transforming complex information into an understandable visual narrative.
  3. Duarte, N. (2010). Resonate: Present Visual Stories That Transform Audiences. Wiley.
    Relevant to the paper's discussion of technical storytelling, audience engagement, contrast, narrative structure, and presentation persuasion.
  4. Reynolds, G. (2020). Presentation Zen: Simple Ideas on Presentation Design and Delivery (3rd ed.). New Riders.
    Supports the principles of simplicity, visual hierarchy, audience focus, and eliminating unnecessary information.
  5. Gallo, C. (2014). Talk Like TED: The 9 Public-Speaking Secrets of the World's Top Minds. St. Martin's Press.
    Relevant to memorable technical communication, storytelling, emotional connection, and presentation delivery.
  6. Aristotle. On Rhetoric: A Theory of Civic Discourse. Translated by George A. Kennedy. Oxford University Press.
    Foundational source for ethos, logos, and pathos, which provide the classical foundation for the paper's ethical persuasion framework.
  7. Cialdini, R. B. (2021). Influence: The Psychology of Persuasion (New and expanded ed.). Harper Business.
    Relevant to understanding persuasion, credibility, social influence, commitment, authority, and decision-making. The principles should be applied transparently rather than manipulatively.
  8. Heath, C., & Heath, D. (2007). Made to Stick: Why Some Ideas Survive and Others Die. Random House.
    Useful for explaining why technical messages need simplicity, unexpectedness, concreteness, credibility, emotion, and stories.
  9. Patterson, K., Grenny, J., Maxfield, D., McMillan, R., & Switzler, A. (2012). Crucial Conversations: Tools for Talking When Stakes Are High (2nd ed.). McGraw-Hill.
    Relevant to technical disagreements, stakeholder discussions, objections, engineering reviews, and high-stakes decision-making.
  10. National Academies of Sciences, Engineering, and Medicine. (2017). Communicating Science Effectively: A Research Agenda. The National Academies Press.
    Important foundation for communicating scientific evidence to different audiences and understanding how people interpret scientific information.
  11. National Academies of Sciences, Engineering, and Medicine. (2016). Communicating Science Effectively: A Research Agenda. National Academies Press.
    Supports the paper's distinction between scientific evidence, audience needs, communication strategy, and public understanding.
  12. Alley, M. (2013). The Craft of Scientific Presentations: Critical Steps to Succeed and Critical Errors to Avoid (2nd ed.). Springer.
    Particularly relevant to the target audience of engineers and scientists, including organization, visual aids, technical explanations, and scientific presentation delivery.
  13. Kosslyn, S. M. (2007). Clear and to the Point: 8 Psychological Principles for Compelling PowerPoint Presentations. Oxford University Press.
    Useful for the paper's discussion of cognitive load, visual communication, attention, and information organization.
  14. Tufte, E. R. (2001). The Visual Display of Quantitative Information (2nd ed.). Graphics Press.
    A foundational reference for scientific graphs, quantitative visualization, data integrity, and avoiding misleading visual presentation.
  15. Tufte, E. R. (2006). Beautiful Evidence. Graphics Press.
    Relevant to the communication of evidence, scientific visualization, diagrams, and analytical reasoning.
  16. Feynman, R. P. (1985). Surely You're Joking, Mr. Feynman! W. W. Norton.
    Useful as a broader example of communicating complex scientific ideas through clarity, curiosity, concrete examples, and intellectual honesty.
  17. Popper, K. R. (2002). The Logic of Scientific Discovery. Routledge.
    Provides philosophical background for falsifiability, testing, evidence, and distinguishing scientific claims from unsupported assertions.
  18. Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
    Relevant to understanding cognitive biases and why technical communicators must be careful about framing, assumptions, uncertainty, and decision-making.
  19. Heath, R. L., & O'Hair, H. D. (Eds.). (2009). Handbook of Risk and Crisis Communication. Routledge.
    Relevant to technical risk communication, organizational communication, public relations, crisis communication, and communicating uncertainty.
  20. Cutlip, S. M., Center, A. H., & Broom, G. M. (2006). Effective Public Relations (9th ed.). Pearson.
    Provides a classical foundation for public relations, stakeholder communication, reputation, media relations, and organizational communication.