Build Dynamics

Every engineer I’ve worked with prefers and is more skilled with front-end development or back-end development. Yet the industry continues to seek out the coveted “full-stack engineer”—the magical engineer who can whip up beautiful user interfaces with HTML, CSS, and JavaScript, while also building APIs, provisioning databases, and scaling servers.

As a strong advocate for generalists, isn’t this contradictory to that belief? Not at all.

Engineers need a full-stack understanding, not expertise in everything. The power of a generalist is not the ability to do everything, but rather a holistic understanding that enables breadth and depth in their work. They nurture skills to go deep when they need to, and leverage divergent thinking to create novel and innovative solutions.

I used to lead a UI Engineering team. I fought for this team to exist. We were the bridge between design and back-end development, a keystone in creating useable and effective user experiences. We were the translation layer, pioneering the use of early design systems as a scalable system for building beautiful software.

One of the initiatives I created was called the Internal Tool Rotation. At regular intervals, one member of the UI Engineering team would build an internal tool that benefited the organization. Other than making something valuable to the team, the only rule was to use a new technology that expanded their full-stack understanding. We worked within a Ruby on Rails monolith, so one engineer built a team directory as a Rails app. I built a Sinatra application that connected to the Basecamp API and equipped the operations team with a special view of the calendar for launches.

The goal wasn’t for members of the UI Engineering team to write the Rails back-end and replace those back-end engineers. It was so they could better understand that side of the work, and increase the fidelity of communication when working together.

And it worked. Our teams worked better together to create better products, while building additional skills and making useful software for the business in the process.

So why did the “full-stack engineer” role become so ubiquitous? Around 2010, when JavaScript was eating the software world, the technology itself allowed use of the same language on both the client and server. So then the logical conclusion was that the same engineer could handle both parts. Thus the magical role was created and popularized.

But I think this is the wrong way to look at engineering. Rather than define the roles by function, we should look at the different perspectives and dynamics of work. How an engineer approaches the work tells you more about their focus than an arbitrary full-stack distinction. In this case, the stack is periphery to the function it represents.

I call these Build Dynamics, and they fall into three distinct forces:

1. Forging
2. Refining
3. Accelerating

(This idea lives in the 🦉 Clarity Codex of the Claritorium.)

Forging

Building features requires specific skills. More than that, it requires a unique perspective on the work. You wade into the unknown, discover and document tasks, and build incrementally through rapid prototyping. The myth of software development is that you can pre-plan the work before it begins. But no matter how much you plan and try to slice up the work, the unknowns still lay dormant.

It’s all guesswork until you do the work.

When you start, you’re at the bottom of the hill. Your job is to get to the top of the hill, when you know how you’re going to implement the feature. You see all the lines of the work in front of you. You have a clear plan. Then you run down the hill and execute rapidly. You build vertical slices of functionality that integrate both the front- and back-end components. All the tension lives in the integration points, so you don’t waste time using dummy data or avoid thinking about the user experience. It’s a holistic approach where working software serves as the true and only measure of progress.

Forgers push forward with new features and bold bets. They think like explorers—cutting fresh paths through ambiguity and moving fast to create new value.

I was talking to a senior engineer about a new feature recently. They were thinking out loud and describing the work, perfectly articulating independent scopes of work. And that’s the key to rapid progress: you take the bigger thing and complete it in small, tightly scoped steps. In software, that means releasing smaller units of work you can test and iterate against. Progress builds momentum.

That’s what Forgers do. They execute against larger projects to deliver new value. This is the work most cherished by organizations. It’s the fancy new features customers request.

But it’s only part of the equation.

Refining

Software products rely on features to drive new business. But over-indexing on this work creates other issues. More features means a larger surface area, not only in the product functionality, but with the size of the codebase as well. That means a higher chance for regressions, deeper knowledge requirements, and increased exposure risk.

Forging is additive.

The quality of software lives in refinement—the iteration of continuous improvements. Often, that means reducing complexity, removing functionality, and simplifying the software.

Refinement is subtractive.

You remove bugs, remove choices to simplify the design, and refactor code through reductions in complexity.

Refiners polish and improve with steady fixes and enhancements. They think like craftspeople—sharpening, tuning, and simplifying until the product feels reliable and smooth, improving quality and the overall user experience.

Everyone clamors for new features, but product quality emerges in refinement. Taking time to expend energy on the little details—the quality-of-life improvements—is how products go from good to great to exceptional. Take Linear, for example. It’s an exceptional product with a high quality bar. They have a zero-bugs policy and train engineers to see, feel, and fix everything that lowers the quality of the product. They constantly refine.

These are perspectives for a reason. Refiners must look at the work a specific way. They notice the little things—the tiny details like alignment, animations, and adjustments that are subtle, yet impactful.

This type of work should be driven by feedback and constrained in scope, both in the size of work and the time dedicated to it. I like to keep 1-2 engineers always focused on refining. They rotate in and out of feature work, and use feedback and intuition to craft small one-day-or-less issues as units of work. When you build new features, you need to reserve time for this work. Adding without subtracting shifts the product equilibrium.

Find the balance of Forging and Refining.

Accelerating

One of the best parts of engineering is the number of ways you can solve a problem. But it’s also one of the worst parts of engineering.

For most problems, you either:

• Patch: Make a smaller change to fix the problem in a less effective, but faster way. Low complexity, low resiliency.
• Pursue: Make a bigger change to solve the problem more effectively, but with more time. High complexity, high resiliency.

My standard approach is to patch first and pursue later. And Accelerators thrive when building long-term, stabilizing solutions. Because while it feels effective to patch, delaying stability initiatives hurt the product in the long run. You need Accelerators.

Accelerators build the invisible infrastructure—systems, integrations, and developer experiences that make everything else faster and more resilient. They think like architects, extending reach, amplifying velocity, and preventing the system from collapsing under its own complexity.

Accelerators are typically the most senior engineers. They’re the principle engineers, solutions architects, and DevOps practitioners. They care about security, stability, and developer experience. Their work enables the Forgers and Refiners to move with speed.

The most attractive work on a roadmap are the sexy features—the high-profile projects that create direct and visible impact for the business. But not all critical work is sexy. Often, the work of an Accelerator is unheralded work without immediate effects. But their work builds resiliency into the product, the team, and the business:

• Adding new build tools (like linters) that help the team see and resolve errors early.
• Standing up sandbox environments to improve testing and feature iteration.
• Optimizing database queries to increase performance and response times.

They work on the platform—the underlying foundation that supports the team. Without a strong foundation, building features and making improvements is like hammering a nail into sand. The changes lack impact without a strong foundation. Your shiny new feature that throws errors or lags in performance won’t help users achieve their goals.

You need Accelerators to build resiliency.

Orchestration

These focus areas are not silos. Work streams in a continuous current between Forgers, Refiners, and Accelerators. And, depending on your team size, the same engineers may even rotate across all areas. My product philosophy is holistic. I believe great work comes from sharing context broadly and enabling the team to focus with intention.

Balance

Building SaaS products is volatile. There is a constant flood of feedback. Left unchecked, you can drown in the noise. But with a clear focus you can constrain the scope of work and stay adaptive (not reactive!) to new priorities. The key is to keep Refinement work tightly scoped and constrained to less than a day of work for each issue.

You can maintain focus with the Forgers while the Refiners field smaller units of work. The Forgers are focused on a bet, which is a specifically sized amount of work that defines how much time they will stay focused. This is the appetite. Depending on the lifecycle of your company and product, you can vary this number for 1-6 weeks for each bet.

For the Forgers, though, they work on constrained issues and can redirect attention easily when priorities shift. A new high-priority bug is reported? They shift to it quickly because each issue should have a known problem, a known solution, and limited scope.

It’s all guesswork until you do the work is still true, but the risk is lower. Also, with a smaller time investment, the next item in the queue is never far away.

Diffusion

As the size of a codebase grows, engineers accrue domain-specific knowledge. One engineer builds a feature and, when the next feature comes along in that same area, they’re the natural pick to work on it. This is common. But it’s also a problem.

What happens when that engineer is on another project? Or vacation? Or leaves? Even if they diligently documented their knowledge and wrote pristine code, a lot of the domain knowledge becomes tribal. It’s trapped in their head; your team is in a bad spot.

You have to remove silos of work. Build Dynamics help because each area should work on the same parts of a codebase, but at different points in time and in different ways:

• The Forgers build a new feature that lets users talk to their data with an AI chat.
• The Refiners refine the quality through continuous feedback with users.
• The Accelerators fine-tune the LLM to improve the response time.

They each touch the same code, but in different ways. Removing the silos of domain knowledge should be done intentionally. When a new project is shaped ahead of development, bring the engineer domain expert into the shaping process early. They can address technical feasibility and risks ahead of time. Then you can hand the work off to a new engineer, intentionally disperse the knowledge, and keep the domain expert on hand for support. A slowdown in the short-term accelerates speed in the long-term.

Flow

Build Dynamics extends beyond just engineering. It’s a holistic lens for building products. You move fluently through delivering new value, improving quality, and scaling with speed. When evaluating the state of the product, ask your team:

• Do we need to add new value?
• Do we need to improve the quality of the product?
• Do we need to scale with speed to deliver work more quickly?

Product gravity will always pull you toward adding new value, but value is increased in every level. New features increase value; a higher-quality product increases value; and scaling with speed increases value. Build Dynamics is the invisible choreography of high-functioning product teams that build momentum, increase resilience, and deliver impact in their work.