Opening Remarks

Listening Recap

Multiple practitioners.
Multiple positions.

Synthesizing the insights means analyzing multiple data points.
It does not mean finding one true opinion.

It’s tempting to listen to different people and average the perspectives “to something that reflects what probably most people think”. That means you’ll lose the most useful part of what you just collected: the variety. When two accounts disagree, it tells you something about the phenomenon itself, not just about the people involved.

Learning Outcomes

By the end of this unit, you will be able to:

Elicit and structure diverse practitioner claims through live capture and open coding, without collapsing them into one averaged account.
Identify the disciplinary lens, technical, behavioral, organizational, or economic, implicit in a claim, and tag it by kind: practice, challenge, or question.
Cluster claims into a candidate phenomenon and knowledge problem, integrating multiple perspectives into one problem framing while keeping the tensions between them visible.

Perspectival Variety

Pluralism in Practice

Who speaks from which position?
What assumptions about the world are embedded in each account?

Every practitioner you heard from occupies a structural position, a role, a department, an incentive structure, a stake in the outcome, and that position shapes what they notice, what they treat as obvious, and what they leave unsaid. A vendor and a client describe the same rollout differently because their positions make different things visible. Neither one is lying.

Treat each input as evidence of a position, not just a claim. Ask, for each: from where does this person see the challenge, and what does that perspective let them see that others cannot?

Epistemic Pluralism in IS

The disciplines below study the same phenomenon, each from a different angle.

Scholars in information technology, software engineering, and computer science study the technical and computational attributes of digital technology as such.
Scholars in behavioral, cognitive, and psychological sciences study individuals’ exposure, use, appropriation, and general behaviors around digital technology.
Scholars in organisational science, management, and business study how corporate environments shape, and are shaped by, digital technology.
Economists study the large-scale effects of digital technology diffusion and innovation on organisations, markets, and societies.

This is the same pluralism you just met in your industry inputs, expressed in academic research instead of practitioner accounts (Recker, 2021b). IS research is open to methodological and paradigmatic pluralism because the discipline studies people and technology together, and no single lens (technical, behavioral, organisational, economic) captures the whole phenomenon on its own.

Practical Mapping Advice

When you map your industry inputs, try tagging each one with which of these four lenses it is implicitly using.

A practitioner talking about integration architecture is reasoning technically. One talking about adoption resistance is reasoning behaviorally. One talking about governance and incentive redesign is reasoning organisationally. One talking about market-level competitive pressure is reasoning economically.

Most inputs will actually mix two or three lenses without saying so.

Contradictions as Signal

Treat unexpected contradictions between inputs as signals worth investigating.

We will return to this idea in U4: Topic, where we will discuss the full criteria for a good topic.

For now, the practical version: when two of your inputs describe the same fact pattern but draw opposite conclusions from it, or when a claim someone makes does not fit what a different practitioner told you, write down both positions and where they diverge Colquitt & George (2011) call this kind of divergence a “breakdown,” and treat it as more interesting than a topic that is already obvious to everyone in the room.

Notes and Summary

Live Capture

You can’t transcribe live; create mnemonic triggers instead: so-called jottings

Jottings are brief, in-the-moment notes that serve as mnemonic triggers to reconstruct full, vivid fieldnotes later (Emerson et al., 2011): cryptic keywords, vivid snippets of dialogue, and sequences, not polished prose.

Capture in vivo phrasing: verbatim snippets and indigenous terms, not your own summaries.
Note their role or context in a few words.
Flag anything that surprises you, or contradicts an earlier talk, immediately.

Example

CISO fin.serv. — no auto, human OKs every action. slow but safe??

Jottings are deliberately incomplete. Writing full sentences while someone is still talking costs you the next claim. Expand jottings into the four-step structured note within hours, while memory can still fill in the gaps jottings leave behind.

Suggested Tools

Paper notebook or index cards work well: no charging, no app-switching, and you can keep looking at the speaker instead of a screen. A plain note-taking app (Notion, Obsidian, or even a text file) works too if typing is faster for you. Voice memos are an option only if the speaker has agreed to being recorded; check before you record.

In this module, I ask you to use pen & paper, also to not get distracted and stay focused.

Structured Notes

You need a repeatable way to turn your jottings into something you can compare across talks.

Capture the claim: what, specifically, did this person say, in close to their own words?
Tag the kind: is this a practice claim (what they do, or how they approach the challenge), a challenge claim (what puzzles them, an unresolved problem), or a question claim (something they ask, or clearly imply, without answering it themselves)?
Attribute the position: what role or vantage point plausibly shapes this claim?
Flag tensions: does this claim sit comfortably with, or contradict, another input you have already noted?

Example

Claim: Every agent action needs human sign-off before it executes.
Kind: practice
Position: Financial services CISO
Tension: none yet, this is the first input touching this issue

This is a deliberately lightweight form of open coding (Strauss & Corbin, 1998), one pass per input, done shortly after the talk while your jottings are still legible and the context is fresh. You are not building a formal codebook yet; that level of rigor comes later, in your systematic review. Working from jottings and memory instead of a transcript is a real adaptation: qualitative researchers open-code recordings and transcripts, while you open-code what you managed to jot down live, so capture quality matters even more here than it would with a recording to fall back on.

Do this individually, right after each industry input, while your jottings are still fresh. Structuring notes three weeks later, once the jottings have gone cold, reintroduces exactly the kind of unexamined assumption this exercise is meant to surface.

Suggested Tools

A spreadsheet (Google Sheets, Excel), one row per input and one column per field, lets you sort and filter later, by kind, by position, or by whatever you flagged as a tension. It only helps if you fill in the judgment calls, kind and tension, rather than just transcribing the claim; a spreadsheet of unexamined claims is still just a list. A plain note-taking app (Notion, Obsidian, or even a text file) with one entry per input works just as well, and keeps everything in one place if you plan to cluster inside the same tool later.

Map-of-Perspectives

Identifying Candidate Topics

Across your inputs on agentic AI and cybersecurity, only some of what you heard will obviously relate to something else you heard. Building the map means finding which claims belong together, and naming the phenomenon and knowledge problem they point to.

Three passes got you here: jottings captured each talk live, open coding structured and tagged each input shortly after. This pass compares structured notes across all the inputs you have so far.

Raw Inputs

Contributions from the field take the form of practical examples, challenges, and sometimes even the questioning of assertions.

It is your task to identify questions that give rise to further research.

The inputs you got from open coding:

Practice claim: what they do, or how they approach the challenge;
challenge claim: what puzzles them, an unresolved problem they name; and
question claim: something they ask, or clearly imply, without answering it themselves.

You already tagged each claim with one of these three kinds while open coding it. The tag matters because the three kinds cluster differently: two contradicting practice claims are informative in a different way than a challenge claim that undercuts a stated practice, or a question claim that turns out to be exactly what two other practitioners were circling without asking it outright.

Claim Clustering

Which of your claims, of any kind, point at the same underlying issue?

Analyze your claims, tagged practice, challenge, or question.
Group any that touch the same underlying issue in the domain, not just the same surface topic.
Name what the group is actually about, in one sentence. That is your candidate phenomenon.
Ask what nobody in the cluster, and as far as you can tell nobody in the literature, has resolved. That is your candidate knowledge problem, the question for which new knowledge is needed.

After open coding, which produces isolated, tagged observations per input, clustering synthesizes them by applying a lightweight form of axial coding (Strauss & Corbin, 1998) as a mind map instead of a formal category scheme. A cluster is often strongest when it mixes kinds: a practice claim beside a challenge claim that shows the practice failing, or a question one practitioner raised that matches what a different practitioner’s challenge was circling without naming. A tension between two contradicting practices, or between a stated practice and a challenge that undercuts it, is the clearest sign of a real, unresolved knowledge problem rather than one already settled in the field. Several practitioners converging on the same unexamined gap without realizing it is an equally useful discovery; see Contradictions as signal, earlier in this unit (Colquitt & George, 2011).

Outlook

Domain, phenomenon, knowledge problem is the structure Recker (2021a) uses to define an effective topic, the one you will meet formally in U4: Topic. Your domain is already fixed: agentic AI and cybersecurity. What you are doing here is finding the phenomenon and the knowledge problem inductively, from the plurality of what you heard, instead of being handed them.

Topic Mapping

Notes field	Candidate topic element
A cluster of related claims, practice, challenge, or question	The phenomenon
What nothing in the cluster, or the literature, resolves	The knowledge problem, your candidate question
A contradiction between two claims in a cluster	A tension, evidence the knowledge problem is real

Table 1: From perspective notes to a candidate topic

Nothing here needs to be invented. Every element is a rearrangement of what your note-taking procedure already produced, plus one genuinely new judgment call: deciding which claims belong to the same cluster, and naming what they are actually about.

Building a Map

Turn each cluster into one branch: place its claims as separate boxes, grouped together.
Add one box below the claims for the phenomenon, and one more below that for the knowledge problem, using the labels named while clustering.
Draw arrows from each claim to the phenomenon, and from the phenomenon to the knowledge problem.
Wherever two claims in a cluster genuinely contradict, connect them directly with a separate, labeled tension link instead of routing through the phenomenon box.
Repeat once per cluster; two or three separate branches is the normal outcome, not a sign the clustering went wrong.

%%{init: {'flowchart': {'rankSpacing': 30, 'nodeSpacing': 12, 'subGraphTitleMargin': {'top': 8, 'bottom': 8}}}}%%
flowchart TD
    %% Base styling
    classDef claimBox fill:#f5f5f5,stroke:#000000,stroke-width:1px,color:#000000;
    classDef phenomBox fill:#dedede,stroke:#000000,stroke-width:1.5px,color:#000000;
    classDef problemBox fill:#bcbcbc,stroke:#000000,stroke-width:2px,color:#000000;

    DOMAIN["Domain: Agentic AI and Cybersecurity"]

    %% ==========================================
    %% CLUSTER 1
    %% ==========================================
    subgraph T1["Cluster 1: Human Oversight vs. Automated Velocity"]
        direction LR
        C1["<b>Claim 1 [Practice]</b><br/><i>FinServ CISO:</i> Every agent action requires<br/>mandatory human sign-off before execution."]:::claimBox
        C2["<b>Claim 2 [Challenge]</b><br/><i>Vendor Lead:</i> Mandatory sign-off makes agents useless;<br/>clients demand real-time autonomous remediation."]:::claimBox
        C3["<b>Claim 3 [Question]</b><br/><i>SecOps Analyst:</i> At what operational speed does<br/>human oversight become purely nominal theater?"]:::claimBox
        C1 <-.->|TENSION: Safety vs. Velocity| C2
        C2 ~~~ C3
    end

    PH1["<b>Phenomenon 1</b><br/>Friction between operational velocity and human oversight<br/>in autonomous high-stakes execution."]:::phenomBox
    KP1["<b>Knowledge Problem 1</b><br/>How can organizations balance standing autonomy and continuous auditability<br/>without bottlenecking response time?"]:::problemBox

    DOMAIN --> T1
    T1 --> PH1
    PH1 --> KP1

    %% ==========================================
    %% CLUSTER 2
    %% ==========================================
    subgraph T2["Cluster 2: Machine Identity & Delegation Gaps"]
        direction LR
        C4["<b>Claim 4 [Challenge]</b><br/><i>Healthcare IT:</i> IAM infrastructure lacks any model<br/>for autonomous multi-agent delegation."]:::claimBox
        C5["<b>Claim 5 [Challenge]</b><br/><i>Public Sector Lead:</i> Runbooks assume human actors;<br/>agent tasks trigger false-positive rogue alerts."]:::claimBox
        C6["<b>Claim 6 [Practice]</b><br/><i>Cloud Architect:</i> We issue static admin tokens so agents<br/>can resolve cross-system infrastructure tickets."]:::claimBox
        C4 ~~~ C5
        C5 ~~~ C6
        C4 <-.->|TENSION: Least Privilege vs. Static Escalation| C6
    end

    PH2["<b>Phenomenon 2</b><br/>Mismatch between legacy security architectures and<br/>non-deterministic autonomous agent workflows."]:::phenomBox
    KP2["<b>Knowledge Problem 2</b><br/>How must IAM architectures evolve to govern ephemeral, non-human agency<br/>without defaulting to over-privileged service accounts?"]:::problemBox

    KP1 ~~~ T2
    T2 --> PH2
    PH2 --> KP2

    %% ==========================================
    %% CLUSTER 3
    %% ==========================================
    subgraph T3["Cluster 3: Multi-Agent Accountability & Forensics"]
        direction LR
        C7["<b>Claim 7 [Challenge]</b><br/><i>Forensics Lead:</i> Tracing non-deterministic reasoning loops<br/>across interacting agents is impossible post-incident."]:::claimBox
        C8["<b>Claim 8 [Question]</b><br/><i>Legal Counsel:</i> If an agent hallucinates a defensive countermeasure<br/>and breaks systems, who bears liability?"]:::claimBox
        C9["<b>Claim 9 [Practice]</b><br/><i>Risk Officer:</i> We archive raw prompt-response text logs<br/>to establish defensible compliance audit trails."]:::claimBox
        C7 ~~~ C8
        C8 ~~~ C9
        C7 <-.->|TENSION: Dynamic Reasoning vs. Static Logs| C9
    end

    PH3["<b>Phenomenon 3</b><br/>Opacity and causal ambiguity of multi-agent reasoning chains<br/>in post-incident digital forensics."]:::phenomBox
    KP3["<b>Knowledge Problem 3</b><br/>What constitutes legally defensible forensic provenance<br/>for emergent, multi-agent autonomous decisions?"]:::problemBox

    KP2 ~~~ T3
    T3 --> PH3
    PH3 --> KP3

Figure 1: An example Map-of-Perspectives (invented for illustration; not a transcript of real industry input)

Suggested Tools

Your Map of Perspectives has to be submitted on Moodle as a readable, gradable PDF, so build it in whatever helps you think, then plan for how it becomes that PDF.

A digital whiteboard (Miro, FigJam, draw.io) exports directly to PDF and avoids an extra step. A whiteboard or a wall with sticky notes is a good way to explore early, messy clusters by physically moving claims around, but budget time to digitize it afterward, a photo is not gradable, you will need to redraw it or export it cleanly. If you are already keeping your structured notes in an app with a canvas feature (e.g. Obsidian Canvas), building the map there keeps everything in one place and exports to PDF directly.

Homework

Finish structuring notes for your remaining industry inputs, then build your map.

Write up structured notes for any inputs you have not yet processed, using the four-step procedure.
Lay out all your claims and cluster them into candidate phenomena.
For each cluster, name the knowledge problem it raises, and mark any tensions between claims.
Identify the one candidate phenomenon and knowledge problem you are currently leaning toward as your tension.

This map, and the tension you select from it, is what you carry into U4: Topic, where domain, phenomenon, and knowledge problem become the formal criteria for an effective research topic.

Literature

Colquitt, J. A., & George, G. (2011). Publishing in AMJ—part 1: Topic choice. Academy of Management Journal, 54(3), 432–435.

Emerson, R. M., Fretz, R. I., & Shaw, L. L. (2011). Writing ethnographic fieldnotes (2nd ed.). University of Chicago Press.

Recker, J. (2021a). Scientific research in information systems: A beginner’s guide (2nd ed.). Springer.

Recker, J. (2021b). The research process. In Scientific research in information systems: A beginner’s guide (2nd ed.). Springer.

Strauss, A., & Corbin, J. (1998). Basics of qualitative research: Techniques and procedures for developing grounded theory (2nd ed.). Sage Publications.