Scaling Engineering Culture Through Hypergrowth: What We Got Right and Wrong

When Lumorion crossed the 12-person engineering threshold in early 2025, we operated on the kind of implicit culture that small teams enjoy effortlessly. Everyone knew everyone, decisions happened in hallway conversations, code review standards were maintained through osmosis, and onboarding meant sitting next to a senior engineer for a week. Eighteen months later, with 85 engineers across seven teams and three time zones, every single one of those mechanisms had broken down. The story of how we rebuilt our culture intentionally is one of our most important institutional lessons.

The first casualty of scale was decision-making velocity. With 12 engineers, any technical decision could be made in a single meeting because all the relevant context holders fit in one room. At 40 engineers, decisions started stalling because no one was sure who had authority to make them. We solved this by implementing an RFC process with clear ownership rules: the team that owns the affected system makes the decision, publishes an RFC for visibility, and other teams have a 72-hour comment window. After the window closes, the owning team decides and moves forward. This process felt bureaucratic at first but actually accelerated decisions because it eliminated the ambiguity about who was responsible.

Code quality was the second area that required explicit mechanisms. In a small team, a shared sense of what good code looks like develops naturally through constant pairing and review. At scale, you get divergent standards across teams — one team writes exhaustive unit tests while another relies on integration tests, one team favors explicit error handling while another uses exception-based control flow. We addressed this by codifying our standards into automated tooling: linters, formatters, architecture tests that enforce dependency boundaries, and CI checks that measure test coverage thresholds. The rule was simple — if a standard is important enough to enforce, it is important enough to automate. Human code review could then focus on design decisions and business logic rather than style and convention.

Onboarding at scale required a complete rethink. The sit-next-to-a-senior-engineer model does not work when you are hiring five engineers per month and senior engineers cannot spend 20 percent of their time on onboarding without their own work suffering. We built a structured 30-60-90-day onboarding program with concrete milestones: ship a bug fix in week one, own a small feature by week four, lead a technical design by week eight. Each milestone has a self-contained guide and a designated mentor who commits four hours per week, not four hours per day. New hires report being productive significantly faster under this system than our ad hoc approach, and mentors report that the structured format makes their time commitment predictable and sustainable.

The practice we got most wrong was transparency. In the early days, we shared everything with everyone — every financial metric, every strategic debate, every client concern. This felt virtuous and aligned with our values, but at 85 people it created noise that drowned out signal. Engineers were anxious about client negotiations they could not influence and distracted by strategic discussions that were weeks from resolution. We shifted to a tiered transparency model: team-level metrics and decisions are shared in real time, company-level updates are shared weekly in a structured format with context and next steps, and sensitive negotiations are shared only when there is something actionable. This was a hard lesson in the difference between transparency and information overload.