Standard operations guide

World Lab operates by several standardized procedures. Every participant is expected to know and abide by these standard operations.

Servant leadership

Traditional leadership

In traditional hierarchies, leaders and managers specify exact tasks for teams to take on. Final responsibility and the ultimate creative potential rests on the team leader, with team members being tools for the team leader to accomplish their goal.

In this scenario, team leaders are like parents and team members are more like children, relying on their parents' guidance.

Servant leadership

In World Lab, we turn this hierarchy on its head. individuals are expected to speak up, take initiative and use their creative potential to solve problems.

How individuals behave in different leadership styles:

Aspect / behavior	Traditional team members	Servant-led team members
Tasks	Wait for manager's permission to take on tasks	Expected to create and distribute tasks among themselves.
Problem solving	Escalate problems to the managers.	Expected to find and solve problems autonomously.
Deadlines	Deadlines set by managers with no input from team.	Often participate in setting or set their own realistic deadlines.
Focus	Focus on completing assigned individual tasks.	Focus on achieving overall goals.
Risk & failure	Avoid risks; failure may be penalized.	Encouraged to take calculated risks.
Feedback	Teams only address issues with team leader.	Teams expected to bring up team issues and solve them together.
Ownership	The team leader is the only one responsible for team and it's goals.	Team members are all equally responsible for the goal.

How leaders behave in the different styles:

Aspect / behavior	Traditional team leaders	Servant leaders
Team motivation	Motivates with aggression and fear.	Listens to the team and builds consensus. Continuously reiterates the team's "why" and the bigger impact of their actions.
Primary focus	Managing the team directly.	Removing obstacles for team. Teaching self-initiative.
Communication style	Directing, cascading information.	Open team conversations. Public documentation. Active listening.
Problem response	Assigns blame.	Asks "What can we learn?"; removes obstacles.
Performance monitoring	Manager monitors individual/team performance.	Team expected to keep track of its own performance metrics.
	The leader is faultless.	Leader is vulnerable, clarifying what they know and don't know and admitting mistakes.

The weakness of traditional teams:

Depends on the genius of a team leader rather than the collective intelligence of a team.
People are more motivated by feeling a sense of ownership and agency over a task than via fear.

The weakness of servant-led teams:

They are difficult to understand because our education system often teaches the opposite.
They lead to a lack of responsibility if the principles of self-organization are not actively taught.
The servant leader must take the initiative to set the appropriate boundaries to autonomy to ensure focus on the goal.

Setting the boundaries of autonomy

Servant leaders set clear boundaries (like purpose, scope, quality, and deadlines) to define the goal and operational limits. This clarity empowers teams by providing focus and psychological safety, allowing them to navigate autonomously towards the objective without dictating how they work.

Example in the context of a game

Purpose & vision boundary:
This boundary defines the why and core objective: deliver the 'Crystal caves' level for the demo, specifically to showcase the new 'crystal resonance' mechanic and gather player feedback on its intuitiveness. This provides focus.

Scope boundary:
Clarifying what's in and out for this specific goal: focus on 3 cave sections, 4 resonance puzzles, and 1 new hazard. A boss is explicitly out of scope for this demo build. This prevents scope creep and manages effort.

Quality & 'done' boundary:
This sets the required standard for success: 'playable' means smooth performance (>60fps), a functional and understandable mechanic, solvable puzzles, and no critical bugs. Art must meet the defined 'alpha complete' standard.

Autonomy within boundaries:
While respecting the six-week timeline and other constraints (like scope and quality), this boundary grants the team freedom to decide how they achieve the goal, determining specific puzzle designs, layouts, hazard placement, and internal task planning. It reinforces trust but requires reporting roadblocks.

Values/collaboration boundary:
This addresses the how of teamwork and interaction: guiding the team to prioritize collaborative brainstorming and utilize internal playtesting for rapid, constructive feedback, aligning with team working agreements.

Retrospectives

Experienced teams recognize the value of reflecting on their mistakes and improving. A retrospective is a dedicated process in which teams take time to pause, inspect recent performance, criticize themselves, and take feedback into a plan of action to improve.

Psychological safety is the foundation. Team members must feel secure sharing openly. This means operating with a belief in "everyone's best intentions" and, critically, focusing on solving process problems, not blaming individuals.

A lean coffee is World Lab's preferred way of doing a retrospective.

Lean coffee process outline

Lean coffee process outline

This process facilitates focused discussion, starting with positives and moving to challenges.

Phase 1: Discussing positives

Generate: (5 min) Participants write down recent successes/positives on notes. Facilitator groups similar items.
Vote: (3 min) Participants vote on the most impactful positives.
Discuss: Discuss top-voted positives. Focus on understanding success factors and acknowledging contributions.

Phase 2: Addressing challenges

Generate: (7 min) Participants write down challenges/impediments. Facilitator groups similar items.
Reframe as "How might we...": Collaboratively rephrase key challenges into "How might we..." questions (e.g., "How might we reduce bug frequency?").
Vote: (4 min) Participants vote on the HMW questions they deem most important.
Discuss & action: (e.g., 10 min total per item)
- Clarify problem: (2 min) Discuss the top-voted item to ensure shared understanding.
- Silent solution generation: (3 min) Participants silently write down potential solutions/ideas on notes.
- Discuss solutions & action: (5 min) Review generated solutions, discuss feasibility, and define at least one specific action item with an owner.
- Park undiscussed items for later.

Phase 3: Documentation & follow-up

Review & Assign: Briefly review all generated action items. Confirm owners and deadlines/follow-up plans.
Document: Record action items visibly. Assign someone to document key lessons learned in a shared knowledge base or create documentation tasks.

The secret power of this process is that it's not so much a discussion as a quiet, synchronous ideation session that allows a large number of diverse views to be brought up without contention between those views, each individual view getting its own discussion opportunity.

This structure is vital. It provides necessary and safe process for potentially difficult feedback. Without it, discussing failures can become unstructured, personal, and damaging to psychological safety.

The outcome is team-owned commitments for change, not fault-finding. The servant leader facilitates this, ensuring safety and focus, thereby empowering the team's continuous adaptation through a reliable feedback loop.

Documentation

World Lab encourages teams to create their own team documentation. These documentation platforms should be:

Visual - Prioritize visuals over text.
Lightweight - Rather than being comprehensive, seek to summarize with bullet points and tables.
Ordered - Have a clear order to your documentation and a path to guide new people through.
Living - Continuously update your documentation.

Clear standards for when, where, and how to update documentation help spread responsibility for keeping it accurate and up-to-date.

Ensure you share lessons learned and globally-useful tutorials with the whole community in the Discord for World Lab:

Validating demand

Passion drives many teams to build before checking if anyone wants what they're creating.

Practicing the validation of demand is complex in an environment like World Lab but it's still highly necessary.

Offer the project requestor a simpler alternative to see if it better fulfills the need.
Share the idea on social media and see how the public
Share mockups or concept art of the idea to gauge people's reactions
Create a landing page featuring part of the product and see how many people sign up for details.

Before you create anything, figure out what problem people actually want solved and the cheapest and easiest way to solve it.

Flexible approach

Companies used to manage themselves by starting with a comprehensive plan and making sure that the plan was meticulously followed until project completion.

By contrast, those in World Lab start by making the smallest presentable piece of a project.

Instead of building components of a car piece-by-piece (wheel, chassis, etc. - delivering no value until the end), you start with the simplest thing that achieves the user's core need (transportation). Start with a skateboard (minimal transport). Get feedback. Iterate to a scooter (easier balance). Get feedback. Iterate to a bicycle (better distance). Get feedback. Iterate to a motorcycle or car based on evolving, validated needs.

By starting with a skateboard, developers learn about what the target audience actually needs. It helps shape the sort of car they will make in the end.

For example, we may discover that the audience enjoys a slow scenic experience and we may focus on big windows in the car as a result.

Although this approach requires building several more vehicles, it is in fact more efficient, allowing one to discover false assumptions and one audience's true needs early.

At World Lab we publicly test working products in front of an audience as close to our target audience as often as possible to continually inform our development process.

Volunteer-specific systems

There are certain systems specific to volunteer-work that are tried-and-tested.

Prioritize the individual

There is a tendency for volunteer teams to want to hold onto people, but the mission of the volunteer organization should always come as second to the needs of it's volunteers as individuals.

This means giving people the flexibility to take breaks understanding that people will do so and being comfortable with a more dynamic team structure.

Leading by example

Don't ask volunteers to do something you're not willing to do.

Organization and preparation

Organization and proper preparation helps autonomous teams take on their goal.

Every task must have:

A clear deadline
A clearly specified definition of done
A single owner of final responsibility
Acceptance criteria

Self-initiative

Organization and preparation

It goes without saying that organization and proper preparation is essential to every endeavor we undertake.

Every task must have:

A clear deadline
A clearly specified definition of done
A single owner of final responsibility
Acceptance criteria