E.4 Department-specific guidance
Summary
The tech team builds systems that help people become supporters, members, and organizers. The team favors scalable systems, information that AI can work with, and learning through frequent prototypes, and it works in two-week sprints.
E.4.1 Tech team: strategy primer
Users and outcomes. Start with the people a system serves and the next step it helps them take. We practice “big organizing”: volunteers recruit more volunteers, increasing the movement's capacity to act. For the tech team, that means improving the path from an action to further participation and responsibility. Exponential growth is an ambition, not a measured result or a guaranteed growth rate.
The movement flywheel in 1.2.5 shows the act, recruit, train cycle and the systems that could support each stage, such as a member portal, dues, Discord, courses, and a phone app. It does not establish that each system or program is available or adopted.
Prioritization and technology choices. Three principles guide the team:
- Scalability even over speed. Consider how a system would serve thousands of new people each month. Treat that scale as a design scenario rather than a forecast.
- AI-native over familiarity. Choose systems whose information is machine-readable and whose work can be captured and understood by AI.
- Prototype over perfection. Iterate and deploy every two weeks to learn from actual use. The two-week sprint cycle puts this into practice.
These principles require judgment together. A prototype should answer a useful question, and a system choice should help the movement achieve an outcome. Record the reason for consequential tradeoffs so other contributors can understand the decision.
Shared information: the company brain. We aim to build a “company brain” with access to as much information about the movement as possible. Its purpose is to connect activity, metrics, insights, and strategy so AI can suggest next steps and people can focus on work requiring human judgment.
Open the company brain diagram at full size.
In text: supporter signals include social-media views, website clicks, email engagement, and event attendance. Member signals include account creation, membership sign-ups, Discord activity, and course completion. Organizer signals include actions, events, meetings, and updated governance records. These feed metrics about what happened, insights about what was learned, and strategy about what to do next. They are candidate signals, not confirmed data integrations or performance measures.
The implementation, ownership, information-access rules, and human decision process for the company brain remain unresolved. The aim to capture information does not by itself authorize access to personal or restricted information. For existing context, read Atlas and AI.
Dated focus: 2026 Q4. The team's primary goals for this quarter are below. Current assignments live in Atlas.
| Focus | Responsibility |
|---|---|
| Streamline key tech systems for members and organizers | Backend Builder |
| Lay groundwork for supporter outreach and an app | Frontend Builder |
| Build course content for supporters, members, and organizers | Rohan |
For tech contributors working as Individual Contributors, the draft rubric below describes Output, Communication, and Judgment. It is maintained in A.1.2 and shared with E.1.1 Individual Contributor.
| Rating | Output | Communication | Judgment |
|---|---|---|---|
| 5 — Extraordinary | Repeatedly delivers major, high-quality systems or products that materially expand organizational capability. Creates tools or automation that multiply future output and handles highly ambiguous technical problems independently. | Creates exceptional clarity with very little overhead. Anticipates information needs, surfaces risks early, documents consequential decisions, and substantially reduces coordination costs. | Consistently identifies important problems or opportunities before they are assigned. Reframes problems, finds substantially higher-leverage solutions, and makes excellent product and technical tradeoffs under uncertainty. |
| 4 — Exceeds expectations | Consistently ships high-quality work faster or at greater scope than expected. Owns substantial projects end-to-end, improves underlying systems, and creates reusable leverage. | Proactively communicates progress, reasoning, blockers, results, and next steps. Anticipates questions, closes loops, and raises issues before they become problems. | Frequently improves the proposed approach. Prioritizes effectively, challenges weak assumptions, simplifies systems, and notices important downstream consequences. |
| 3 — Fully meets expectations | Reliably delivers agreed work at the expected pace and quality. Tests and debugs their own work, finishes projects, follows through on commitments, and independently owns scoped projects. | Clearly and proactively communicates what they are doing, why, current status, blockers, important decisions, results, and what comes next. Others generally do not need to chase them for information. | Understands organizational and user goals, prioritizes accordingly, makes sound product and technical tradeoffs, and independently handles most decisions within their domain. |
| 2 — Developing | Produces useful work, but speed, quality, or reliability is inconsistent. Work sometimes requires substantial rework, follow-up, or additional direction. | Communicates when prompted, but updates may be late or incomplete. Blockers sometimes surface too late, or activity is reported without enough explanation of outcomes or next steps. | Handles clearly defined decisions but struggles with ambiguity, prioritization, or system-level consequences. Frequently needs guidance when comparing alternatives. |
| 1 — Below expectations | Frequently misses commitments or produces incomplete, unreliable, or low-value work. Requires substantial supervision or repeated follow-up. | Progress is difficult to understand without asking. Important blockers, changes, or failures surface late and create uncertainty for others. | Frequently works on the wrong things, requires step-by-step direction, or makes avoidable product or technical decisions that are misaligned with organizational goals. |
Source: A.1.2 IC expectations rubric · Status: draft · Updated: 2026-10-02
E.4.2 Tech team: meeting format
The tech team works in two-week sprints with six meetings: sprint planning, governance, and a 1:1 in week 1; a sprint check, an all-hands, and demo day in week 2. A.2.5 Tech team meeting agenda holds the steps for each meeting.
For general meeting practice, see 3.4 Facilitation; the Fellowship's schedule there is separate from the tech team's.
E.4.3 Other departments
Guidance for other departments will be added as their scope, owners, and practices are confirmed.
Further Reading
From Hierarchy to Intelligence, by Jack Dorsey and Roelof Botha, informs the company-brain idea; see B.6.2 People and development.