“The most powerful person in the world is the storyteller.” — Steve Jobs

In the early 2000s, Nokia dominated mobile phones. Its strategy, built on exceptional hardware engineering and global supply-chain execution, worked flawlessly until 2007. The company didn’t fall because its engineers lacked insight. It fell because the organization couldn’t convert critical technical knowledge into strategic intent. The signals were present; the translation mechanisms were not.

Nokia’s software teams had long recognized that Symbian’s architecture was reaching its limits. It was fragmented, costly to evolve, and increasingly misaligned with the emerging touch-driven experience. Alternative platforms such as Maemo and later MeeGo were being explored, and the technical risks were well understood within engineering. But these concerns were filtered through a hardware-first culture that interpreted platform limitations as minor technical defects, not as threats to the business model. The communication path from “this architecture will constrain what the business can do” to “this requires a strategic shift” simply wasn’t there.

At the same time, senior leadership continued to optimize short-term device metrics. They still viewed the competitive landscape as a handset battle rather than an ecosystem battle, and the implications of Apple’s and Google’s platform strategies never translated into a unified architectural or strategic response. Nokia’s organizational structure created a communication gradient: technical truths lost meaning as they travelled upward, and strategic signals failed to reorient investment, priorities, or direction.

Within five years, the world’s leading mobile manufacturer was forced to exit the handset business, not because it lacked capability, but because it lacked the ability to translate insight into coherent action. This chapter focuses on the story gap: how to communicate strategic needs clearly, how to ensure signals travel across the organization intact, and how to avoid the silent failures that undermine strategy long before the market ever does.

In this chapter, you’ll learn how to:

• Communicate strategic intent with clarity, ensuring technical insight translates into decisions rather than confusion

• Structure a coherent strategic narrative using proven frameworks to move from context to conclusion

• Develop presentation material that supports decision-making, not just information sharing

• Deliver your message effectively, guiding senior stakeholders from understanding to commitment

You will use these skills to close the story gap: translating strategy, architectural intent, and plans into a narrative that enables decisions. Not more slides, but a clear line from context to conclusion, so leaders understand the trade-offs, commit to a direction, and act.

How to Be An Effective Communicator

Delivering a technology strategy is not simply an act of presenting information; it is an act of leadership and influence. The best strategy in the world will fail if the communicator lacks clarity of purpose or the ability to authentically connect with the audience.

Clarify your objective

Before you open a slide deck or write a single email, you must answer one question with absolute, non-negotiable clarity: What is the one thing I need the audience to believe or do when I stop speaking or reading? This is the foundation of strategic communication. Without a single, clearly defined objective, your message will lack focus, and your audience will leave confused about the desired next step. Your objective should never be passive, such as “to inform the Board” or “to update the team.” It must be an action verb tied to a measurable outcome. Consider the examples in table 2-1 where we take a passive goal and turn it into an active objective.

When you define your objective down to the ‘one thing,’ you achieve two crucial results:

1. Elimination of Noise: Every slide, chart, and word you use must directly serve that single objective. If a piece of data doesn’t help you achieve the objective, it belongs in the appendix, or nowhere at all.

2. Forcing the Answer: By knowing the desired action, you structure your entire presentation to lead logically and inevitably to that conclusion. Your presentation becomes a persuasive roadmap, not a rambling document review.

Master the three modes of Persuasion

As an IT leader, you must consciously deploy all three modes to secure buy-in. Relying solely on data (Logos) is rarely enough; you must also establish your credibility (Ethos) and connect your strategy to the organization’s goals and fears (Pathos). The following subsections detail how to weave each of these essential appeals into your strategic narrative to maximize influence and drive action.

Ethos: Establishing Credibility and Character

Ethos is the appeal to authority, credibility, and trust. In executive communication, this is often the most critical mode, as the audience is primarily buying into you as the reliable leader of the technology strategy, not just the merits of the plan itself. To show credibility you must:

Demonstrate Expertise, Not Jargon: Your credibility must be established through competence. While your strategy should be technically sound, your communication must be free of technical jargon. Translate complex concepts (e.g., “decoupled architecture”) into business results (e.g., “faster speed to market”). If you can’t explain things in a simple, down to earth manner that a 5 year old can understand then you must question if you truly understand yourself.

Pathos: Connecting to Organizational Emotion and Value

Pathos is the appeal to emotion, values, and shared organizational goals. While the C-suite may seem purely rational, all major decisions are influenced by underlying motivations: fear, opportunity, competitive desire, and security. To connect to your audience, you must:

Speak the Language of Pain and Opportunity: Connect your strategy to the things the executive team cares most about: revenue growth, competitive positioning, profit and operational risk. Frame a system modernization not as a technical upgrade, but as “the strategic pivot necessary to unlock 20% market share growth” or “the proactive shield against a catastrophic security event.”

Logos: Providing Logic, Data, and Evidence

Logos is the appeal to logic, facts, and reason. This is the traditional comfort zone for technical leaders, but it must be used strategically to support the narrative, not lead it.

Data Supports the Conclusion: Ensure all data is used to substantiate your strategic conclusion, following the pattern: “We must do X (strategy), because of Y (data) .” Never start with the data and ask the audience to draw their own conclusion.

Focus on Business Metrics: Use charts and graphs that display financial or operational outcomes (e.g., reduction in customer churn, accelerated time-to-market, mitigated financial exposure). Technical metrics (e.g., server uptime, latency) should only be used if they have a clear and immediate translation to a business KPI.

How To Structure A Story

Effective communication is not about volume; it’s about structure. When presenting IT strategy to the Board or executive committee, your goal is not merely to convey information, but to command attention and compel action. This requires structuring your message in a way that aligns with how executive minds process information, starting with the conclusion first.

• Frame the Problem (The Story): We begin by using the Situation, Complication, Question, Answer (SCQA) model. This forces you to establish the organizational context, define the precise challenge, and articulate the key question your strategy solves before you present the solution aka The Answer. This is how you gain immediate buy-in.

• Structure the Solution (The Answer): We then use the Pyramid Principle to build the body of the answer. This flips traditional communication on its head, ensuring you lead with your main conclusion and support it with clear, logical arguments. The Pyramid Principle is used to systematically defend your Answer, going into more detail the further down you go.

• Close the Argument: You summarize the key impacts, risks and present the Final Ask.

How to Structure The Story : SCQA

The SCQA framework provides a persuasive narrative arc required to capture and hold an executive audience’s attention. Executives are less interested in history and more interested in the future, specifically, how to solve the most pressing problems. SCQA quickly guides an audience through a logical story and moves past accepted facts to the specific challenge that necessitates your recommendation.

The model works by creating tension and immediately resolving it:

1. S - Situation (The Context)

• Purpose: Establishes common ground. This is a non-controversial, shared fact that everyone in the room accepts. It sets the baseline reality.

• Example: “Our company is currently the market leader in affordable home furnishings, driven by our global scale and physical store presence.”

2. C - Complication (The Challenge)

• Purpose: Introduces the tension or the pain point that disrupts the Situation. This is the specific problem your IT strategy is designed to solve (e.g., rising costs, competitor threat, technological obsolescence).

• Example: “However, our fulfillment cost per order is £22, which is unsustainable, and our legacy systems prevent us from achieving the £17 target necessary to compete on cost.”

3. Q - Question (The Inquiry)

• Purpose: Articulates the strategic question that the Complication raises. This question must be the one that your entire presentation answers.

• Example: “Therefore, how must IT modernize our operations to enable massive global scale and reduce the fulfillment cost per order from £22 to £17?”

4. A - Answer (The Conclusion)

• Purpose: States the solution immediately. This is the top of your Pyramid, the single strategic objective you want the audience to approve.

• Example: “We recommend immediate investment in the Modern Customer & Operations Stack to deliver system-driven cost reduction and customer empowerment.”

The power of SCQA is that it communicates not just what you are recommending, but why the recommendation is strategically necessary right now. Importantly this process shows your working, and the underlying assumptions that have driven your recommendation.

How to Structure The Answer/Argument: Pyramid Principle

Once the context is established using SCQA, you use the Pyramid Principle (developed by Barbara Minto) to structure the supporting arguments for your answer (the ‘A’ in SCQA). This principle ensures your communication is top-down, maximizing clarity and retention. This structure is essential because it allows you to lead with the conclusion and adapt the depth of the conversation instantly, enabling a perfect elevator pitch. Figure 2-4 shows the depth of information and where it can be used.

• Level 1: The Answer/Conclusion (The Top): This is the single, overarching idea or recommendation. It should be the first sentence spoken. (Example: “We must transition to Cloud ERP.”) This level provides the instant executive summary.

• Level 2: Key Supporting Arguments (The Pillars): These are the 3-5 major, distinct reasons why the conclusion is correct. They must be logical, mutually exclusive, and collectively exhaustive (MECE) - we will revisit this concept in Chapter 4. These form the “pillars” holding up the conclusion. Levels 1 and 2 together form your effective 60-second elevator pitch. (Example: Pillar 1: Reduce TCO and risk. Pillar 2: Enable scalable global growth. Pillar 3: Improve data governance and compliance.)

• Level 3: Data and Supporting Points (The Base): This is the lowest level where you place the detailed evidence, numbers, and data that substantiate each of the Level 2 arguments. Moving deeper into this level provides the exhaustive detail and proof required for skeptical audiences. You only present this data if asked, or if it is crucial for a specific point. (Example: Data supporting Pillar 1: “TCO is reduced by 35% over five years, based on vendor comparison data.”)

How to Structure Your Close

Your close is not a recap, it is the moment where strategy turns into decision. Everything before this point has been designed to earn the right to ask for commitment. Treat the close as a deliberate, structured move, not an afterthought.

A strong close does three things, in order:

• It demonstrates control of risk.

• It reinforces the logic of the recommendation.

• It forces a clear decision.

Demonstrate Control of Risk

Well-structured risk slides share three characteristics:

• They focus on material risks (financial, operational, strategic), not hypothetical edge cases

• They quantify impact where possible

• They show active mitigation, not passive acceptance

Reinforce the Logic Using the Rule of Three

People retain structure better than detail. Use the Rule of Three to restate your argument in its most distilled form, anchored to the logic you have already established.

• Re-state the Core Problem: Briefly return to the Complication from your SCQA. Remind the audience why the status quo is no longer acceptable.

• Re-state the Solution Pillars: Summarize the three primary supporting arguments (Level 2 of the Pyramid). These should map cleanly to the main branches of your logic tree.

• Re-state the Required Action: Repeat the single objective you defined at the start — unchanged, unsoftened, and explicit.

This repetition is not redundancy; it is reinforcement. You are ensuring the decision frame is unmistakable.

Force the Decision with a Clear Ask

The close must end with commitment, not conversation. You are not asking whether the audience understands, you are asking whether they agree to act. Therefore end by explicitly answering the strategic question you posed at the beginning, then immediately follow with a decision-forcing ask.

• Final Statement: Address the Question in SCQA directly. State how your recommendation resolves it.

• The Final Ask: Ask a question that requires a decision or commitment, not commentary. Avoid open-ended closers like “Any questions?”, they signal that the moment for action has passed.

Developing Your Deck

A brilliant story structure can still fail if it’s trapped within a confusing or overcrowded presentation. The slide deck is the final, tangible output of your communication strategy, serving as both a presentation aid and a standalone decision-document. The objective of “Developing Your Deck” is to ensure your visual communication amplifies, rather than dilutes, your strategic message.

One Message Per Slide

The single greatest enemy of executive comprehension is the overloaded slide. Each slide should represent a single claim that supports the overall argument. If a slide attempts to cover multiple branches at once, it is no longer defensible or memorable. This discipline slows the presenter but dramatically accelerates executive understanding. The audience always knows where they are in the argument and why this point matters.

Use the claim at the top of the branch as the slide title. This ensures that an executive who spends only five seconds scanning your deck can read the titles alone and immediately understand the full strategic narrative and its conclusion.

Avoid vague titles such as “Current State” or “Next Steps.” Every title must state a position, decision, or implication.

Prep the audience before hand

Never let your strategic presentation be the first time the decision-makers see your key recommendations. The executive meeting is for discussion and decision, not for initial orientation. Effective presentation starts days, or even weeks, before you step into the room. As radiohead sings, ensure there are no alarms and no surprises at the presentation.

• Pre-Wire the Key Stakeholders: Meet with the most influential audience members (e.g., the CEO, CFO, and key business unit leaders) individually. Use this time to secure their initial buy-in on the most controversial or high-investment points.

• The Goal: Isolate potential objections privately so the executive meeting contains no surprises.

• The Benefit: When these stakeholders nod or offer supportive comments during the final presentation, they validate your strategy for the rest of the room.

• The Executive Summary is Mandatory: Send a concise, one-page executive summary (including your SCQA conclusion and Level 2 Pyramid Pillars) 24–48 hours before the meeting. The main presentation deck should be sent only to those who request the detail.

• The Goal: Allow the audience to process the conclusion and prepare questions in advance, rather than struggling to understand the core premise during the meeting.

• Define Your Desired Next Step: Conclude your pre-briefing with a clear statement of the action you need: “My objective for Tuesday is to secure approval for Phase 2 funding. Will you support that objective?” This forces commitment and ensures you have allies in the room.

Key Takeaways

Effective strategic communication is not about presentation skill or storytelling flair, it is about translating intent into decisions. The role of the IT leader is to ensure that critical insight travels through the organization intact, without being diluted, distorted, or lost.

The core principles to remember are:

• Clarity precedes persuasion: Before you communicate, be explicit about the single decision or action you need. If you cannot articulate this clearly, no amount of data or storytelling will compensate.

• Structure beats volume: Executives do not want more information; they want clear reasoning. Use structured narratives to move from context to challenge to answer, and support conclusions with logically ordered arguments.

• Lead with the answer: Strategic communication is top-down. State the conclusion first, then defend it. This builds confidence, accelerates understanding, and allows debate to focus on what truly matters.

• Logic creates credibility: A well-constructed logic tree ensures every claim is defensible and every slide earns its place. If the argument cannot be explained verbally without slides, the thinking is not yet complete.

• Persuasion requires balance: Data alone is insufficient. Successful communication integrates credibility (Ethos), emotional relevance (Pathos), and logical evidence (Logos) to secure genuine commitment.

• Delivery is part of the strategy: How you present, pace, pauses, confidence, and control, directly affects whether your strategy is trusted and acted upon.

When these principles are applied consistently, communication stops being a reporting exercise and becomes a leadership tool. This is how IT leaders shape strategic intent, secure alignment, and turn insight into coherent action.

What You Should Do Next

• Define the One Decision You Need: Before opening PowerPoint, write down the single action you want the audience to take. If you can’t express it as a clear decision or commitment, your story is not ready.

• Write the Story Before the Slides: Use SCQA to frame the problem and articulate the Answer. Then outline your supporting arguments using the Pyramid Principle. Do this on paper or a whiteboard first. Slides come last.

• Pressure-Test the Logic: Read your story aloud to a trusted colleague. If the logic feels forced, circular, or defensive, refine the structure — not the data. Weak stories are rarely fixed by more slides.

• Design for Skimming, Not Reading: Draft your deck and read only the slide titles in sequence. If the titles don’t tell a complete, persuasive story on their own, rewrite them until they do.

• Practice the Close: Rehearse your final two minutes until the call to action feels natural and confident. Know exactly how you will ask for approval, alignment, or sponsorship — and be comfortable with silence after you ask.

Treat every strategic interaction as a rehearsal for the next one. Over time, these techniques stop feeling like frameworks and start becoming instinct. That’s when communication shifts from something you do to something you lead with.

We will use these techniques when we create an example strategy, architecture initiative and strategic plan deck in parts 2, 3 and 4.

Scott Millett is refining this series—and the book—as we go. What resonated, what needs sharpening, and what gaps did you spot? Share your thoughts in the comments—we’d really appreciate it.

Leave a comment

Each installment is a light, web‑ready adaptation of an original chapter submitted by Millett, giving readers the opportunity to preview the knowledge that will be included in the final book. In return, we invite you to leave constructive feedback to improve the book and the chapter in the comments below and follow Millet on this adventure.

Let us begin.

“The main thing is to keep the main thing the main thing.” — Stephen Covey

If you’re a CTO, CIO, or IT leader, you’ve probably been told to “be more strategic” and “align with the business.” That’s easier said than done. We’re experts in technology, but many of us lack the mental models to turn abstractions like strategy and digital transformation into actionable plans. When the board or CEO asks for a long‑term roadmap that shows how technology enables growth, we’re left wrestling with vague terms and questions we were never taught to answer.

Even when a technical plan exists, we often fail to articulate it. Communication either dives too deep into detail or floats into abstraction. The result is the same: we don’t explain technology choices in a way that shows how the business competes and wins.

This gap—between creating a strategic plan and communicating it—sits at the heart of this article. What follows is the moment that forced a shift from running systems to defining direction, shaping architecture, and delivering strategic impact, and the journey that led to the framework at the center of this work.

The situation

I joined a company as its first IT Director and immediately entered a due‑diligence process. Three months later we were acquired by a private‑equity owner. The process was intense, but it provided a deep understanding of databases, infrastructure, security, risk, applications, and the team. The IT landscape wasn’t perfect—no company’s ever is—but it felt manageable.

Then came the Tuesday morning email: “The 100 Day Plan.” Among the requests:

“We need a comprehensive IT strategy aligned with our growth objectives. Present initial thoughts next month, with a full strategic plan in 100 days.”

The complication

I knew technology inside out. Strategy—linking technology to business goals—was another story. Like many would, I turned to Google. Frameworks, templates, and roadmaps abounded, but they felt generic and disconnected from our situation.

I produced a polished deck, full of technology roadmaps, maturity assessments, and investment priorities.

In the boardroom, the CEO flipped through the pages and paused.

“This all looks thorough,” he said. “But what problem are we trying to solve?”

I froze. I had built a deck of technology solutions without defining the problems they solved—outputs, not outcomes. Activity, not impact. I was being seen exactly as presented: a capable technology manager outlining projects, not a strategic leader proposing investments to deliver impact. There was no visible link between technology investment and business outcomes.

Figure 0.1: The gap between technology output and business impact

The question

That single question—What problem are we trying to solve?—exposed deeper challenges:

• How does an IT leader become a strategic leader?

• How do you connect technology to competitive advantage—in practice, not theory?

• How do you explain those connections so boards and executives immediately understand?

These became the guiding focus.

The answer

IT strategy is business strategy. Every technology decision is a business decision about how the organization competes, operates, and delivers value. Consolidating systems across brands isn’t just integration; it’s a choice about whether to compete as one company or many. Investing in real‑time analytics isn’t just faster reporting; it’s enabling dynamic, personalized pricing that affects competitiveness and margins.

Most IT leaders struggle to make that connection. We know the technology, but not always how to translate it into advantage. That struggle appears as recurring structural gaps that make it impossible to answer the CEO’s question. Left unaddressed, they lead to outputs without outcomes—technology choices that don’t create business impact.

The four gaps:

• The Understanding Gap: The disconnect between business goals and IT’s strategic contribution. This is the inability to answer “What problem are we trying to solve?” and to tie IT choices to how the business competes and wins.

• The Translation Gap: The disconnect between IT’s strategic contribution and the enabling architecture. High‑level intent never becomes coherent design, resulting in fragmented, fragile systems.

• The Focus Gap: The disconnect between enabling architecture and impactful plans. Investments aren’t prioritized by measurable strategic impact, producing sprawling, low‑value project portfolios.

• The Communication Gap: The inability to clearly communicate strategic intent, architectural vision, and execution plans. This multiplies every other failure by eroding buy‑in and funding.

Together, these gaps break the link between IT action and business success: strategies that look impressive on paper but don’t change results; delivery plans that are busy but directionless. Closing them transforms IT leadership—from order‑taking to shaping direction, driving advantage, and turning outputs into outcomes.

Figure 0.2 — The four gaps that lead to a lack of business impact

Closing the Gap

That boardroom moment made something clear: a better presentation wasn’t enough; a better way of thinking was needed. I began sketching how strategy, architecture, and planning connect. Over time—across board presentations, diligence cycles, acquisitions, and strategy sessions—that evolved into the DSD Loop: Define → Shape → Deliver. It is a practical way to connect strategy, architecture, and planning through a consistent story, ensuring the CEO’s question can be answered at every stage.

Figure 0.3 — Addressing gaps using the Define–Shape–Deliver Loop to deliver business impact

Table 1: The DSD loop and its impact

Why this approach works

The challenge isn’t intelligence or effort; it’s starting in the wrong place. When you define business intent first, shape architecture second, and deliver last, you stop reacting and start directing. You move from “What do you need from IT?” to “Here’s how technology will help us win.”

The DSD Loop deliberately puts delivery last because many failures start with technology first. That thinking leads to “AI is the solution; now find a problem,” or building data platforms before deciding which decisions data should inform. Start with intent, then shape the architecture, and delivery becomes straightforward—the red thread links every technical choice to a strategic outcome.

Who this is for

• CIOs/CTOs seeking to be seen as strategic enablers, not cost centers.

• CEOs/COOs who know digital transformation is essential but need signal over noise.

• Consultants who help clients cut through complexity.

• Students and practitioners who want to see how technology and business strategy intersect.

This approach won’t hand over a magic formula or prescribe specific technologies. Context matters. What it offers is a way to strengthen critical thinking, creativity, problem‑solving, leadership, and influence—so outcomes improve.

Why listen

This is grounded in lived experience: the Tuesday email, the frantic searching, the hollow slide deck, and the CEO’s question. Since then came boardrooms, due diligence, investor conversations, and most importantly, consistent business impact—paired with deliberate study of how strategists frame choices, tell stories, and create results.

How the book and series is structured

Figure 0.4: What you will learn by the end of the book and series

We’ll walk from a standing start to strategic momentum by Day 90, unpacking each stage of the DSD Loop. The techniques aren’t new inventions; they’re proven patterns used in context so strategic intent flows through design and into delivery.

• Part I: Understanding the Fundamentals — Strategy as explicit choices to win; architecture as consequential design for coherence; planning as prioritization anchored to outcomes.

• Part II: Day 0–30 — Define an IT Strategy that Wins — Establish the directional why and strategic what; translate business goals into capability enhancements and IT actions; culminate in a communication plan that ties every action to business success.

  

• Part III: Day 31–60 — Shape the Target Architecture — Move from intent to socio‑technical design: technology, teams, operating model, and governance; understand the AS‑IS, outline initiatives, and tell the story of value.

  

• Part IV: Day 61–90 — Deliver an Impactful Plan — Prioritize by value and constraints; form the strategic roadmap and short‑term operational plan; communicate for investment sign‑off by focusing on measurable impact.

  

• Part V: Evolving the Strategy (Beyond Day 90) — Treat strategy and architecture as living; adopt adaptive strategy and evolutionary architecture for continuous planning.

Building Critical Skills for Future Success

Based on the World Economic Forum’s Future of Jobs Report (Jan 2025), the most critical skills cluster into four categories:

1. Cognitive & Problem‑Solving — Analytical thinking, complex problem‑solving, critical thinking, creativity, reasoning.

2. Technical & Digital Fluency — Technology use/monitoring/control; design and programming.

3. Interpersonal & Social Influence — Leadership and social influence.

4. Self‑Management & Learning — Active learning, resilience, stress tolerance, flexibility.

This series emphasizes translating technical strength into strategic outcomes by developing cognitive, interpersonal, and self‑management capabilities. Each phase of the DSD Loop builds the following:

• Define (Day 0–30): Critical thinking to structure the problem space; effective communication to secure alignment; creativity to challenge the status quo.

• Shape (Day 31–60): Creative reasoning using visual mapping to design enabling architecture; translate technical vision into non‑technical language; active learning to derive coherent, evolutionary design principles.

• Deliver (Day 61–90): Analytical prioritization to justify investment; storytelling to close the communication gap and influence stakeholders; resilience to manage ambiguity and maintain roadmap integrity.

How to use this playbook

This is a playbook, not a textbook. The goal is progress, not perfection—guided by the DSD order: Define → Shape → Deliver. Most IT strategies fail by starting with delivery before intent and architecture.

Use it to:

• Build a three‑year strategic plan for investment cases and board planning.

• Focus on a specific objective (e.g., a new product line, a new market, a new digital service).

• Prepare a board presentation that tells a clear story about how technology drives positive business impact.

Whichever path you take, begin with intent, then shape how technology and teams will enable it, and only then plan and deliver the work. You don’t have to perfect everything at once. Identify the next logical step in your Define–Shape–Deliver journey, apply it, learn, and return to refine. Effective strategy evolves through a continuous loop—each cycle sharper and more connected to business outcomes than the last.

Up Next: Beginning with the fundamentals

Before applying the framework, it is important to establish the basics. Most IT strategy failures don’t happen because of technology; they happen because leaders misunderstand what strategy is, how it connects to architecture, and why traditional planning falls short. That’s where we will begin in the next article in the series: strategy, architecture, and planning as practical tools for better decisions.

Scott Millett is refining this series—and the book—as we go. What resonated, what needs sharpening, and what gaps did you spot? Share your thoughts in the comments—we’d really appreciate it

Leave a comment