⚙️

Engineering Manual

Manifesto

Mission

Our mission is to build the most developer-friendly and customizable CMS on the market.

Guiding principles

We do it for the users

The bottom line is everything we do delivers value to the users. Whether it’s the open-source community, customers, or partners our priority is to deliver valuable software to our users. we take a user-centric and solution-oriented approach to make pragmatic choices.

We make data-driven decisions and interact with users as frequently as possible to get the right data and insights.

Agile at heart

We strongly believe that the world is constantly evolving and changing around us. This also means software requirements and users’ needs change more rapidly than you can deliver software. This is why we try to follow the Agile principles in the way we work. If we were to summarise it, we try to follow the “iterate, learn, and increment” cycle when building Strapi. We aim to deliver value frequently, listen to user feedback and pain points and improve continuously the way we work and what we deliver in a consistent and sustainable way.

Engineering as a foundation

Being user-centric and value-focused is part of our fundamental principles, but it doesn’t mean Engineering should be left behind.

We build with care and take pride in our work. We believe it is the best way to deliver great software that will meet our and the user’s expectations. We monitor technical debt and eliminate it pragmatically, we focus on building maintainable and scalable software with quality in mind. We challenge ourselves and others with kindness.

We empower squads to be more and more autonomous and expect them to own what they deliver and as such, the team wins and loses together.

Values

How the Engineering team embodies the Strapi values?

  • Measured ambition: Delivering features and building things fast is crucial. However, we always try to do this with care and pragmatism.
  • Genuine humility: We learn every time we deliver. We observe with an open mind to always improve. There is no room for ego, we share our achievements and our failures and everyone’s voice in the team is worth being heard.
  • Proactive Responsibility: We value autonomy and ownership. However, we make sure we are aligned on practices, philosophy, and values. We empower teams to own what they deliver.
  • Rational transparency: We make pragmatic decisions transparently. We share opinions with an open mind. We disagree, and commit if necessary, and always with goodwill. Being open source at heart we do this in the open when it makes sense and as much as possible.
  • Active care: Care is one of our major daily concerns. We find it at every layer of our organization and work. We care about users. We care about our work and do it the best we can. We care about how we communicate as a team and how we improve. Last, but not least, we care about each other and ourselves.

How The Team Works

Team structure

The Engineering and Product teams share a common Squad organization. Each squad focuses on a user persona and has a specific mission.

  • Developer Experience
    • Persona: Developer
    • Mission: Be the most developer-friendly Headless CMS on the market
  • Content Editing Experience
    • Persona: Content editor
    • Mission: Create the best content editing experience on the market
  • Expansion
    • Persona: Contributor
    • Mission: Build the most active & qualitative open-source ecosystem
  • Growth
    • Persona: New User
    • Mission: Create a frictionless and seamless user experience
  • Tooling
    • Persona: Strapier
    • Mission: Create and maintain best-in-class (in house) critical tools
  • Cloud
    • Persona: Developer
    • Mission: Make deployment easier than a phone call

In a perfect world we would like each squad to be composed of the following people:

  • Engineering Manager
  • Software Engineer
  • Quality Assurance Engineer
  • Product Manager
  • Product Designer

This is a hard-to-reach ideal with the current tech industry hiring market but this is what we aim for. We believe this is the best setup for squads to reach maximum autonomy and velocity.

Team cadence

Here is the list of team meetings, events, and rituals we have in the engineering team.

Management:

  • Weekly 1-1: Every member of the team has a weekly 1-1 with their manager.
  • Quarterly meeting: Every member of the team has a quarterly 1-1 focused on performance, learning, and personal development.

Operations:

  • Agile Rituals: All the squads follow a sprint schedule of 2 weeks. Here is the list of recurring events:
    • Daily standup meeting: The goal is to share progress, roadblocks and discuss current topics.
    • Retrospective: The goal is to reflect on the last sprint and think about what we did great and what we could improve as a team. This is a great time to share good vibes, wins but also to discuss openly difficulties and frustrations. You should always go into this meeting with an open mind and care at heart.
    • Demo: Your team has done great things during the sprint? It’s time to share it with the rest of the company. This is a great time to show and tell what has been done and what’s coming next.
    • Sprint planning: This is the event where you bootstrap the upcoming sprint. You define as a team the sprint objective, what you will be working on and how you will get there.
    • Backlog review: This ritual aims at refining the scope and definition of user stories in the backlog. The goal is to make sure those user stories are ready to be developed during the upcoming sprint. The team usually goes over multiple aspects of the user stories like the management rules, the design, or the technical requirements.
  • Engineering manager sync: We take time to reflect on achievements and pain points during the week. This is a lot of glue work and cross-functional sync to make sure the organization as a whole works smoothly. This is also a good opportunity to discuss OKRs, Roadmap, and Vision on a regular basis.
  • Bi-Weekly Team Meeting: More tech-oriented teams have a bi-weekly meeting to discuss longer-term topics and share knowledge. We currently run Frontend and Backend syncs.
  • Bi-Annual cool down week: In early April and October, we have a cool-down period that lasts one or two weeks. We stop our daily tasks and take the opportunity to take a step back. We run team workshops, macro retrospectives and talk about vision and strategy. We do team-building events or work on topics that weren't defined as priority based on the company goals but that matter to us. It’s also a great chance to take time to work with people from completely different teams or departments on cross-functional or company topics.