For Writers

Navigating complexity

Games teach a mechanic → present a challenge → introduce another mechanic → layer another challenge → final boss demands combining all mechanics to solve.

Writing could follow this same architecture:

• Introduce concept A + ground it with example
• Introduce concept B + practice with new example
• Show how A and B interact + explain real-world application
• Present the complex phenomenon (your actual subject) requiring all prior concepts woven together

We hope this scaffolding approach contributes in building reader capacity to think systemically.

Field Trip Case Studies

Field Trip case studies does not accept open submission by default, but for adventurer who takes the challenge here are our requirements (two approaches to capture decision-making processes that readers can reproduce and adapt):

Option A: Sequential Flow Tracking

Examine each project phase systematically (Project Initiation, Financing, Project Management, Marketing, etc.). Track how initial resources and information converted into decisions, how key milestones consumed resources and created outputs, and how those outputs delivered actual benefits. Address:

• What resources you started with and what information guided your decision to commit them
• The method used to decide where to allocate resources at each decision point
• Key steps or milestones, what resources they consumed, and what they created
• Looking back, which steps were inefficient and what alternatives you might have taken
• How you acquired users or participation after launch
• How you verified the project delivered benefit with specific data or observations
• Advice you would give to others facing similar situations

Option B: Critical Decision Tracing

Focus on difficult decisions throughout the project journey. Use the sequential framework above as a foundation, but emphasize how you interpreted challenging situations and the reasoning behind your choices. For each critical decision:

• Describe the situation and information available at that time
• Explain how you interpreted it, including cognitive biases, constraints, or assumptions
• Detail the decision made and your reasoning process
• Reflect on the outcome and what made this a good or bad decision in retrospect
• Identify lessons others could adapt to their own contexts

Option C: Lesson Learned Entry Schema

Multiple entries for multiple lessons, even if they are learned within a single project.

Submit discrete, structured lessons from project experiences using our standardized framework. Each entry should capture a single meaningful success or failure that others can learn from. Structure your submission around these four dimensions:

• Core Event & Outcome: Describe what happened in concrete terms. Summarize the lesson briefly, identify the project phase or theme, quantify the impact (resources wasted, goal achieved, reputation affected), and explain what corrective actions were taken or what practices should be replicated.
• Context & Decision Environment: Provide the situational backdrop without revealing identifying details. Indicate the timeframe loosely (e.g., "late 2024" or "during rapid expansion phase"), describe relevant external factors (market conditions, regulatory changes, competitive pressures), and identify cognitive biases or mindsets that influenced decisions (overconfidence, groupthink, confirmation bias).
• Methodology & Execution: Explain what went right or wrong in how the work was done. Identify the pattern type (communication breakdown, resource misallocation, successful agile adaptation), describe key resource allocation decisions (team composition, tool selection, vendor choices), specify which activities received focus (feature development, market timing, user adoption strategies), and indicate the relevant project phase (initiation, financing, management, marketing).
• Actionable Insights: Make your lesson transferable to others. Provide specific recommended actions that others can apply, offer counterfactual analysis (what alternative approaches might have worked better or worse), specify which organizational scale this lesson best applies to (startup, mid-sized, enterprise, volunteer team), and identify relevant activity categories (B2G software, EdTech, financial services, community outreach).

Community Story of projects

For projects sharing as Community Stories, consider structuring your content around key questions that help readers understand:

• The initial problem or opportunity your project addressed
• Key decisions and assumptions made along the way
• Challenges encountered and how they were handled
• Current outcomes and lessons learned
• What you would do differently next time

Use our structured questionnaire to help organize your submission.

Information Processing and De-identification Methodology

For projects preferred De-identification: All direct identifying information must be replaced with generic or abstract roles and categories.

Original Information Type	Processing Method	Example of Abstract Entity Replacement
Personal Names	Replaced with generic character roles.	Senior Manager, Project Lead, Core Engineer
Organization Name/Brand	Replaced with organization category and size.	A leading regional FinTech startup, A large Asian media conglomerate
Project Name/Code	Replaced with project type and purpose.	User Data Collection Platform Project, Internal Resource Integration Plan
Sensitive Business Details	Replaced with functional descriptions.	A highly regulated B2G contract (Replacing: A contract signed with a certain department of the Taiwanese government)
Precise Date/Location	Replaced with time intervals or geographical regions.	Q2 2024, A certain industrial park in Southeast Asia