Q&A: collaboration, redundancy, and contractor-like models

Video segment: 15:07–16:12

An FDE project can be close to a customer and still should not depend entirely on one person. The main practical point in this short answer is simple: put more than one person on a customer project when possible. That spreads the customer and project knowledge, so one unavailable person does not stop the work.

The source's answer: avoid a one-person dependency

The speaker is asked about how multiple FDEs might collaborate. He encourages having multiple people on a customer project. His reason is that one person who holds all of the knowledge is a single point of failure.

A single point of failure is one person, system, or component whose absence can block the whole effort. In this case, the risk is not only that the person writes a particular piece of code. They may also be the only person who knows:

• what the customer is trying to achieve,
• why a solution was built a certain way,
• how the customer uses the platform, and
• what work remains.

If that person is unavailable, the team must rediscover this context before it can act confidently. Having more than one FDE involved reduces that concentration of knowledge.

What the source states: Multiple people on a customer project are preferable to having all knowledge held by one person, because the latter creates a single point of failure.

A concrete illustration

Imagine one FDE is helping a manufacturer use a shared software platform to support a planning workflow. If only that FDE has spoken with the customer and understands the customizations, an absence can pause both technical decisions and customer communication.

With two FDEs, each can retain some of the relevant context. One can continue a customer discussion or make a change when the other is unavailable. The point is not that two people automatically eliminate risk. It is that the project is no longer wholly dependent on one person's memory and availability.

This example is teaching context, not a specific customer scenario from the video.

Collaboration is not the same as a contractor arrangement

The question appears to move between several possibilities: two FDEs working together, two companies, a possible bakeoff, and a partner. The transcript is fragmented, so the exact question is not fully recoverable. The speaker also says that a two-company or partner model can exist, and describes it as mentally similar to using a contractor. The exact arrangement would need to be worked out.

This distinction matters:

Situation	Core idea	What the speaker does not specify
Multiple FDEs on one customer project	Share the work and avoid a one-person knowledge dependency.	Roles, documentation, ownership, or handoff rules.
A partner or two-company model	Think of the outside relationship somewhat like engaging a contractor.	Contract terms, management structure, technical ownership, or accountability.
A bakeoff	A comparison or competition between alternatives.	Whether a bakeoff is the recommended delivery model.

Calling the partner arrangement “contractor-like” is a useful mental shortcut, not a complete definition of FDE work. It does not mean that every FDE is a contractor, nor does it define who employs the engineers or who owns the customer outcome.

How this fits the larger FDE model

Earlier in the talk, FDE work is framed as customer-specific delivery built on a shared platform and its reusable primitives. Those shared building blocks can make it easier for several engineers to work in the same general technical environment. But they do not remove the need to coordinate. Customer context, decisions, and remaining work still need to be understood by the people serving that customer.

The lesson is therefore narrow but important: a reusable platform helps avoid rebuilding software from scratch, while collaboration helps avoid rebuilding understanding from scratch when one person is unavailable. They address different risks.

Do not over-read the answer

The speaker does not give a universal staffing formula. He does not say every engagement needs exactly two FDEs. He also does not prescribe documentation practices, a manager structure, a partner-selection process, or a legal model for contractors. The practical principle is redundancy in important customer and project knowledge; the appropriate team structure depends on the project.

The next question returns to a related scaling boundary: which customer-specific work should stay bespoke, and which repeated work should eventually become part of the shared platform.