Implicit culture works when there are three of you in a room. Everyone can see how decisions get made. Everyone absorbs the norms by proximity. But somewhere around the ten-person mark, that ambient understanding breaks down. New people join who never witnessed the founding decisions. Subteams form with their own micro-cultures. Conflicting interpretations of "how we do things here" start producing friction in critiques, in hiring conversations, in the way work gets prioritized. This is the moment where design teams either write down their principles or spend the next two years arguing about things they assumed were obvious.
I learned this lesson the hard way. In 2017, I founded Compass of Design, an online community for self-taught and early-career designers. Over two years, I published 43 articles, curated 78 books across 13 categories, and built a Slack community with active members across time zones and experience levels. The community started with a handful of people who shared my specific perspective on learning design through practice, feedback, and honest self-assessment. It grew into something more complex. And the moment it outgrew the circle of people who had been there from the beginning, I had to confront a question I was not prepared for: what exactly are we about, and how do we make sure new members understand that without me personally explaining it to each of them?
That same question plays out on every design team that scales past its initial core. Whether you are a design manager building team culture at a startup or a senior IC at an enterprise organization trying to hold the line on quality as headcount doubles, the underlying challenge is the same. You need explicit principles. Not aspirational posters on a wall. Not company values rephrased in design language. Operating principles that tell your team what to do when they are stuck, what to optimize for when tradeoffs conflict, and what behaviors to reward even when nobody is watching.
Why Design Teams Need Explicit Principles
Principles function as decision-making shortcuts. They answer the question "when in doubt, we..." before the doubt arises. When a designer on your team is deciding between shipping a polished feature late or a rough feature on time, the answer should not depend on which manager they happen to report to. It should be encoded in a principle that the whole team understands and has agreed to.
There is an important distinction between company values and team operating principles. Company values are broad: "Move fast," "Put customers first." These are fine as guardrails, but they do not help a designer decide whether to invest an extra sprint in accessibility testing or ship what they have. Team operating principles sit underneath company values and translate them into actionable guidance for the specific tradeoffs designers face.
When I was running Compass of Design, the implicit principle was something like "learn by doing and sharing, not by gatekeeping credentials." That worked when the community was small and self-selecting. But as it grew, I started seeing behaviors that conflicted with that principle -- members being dismissive of questions they considered too basic, or elevating formal education over demonstrated skill. The principle existed in my head, but I had never written it down or made it a visible part of the community's identity. By the time I recognized the drift, correcting it required more effort than codifying it would have in the first place.
What Design Community Principles Look Like in Practice
The best design team principles share a few characteristics. They are specific enough to be useful, memorable enough to be recalled in the moment, and honest enough to reflect actual tradeoffs rather than aspirational platitudes.
Dropbox's design team built their principles around phrases like "Design with data" and "Ship to learn." These are not generic. "Design with data" tells a designer that intuition alone is not sufficient for major decisions -- the team expects evidence. "Ship to learn" tells a designer that a scrappy release that generates real user feedback is more valuable than a polished release that never gets validated. Both principles encode a specific stance on a real tradeoff that designers face constantly.
Salesforce, operating at a much larger scale with hundreds of designers across product lines, developed a principle they call "Be a multiplier." In practice, this means a senior designer's work is measured not just by what they ship personally, but by how much they enable others to ship better work. That principle directly influences how the team evaluates performance, how they structure design critiques, and who gets promoted. It is not a poster. It is an operating rule.
Spotify embedded their design principles into the squad model, where small autonomous teams operate without centralized enforcement. Principles like making the complex simple and designing for trust had to be internalized deeply enough to guide decisions when no design lead was in the room.
The structure that works best: three to five principles, each with a short explanation and one or two behavioral examples. More than five and people cannot remember them. The behavioral examples are critical -- they translate an abstract principle into "here is what this looks like on a Tuesday afternoon when you are deciding what to do."
How to Develop Principles for Your Team
The single most important thing about developing principles is that the team needs to co-create them. Principles handed down from a manager's offsite carry no weight. Principles that emerge from honest team conversation about what matters carry enormous weight, because people defend what they helped build.
The workshop format I have seen work best starts with three questions. What do we actually value -- not what we think we should value, but what we reward and gravitate toward? What behaviors frustrate us? And what decisions do we keep having the same argument about? That last question is the most productive, because recurring arguments are almost always a sign of a missing principle.
When I ran Compass of Design, the recurring argument was about depth versus breadth. Some members wanted the community to go deep on specific skills -- letterform anatomy, color theory, grid systems. Others wanted it to stay broad and accessible, covering freelance business, portfolio strategy, and career navigation. Both perspectives were valid. The tension was productive when it was acknowledged, but destructive when it played out as passive-aggressive criticism of each other's contributions. A principle like "we go as deep as the topic demands, but we never make depth a gatekeeping mechanism" would have resolved months of friction if I had articulated it early.
There is a useful test for whether a principle is specific enough: does it help you make a decision you would not have made otherwise? "We value quality" is not a principle. Every team values quality. It does not help you choose between two reasonable options. "We will delay a launch by one sprint if accessibility testing is incomplete" is a principle. It tells you exactly what to do in a specific situation where reasonable people might disagree. If a principle applies to every team everywhere, it is too generic to be useful.
Bottom-up development does not mean the manager abdicates responsibility. Someone needs to facilitate, synthesize themes, and push back when a proposed principle is too vague or contradicts another. The manager's role is to guide the process and ensure rigor, not to dictate content.
Operationalizing Principles
A principle that lives in a Notion doc nobody reads is not a principle. It is a memo. Principles only matter if they show up in the team's daily operating rhythm. There are four places where principles need to be actively present.
Design critiques. This is the most natural integration point. When a designer presents work, the critique should explicitly reference team principles. Not as a checklist, but as a lens. "This solution is polished, but does it align with our principle of shipping to learn? Could we test a rougher version first and iterate based on data?" When principles become part of the critique vocabulary, they stop being abstract and start shaping actual design decisions in real time.
In Compass of Design, our critique sessions were one of the most valued parts of the community. What made them productive was a shared understanding that feedback should be constructive, specific, and oriented toward the designer's stated goal. That was an implicit principle. If I had made it explicit, the quality bar would have been more consistent across facilitators and time zones.
Hiring. Principles should directly inform interview questions. If your team values "design with data," ask candidates to describe a time they changed a design decision based on data. If you value "be a multiplier," ask for a situation where they made another designer's work better without being asked. Hiring against principles ensures new team members arrive already aligned with how the team operates.
Onboarding. New team members should learn the principles in their first week, and they should learn them through stories, not slides. Each principle should come with a real example from the team's recent history: "Here is a time we lived this principle and it worked. Here is a time we did not and it caused problems." Stories make principles sticky in a way that bullet points cannot. At enterprise scale, Salesforce and similar organizations assign onboarding buddies whose explicit role includes modeling and explaining team principles during the new hire's first thirty days.
Retrospectives. Every team retro should include a brief check on whether the team is living its principles. This does not need to be formal. A simple question at the end of each retro -- "Did any of our principles help us this sprint? Did we violate any?" -- keeps principles in active circulation and creates a natural feedback loop. If the team consistently reports that a principle did not come up or was not relevant, that is a signal that the principle may need to be revised or retired.
Lessons from Scaling a Design Community
Running Compass of Design for two years taught me things about community principles that I have since applied to every design team I have worked with. The lessons translate directly because the dynamics are the same: a group of people with shared interests but different backgrounds, experience levels, and communication styles, trying to do good work together.
The first lesson is that principles need to be visible at the point of entry. In Compass of Design, new members joined through different channels -- the newsletter, a direct Slack link, a shared article. Those who arrived without context were the ones most likely to violate community norms, not out of bad intent, but out of ignorance. Consistent onboarding across every entry point is not optional at scale.
The second lesson is that the leader's behavior sets the principle, regardless of what is written down. In Compass of Design, when I was engaged and modeling the behavior I wanted to see, the community reflected that. When I was stretched thin and less present, the tone drifted. This is equally true for design managers. Your team watches what you do far more carefully than what you say. If your principles say "ship to learn" but you personally polish every project for three months before releasing it, your team will follow your behavior, not your principles.
The third lesson is that curated resources are a form of cultural expression. The 78 books I curated for Compass of Design were not just a reading list -- they were a statement about what the community valued: practical craft skills, ethical design thinking, freelance sustainability, typographic excellence. Design teams can use the same approach. A curated list of talks, case studies, and tools that reflect the team's principles is a cultural artifact that shapes how people think even outside of work hours.
The fourth lesson is that community health requires active maintenance, not just initial setup. Writing principles is the easy part. Maintaining them through personnel changes, strategy shifts, organizational turbulence, and plain old entropy is the hard part. I closed Compass of Design in 2022 not because the principles failed but because maintaining a community at scale requires sustained energy that I was directing elsewhere. Design teams have an advantage that volunteer communities do not: they have organizational structure, paid time, and managerial authority to invest in culture maintenance. Use those advantages deliberately.
Evolving Principles Over Time
Principles are not permanent. They are appropriate for a specific team at a specific stage. What serves a five-person team building its first product is different from what serves a fifty-person team maintaining a design system across six product lines. Treating principles as immutable leads to the same rigidity that having no principles leads to -- people either ignore them or follow them dogmatically, neither of which helps.
Three signals tell you it is time to revisit. The first is a significant change in team size -- if your team doubles, the new half had no hand in creating the principles and may not feel ownership. Revisiting restores that ownership. The second is a strategy shift. "Ship to learn" means something different when your users are individual consumers versus enterprise procurement teams with eighteen-month evaluation cycles. The third is repeated friction that the current principles do not resolve. If the same argument keeps happening and your principles do not help settle it, you are either missing a principle or an existing one is too vague.
When you sunset a principle, document why. Institutional memory matters. Future team members will wonder why the team operates the way it does, and having a record of "we used to value X, but we moved away from it because Y" prevents the same debates from recurring every eighteen months. At Compass of Design, I documented the evolution of our content strategy across 43 articles -- you can trace the shift from broad career guidance to deeper craft education over time. That documented evolution was itself a useful resource for understanding what the community needed at each stage.
Getting Started
If your design team does not have explicit operating principles, start small. Block ninety minutes with your team. Ask the three questions: what do we value, what frustrates us, and what decisions do we keep arguing about. Capture everything. Then take a week to synthesize the themes into three to five candidate principles, each with a one-sentence explanation and a behavioral example. Bring them back to the team for feedback. Refine until the team feels genuine ownership.
Then put them to work. Reference them in your next critique. Use them in your next interview. Include them in your next onboarding session. Revisit them at your next quarterly retro.
Principles are not a bureaucratic exercise. They are the operating system of your team's culture. The teams I have seen thrive at scale -- at Dropbox, at Salesforce, at Spotify, and in the small community I built from scratch -- are the ones that took the time to articulate what they believe, made those beliefs visible in daily practice, and had the discipline to evolve them as the team and the work changed. That deliberateness is the difference between a team that scales gracefully and a team that grows apart.