Skip to content

Instantly share code, notes, and snippets.

@timmyreilly
Last active August 12, 2026 19:52
Show Gist options
  • Select an option

  • Save timmyreilly/8f56815e45d447efe9077a0a39e17b6e to your computer and use it in GitHub Desktop.

Select an option

Save timmyreilly/8f56815e45d447efe9077a0a39e17b6e to your computer and use it in GitHub Desktop.
Tim Reilly - Field Notes and Resource Links

Tim Reilly - Field Notes and Resource Links

A small, public-safe set of links I often share in conversations about field engineering, architecture discovery, domain modeling, and moving from discussion to buildable systems.

Event Storming and Domain Modeling

Architecture, Delivery, and Python Examples

AI, Tools, Text, and Creative Practice

Distributed Systems, Security, and Networks

Generative Design and Shape Grammars

Field Engineering / FDE Discussion Starters

  • Start with the customer's operating model, not the demo: what decisions, actions, and feedback loops change if this works?
  • Use Event Storming to identify bounded contexts, command/event flows, policy hotspots, and seams for delivery ownership.
  • Treat dashboards/reports as evidence, not the product. The product is a repeatable workflow that changes behavior.
  • Separate three motions early: advisory framing, prototype/code-with, and production co-delivery.
  • Prefer a thin product-shaped slice over a broad platform-shaped promise.

Philosophy / Manifesto Seeds

  • Do the right thing, even when the right thing is slower to explain than the flashy thing.
  • Listen first. The useful system is usually hidden in the customer's language, workarounds, and pain.
  • Untangle before you automate. Tools should reveal the knots, not just make them faster.
  • Use simple durable media - notes, events, diagrams, links, plain text - to make thinking visible.
  • The work is not to sound smart in the room; it is to leave the room with shared understanding and a next responsible action.

Lightweight Working Agreements

A simple starter for customer gameplans: make the collaboration model explicit before the work gets busy.

  • Common goal, clear scope: keep the problem statement, current priorities, and definition of done visible in one shared place.
  • One owner per outcome: many people can contribute, but every decision, risk, backlog area, and deliverable needs a named owner.
  • Write decisions down: use durable notes, work items, diagrams, and short decision records so the team does not depend on memory or hallway context.
  • Collaborate early and often: share rough thinking, prototypes, blockers, and tradeoffs before they are polished.
  • Use meetings intentionally: keep a lightweight rhythm for standup, backlog refinement, stakeholder review, and retrospective; cancel or shorten meetings that are not creating shared understanding.
  • Bring data to disagreements: prefer customer evidence, usage signals, logs, examples, constraints, and working software over opinion.
  • Ask for help quickly: needing help is normal; surfacing uncertainty early reduces surprises and raises quality.
  • Protect focus and boundaries: agree on core collaboration hours, response expectations, escalation paths, and what work is intentionally out of scope.
  • Keep it simple: choose the smallest useful process, artifact, and architecture that helps the team learn and move responsibly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment