500 Engineers: Rules as Organizational Infrastructure
At 500 engineers: you have 40-60 teams across 3-5 business units, multiple technology stacks in production, cross-team dependencies that require coordination, compliance requirements from enterprise customers, and enough organizational complexity that informal processes create bottlenecks. AI rules at this scale are organizational infrastructure: they require dedicated ownership, automated tooling, formal governance, and continuous measurement.
The 500-person organizational structure: 1 CTO, 2-3 VPs of Engineering (each owning a business unit), 10-15 Engineering Managers, 40-60 teams, and 5-10 staff/principal engineers. AI rules require: a rules platform team (2-3 engineers), business unit rule owners (1 per BU), and technology rule maintainers (1 per major technology stack). Total rules-related roles: 10-15 people with partial allocation.
What changes from 100 to 500: governance moves from informal to formal (architecture review board), distribution moves from manual to automated (sync tooling), adoption moves from demo-based to dashboard-tracked, and rule ownership moves from individual to committee-based for organization-level changes.
Governance and Operations Model
Architecture Review Board: meets bi-weekly to review proposed changes to organization-level rules. Members: principal engineers, VP Engineering representatives, security lead. Responsibilities: approve/reject organization rule changes, resolve cross-BU rule conflicts, set the quarterly rules roadmap. AI rule: 'The ARB does not review team-level or technology-level rules — only changes that affect all 500 engineers. This keeps the board focused on high-impact decisions and avoids micromanagement.'
Business unit rule owners: each BU has a designated rule owner (typically a staff engineer) who: maintains the BU's technology rules, coordinates with other BU owners on cross-BU standards, represents the BU at the ARB, and manages rule adoption within the BU. AI rule: 'BU rule owners are the most important role in the governance structure. They translate organizational standards into BU-specific guidance and ensure rules work for their teams' actual workflows.'
Rules platform team: a small team (2-3 engineers) that operates the rules infrastructure: sync tooling (automated distribution to all repos), compliance dashboard (which repos have current rules), rule composition engine (merging organization + technology + team rules), and support (helping teams configure and customize rules). AI rule: 'The platform team maintains the infrastructure, not the rules themselves. They build the tools that make rule authoring, distribution, and compliance tracking easy for everyone else.'
The ARB meets bi-weekly and makes big decisions. The platform team builds tools. But the BU rule owner: talks to teams daily, understands their real-world constraints, translates organizational standards into practical team guidance, and identifies rules that are causing friction. Without effective BU rule owners: organizational rules feel disconnected from daily development. Invest in selecting and supporting strong BU rule owners — they make or break the rules program.
Automated Distribution and Compliance
Automated sync: when organization or technology rules change, the sync tool: opens PRs in all affected repos, shows the diff between current and new rules, tracks which repos have merged, and reports lagging repos to the BU rule owner. AI rule: 'At 500 engineers: automated sync is essential. Manual distribution to 200+ repos is not feasible. The sync tool must be reliable (runs successfully > 99% of the time) and non-disruptive (PRs, not force-pushes).'
Compliance tracking: a dashboard shows: rules adoption by BU (percentage of repos with current rules), rules version distribution (which repos are on which version), compliance scores (repos meeting all required rule sections), and trend over time (is adoption improving?). AI rule: 'The compliance dashboard is a management tool, not an enforcement tool. BU rule owners use it to identify teams that need help. VP Engineering uses it for executive reporting. It does not automatically block PRs or deployments.'
Graduated enforcement: at 500 engineers, some rules warrant enforcement. Security-critical rules (input validation, authentication, encryption): enforced in CI — PRs that violate these rules cannot be merged. Quality rules (naming, patterns, testing): advisory — flagged but not blocking. Convention rules (formatting, import ordering): automated fixes (Prettier, ESLint --fix) rather than enforcement. AI rule: 'Enforce security rules. Advise on quality rules. Auto-fix convention rules. This graduated approach: protects against security vulnerabilities without creating friction on style preferences.'
A compliance dashboard that blocks deployments for non-compliant repos: creates emergency override culture (teams bypass the dashboard during incidents), punishes teams that have legitimate exceptions, and makes the platform team the enemy instead of the enabler. The dashboard should: give visibility to management (which BUs are lagging), help BU rule owners identify teams that need support, and track trends over time. Enforcement belongs in CI (for security rules only), not in the dashboard.
Cross-Business Unit Coordination
Shared services and APIs: at 500 engineers, multiple BUs consume each other's APIs. Cross-BU API standards (defined by the ARB): consistent response formats, error handling, authentication patterns, and versioning. AI rule: 'Cross-BU API rules are the highest-impact organization rules. They enable: any team's service can be consumed by any other team without custom integration. Test these rules with real integrations before mandating across the organization.'
Technology standardization: each BU may have different primary technologies (BU A: TypeScript/React, BU B: Go/gRPC, BU C: Python/FastAPI). Organization rules: apply to all. Technology rules: apply within the technology. Cross-technology rules: define how different technologies interact (API contracts, event schemas, shared data models). AI rule: 'Cross-technology rules are maintained by the ARB with input from all BU rule owners. These rules define the integration patterns that make the system cohesive despite technology diversity.'
Quarterly alignment: all BU rule owners meet quarterly to: review the rules roadmap, share lessons learned (what rules worked well, what caused friction), propose cross-BU rule changes, and plan for upcoming technology migrations or compliance requirements. AI rule: 'The quarterly alignment prevents BU rule divergence. Without it: BUs develop incompatible patterns that make integration increasingly difficult. The alignment meeting is the most important recurring rules event.'
At 500 engineers: the most expensive integration bugs happen between BUs. BU A's service returns errors as { error: 'message' }. BU B expects { error: { code: 'INVALID', message: '...' } }. Integration fails. Cross-BU API standards that define: response format, error shape, pagination, and authentication — prevent these integration failures before they happen. These standards should be the first rules the ARB approves and the most strictly enforced.
500-Person Org AI Rules Summary
Summary of AI rules framework for 500-person engineering organizations.
- Governance: ARB (bi-weekly, org rules only), BU rule owners (daily, technology + team rules), platform team (tooling)
- Distribution: automated sync. PRs to all affected repos. Track merge status per BU
- Compliance: dashboard for management visibility. Not an enforcement tool (except security rules)
- Graduated enforcement: enforce security, advise quality, auto-fix conventions
- Cross-BU APIs: consistent response format, error handling, auth, versioning — highest impact rules
- Technology diversity: org rules for all, technology rules per stack, cross-tech rules for integration
- Quarterly alignment: all BU rule owners review roadmap, share lessons, plan cross-BU changes
- Team size: 2-3 platform engineers, 3-5 BU rule owners, 5-10 technology maintainers (partial allocation)