Chapter Management Model

Photo by Waranont (Joe) on Unsplash

TL;DR

This article gives a recipe for how to unify a company’s technical stack and always get up-to-date technical documentation that contains information about projects from different teams.

What is a Chapter?

Chapters are groups of organisation members working within a particular field. They have the same functional or technical skills.

These teams do not have specific responsibilities for delivering business value, but they do assist in building standard tools, methods, and ways of working.

The FE chapter is highlighted in green. The number of software engineers is represented in the circles.

“FE” STANDS FOR FRONT END, CLIENT-SIDE OF THE APPLICATION

This refers to the part of a software application or website that the user interacts with directly. It includes the graphical user interface, as well as any other elements that are visible to the user, such as buttons, menus, and forms.

Please note, I am not going to describe the Spotify model in detail, you can read it yourself based on this article from Atlassian as well as the original source — this whitepaper. It is worth noting that the Spotify model is not a framework, but rather an attempt to structure the departments within a company. Then the personal tailoring of the solution, according to the problems of a particular organisation, begins.

Initial Problems List

Squads frequently make independent decisions regarding the technical stack, often doing so in isolation and during distinct time periods. As a result, the overall scenario might appear as follows:

Decomposition based on the chapter technologies used from the previous illustration.

Although everyone uses the same programming language (in this case JavaScript), teams or specific managers may choose different frameworks, libraries, DVCS providers, etc.).

As mentioned in one of our articles,

“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.” — Bertrand Russell.

so let’s do that:

• Teams are divided, and developers may not know each other. Or even if they do, they don’t communicate.
• Developers from different teams (squads) do not have a basic understanding of how neighboring squads organise their projects, so there is no way to request a code review when needed​.
• The technical stack and documentation are not standardised.
• No platform for developers to interact with the design / arch / QA / DevOps / etc. department​.
• No audit of technical debt, accumulation of obsolescence.​
• There is a lack of insight into the qualifications of chapter participants and their aspirations to learn.​
• Non-chapter members (e.g. non-frontenders) were interviewing front-end candidates. But anyway, there are no materials based on projects for job-interviews.​

If your organisation is facing similar problems or some of them, perhaps this guide will help you review the situation.

Solution

To make it easier to manage, let’s divide the problem-solving tasks into three circuits:

• LEARN will cover topics like “A promising technical stack for creating a new project or adapting existing ones”. This direction improves the developer experience (DX), delivery speed, but also impacts non-functional requirements (NFR), whether it’s security, performance or maintainability.
• The goal of SYNC is to solve the problem of team disconnection and create a single source of truth. SYNC focuses on documentation and workshops based on existing documentation and it’s goal — integrating knowledge into a coherent system.
• The example of HIRE will be a list of job-interview questions based on real organisation projects/issues and community awareness of our organisation activities.

Now knowing the directions, let’s identify 6 main tools that will help to interact within those directions:

I highly recommend using tools that are already in use in your company.

The path of unification will help you reduce costs, improve the ease and efficiency of your teams’ work!

Main concept

As you may have noticed, the “Stable chapter wiki” is the core tool — there’s a reason why I’ve highlighted it in a different colour than the other tools.

The idea is to create a documentation portal that always contains up-to-date information.

However, this will obviously require preparation.

There are 2 major impediments at this stage: the lack of unification in the technical stack and the absence of a workflow that includes keeping the documentation up to date.

It is not enough just to create an alternative documentation system. It must be incorporated into the routine process of the squads at management level.

01 — Projects

Let’s deal with the unification of the technical stack:

Adapting projects to a single stack will enable common conventions to be applied and allow developers to unite around a universal technology.

It’s getting much better, but it’s still not perfect. Projects are located in different places.

The monorepo made it easier for all chapter members access to the codebase.

It should also be noted that we can now also unify our UI by creating a design system and a reusable component library based on it.

02 — Docs

Documentation is also part of the monorepo. All content is created in markdown format.

03 — Monthly Meetings

The monthly meeting includes a review of documentation changes for each project by Git pull request submitters.

What is a Monthly Meeting?

• Scheduled on the last Thursday of each month (or the following Thursday if necessary).
• Highly recommended for all FE chapter participants.

Note: While the meeting is primarily tailored for front-end developers, it is open to a broader audience, including team leaders, tech leaders, invited guests from other chapters, product managers, designers, and professionals with a keen interest in front-end development.

Purpose of the Monthly Meeting:

• Accumulation and sharing of knowledge within the stable chapter wiki.
• Keeping knowledge up-to-date with the latest industry trends.
• Synchronization among teams for better collaboration.

Agenda:

• Updates from one representative of each team, highlighting significant changes in projects from the past month. This may include new features, updates to existing features, and whether these changes necessitate additions to documentation.
• Presentation of Pull Requests with documentation or Spikes, showcasing the progress made in the last month.
• Backlog refinement: ensuring the chapter backlog is well-maintained and up-to-date.
• Planning commitments for the upcoming month.

04 — Stable chapter wiki

Why do we need a separate portal when we already have operational corporate wiki (e.g. Confluence or Notion)?

The operational corporate wiki lacks a pull request mechanism. It is desired that every member of the chapter actively participates in reviewing the added materials and stays informed about them. In corporate wiki, a page can be added without anyone being aware of it. Although it can be mentioned, a tool that mandates action from the participant is preferred.

What is the intended long-term outcome?

1. All chapter members possess a basic understanding of all front-end projects and can assist in conducting code reviews when a colleague is unavailable (due to vacation or illness) [SYNC circuit].
2. Chapter members experience reduced stress when transitioning between squads/projects, thanks to consistent updates provided during monthly meetings and access to up-to-date documentation [SYNC circuit].
3. Each participant contributes a short presentation based on their work, occasionally crafting public blog posts [SYNC, STUDY and HIRE circuits].
4. Integration of project-related questions into the knowledge base for use in job interviews. Development of a comprehensive job-interview question list derived from our actual projects, ensuring the ability to hire qualified and relevant developers whenever the need arises in the future [HIRE circuit].

Photo by Martin Sanchez on Unsplash

Thank you for your interest in this article!

Please clap, subscribe and stay tuned for upcoming related content that will delve deeper into today’s topic.

See you soon!