Be a Full Domain Engineer

50% communication

To effectively build product and software multiple layers need to work seamlessly together. If any layer fails, the entire product will suffer. 50% of building, is communication to align the different layers.

For startups the best way to handle the different layers is to have principal engineers who understand their domain. This is because an engineer that understands a domain will be more effective in implementing solutions within that domain. Having seniors keeps the team small and avoids too many communication channels. Each additional person exponentially adds to the number of communication channels.

Full Domain Engineer

A "Full Domain Engineer" is someone that is capable of handling all the different layers required to cover an entire domain. This expands the typical "Full Stack" engineer who is capable of handling implementation across front-end and back-end.

In the age of AI, being a "Full Domain Engineer" will be critical. The communication, ownership, and responsibility of technical + product layers will continue to be best piloted by a human being. These humans who are responsible for their layer will use AI tooling to effectively manage and orchestrate their area of responsibility.

Domains 2 Key Areas

The 2 key areas of a domain are Capabilities and Experiences. These correspond to Back-End and Front-End. It's a better mental model to define these responsibilities by the results, instead of the how. Capabilities are built with back-end engineering. Experiences are built with Front-End engineering.

Engineers typically focus on creating capabilities. Product typically focus's on creating experiences from those capabilities. Mixing the two goals is a source of friction and confusion at most companies.

Capabilities should be built in such a way that they can be easy to configure and assemble in different ways. This way product can achieve the desired customer experience. Engineers should not try to "build the experience" as that will be rigid and a lot of communication is lost on the details. Rather they should build the components in a way that is easy for product to customize.

Missing or inflexible capabilities is a different problem than missing or poor customer experiences. It takes different approaches to correctly drive each.

The 8 key layers within a Domain

Capability Layers

1. "Business Representation"

- Is there an understanding of the business. For example accounting, ACH, Loans, Card knowledge is required to deliver a FinTech solution. Ideally this knowledge is hidden from customers so that their experience is as simple as possible. Business Representation requires both the understanding of the business, and the ability to express code/data/objects/events aligned with the naming conventions and structure of the business domain. For examples - Payment Domain, Card Domain. This should be done in a way that product can use the business representations to design an experience.

2. "Architecture"

- What are the boundaries of a component. What are the interfaces for the component. What are responsibilities and capabilities of a component. How do components interact, for example via events or REST calls. Architecture is the tools/capabilities and how to keep things uncoupled, and how they can be stitched together to facilitate easy to change solutions.

3. "3rd Parties"

- 3rd Parties are basically capabilities we buy. Home grown solutions are typically slow to get to market. Partner with 3rd parties who are experts in their area so that you can focus on stitching things together in novel ways. This needs relationship management, encouraging innovation in partners, reporting and tracking bugs, and adjusting to changes in their systems.

4. "Back-End Implementation"

- This is the implementation of the above layers. Code is written to create capabilities that can be used to create experiences.

Experience Layers

5. . "Customer/Back-office Journey"

- Ultimately we build products to provide value to customers. This is accomplished by helping customers avoid pain, get a gain, do it quickly, and without much effort. What are the steps a customer does and what are the steps we do to create value. Back-Office is anything we do as part of the journey. This can be with people (Like an operations team), or with code. Simplify/speed those steps up. What are the capabilities needed to create or improve the customer journey.

6. "Design"

- What is the look and feel of the experience. How does it tie into the brand and provide status and perceived value to the customer.

7. "UX Implementation"

- This is the implementation of the Journey and the Design. Once imagined/designed things need to be built in FE code.

8. "Data"

- Data is key for business value and critical in the age of AI. It should be thought of as a first class citizen. This is how data is stored, and how it can be accessed for analysis. A good understanding of the business needs of the data is critical to enable solutions; analysis, and recommended optimizations. (I debated if this is a capability, or part of the experience of the business. I think it's part of the experience; although internal objects/data structure are part of capabilities. )

Productizing Layers

Lastly there are 2 "Layers" that are purely technical and cut across all domains.

9. "Infrastructure"

- How do we deploy and maintain code. What is the underlying technology we create our architecture on top of. How is our architecture connected together. What cloud is used and how is infrastructure as code created.

10. "Operations"

- The Ops in DevOps. Systems need monitoring and need observability. What are the technical "Ility" requirements like observability, testability, maintainability, recoverability, securability, etc etc. How do we monitor and run production code.

Team Construction

Often when creating teams people think of back-end/front-end and product/eng. I think it's better to look at Capabilities and Experiences by bridging the product/engineering gap. The different layers within those categories each requires slightly different skill sets. Make sure your team covers them all and use the list as a way to identify gaps. A key value of a "Full Domain Engineer" is the ability to fill multiple boxes for a given domain; saving big time.

Closing Questions

• Are there missing layers?
• Does your team have gaps in the layers?
• How can AI help with each layer?
• What layers are you great at; which ones do you want to learn?