How to Consistently Deliver with a Top Performance Mindset - w/ David DeYarza, CEO at Builderbox

BuilderBox CEO David DeYarza said the drawings do not build the building on their own. He added, “People do.” In the 2017 conversation, he used that line to explain why project software is not only a document problem. It is also a communication standard.

David's implementation experience was specific. When leaders required one shared place for project communication, the platform had a clear role. When email, side conversations, and disconnected tools remained equally acceptable, the new system became another data silo.

A platform becomes another silo when no one changes behavior

David DeYarza said his most successful implementations happened when an owner or project leader made one thing clear: use one shared place for project communication. Without that mandate, the platform sat beside email and other systems, becoming another login instead of the record of the work.

That is not mainly a product problem. It is a leadership problem. Teams rarely standardize around one communication pattern by accident.

The issue is not whether people are communicating. The issue is whether the project can still see who decided what, what depended on it, and what needs to happen next.

Context matters as much as the document

David also emphasized context. An RFI, submittal, or change record can exist without preserving the surrounding discussion that explains why the decision was made. When that context lives in scattered messages, the team may recover the formal record later and still miss the reason behind it.

That matters most when the project is under strain. A team trying to understand an old issue does not need one more folder to search. It needs the decision, the conversation, the owner, and the next step to stay connected.

David's field example about conflicting foundation information made the risk plain. A footing had already been poured when the conflicting information was raised. At that point, the team was dealing with work completed against an unresolved record.

Readiness needs to be visible before the work moves

David also described a useful ambition for project systems: make readiness visible before the team proceeds. That means showing whether a task, drawing, question, or dependency is actually complete enough to move into the next step.

This is where collaboration software can help in a specific way. It cannot decide whether the team is exercising good judgment. It can help expose whether a dependency is still open, whether ownership is clear, and whether everyone is acting from the same current picture.

That is different from digitizing a form and leaving the dependency hidden. The readiness view David described was intended to show an open question before the related task moved forward.

Evaluation is easier when the cost and commitment are visible

One more thread in the episode was pricing and trial access. David argued that teams should be able to understand the cost and test a system before the project budget was locked.

He described receiving software pricing too late to add it to a fixed job budget. Visible pricing and trial access were his proposed response to that evaluation problem, not proof that adoption would follow.

Take one recent issue that was difficult to reconstruct and trace the final decision back through the conversation, dependency, owner, and next action. Mark the first place where the record breaks. The project leader can then decide which channel should own that part of the next issue and tell the team where the answer must be recorded.

Software can connect the record. The project leader still has to set and uphold the communication standard that makes the record trustworthy.