About this Book

Compared to other industries, software products benefit from low upfront costs and low distribution efforts, enabling us to create cheap prototypes and deliver them to users globally with little overhead. Successful software companies adapt to rapid technological, economic, and political changes to viably compete in any market.

If we impair these traits with obtrusive organizational or technical processes, our business loses its ability to pivot with market changes. While it is not always necessary to act, the decision to do so should be driven by business factors, not technological limitations.

Within Engineering Collaboration, we discuss intramural strategies that have proven useful for a broad spectrum of organizations. We consider how we build autonomous, flexible, and collaborative teams and solve the apparent paradox of providing a stable and low-latency experience while continuously responding to user feedback and regulatory compliance.

Structure

Engineering Collaboration is structured into three sections, addressing engineering processes at two levels within our organization.

Collaborating within a Company covers organic cross-team collaboration while limiting noise. We discuss established strategies for nurturing a growth mindset to sustainably increase the complexity of our product and expand the number of teams within our organization. The topics discussed in this section address problems encountered by Senior Engineers and beyond, in both the management track and individual contributor track.
Collaborating within a Codebase analyzes good practices for the day-to-day work of engineers to achieve software products with high adaptability and stability. This section presents workflows and automation concepts to increase the frequency of our software deliveries. These solutions are the foundation of sustainable growth and are applied by engineers of all levels, Junior to Principal.

By initially focusing on company-wide strategies, we anchor the context of our individual contributions in the ultimate objective: market competitiveness. We understand how our contributions improve discrete metrics (i.e., development cost or time, market share, or revenue) or holistic metrics (i.e., employee experience, satisfaction, or retention).

While progress does not have to be initiated by leadership, it certainly needs to be backed by it. In time, every change faces push-back that can only be overcome by authority. Associating the benefits of development practices with our competitiveness provides a mutually understood and explicit vision of our organization's potential.

What this Book is NOT

Across three sections, we discuss efficient software delivery practices for organizations of various sizes. Conversely, we do not consider this book to be any of the following:

This is not a Coding Book

A couple of decades ago, the core business of an organization was run through sales, marketing, and HR departments. IT was considered a necessary cost factor that was at best overlooked, at worst the first target of budget cuts. Today, the situation appears to be reversed.

This book covers a lot of ground, not all of which is confined within an engineering frustum. When reading this book, we consider how the practices described within can be used in tandem with departments outside of engineering. We might improve the efficiency of our communication channels within our iteration process.

This book does not include source code, does not advocate for any particular tech stack, and does not assume the use of any tool or platform (apart from Collaborating within a Codebase, which requires experience with version control).

This is not a Step-by-Step Guide

We use the contents of this book as a starting point for iteratively evolving the software strategies of our organization. We do not advocate changing an entire company overnight.

The goal of our organization is to solve the problems of our customers. We avoid inanely copying processes from conference talks and other companies, as we might not necessarily understand why those processes are successful within that company.

That being said, we find the concepts written in this book to be helpful for a broad spectrum of software companies and are confident that readers will derive some benefit.

This is not a Bible

We avoid the term "best practices" in this book. "Best" is subjective to industries, personalities, geographic location, diversity of staff, size of organization, and numerous other factors; using the superlative is pure hubris. The strategies in this book are shared without righteous zeal.

The concepts discussed in this book should be applied by implementing small changes for a limited number of teams. We reduce the cost and risk of verifying the positive effect we intend to implement in our organization by testing the changes within an isolated team.

Lastly, while we do our best to keep the language as inclusive as possible, there is a non-zero chance that certain words or phrases will not be received in the way they were meant to be. Language is difficult. The written word is difficult. Please read this book with the positive intent in which it was penned.

Rewrite progress

The book includes a rough draft of the chapters I want to cover. However, these mostly consist of notes and currently do not offer a coherent reading experience. I am in the process of rewriting and editing the book for an initial release version. The following chapters are in a somewhat decent shape: