How I embed in engineering teams as a design director

The fastest way to earn trust with an engineering team is to show up where they work. Not in Figma—in their codebase, their pull requests, their standups. As a design director, I don’t just hand off specs; I participate in sprint planning, review PRs for UI accuracy, pair with engineers on tricky interactions, and commit directly to the codebase when it makes sense. This isn’t about replacing engineers—it’s about removing the translation layer between design intent and production output. Every layer of translation between a design decision and its implementation is a place where fidelity is lost and trust is eroded. The goal of embedding in engineering is to eliminate those layers.

What it actually means to show up in engineering’s space

Most designers interact with engineering through a handoff artifact: a Figma link, a Zeplin screen, a spec doc. The engineer interprets it and builds. If something looks different, there’s a back-and-forth in a comment thread or Slack. This workflow feels normal until you experience what happens when it’s replaced with direct collaboration.

When I embed in an engineering team, I participate in the tools they use daily. I’m in the sprint board, not just the design board. I’m in the repository, not just the design file. I review front-end pull requests—not for code quality, which is the engineer’s domain, but for visual and interaction fidelity. When a component is 4px off its design spec or missing a focus state, I catch it before it merges, not after it ships.

The shift this creates is significant. Engineers stop treating design as an upstream process that produces files and start treating the design director as a collaborator who understands what they’re building and will help them get it right. The dynamic changes from “design hands off, engineering interprets” to “design and engineering solve the implementation together.” That’s a fundamentally different quality of output.

The sprint rituals that make embedding work

Embedding isn’t about attending every engineering meeting—it’s about being present at the specific moments where design decisions get made or re-made in code.

Daily standup (or async equivalent). I join or review the standup so I know what’s currently in flight and what’s blocked. If something touching UI is in progress, I reach out proactively—not reactively. The standup is how I prevent “design hasn’t seen this yet” from becoming a late-stage problem.

Sprint planning. I participate in sprint planning for any sprint that includes front-end work. Not to estimate story points—that’s the team’s job—but to flag design complexity that might not be visible from the ticket description alone. An animation that looks simple in Figma might require a state machine. An interaction that’s obvious to a designer might be a four-day engineering task. Flagging these in planning prevents them from becoming surprises mid-sprint.

PR reviews for UI work. I add myself as a reviewer on every front-end PR that touches visual components or user flows. My review is focused exclusively on: does this match the design intent, are all states handled, does it work on mobile, are there accessibility issues? This is separate from the engineering review for code quality. The combination of both reviews means the PR can’t merge until both the code and the visual output are correct.

Design reviews inside the sprint. Rather than holding separate design reviews at the start and end of the sprint, I run micro-reviews during the sprint: a 15-minute async Loom walkthrough when a feature is in mid-development, a quick pairing session when an engineer is about to implement something complex. The feedback loop is tighter, and rework is caught earlier.

How do you pair with engineers on complex interactions?

Pairing sessions are the most effective single practice for bridging design and engineering, and they’re also the most underused.

A pairing session for a complex interaction: I sit (or screenshare) with the engineer while they implement the interaction. I can point to the prototype and say “the delay here should be 200ms, not 300—it feels sluggish.” The engineer can say “the way this animation is structured, that delay is actually happening here, not where you think.” We solve it together in real time, in code, in the browser. The output is better and faster than any spec doc could produce.

The interactions where pairing is most valuable:

• Complex animations with multiple states and timing dependencies
• Responsive layout decisions that aren’t fully specced in the design file
• Accessibility implementations where the right pattern isn’t obvious from the design
• Anything where the spec says “matches design” but the implementation will inevitably require engineering judgment calls

For pairing to work, the design director needs enough technical fluency to understand what the engineer is doing and to communicate in their frame of reference. Not to write the code, but to read it well enough to have a productive conversation. Tools like AI code generation (which I cover in AI-assisted design workflows) are increasingly helpful here—being able to scaffold a quick implementation to show the pattern you’re looking for is faster than a paragraph of written explanation.

Managing design file drift

One of the most persistent problems in design-engineering collaboration is that the Figma file and the production codebase slowly diverge over time. Engineers make pragmatic adjustments during implementation. Design files aren’t updated. Six months later, the design system components in Figma don’t match what’s in production, and no one knows which version is the truth.

The solution is treating divergence as a shared responsibility with an explicit process for reconciliation.

My approach: I maintain a “divergence log” in the design file—a simple doc or sticky note list that tracks every time production diverges from the design file and why. Monthly, I do a sweep: components that were legitimately improved in production get updated in Figma. Components that were incorrectly changed in production get flagged for a fix. The design file is always in the direction of “source of truth,” even if it’s briefly behind production.

The other part of this is structural: engineers should feel empowered to flag when they’re about to make a design decision and want design input, rather than making the call silently. This only happens when the design director has made clear that design is available, responsive, and genuinely collaborative—not a bottleneck to route around.

What embedding looks like in remote and nearshore setups

The embedding model works in remote setups but requires deliberate adaptation. The informal proximity of an in-office environment—walking over to show someone something, catching an engineer at their desk, overhearing a conversation—gets replaced by structured async and intentional sync.

In my remote setup, I use a combination of:

• Loom walkthroughs for async design reviews during a sprint. A 3-minute video walking through a design change or flagging a PR issue is more efficient than a written comment and more personal than a ticket.
• Live review sessions over video for anything that requires real-time judgment calls. Screen sharing with the dev environment open, reviewing in the browser, not in static mockups.
• Branch preview deployments for PR reviews. If every PR has a live preview URL, design review is reviewing the actual output, not inferring from code diffs. GitHub Actions can automate this for most modern stacks.
• Dedicated pairing slots in the shared calendar. Not as-needed (which means never)—scheduled blocks of time where any engineer can book design pairing during the sprint.

For how this connects to a broader nearshore design leadership model, how I structure remote design teams for US startups covers the team structure and operational patterns that make distributed design work at speed.

The long-term trust dividend

The most valuable outcome of embedding deeply in engineering isn’t any specific artifact or process improvement—it’s the trust dividend that compounds over time. Engineers who have worked with a design director who shows up in their PRs, who pairs with them on hard problems, who doesn’t disappear after the handoff, develop a fundamentally different relationship with the design function.

That trust manifests in specific, measurable ways: engineers flag design issues proactively rather than making silent judgment calls; they ask for design input earlier in the process; they advocate for design quality in technical architecture discussions; they pull the design lead into conversations where design should have a voice but traditionally hasn’t.

This is how design earns influence in an engineering-led culture—not by claiming it, but by demonstrating consistent value in the spaces where engineering works. The embedding practice is the mechanism. The trust is the result.

Key Takeaways

• Embedding means showing up in engineering’s actual work context—sprint boards, repositories, PR reviews—not just inviting engineers to design reviews
• The highest-leverage sprint ritual is reviewing every front-end PR for visual and interaction fidelity before it merges, not after it ships
• Pairing sessions on complex interactions produce better output than specs because both parties can adjust in real time in the browser
• Manage design file drift proactively: maintain a divergence log and reconcile monthly so the Figma file stays directionally authoritative
• In remote setups, replace informal proximity with structured async (Loom, branch previews) and intentional sync (scheduled pairing slots, live reviews over video)