Communication and Feedback

I wrote this page to make communication easy for both of us—so you get faster, more useful feedback with less back-and-forth.

NoteWhere to Find Policies and Requirements

If you’re looking for administrative requirements (agreements, ethics approval, similarity reports, confidentiality), start with Thesis Guidelines and the relevant Project Milestones.

Before Our First Meeting

If you want me to assess whether a topic is feasible and a good fit, send either:

  • A one-pager (what the company wants, the context, available data, and what you are expected to deliver), or
  • A draft problem statement (what is wrong, why it matters, and what success looks like in measurable terms).

If you are visiting the company early, try to leave those stakeholder meetings with answers to:

  • What does “success” mean for them (KPIs)?
  • What decisions do they actually want to improve?
  • What is the current baseline/benchmark process we should compare against?

What I Need to Give Useful Feedback

When you ask for feedback (email or meeting), include:

  • A link to the current document (Overleaf/GitHub) and what changed since last time.
  • The 1–3 questions you want answered (be explicit about what kind of feedback you want).
  • Any hard constraints or deadlines (greenlight, company presentation, colloquium).

If you send text, send a complete unit (a full section/chapter), not isolated paragraphs.

Meetings

I am happy to meet early to brainstorm, but meetings work best when you have something concrete to discuss (draft intro, problem statement, outline, experiment plan, etc.).

Before booking, do two quick things:

  1. Update PROJECT_MANAGEMENT.md with your questions and a short status update.
  2. Run the Report Quality Check on whatever you will share.

Meeting Log (PROJECT_MANAGEMENT.md)

Keep a running log in your shared project workspace (usually in PROJECT_MANAGEMENT.md). For each meeting, add:

  • The questions you want to answer next
  • What changed since the last meeting
  • Your next steps for the next 1–2 weeks

For a full template and example, see Research Collaboration System.

Email Is for Logistics (Usually)

Email works well for:

  • Scheduling, deadlines, and administrative questions.
  • Pointing me to a new draft and telling me what you need from the next feedback round.

Email is not ideal for:

  • Long technical discussions without a shared artifact (model, draft, figure, or code).
  • Debugging “everything at once” without a minimal example or a clear question.