Team Organization

Hero image for Team Organization

Armed with a clear set of roles, the next step is to define how these different types of professionals can work together efficiently. The way the team currently works — just like everything else — has been constantly evolving to fit its needs while still being true to the core principles.

Team members can have an overview of the current team organization on Notion.

Methodology

As the team grew, it was necessary to formalize the sub-roles and sub-groups within the whole team to make groups’ and individuals’ responsibilities and boundaries clearer. The team recognizes itself in the Agile methodology - theorized by Henrik Kniberg and Anders Ivarsson - as it represents closely how the team is working with the added benefit of a clearer nomenclature. The team’s organization structure also has specific deviations from this nomenclature to accommodate custom needs.

The team is organized into several units called Squads, Chapters, Guilds, and Areas.

Squads

Organization - Squad

  • Squads are the building blocks of individuals for projects.
  • Each project - whether for a client or for an internal purpose - has a dedicated cross-functional squad composed of 1 Product Manager (PM), 1 UX/UI Designer, 1 Engineering Lead (EL), 1 Team Lead Developer and 2-3 developers.
  • Squad members have end-to-end responsibility for the whole project. So it can be compared to a mini-startup.
  • A squad is self-organizing so they have freedom of their product and technical choices. Their decisions are only limited by the client’s and/or the company’s mission.
  • The Product Manager is an integral part of the squad i.e. squad members do not report to the Product Manager but work with him/her just like any other squad member.
  • A squad has the following rituals:
    • Daily standups
    • Weekly sprint planning
    • Weekly sprint reviews

Chapters

  • Chapters regroup individuals who share mastery in a skill and/or domain i.e. people who do similar work. The team has the following chapters:
    • Android Chapter
    • iOS Chapter
    • Product Chapter
    • Web Chapter
  • The purpose of a chapter is to share knowledge, to learn from each other, and to reduce the silo effect and sense of isolation. As not all chapter members are part of the same squad, it allows to reconnect all members together and share knowledge across projects.
  • Chapters are led by a Chapter Lead. Chapter leads are rotated every 6 months. Just like squads, leads are not bosses but instead are servant leaders whose main purpose is to support and focus on nurturing and growing the chapter members as individuals but also as a group.
  • A chapter has only one ritual: Bi-weekly retrospectives.

Because the team aims for developers to work in all areas of web development, there are currently no Front-end Chapter or Backend Chapter contrary to many companies who adopted a similar methodology.

Guilds

  • A guild is an open group around an interest so anyone can join or leave any guild. Some of the existing guilds are:
    • Infrastructure Guild (devops)
    • Security Guild
    • Ruby Guild
    • React JS Guild
  • The purpose of a guild is also to share knowledge and instigate new initiatives.
  • A guild is led by a Coordinator.
  • A guild has no compulsory ritual but each coordinator can decide to have a Monthly retrospectives.

All guild activities are optional by default.

Areas

The company superstructure consists of four business areas:

  • Business Operations
    • Managed by the CEO.
    • Includes the following sub-areas:
      • Office Operations
      • People Operations
      • Talent Acquisition
        Each sub-area is managed by a manager and is comprised of associates.
  • Engineering
    • Managed by the CTO.
    • Supported by Engineering Leads.
    • Comprised of software developers.
  • Product
    • Managed by the CPO.
    • Comprised of product managers and UX/UI designers.
  • Sales
    • Managed by the CEO.
    • Supported by the Sales Managers.
    • Comprised of business development associates.

Each area has distinct rituals but the following rituals are usually followed:

  • Daily standups.
  • Weekly or monthly planning sessions.

In Practice

Each teammate can be a member of multiple squads, chapters, guilds and tribes as they can be involved in many internal and external efforts. These overlaps - which are quite normal - could be very confusing and create inefficiencies without a proper nomenclature.

Developer

A Developer has these standard memberships:

  • One client-project squad as clients are provided with dedicated squads hence guarantee that the developers work on only one project at any given time.
  • At least one Chapter (Android, iOS or Web) or multiple based on their skill sets.
  • One or more Guilds based on their interests.
  • Engineering Area.

Product Manager

A Product Manager has these standard memberships:

  • At least one but usually multiple client-project squad(s). Contrary to development, Product Management is not always a full-time activity hence the involvement of Product Managers in multiple squads.
  • Product Chapter.
  • One or more Guilds based on their interests.
  • Product Area.

UX/UI Designer

A UX/UI Designer has these standard memberships:

  • At least one but usually multiple client-project squad(s). Contrary to development, UX/UI is rarely a full-time activity during the whole lifetime of a project hence the involvement of UX/UI designers in multiple squads.
  • Product Chapter.
  • Product Area.

In addition, a UX/UI Designer might have the following optional memberships:

  • One or more other Chapters (Android, iOS or Web) based on their skill sets.
  • One or more Guilds based on their interests.

Rotation

Whether it is a client project or an internal project/activity, each teammate has the opportunity to be involved in more than one effort during his/her journey at our company.

Rotations are formalized by following a simple half-year schedule: January -> June and July -> December. This schedule applies for both squads members working in long-running projects (over 6 months) and chapter leads rotation.

Organization - Squad

This standard rotation schedule defines when a rotation can occur or be planned for a teammate. After working for six months on a project, an Engineering Lead can recommend a rotation for one of their reports and/or a developer can request a rotation. When a project has a shorter duration, rotations are avoided for the continuity of the project.

Outside of this schedule, punctual rotations of some teammates can also happen to accommodate new projects based on the skill set required. In these cases, the same processes are followed as for standard rotations.

Guide for efficient squad rotations ⚡

Rotations aim at developing group ownership while still allowing the individual growth of every teammate.

Group Ownership

It is not only what we do, but also what we do not do, for which we are accountable. – Moliere

Every teammate must have an ownership mentality in any effort we undertake to fulfill the company’s mission. But this ownership must be achieved with the rest of the team in mind.

For developers, it means that a line of code or a feature does not belong to one person only. Instead, any developer on the team can pick up where another developer left off with ease and efficiency. In order for us to achieve this, we must work on and enforce team conventions on how we develop software applications. The same applies to Product Managers and UX/UI designers.

It makes everyone responsible to always deliver work with the whole team in mind. In case of challenges or issues, it also avoids any blame game as we - as a team - are responsible for what we deliver.

Individual Growth

Each teammate joins the company at different stages in their individual path i.e. some joined us at junior level while others at mid-senior, senior or principal level. At the same time, everyone grows at a different pace following our growth tracks so it’s critical to account for this disparity. Eventually, each teammate actually needs to be given the opportunity and the chance to show how he/she can handle new situations and grow from it.

When rotating between squads, each teammate has the opportunity to work on different systems and in various domains. A teammate can work on a Ruby-based application for a European Healthcare startup then work on a Go-based Loyalty Management system for a large Asian corporation. The challenges and solutions are different from one project to another. As a result, teammates acquire new knowledge faster and develop broader skills.

The roles of Team Lead and Chapter Lead are opportunities to demonstrate leadership skills without being the most senior team member. For instance, the Team Lead of a squad could be the teammate who knows the domain or the project the most, had the longest tenure at the company compared to the other developers, or must lead a project to fulfill one of his/her objectives for his/her growth track.

When it comes to rotations, the Product Chapter is in charge of both planning and implementation. As much as possible, we attempt to accommodate the individual preferences but we also need to cater to business needs and projects priorities.