Infrastructure Gravity and Domain Engineering

Jack Danger explains the concepts of Infrastructure Gravity & Domain Engineering in an excerpt from his book, Executive Engineering.

I love the concept of having engineering teams dedicated to the business domain:

This middle layer is the glue that binds everything together. We can define it as “Everything that’s unique to this company’s features but not unique to any one feature.” It’s the internal semantics of the product suite as a whole, even if that product suite isn’t a suite yet. Even if it’s not a whole product yet.

Going further:

This is Domain Engineering; your company’s competitive advantage and your greatest asset as a technical leader.

Domain Engineering is the process of reusing domain knowledge to minimize the cost of developing products.

This covers things from “platform”-y things like the particular set of magic needed to write a new microservice with all the right auth, tracing, and other patterns, or a library of front-end components that reflect the company’s design language. But it also covers truly domain things that multiple features or products use—at Toast, a team that managed our internal system for representing versioned restaurant configuration data (e.g., menus, settings) would have fit perfectly in this bucket.

Domain Engineering is also the right conceptual home to shepherd better development of the company’s competitive product advantages.

He then explains how infrastructure gravity and product lift make it hard to naturally form domain engineering teams. In a separate post, he explains how to staff domain engineering teams.

— via Rand’s Leadership Slack.