Organization and processes
Teams or individuals. Squads or managers. Departments or owners. We don’t build digital products alone—we must collaborate to achieve outcomes. “Unity is strength,” as some mottos say. If individual work sometimes needs organization, group work needs it even more.
In this chapter we’ll talk about organization and processes where you can contribute to add more value. From here, the handbook becomes more pragmatic—at least for the next four chapters.
Synchronize the network
Group work comes before individual work. Working with people carries responsibilities—one of the most important is ensuring everyone knows what they need to know at the right time. Disseminating information is key, and so is understanding the different kinds of knowledge and how to share them.
Time‑sensitive knowledge
Time‑sensitive knowledge is information that matters now due to specific circumstances and loses value over time. For example: incidents or blockers.
Surface it as soon as possible—during daily stand‑ups or in Slack/Teams—but don’t overspend time communicating it.
Evergreen knowledge
Evergreen knowledge doesn’t expire; its value is not urgency but transcendence—like product documentation or decision‑making processes.
Here the “how” matters. Synthesizing dense information is an art valued in every discipline. Share it where it’s broadly accessible: Notion, Confluence, etc.
Detecting information, knowing who needs it and how to communicate it isn’t easy—especially in remote teams. Capture, understand, and share.
Leading the discipline’s future
In 2012, Spotify published how they structured engineering internally. It was a turning point—the first time a big tech company openly discussed Scrum, sharing their experience and the changes they made to adapt it.
How Spotify scales with Scrum.
Many companies adopted squads, tribes, and chapters without asking whether the model fit them. A decade later, Spotify revised its own model. Still, two ideas are compelling: chapters and guilds—forums where people of the same discipline or shared interests debate the future of their craft.
In practice, they’re similar; they differ mainly in scope (chapters focus on team/tribe; guilds can span the company).
Two strong outcomes:
- Better flow of ideas and knowledge; shared context avoids duplication.
- Acts as glue between teams; provides forums for expression and discipline‑level decision‑making at team, tribe, or company levels.
If your team/tribe lacks a frontend chapter, propose creating one. If you have one, participate—bring ideas that improve engineers’ day‑to‑day.
Help connect the dots
As an engineer, your knowledge goes beyond coding. You have full context of how the product is implemented—its strengths and Achilles’ heels. You know where it can scale and what needs review before building on top.
This context is invaluable when defining roadmaps, setting deadlines, or designing interactions.
Step outside your comfort zone—participate in product definition and design reviews. It leads to better solutions and fewer surprises later.
Know where we are and where we’re going
Engineers often get information top‑down; we don’t always know company or team goals at medium/long term horizons. It may seem irrelevant to development, but many scalability and tech debt issues arise from a lack of visibility into goals and product vision.
It’s true that long‑term direction isn’t always clear—especially at early stages before product‑market fit—but you can still align with those who do have a longer‑term view.
Join goal‑setting sessions, or at least ask for summaries so you remain aligned with the team.
Processes and organization are vast topics—we’d need half a lifetime to master them. The key takeaway: processes are meant to be broken (with care). They’re useful and better than chaos, but they’re not always the optimal way for everyone to solve a problem.
Embrace processes, live them, and adapt them to you, your situation, and your team.