Protect Your Engineering Culture As You Scale: Write Down Your Team’s Cultural Manifesto

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.

IMVU’s Agile Engineering Process — Interview with Clinton Keith of Agile Game Development

I spent a day hosting Clinton Keith in the IMVU offices during the Game Developer’s Conference in March, and I spent time describing IMVU’s product development process and our implementation of Agile and Lean Startup methodologies. He heard a lot of interest in our success from people at GDC he spoke to about IMVU, and he asked if I would do a Q&A session. Here is an excerpt of our interview posted to his Agile Game Development Blog:


Agile Game Interview – Agile Engineering for Online Communities 

James Birchler is an Engineering Director at IMVU, where he implemented and manages IMVU’s product development process using Agile and Lean Startup methodologies. Prior to joining IMVU in 2006, he redesigned the product development process at Bargain Network, Inc., helping complete the company’s acquisition by Vertrue, Inc. Previously, James was a Director at There.com, responsible for technical design, creative design, and content of the web applications and GUI for There’s virtual world application. James will be presenting on Lean Startup methodologies at the Startup Lessons Learned Conference on April 23 in San Francisco, and is a frequent contributor to the IMVU Engineering Blog.

Clinton Keith: What is IMVU?

James Birchler: IMVU, Inc. (www.imvu.com) is an online community where members use 3D avatars to meet new people, chat, create and play with their friends. IMVU has reached 40 million registered users, 10 million unique visitors per month and a $30+ million annualized revenue run rate. IMVU has the world’s largest virtual goods catalog of more than 3 million items, almost all of which are created by its own members.  IMVU achieved profitability in 2009 and is hiring aggressively with plans to double the size of its team in 2010.

CK: What is the overview of the IMVU engineering process?

JB: Our engineering team practices what people refer to as “Agile” or “Lean Startup” methodologies, including Test-Driven Development (TDD), pair programming, collective code ownership, and continuous integration. We refactor code relentlessly, and try to ship code in small batches. And we’ve taken continuous integration a step further: every time we check in server side code, we push the changes to our production servers immediately after the code passes our automated tests. In practice, this means we push code live to our production web servers 35-50 times per day. Taken together with our A/B split-testing framework, which we use to collect data to inform our product development decisions, we have the ability to quickly see and test the effects of new features live in production. We also practice “5 Whys” root cause analysis when something goes wrong, to avoid making the same mistakes twice.

CK: How do you get so many changes out in front of customers without causing problems, either for your customers or your production web servers?

JB: I think it’s important to point out that sometimes we actually do introduce regressions and new bugs that impact our customers.  However, we try to strike a balance between minimizing negative customer impacts and maximizing our ability to innovate and test new features with real customers as early as possible. We have several mechanisms we use to help us do that, and to control how customers experience our changes. It boils down to automation on one hand, and our QA engineers on the other.

First the automation: we take TDD very seriously, and it’s an important part of our engineering culture. We try to write tests for all of our code, and when we fix bugs, we write tests to ensure they don’t regress. Next, we built our code deployment process to include what we call our “cluster immune system,” which monitors and alerts on statistically significant changes in dozens of key error rates and business metrics. If a problem is detected, the code is automatically rolled back and our engineering and operations teams are notified. Next, we have the ability to limit rollout of a feature to one or more groups of customers–so we can expose new features to only QA or Admin users, or ad-hoc customer sets. We also built an incremental rollout function that allows us to slowly increase exposure to customers while we monitor both technical and business metrics to ensure there are no big problems with how the features work in production. Finally, we build in a “kill switch” to most of our applications, so that if any problems occur later, for example, scaling issues, we have fine-grained control to turn off problematic features while we fix them.


Read the rest of Agile Game Interview – Agile Engineering for Online Communities …

IMVU’s Approach to Integrating Quality Assurance with Continuous Deployment (for IMVU Engineering Blog)

When I started managing IMVU’s Quality Assurance team about 18 months ago, we were just beginning to implement big changes to our product development process. Some of those changes were in the area of quality assurance, and I finally got around to writing about how QA actually functions today at IMVU. Here is an excerpt:


IMVU’s Approach to Integrating Quality Assurance with Continuous Deployment

We’ve heard a lot of interest from folks we’ve talked to in the tech community and at conferences about our Continuous Deployment process at IMVU, and how we push code up to 50 times a day. We’ve also received some questions about how we do this without introducing regressions and new bugs into our product, and how we approach Quality Assurance in this fast-paced environment.

The reality is that we occasionally do negatively impact customers due to our high velocity and drive to deliver features to our customers and to learn from them. Sometimes we impact them by delivering a feature that isn’t valuable, and sometimes we introduce regressions or new bugs into our production environment.

But we’ve delivered features our customers didn’t like even when we were moving more slowly and carefully—and it was actually more costly because it took us longer to learn and change our direction. For example, we once spent more than a month of development time working on a feature called Updates–similar to the Facebook “friend feed”, and we guessed wrong–way wrong–about how our customers would use that feature.  It took us a way too long to ship a feature nobody actually wanted, and the result was that we delayed delivery of a feature that our customers were dying to have: Groups.

Asking customers what they want takes guesswork and internal employee opinions out of product development decisions, making it easy to resolve questions such as, “Should we build tools to let users categorize their avatar outfits, or should we build a search tool, or both?”  We make the best decisions we can based on available customer data, competitive analysis, and our combined experience and insights—then build our features as quickly as possible to test them with customers to see if we were right.


Read the rest of IMVU’s Approach to Integrating Quality Assurance with Continuous Deployment

It’s Hack Week at IMVU (for IMVU Engineering Blog)

I helped launch the IMVU Engineering Blog two weeks ago as a Hack Week project. The first posting to that blog is an explanation of Hack Week and how we do it at IMVU, authored by myself and Roland Blanton, an Engineering Manager at IMVU. Here is an excerpt:


It’s Hack Week at IMVU

Yesterday we kicked off another Hack Week at IMVU, a solid week when we put product development in the hands of IMVU engineers. What does this mean? An engineer can spend the week working on something they personally feel is valuable to the company. It’s a way to harness experience and insights from across the company and give everyone more ownership over what we are building here. The buzz in the building is tangible: there are fewer meetings, less process around group work, and people are focused on finishing their features to put them in front of customers.

Hack Week has been an integral part of our engineering culture since 2007, giving our software engineers a chance to guide product development and test their ideas. This tradition has resulted in many popular features like Outfits ManagementTurbo Product Loading of 3D assets, IMVU Badges, and shopping directly from a 3D chat. All these features were driven by IMVU engineers during past Hack Weeks and then adopted by our product teams for release to all customers.


Read the rest of It’s Hack Week at IMVU