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 two sections, addressing engineering processes at two levels within our organization.

• Collaborating within a Codebase analyzes good practices to frequently deliver software products. We cover workflows and automation concepts that enable engineers to "do the right thing" and write stable software out of the box. Engineers across all levels apply these solutions to build and grow products sustainably.

• Collaborating within a Company covers strategies to sustainably grow a product into a team, and teams into an organization. We consider how to foster purposeful collaboration and reduce distractions within teams. We discuss problems encountered by senior employees and upwards, in both the management track and individual contributor track.

Both parts anchor their respective topics in our ultimate objective: market competitiveness. We make changes to our development processes to improve discrete metrics (i.e., development cost or time, market share, or revenue) or holistic metrics (i.e., employee experience, satisfaction, or retention).

While change does not have to be initiated by leadership, in larger organizations it certainly needs to be backed by it. In time, every progress faces push-back that can only be overcome by authority. Both parts of Engineering Collaboration detail their business value and help communicate the necessity of development practices to leadership.

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

The goal of our organization is to solve the problems of our customers. To do our best work, 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, I find the concepts written in this book to be helpful for a broad spectrum of software companies and am confident that readers will derive some benefit.

Not every change requires a company-wide vertical crusade. Engineering Collaboration serves as a starting point for iteratively evolving our personal deliveries, or workflow strategies within our team. We get to decide what strategies to trial and determine what works and what doesn't.

This is not a Bible

I 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. I share the strategies and opinions in this book with no 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.