Question
What does it mean that schema propagation in organizations?
Quick Answer
New members absorb organizational schemas through onboarding, socialization, and observation — but the propagation process is largely undesigned. What new members learn is determined more by who they sit near, who mentors them, and what they observe in their first weeks than by any formal.
New members absorb organizational schemas through onboarding, socialization, and observation — but the propagation process is largely undesigned. What new members learn is determined more by who they sit near, who mentors them, and what they observe in their first weeks than by any formal onboarding program. Organizations that design their schema propagation deliberately can shape which schemas new members acquire and which they question.
Example: A fast-growing startup hired thirty engineers in six months, tripling the engineering team. The original team of fifteen had a strong schema of 'ownership': each engineer owned their service end-to-end, from design through deployment through on-call support. This schema produced high accountability and fast decision-making. But the schema was never formally documented. New engineers learned it through observation and informal mentoring. The problem was that the thirty new engineers were distributed across three offices, and each office developed a slightly different version of the ownership schema. In the headquarters office, where most of the original team sat, new engineers absorbed the full schema: own everything, decide fast, be accountable. In the second office, where only two original engineers worked, new engineers absorbed a diluted version: own your code, but escalate decisions. In the third office, which had no original team members, new engineers defaulted to their previous companies' schemas: write code, hand off to operations, wait for product to set priorities. Within a year, the engineering team had three different operating schemas despite being nominally one team. The VP of Engineering, Tomas, realized that schema propagation had not been designed — it had been left to proximity. He instituted three changes: (1) every new engineer spent their first two weeks at headquarters with the original team, (2) the ownership schema was explicitly documented with concrete examples, and (3) each new engineer was assigned a mentor from the original team for their first quarter. The schema propagation became deliberate rather than accidental, and the next cohort of hires operated from a consistent schema regardless of office location.
Try this: Think about your first month at your current organization. What were the three most important things you learned — not technical skills, but how the organization works? How did you learn them: through formal onboarding, through a mentor, through observation, or through making a mistake? For each, assess: Was the learning deliberately designed by the organization, or was it accidental? If accidental, was what you learned accurate — did it reflect the organization's actual best practices, or did it reflect the particular quirks of whoever happened to be near you? This exercise reveals the quality of your organization's schema propagation process.
Learn more in these lessons