Culture eats strategy for breakfast. —Peter Drucker   Tweet this.

I frequently speak with startup founders and leaders who are growing and scaling their teams, and among the most common questions I hear are about building and maintaining engineering team culture. This is because that while establishing the culture you want at your startup is hard, maintaining it as you scale can be even harder. I’d like to share a few of the lessons I’ve learned, some of them the hard way, during my last 15 years working with engineering teams.

Scaling your team can wreak havoc on your established culture, overwhelming it with surprising speed as new hires bring fresh ideas and expectations about how your teams function and collaborate — but only if you let it.

In other words, the real threat to your culture is not your newcomers, it is the challenge of being mindful and selective about what you decide to incorporate.

A written manifesto is a simple and effective tool to manage the evolution of your culture to maintain its core attributes.

Culture is the manifestation of the customs, institutions, attitudes, behaviors, and achievements of a group, regarded collectively. In other words, culture is both a product and a process. Your culture evolves—either maintaining or changing—every day in the myriad ways you and your team interact, converse, and collaborate, literally manifesting your culture and making it obvious to all. Your culture is a living archive of all your team has done together.

Your culture is a living archive of all your team has done together. Tweet this.

When you hire new people to scale your team, they begin with none of the rich background of your culture that you and your team have created, lived, and made manifest over time. Unless you create a way for your new team members to access your archive of cultural history, they are going to have a hard time maintaining the culture you built.

By writing down your team’s manifesto—a public declaration of your culture and the standards by which you agree to practice, operate, and be held accountable—you are creating a concrete artifact. Your manifesto if powerful because it goes beyond ephemeral words and actions: it becomes a referent for your team members, both new and old, to use as a waypoint as they navigate their daily choices of words and deeds which when combined, either reinforce or undermine your culture.

I recommend a basic process framework for creating written artifacts which allows for input from all quarters to ensure buy in, while avoiding the paralysis of “design by committee.” Start with ideas, build to a proposal, and finally present a recommendation for adoption.

It is important to communicate this overall process to your team to set expectations and ensure everyone understands when and how they will have input. The goal here is to have your team bought in, and it is important that people feel like they have a voice in the process.

When you’re ready to write your manifesto, start with a core group of leaders and ask them author the manifesto with you. Begin with an idea brainstorm, and ask them to begin drafting a proposal. As they share versions of the manifesto, ask them to incorporate feedback from others in a way that authentically captures the feedback. This is challenging work, as they will need to balance a variety of perspectives. Do not rush this process, and expect this may take several weeks from start to finish.

Make your first shares to a small but diverse set of individuals who can quickly provide feedback to ensure your proposal is directionally correct. From there, share it with your entire team, inviting input, comments, and feedback. Share new versions of the revised manifesto periodically rather than in real time to allow for the team drafting the document to think through, discuss, and carefully craft their revisions.

Here are some sample statements from real engineering team manifestos. You’ll see they cover a wide range of issues around how my teams have chosen to work together, from the practice of software engineering to mindset and communication:

We develop and test our code in a safe and controlled manner using modern tools and processes. We are careful to isolate potential instability in shared environments, services, and data. We consider and plan for potential areas of risk, mitigating them whenever possible.

For any project, we always determine how we will measure its success or failure, and how we will respond to either of these outcomes, and we commit to that follow-up work.

We work iteratively, shipping products quickly to test our riskiest assumptions first to validate our ideas and learn quickly. We practice the 80/20 rule, and believe that rapid iteration, “Launch and Learn,” is a better strategy to deliver value to our customers than seeking perfection before shipping.

We mix modern best practices with pragmatic choices to craft software we are proud of.

Every bug we fix or new feature we build has automated test coverage. If it’s hard to write tests for something, we figure out why and fix it so that it won’t be hard in the future. Code without tests is our “nuclear option” – a last resort and a decision that we make reluctantly and rarely.

We leave each piece of code we touch better than we found it. We refactor and clean up code, but we’re careful to prioritize that work based on the value it delivers to customers, or whether it makes it easier to change the code in the future.

We actively support one another. We create safe spaces for communication so we can feel safe being vulnerable to speak candidly, and ask for help when we need it. We want it to feel comfortable to both seek and offer help.

We take the time to reflect on, learn from, and talk candidly about both our successes and our mistakes. We practice retrospectives and debriefs to capture learnings so we can repeat the good and discontinue the bad. We assume positive intent, and seek understanding not blame.

We use processes as guides, but do not follow them blindly. We expect our processes to change as our context and awareness changes, and as we learn and grow.

Once your team has a version of the manifesto they feel represents your culture and the standards by which the team agrees to practice, operate by, and be held accountable to, ask them to present it as a formal recommendation to the approver (usually the VPE or CTO for an engineering team).

At this point, everyone on the team ought to be familiar with the manifesto, and when you ask they should tell you that it resonates strongly with them. If this is not the case, send the recommendation back for more revisions.

If it is ready, it’s time to roll it out. Plan to communicate your manifesto in multiple venues and using every possible medium. Add a copy to your engineering department wiki or documentation, and provide pointers everywhere your team hangs out online: pin it to your team Slack channel, email to your team list, post in IRC — and in all cases make sure it’s archived and searchable. Make posters and print copies of your manifesto and display them prominently.

Next, hold a ceremony at your next engineering team allhands to announce your manifesto and celebrate it — make it real. Announce it at the company allhands, too, ensure that everyone knows how your team plans to hold itself accountable to delivering for customers and the business. Ensure your managers know to revisit your manifesto regularly, until it too is part of your team’s regular practice of engineering and its culture.

Image Credit: Image cropped from “science” by Robert Couse-Barker, Creative Commons License.