An Engineering Cultural Manifesto guide to help your company win

The single most valuable management tool while you’re scaling your engineering team is something I call a cultural manifesto. This is a document or a set of materials to help your entire engineering team get on the same page about how you make and operate things, and how you function as a team. – Kevin Scott

Kevin Scott, CTO of Microsoft, gave a talk to engineering leaders on the topic of structuring engineering teams for success. He proposed the notion of a Cultural Manifesto to crystallize and document the engineering team’s opinions, and make a commitment in print, on key areas related to how you make and operate things, and how you function as a team. A well-written Cultural Manifesto helps increase your engineering velocity and enables the engineering team to make the right trade offs.

This guide covers the steps to build your manifesto, and provides some examples to get you and your team reoriented on the ‘how’ line of inquiry.

Steps to build an Engineering Cultural Manifesto

1. Understand what your company, business, marketplace, and competitive environment need from your engineering team to help your company win. Focus on the appropriate factors since every company context is unique. Even over a short period, the context for an engineering team can drastically change. It is your responsibility as the leader, to be able to sense and adjust accordingly.
2. Clearly define the role of engineering, based on the context
3. Understand and document the characteristics that need to define your culture based on the role of engineering (eg. Agility, Frugality, Quality)
4. Understand and document the implications of the role of engineering on the technical and operational perspectives. Ask and write down the ‘how’, not ‘what’ questions related to how you make and operate things, and function as a team.
5. Document your ‘unique’ answers to the ‘how’ questions. These are your Principles (Opinions, Beliefs and Thoughts). Principles are rules to align what you are doing to the role of engineering. Any given principle may have both pros and cons that need to be weighed. Structure your points of view, and have sufficient detail so that people know how to implement the same.
6. Discuss with your team and keep evolving your principles. You should seek coordination, not consensus.

Role of Engineering/Culture & Values

1. How can we build a technology platform that would let us move fast and take huge amounts of risk? (Principle: Focus on Agility)
2. How can we leverage a huge set of high quality data to build a suite of products for power users? (Principle: Focus on Customer)
3. How can we revamp the computing architecture to overcome the struggle with problematic deployments? (Principle: Focus on Quality)

How We Make Things?

Coding Standards

1. How are we going to make sure our code base stays clean as we go from 5 developers to 50 to 500?

Programming Languages

1. How do we simplify our Ops stack? (Principle: Stick with technologies that we know)
2. How do we keep our development and maintenance costs low? (Principle: Adopt a monoglot architecture)

Testing

1. How do we enable testing that is not error prone and costly, in terms of man-hours? (Principle: Focus on Unit testing with a handful of integration tests)
2. How do we enable test coverage for important parts of the system? (Principle: Focus on Integration testing)
3. How do we enable non-breaking API changes? (Principle: Adopt a Documentation-first Strategy)
4. How do we make our test setup scalable? (Principle: Avoid Full stack in-a-box strategy/Adopt Cloud testing strategy/Adopt Shared test instances strategy)
5. How do we make our test approach lightweight? (Principle: Adopt Stubbed services strategy)
6. How can we design effective tests to maximize the value of testing? (Principle: Focus on Exploratory testing during pre-production testing)

How We Operate Things?

Fault Tolerance vs Manual Recovery

1. How do we think about automated fault tolerance vs manual recovery?

Monitoring & Alerting

1. How do we do monitoring & alerting?

How We Function as a Team?

Team Structure

1. How do we enable development teams to take more care during the development and testing stages to ensure each service is in ship shape? (Principle: Adopt decentralized governance with Service-based Delivery teams)
2. How do we enable teams to be responsible not for specific code but for customer-facing features? (Principle: Adopt Feature-based Delivery teams)
3. How do we promote our desired architecture (eg. Microservices)? (Principle: Adopt Infrastructure team + Delivery teams)

References

How I Structured Engineering Teams at LinkedIn and AdMob for Success, Kevin Scott

Microservices for Startups: Practical advice for teams considering Microservices, ButterCMS