Everyone Should be a Builder

Last week, we had our annual company offsite in Sedona, Arizona. While we spent plenty of time hiking among the red rocks, riding a hot air balloon, and visiting the Grand Canyon, we also had an important mission while we were there: to make everyone in the company a builder.

For some time now, we have been running what we call an AI Academy, where we share knowledge about how to work with AI tools and build AI literacy across the company. In today's world, not knowing how to use AI is quickly becoming similar to not knowing how to use Google.

This time, however, we decided to go a step further. Instead of only talking about AI, we ran sessions where everyone built their first agents to automate parts of their work.

The energy in the room was incredible. Watching people realize that they could build tools themselves, often for the first time, was one of the highlights of the offsite.

In this article, we'll explore why everyone in a company should be a builder.

Domain Experts Understand the Problem Best

In many companies today, including ours, the process often looks something like this: stakeholders and product teams identify an issue, prioritization happens, requirement documents are written, and then the engineering team receives those requirements. A call is usually scheduled to clarify details with stakeholders, an initial version gets built, and then several rounds of feedback and iteration follow.

Throughout this entire product and development cycle, the requirements pass through multiple people, and inevitably some nuance gets lost along the way. While the engineer building the product is an expert in building systems, they are not necessarily the domain expert on the problem itself.

That dynamic changes completely when the builder is the domain expert. When people closest to the problem have the tools to prototype or even build solutions themselves, they bring the full context of the problem with them. The back-and-forth translation of requirements disappears, and solutions often become much closer to what is actually needed from the start.

Faster Experimentation and Prototyping

Building on the point above, the traditional product cycle can also slow down experimentation. When every idea has to enter a prioritization pipeline before anything is tested, it naturally takes time before teams learn whether something actually works.

When domain experts have the tools to build simple prototypes themselves, experimentation can start immediately. Instead of waiting for development cycles, stakeholders can begin testing ideas right away, iterating and refining them as they go. Often, new insights emerge during this process and the original idea evolves as people interact with the prototype.

The prototype then becomes a strong starting point for the engineering team. By the time it reaches engineering, much of the experimentation and feedback has already happened, the requirements are clearer, and the focus shifts from discovering the solution to building it properly and scaling it.

Scaling Innovation Across the Company

When everyone becomes a builder, innovation no longer depends on just a few people in the team. As everyone starts building tools for themselves, opportunities for improvement become much easier to act on.

In the past, if someone noticed a workflow that could be improved, the idea either had to go through prioritization or was simply left unresolved. When people can build simple tools themselves, those ideas can be explored immediately.

Often, something built for one person ends up being useful for others as well. Over time this creates an environment where innovation is happening across the company, not just within a single team.

Builds Technical Intuition Across Teams

As more people start building and becoming AI-literate, they naturally develop a better understanding of how AI systems work. Through hands-on experimentation, teams learn how to structure problems, what context models need, and where AI can be most useful.

For a company like ours, where the product itself is AI-based, this shared understanding is especially valuable. When the team has stronger intuition about the technology, they can explain the product more clearly to customers, identify opportunities more easily, and contribute more informed ideas to product development.

Engineers Can Focus on Higher-Leverage Work

When teams can prototype solutions and automate smaller tasks themselves, the engineering backlog naturally becomes lighter.

Instead of spending time on every internal request or early-stage idea, engineers can focus on higher-leverage work where their expertise has the greatest impact, such as building scalable systems, improving infrastructure, and turning successful prototypes into robust production solutions.

Conclusion: The Mindset Shift

The real transformation happens when people go from thinking, “I should ask someone to build this,” to “I can build this myself.”

During our offsite, it was incredible to see the excitement across the team as people watched the agents they built start helping them with their everyday work. That moment, when someone realizes they can create tools for themselves, is powerful.

In today’s world, this mindset shift matters more than ever. When people see themselves as builders, organizations become faster, more creative, and better equipped to turn ideas into solutions.