Your first stakeholder or integration meeting

You will be invited to a meeting before you feel ready. That is normal. The meeting is not a test of whether you belong; it is a test of whether the project has been thought through. Your job is to ask the questions that expose gaps without performing expertise you do not have.

Before you walk in

Spend fifteen minutes on context:

• Who called the meeting, and what decision is supposed to come out of it?
• Who is in the room: clinical, IT, vendor, leadership?
• Is this exploratory ("should we do this?") or operational ("we go-live Thursday")?

If you cannot answer the third question, everything else follows from finding out.

Bring a notebook. Laptops look productive; notebooks signal you are listening. Type up notes after, not during, unless you are the designated scribe.

What to ask (and why)

"What problem are we solving, and for whom?" Projects drift when the answer is "integrate System A with System B" instead of "reduce duplicate lab draws" or "get radiology results to the ED faster." Force the clinical or operational problem into the open.

"What does success look like in six months?" Vague answers ("better data") mean undefined scope. Push for something observable: fewer manual re-entries, a report that runs without a workaround, a workflow step removed.

"What happens when this fails?" Not catastrophizing; scoping. If the interface drops, do patients still get care? Is there a manual fallback? Who gets paged? Silence here is a red flag.

"Who owns this on each side?" Named humans, not departments. "IT" is not an owner. If nobody owns it, it will not get fixed at 2 a.m.

"What is in scope for this phase, and explicitly out of scope?" Prevents the meeting from ending with everyone assuming different boundaries.

For integration meetings specifically, add:

• Which standard (HL7 v2, FHIR, flat file, something proprietary)?
• What event triggers the exchange?
• What is acceptable latency?
• Where is the mapping documented?

What to write down

Capture these even if nobody else is taking minutes:

• Decisions made (not just discussed)
• Open questions assigned to a name
• Dates mentioned (go-live, vendor delivery, testing window)
• Terms you did not recognise (look them up after, not in the meeting)

Send a three-bullet follow-up email if you were asked to, or if the room was ambiguous and you want clarity on paper. "My understanding from today: X decided, Y open, next step Z" is never rude. It is professional.

What not to fake

Do not pretend to know acronyms. Ask once: "What does that stand for in this org?" People forget that newcomers exist. Asking clarifies for everyone.

Do not commit to timelines on behalf of a team you do not lead. "I will find out and confirm by Friday" beats "Sure, we can do that next week."

Do not agree that a workflow is simple because the diagram is simple. Diagrams omit the nurse with eleven seconds, the workaround built in 2019, and the policy that contradicts the slide.

Do not offer to "just pull a report" unless you know the data source, the operational definition, and who validates output. Quick reports that are wrong are worse than no report.

Do not silence your clinical instinct to seem technical. If something sounds unsafe or unworkable on the floor, say "I want to understand how this works during a busy shift" is enough. You are not being difficult; you are doing the job.

How to participate when you have nothing to add

You do not need to speak every five minutes. Useful low-risk contributions:

• Summarise a long thread: "So we are deciding between A and B, and the blocker is C?"
• Ask for a concrete example: "Can we walk through one patient through this flow?"
• Request the artefact: "Is there a requirements doc or interface spec we can read?"

Sitting quietly and taking good notes is also participation. The person who sends accurate follow-up is remembered.

After the meeting

Within 24 hours:

1. Look up terms you did not know.
2. Identify one person to ask a clarifying question if something still does not make sense.
3. Tell your preceptor or manager if you heard a risk nobody seemed to own.

Before the meeting, answer these three

1. What decision is this meeting supposed to produce? If nobody knows, the meeting may be theatre. Still go; still take notes.
2. Who will be affected if this goes wrong? Patients, staff, billing, research participants: name the population so technical talk stays grounded.
3. What do I need to read afterward to not be lost next time? Interface spec, workflow diagram, project charter: ask for the artefact by name.

First meetings are not about proving you deserve the seat. They are about leaving the room with fewer hidden assumptions than it had when you entered.