Not Departments
Most organizations run on departments. Marketing. Finance. Operations. HR. Each one has a director, a staff, a budget, and a silo. Information flows up, decisions flow down, and the people doing the work rarely talk to the people in the next department.
Ktown Team is organized into 25 teams instead. They’re not departments. They don’t have directors. They’re organized around community needs - housing, health, education, arts, public safety, technology - and anyone in the Ktown Team community can join one.
The difference is structural. Departments serve the organization. Teams serve the community.
How They Work
Every team has the same basic structure. At least one lead to coordinate, at least three active members contributing regularly, and at least ten supporters who stay informed and step in when capacity allows.
Leads don’t manage. They coordinate. They keep the work moving, represent the team in cross-team discussions, and make sure information flows in both directions. The flat hierarchy means no one is anyone’s boss.
People join teams based on interest, not assignment. A retired teacher might join the Education & Lifelong Learning team. A local business owner might join the Economic Development & Entrepreneurship team. Someone passionate about transit might join Infrastructure & Transportation. Roles within teams are fluid - the same person might be a doer on one team and a specialist on another.
The 25
The teams span the full range of what a neighborhood needs:
- Housing and Infrastructure - the physical neighborhood
- Health & Wellness and Mental Health - community wellbeing
- Education and Youth Development - learning at every stage
- Arts & Culture and Sports & Recreation - community life
- Public Safety and Environmental Sustainability - safety and stewardship
- Legal Aid and Immigration Support - navigating systems
- Digital Innovation and Communications - tools and voice
- Economic Development and Financial Literacy - economic foundation
Each team has a dedicated wiki page describing its focus, potential projects, and how it connects to the broader organization. Each one uses the same platform tools for coordination.
Cross-Team Work
Neighborhood problems don’t respect organizational boundaries. A housing crisis is also a health issue, an education issue, and an economic issue. A new transit line affects businesses, displaces residents, creates construction jobs, and changes commute patterns.
The team model is designed for this. Teams aren’t sealed off from each other. Cross-team collaboration is built into the structure - the General Team serves as a coordination layer, triaging requests and facilitating work that spans multiple teams.
When a project touches more than one area, the relevant teams work together. No permission needed. No turf wars. The governance framework is designed so that decisions happen at the level where the knowledge is, not at the top of a hierarchy.
Why This Matters
The community organizations that exist in Koreatown today do good work. But most of them are organized around a specific issue - housing, legal aid, youth services - and they operate independently. When a resident has a problem that crosses boundaries, they have to navigate between organizations, each with its own intake process, eligibility criteria, and wait times.
Twenty-five teams under one organization, sharing the same tools, the same information, and the same governance structure, can respond to complex problems as connected systems rather than isolated services.
A resident dealing with an eviction doesn’t just need legal help. They might need job placement, translation services, mental health support, and help understanding their rights. In a team-based model, those connections happen inside the organization rather than across a fragmented landscape of referrals.
The Experiment
This model hasn’t been tested yet. It’s a design - documented in the wiki, ready to be implemented. Some things will work as planned. Some won’t. Teams will merge, split, or shift focus based on what the community actually needs.
The documentation is there so that when changes happen, they happen transparently. Every adjustment can be measured against the original design. Every evolution can be tracked. The wiki makes sure nobody has to guess how things were supposed to work in the first place.