We have our product strategy. We have strategic alignment. We have a single prioritised roadmap.

Unified Engineering allows us to map our efforts directly to that roadmap.

At Joyous, all engineers are part of a single team. Our team has shared ownership of the whole codebase. Engineers work on roadmap items in priority order.

As items complete the freed engineers start on the next item or help with ongoing items.

Unified engineering is the opposite of the Spotify squad model. No silos, no dependencies, no arbitrary splits. One roadmap, one engineering team.

Unified engineering consists of the following principles:

Shared ownership of the code base

All engineers are full stack and are able to contribute to all portions of the codebase. No individual or group of individuals has ownership over any section of code.

The code base is considered as a whole, not as parts.

A shared understanding of the code base

This is very important to enable all engineers to work on any part of the code base.

We achieve this by:

• Developing a code base that is homogeneous in nature. Moving from one section of the code base to another is as simple as possible.
• Ensuring there is awareness across the engineering team on how the code base is changing.
• Describing changes that are occurring in the code base. We do this in weekly catchups and presentations of how new features work under the hood.
• Ensuring that every piece of work is supported by an engineer that has a deep understanding of the area.

A shared set of tools, standards and practices

If we want a shared understanding the code base must be easy to understand.

We achieve this primarily through two means:

• Limiting the number of tools and technologies we use.
• Using a shared set of standards and practices across the code base.

For example at Joyous we use TypeScript for everything.

• Our front end is TypeScript (React)
• Our backend is TypeScript (NodeJS)
• Our scripting is TypeScript (NodeJS)
• Our CI/CD is Typescript (Custom Github actions)
• Our infrastructure is codified in TypeScript (Pulumi)

We have a single defined way of writing TypeScript. We enforce this standard through compiler options, tools and pull request reviews. We use Prettier (code formatting) and ESLint (static code analysis).

A focus on keeping the codebase simple

To keep the cognitive load of engineering low, we write as little code as we can. We try to only write code that deals with business logic. We try to keep business concerns simple and separated from one another. We don't force separation as this adds its own flavour of complexity.

A few guidelines we follow:

• Prefer managed solutions
• Prefer the simplest solution that meets the requirements
• Build for known use cases and known future requirements, not for possible futures
• Abstract and extract stand-alone application complexity to self-contained modules.

Unified engineering leads to needing fewer engineers. All engineers are focusing on the top business priorities at all times.

With Unified Engineering we achieve our goals with a smaller and more efficient team. Engineering Crews describes how we scaled unified engineering.