Design Engineering

Being a generalist is a superpower. When you understand a range of domains, you notice patterns, surface principles, and unlock insights. But you also learn how to speak fluently across disciplines. Design, engineering, strategy, management, sales, marketing, operations—these all contain languages. And they’re part of the Value Engine. A generalist who understands each domain unlocks almost supernatural abilities. You diverge and converge fluidly, going wide and deep as each situation requires.

Most of my career—as I was rooted in the craft of design and engineering more than strategy and leadership—was focused on bridging design and engineering through front-end development. I love expressing design through code, creating art in both the user experience and the code that fuels it. I feel at home writing code, seeing something show up on the screen, and then obsessively refining it until the two parts work in harmony; the pixels and the bits as the raw materials of creation.

For years, I fought against the Full-Stack Fallacy of unicorn engineers: the experts in both front-end and back-end engineering. No matter how much the industry wants the role to exist, it doesn’t. I’ve met front-end engineers who can write back-end code; and I’ve met back-end engineers who can write front-end code. But I’ve yet to see an engineer who loves and is exceptional at both parts of the stack. It’s why I call it the Full-Stack Understanding. You don’t need to be an expert in both, but you should know how they both work, no matter which part you focus on.

The real miss, though, is finding engineers who can truly translate a design into working software. This isn’t about pixel-perfect representations of high-fidelity mockups, either. It’s about understanding design principles—colors, spacing, typography—and unifying them as modular components to enable rapid development and prototyping. Because I’ve also met engineers who are “good at front-end,” only to find their inability to apply enough whitespace for basic legibility. A great front-end engineer can spot the patterns in a design, and map them to the code while reconciling the current design system:

• “Are these new rounded buttons changing across the app?”
• “We usually use half this amount of space between lists of cards.”
• “I made the icon update during state change to make it easier to see.”

As I’ve moved through organizations in the product world, I’ve witnessed this disconnect firsthand. Companies scour the talent pool for full-stack engineers, when the real leverage is further up the stack. “Design Engineers” as a role became the hot new job title the last few years. But it’s nothing new. This is the same role I’ve championed for years. The highest leverage you can create on a product team is bridging design and engineering into a cohesive discipline. It’s why I’m so passionate about Product Builders as that holistic role, now and in the future. Whether you call yourself a designer or engineer, you should grow your understanding of your counterpart discipline. It’s where growth lives.

We need more builders and creators who see across the disciplines, translating value effortlessly. We need less handoffs and more value creation by means of integration. When work is handed off without a way to bridge the divide, you create quality degradation. The work suffers. But what if the Design Engineer role is really about the activity, not the title?

This idea is called Design Engineering, which lives in the Clarity Current of the Claritorium and Quality Refinement of Equilio.

Design Engineering is a core activity of the Product Builder. There are three pillars:

1. Upstream Collaboration is how you bring together designers and engineers to share context from the beginning.
2. Downstream Iteration is how you integrate designers and engineers during the build to avoid disjointed decisions.
3. Collective Intelligence is the compounding effect when you integrate the disciplines upstream and downstream.

Upstream Collaboration

The typical process encourages handing off work from design to engineering. Designers work upstream to define a solution that satisfies a critical need. To effectively build the solution, they meet with engineers to discuss the technical feasibility of the design.

Can what was designed be built?

Engineers may push back. They could point out potential unknowns and risks. But they also suffer from the same human tendency to underestimate complexity. Even with an intimate knowledge of the codebase, they often miss major problems early. Why? Because it’s complex! Software is a system of endless variables and possibilities. You never truly know until you start building. Yes, it’s all guesswork until you do the work. I will always say this. Because it’s true.

The solution isn’t more planning. You need to bring the engineers further upstream so they can share in the context to inform downstream decision-making. Good decisions require context. You need a full understanding. And too many product teams leave engineers downstream to solve problems with insufficient data; or they’re expected to lob decisions back over the wall to designers and strategists. This is where the “waterfall process” comes from.

If you continue to treat software development as an assembly line, then you will continue to suffer from poor decisions, low-quality solutions, and missed deadlines.

My product philosophy, Equilio, is built on the idea of intuition, integration, and iteration. And Upstream Collaboration helps with both intuition and integration. When you move further upstream, you understand the why more deeply, which helps build your individual and team intuition. When you bring the entire product team together sooner, you create collaboration that fosters integration and shared understanding.

Now let’s discuss some principles and practices to express Upstream Collaboration.

Principles

Principles express the core beliefs that shape how a team thinks and behaves.

Everyone understands the problem

Make sure the entire team understands the problem before you move into the solution. Create clarity together instead of suffering from translation problems exacerbated by the process of hand-offs.

Constraints are inputs, not blockers

Time, resourcing, and technical constraints help focus your shaping efforts. There’s a shortened version of any feature, and the constraints breed creativity.

Shape together before you build

Everyone should be part of the process to define the solution and share context. The quality of ideas grows when you bring together diverse perspectives.

Practices

Practices translate beliefs into repeatable actions that teams perform to express those beliefs in their unique way.

Collaborative Discovery

Bring engineers into the discovery process with customer interviews. It’s a big miss when you only share outputs and artifacts of customer interviews with engineers. They need to share in the understanding to develop empathy and increase their knowledge of the problem space.

Shaping Sessions

Hold regular open sessions with designers and engineers working together to diverge and converge through sketching and discussion. It’s a wonderful blend of thinking wide and then narrowing as you consider constraints. Doing so also opens the aperture of understanding for the engineers, which pays off downstream.

Project Kick-off

Bring the entire team together to review the shaped work, answer questions, and share context before the build begins. Nothing should be new, but this rhythm aligns the team on the problem, solution, and goals.

Downstream Iteration

Upstream Collaboration solidifies a shared mental model for the team. There’s no need to translate context from design to engineering, increasing shared understanding and avoiding gaps in communication. Now, you move into the work itself. The engineers use the shaped document (the Intent Brief) as framing for the work. It’s like the compass they use to understand the map and the territory.

This is often where the rift emerges. The engineers start working, reviewing the document, designs, and writing code against discovered tasks. Even if they’re involved in Upstream Collaboration, the unknowns still exist when they’re building. The collaboration needs to continue downstream, but with a focus on the engineering work.

Downstream Iteration is when designers and engineers work together in rapid iterations during the build phase. Instead of calling out a problem with the designed solution and handing it off to the designers, they work together to identify a solution. Remember, they’re working off the same base of knowledge developed upstream. They leverage that shared understanding to modify the scope and iterate in the live environment. Everything before you start building is a simulation. You need to do the bare minimum de-risking required to start building. And then you make changes quickly, adapt, and iterate in unison.

Now let’s discuss some principles and practices to express Downstream Iteration.

Principles

The medium is the truth

Design and engineering converge to create the final output—the medium. If you’re building a web application, that’s the browser. Anything you create outside the medium is a simulation, not the final representation. You should always move to the medium as quickly as you can.

Quality comes from iteration speed

Speed and quality are not enemies. They are collaborators in the process of creating quality outputs. The faster the iteration speed—the time it takes to make changes—the better the quality of the final output.

Shared ownership of fidelity

Designers and engineers share ownership of the final product. If colors, typography, and spacing are off, it means the disciplines aren’t working as a unit. Whether you have a Design Engineer or not, you can fill the gap with deep collaboration downstream.

Practices

Pairing Sessions

If you’re building a web application, have a designer and engineer pair to make changes in a live pairing session. This is common practice for engineers to pair and write code, but it doesn’t happen enough across design and engineering. It’s a cross-functional pairing session that improves the team’s taste and performance as they work together. There’s a real-time push and pull as the pair makes changes and wrestles with the tensions directly.

Micro-Iteration Loops

Quality lives in the details. Making small and consistent changes steadily improves quality. It’s when scope gets too big and unwieldy that you run into major issues. An increase in surface area means an increase in risk. Focus on changes you can make in a day or no more than a week. The faster, the better.

Joint Fidelity Reviews

Design and engineering jointly own the final output. Design shouldn’t throw work to engineers and then shrug when the final result doesn’t meet the quality bar. They’re both accountable. And coming together at key moments to review the output—influenced by their distinct perspectives—culminates in an aligned and coherent end product.

Collective Intelligence

Over the past month, we’ve held product brainstorm sessions across two products. We bring together a specific set of people across sales, marketing, design, engineering, and strategy. It’s not too many people in one session because ideas need to flow freely. It’s creative work, which means it’s messy. There’s no agenda or slide deck to look at. We use our intuition to identify a specific area of the product, and then we make changes in real-time. Both products are web applications, so I share my screen and use the browser developer tools (DevTools) to update the HTML and CSS while everyone watches. The contrast of immediate changes creates heightened awareness when something works (or doesn’t). That’s when we, collectively, grow our product sense and make the product better. We reduce and simplify. We’re editing the experience, wielding the proverbial red pen to leave only what is absolutely necessary.

And the product isn’t the only thing that improves: working collaboratively in a single group of cross-functional disciplines on a focused task builds collective intuition. And that’s how you move as a one Collective Intelligence. You use your intuition as an integrated team making rapid iterations in the product. This is exactly what Equilio is all about. You build momentum that compounds as you improve the product and your team in the process. Living in the tension stimulates growth and improvement. Collective Intelligence is a byproduct of Upstream Collaboration and Downstream Iteration. It’s the cumulative effect of a team working in unison against aligned problems.

Now let’s discuss some principles and practices to express Collective Intelligence.

Principles

Everyone thinks out loud

Collaboration thrives when you verbalize your thinking, sharing unprocessed ideas. The raw, unfiltered ideas mix with other ideas to catalyze insights and create clarity. A team that thinks together coalesces as a single entity to deliver impactful outcomes.

Contrast creates understanding

Show the before and after. Make high-contrast changes to understand what works and what doesn’t. Explore the reasoning together to create a shared understanding. If thinking out loud is the externalization of thoughts, then contrast is externalization through visualization and interpretation. Clarity emerges from contrast.

Shared attention generates shared intuition

Energy flows where attention goes. How you think and what you look at shapes your team’s collective mental model. Make sure everyone is looking at the same thing, bringing their unique perspective to pull it apart and put it back together again. In that understanding of what works and doesn’t, the team intuition develops, matures, and flourishes.

Practices

Build Sessions

So many meetings are about slide decks, documents, and endless discussion. But building software is actually about building software. If you’re not careful, everything around the work becomes ceremony—roadmaps, requirements, reviews. Sometimes you forget the craft and the creative process, which is meant to be messy, collaborative, and fun. Get people together and build stuff. Share your screen and draw diagrams, use your product, or actually make a change in the product in real-time. Use Build Sessions to bring energy back into your team.

Real-Time Contrast Loops

When you discuss a change, show the before and after. Let the team see the shift in real-time, and use the contrast to stimulate creative thinking, improve decision-making, and grow the collective intuition of the group. If you treat the craft as fixed, static representations of work, you lose the dynamism inherent in the process. To build product sense, you need to understand the feel of the work. And you get there with contrast.

The Red Pen Ritual

In the weekly brainstorming calls, we’re not adding new functionality. Why? Because every piece of software just adds, adds, adds. But then you end up with an unusable mess. It does everything; and nothing. You need to start by removing. Like an editor, wield your red pen and cross out anything that isn’t absolutely necessary. If it’s not essential, you don’t need it. Addition by subtraction. In the process of removing the nonessential, you highlight the core value of the product.

The Project Engine

Shape Up treats strategy and execution as concurrent paths. While one team is shaping work, another team is building what was already shaped and bet on. But Design Engineering is a merging of these layers. You treat each project as a single unit, from conception to creation. There’s no hand-off.

If that’s the case, then what does this process actually look like? I’m still experimenting, but it’s a combination of Bamboo Teams, Product Builders, and Design Engineering coming together to execute discrete units of work.

The process has five steps:

1. Align: Align on the problem, team, and the boundaries (constraints).
2. Clarify: Develop a shared, first-principles understanding of the core problem.
3. Model: Explore solutions, sketch flows, and converge on a viable direction.
4. Build: Deliver the solution through iterative forging and refining.
5. Learn: Measure impact and feed insights back into the system.

The first and last steps—Align and Learn—aren’t part of the budgeted time. They’re rhythms as part of your standard process. The middle three steps—Clarify, Model, Build—are part of the integrated timeline you define in the first step. The team is assigned in the first step as an integration of design, engineering, and strategy. They work together every step of the way, with each discipline taking ownership at different allocations:

• Clarify is 75% (high) strategy and 25% (low) design and engineering.
• Model is 50% (medium) design and 50% strategy and engineering.
• Build is 75% engineering and 25% design and strategy.

Think of it like a stacked bar chart distribution that makes up 100% allocation at each step. Every discipline is involved throughout the lifecycle, but the emphasis shifts:

• Clarify is about strategy.
• Model is about design.
• Build is about engineering.

How you think about this team should be more nuanced than X number of people. While, yes, you could assign one designer, one engineer, and one strategist to the team, in the new world of Product Builders, this could be one single Product Builder representing each discipline. They would collaborate with the collective, but operate solo against a clear commitment. Using AI tools combined with human intuition, the process rapidly accelerates through the three steps. However, this process also adapts to your current team composition, allowing you to gradually migrate as you create more Product Builders.

Since I’m still early in the exploration phase of this process, let’s walk through each step using an example project: the chat experience feels janky and suffers from poor UX compared to other competitor’s products.

1. Align: The idea emerges and floats to the top of the list. We decide to spend 3 weeks to improve the loading experience. The team will be a designer, engineer, and strategist working together.
2. Clarify: The project kicks off and we spend 2-3 days meeting to review the current experience, watch user session recordings, and play around with competing products. We diverge and converge until we narrow the problem definition: we don’t show enough information while the response is loading to improve perceived loading.
3. Model: Now we’re writing the Intent Brief and working on the shapes. We also apply more constraints here because we know we need about 1.5 weeks to build and refine a version we’ll be proud of. The designer is leading sessions to shape the solution with words and sketches. The engineer is in the code and spiking small prototypes to test early ideas before committing. The model is the representation of the work, but it’s not a replacement for doing the work. We get the Intent Brief done by the beginning of the following week, ready to build.
4. Build: The engineer takes over and cranks out a quick prototype on a deployment URL where we can play with it ourselves. The best measure of progress is working software. And using with the end result early sharpens our intuition. We all meet and review the product to share feedback and iterate in real time. The engineer makes updates live, and we zero in on a solution we like. At the same time, the designer is working on visuals as marketing materials for the work. The strategist is dialing in the success metrics and making sure all events are instrumented.
5. Learn: Shipping the work is only the first part of the process. Once customers use it, that’s when you need to tune into their feedback, translate it, and follow up quickly to keep refining the work. It’s easy to just ship the thing and move onto the next project, but almost every part of the software influences other parts. It’s a complex system. You need a regular rhythm for reviewing metrics, talking to users, and continuing to refine the work. To deliver the project on time, scope was changed, which means additional tasks fall into a list of fixes and improvements.

A Better Way

The typical software development process is predicated on an assembly line concept masquerading as cross-functional collaboration. Building a car on an assembly line is productive, yes, but the resulting product is a fixed entity. Your car doesn’t change every time you get in it. But you know what does (or should)? Software! It’s supposed to me malleable, mutable, adaptable; a living organism with a pulse and a perspective. To not treat it as such is a disservice to the craft.

Every step on the journey from conception to creation is a guess. The problem the customer has is a guess; the solution to said problem a guess; the delivered result a guess. Each milestone is a progression of unknowns, assumptions, and risks. You need to shrink the time from guess to reality. Spending months in user interviews—or months designing in Figma—won’t save you from the unknowns, assumptions, and risks.

Nothing will!

I don’t say that to be cynical. It’s the nature of the work. Your goal is to decrease the time it takes to test your guess in the real world. Make the thing as fast as you can up to the quality threshold you expect. Let people use it, break it, and help you improve it. Moving fast is not an impediment to the quality of work. Speed is how you achieve quality.

Throughout my career, I’ve always found myself in tension with the “standard way” things are done. But it wasn’t until I worked in multiple organizations and affected change that I saw how much so. My defiance and opposition is strong because I’m passionate in a better way to work—a way that’s aligned with making great software. And it doesn’t rely on ceremonies, assembly lines, or handing off accountability. It’s a joint effort of collaborative teams of people who care about doing their best work. They don’t draw arbitrary lines; or say “not my problem”; or do the bare minimum. They care, deeply. They engage in critical thinking and work in unison on meaningful problems.

Design Engineering is a bridge built on Upstream Collaboration, Downstream Iteration, and fortified by Collective Intelligence. It’s an activity, philosophy of work, and a holistic practice. Instilling this philosophy in your team will pay dividends. I’m working on it, and I hope you do, too.