To build a design engineering team, decide who owns production first, because that decides which job you are hiring for. Then start with one design engineer, grown from your team or hired, and hire for behavior rather than a list of keywords. Before the first designer pull request, put the design system behind four guardrails and pair every designer with a named engineer.
This chapter of the guide to becoming a design engineer is for the person who builds the team: a head of design, a design manager or a design-system owner. It uses the guide's definition throughout.
Step 1: Decide who owns production before you hire
The title covers two jobs, and the difference is who gets paged. On the product track, the design engineer works in the app's codebase, and an engineering team owns deploys, incidents and dependencies. On the marketing track, the design engineer often runs a website end to end, production included.
Mehmet Baytaş, previously a design engineer on Attio's marketing team, explained why the difference matters in his Hatch Conference 2026 keynote. An engineer is sometimes on call, he said, and maintaining something in production is the discipline of engineering. A production website carries a different responsibility, and a different lifestyle.
Answer these in writing before you open the role.
| Question | Product track | Marketing or web track |
|---|---|---|
| Who is paged when it breaks at night? | The on-call engineer | Often the design engineer |
| Who merges? | An engineer reviews and merges | Often the design engineer |
| What does the design engineer own after merge? | The quality of what they shipped, not on-call | The whole site, on-call included |
Anton Zaides, an engineering manager, named the open question in his Manager.dev issue When non-devs open PRs. "When something a non-engineer wrote breaks at 2am, does the reviewing engineer own it, does the team own it, or does the author?" Decide it before the first merge, not after the first incident.
This guide describes the product track. If your answers sit in the right-hand column, you are hiring someone closer to a front-end engineer with design craft, and the posting should say so. Chapter 2 answers the objection that the job is really engineering.
Step 2: Grow or hire your first design engineer
Start with one design engineer. Before you hire design engineers from outside, know that the market is thin. Hymera, a recruiting firm, studied design engineer ads across Europe and found almost every role senior. "The junior version barely exists," its report says. "The market wants design engineers who already exist, and it is not making more of them."
Growing one skips the search. A designer on your team already knows the product, the components and the engineers. What they lack is narrower than a second career: five concepts learned inside your codebase, plus one engineer willing to review. Pick the designer who already opens the repository out of curiosity.
Hire when nobody on the team wants the job, or when the product needs craft the team does not have. Baytaş described founders who planned to hire two or three people, a designer and an engineer among them. In his account, once he started, he could do the whole job. If that is the hire you want, you are in the right-hand column of step 1.
Decide where the first one sits. At Vercel, "Design Engineers are embedded in a product team to help launch features that usually take more than a month" (Design engineering at Vercel). The design engineer builds the UI, and the product team builds the API and infrastructure. At a smaller company, copy the split. The design engineer reports into design, and their pull requests go into one product team's review queue.
On our sales calls, product teams typically have one designer for every ten to thirteen engineers. Those engineers' time goes to their own roadmap, so every designer pull request competes for it. Set up the guardrails in step 5 before the second hire.
Step 3: Write the design engineer job description
A design engineer job description should name the track, say who owns production, and describe what the hire ships in the first month. Neither Vercel's nor Linear's current posting mentions on-call.
Vercel's posting for a design engineer on its AI Gateway team is the most explicit about what the hire owns (vercel.com/careers, September 2026). It asks the hire to "Own quality after launch, including visual and interaction craft, accessibility, performance, resilience, instrumentation, and edge cases." It sets the terms for AI too: "You use coding agents in your daily work, but you can explain, test, debug, and take responsibility for the code they help produce." Owning quality after launch is not the same as being paged. Say which one you mean.
Copy this skeleton and fill the brackets.
# Design Engineer, [product area]
## The role
You will design and ship [product area] in our [React / Next.js] codebase.
Your work reaches production through pull requests that [team] engineers
review and merge. [Engineering team] owns deploys, on-call and the backend.
## What you will do
- Design in code: layout, states, motion and copy, on our real components.
- Open small pull requests, and read your own diff before anyone else does.
- Fix design drift you find in engineers' pull requests, in the pull request.
- Keep [design system] tokens and components the source of truth.
## Your first month
- Ship one merged change to [surface], reviewed by [named engineer].
## You have
- Shipped work to show: merged pull requests, live pages, before and after.
- Product design craft in [interaction / visual / systems].
- Enough front end to explain a diff: components, props, tokens.
- Daily use of a coding agent, and the habit of checking what it wrote.
## You do not need
- The design engineer title, or a computer science degree.
- Backend, infrastructure or on-call experience.
## How we hire
- A conversation about work you shipped and the hours you lost in it.
- A paid, scoped task in a copy of our repository, reviewed like any pull request.
- A conversation with the engineer who will review your work.
Three lines carry the weight. "Engineering team owns deploys, on-call and the backend" answers the production question for the candidate. The "You do not need" list follows Vercel's posting, which says "There is no required path into this role." And the first-month line tells a candidate the work is small, reviewed and real.
The candidate's side of the same posting (portfolio, interviews and pay) is in the design engineer career chapter. Posting counts and the words employers use are in the Design Engineer Report 2026.
Step 4: Hire for behavior, not keyword combinations
Baytaş said startups hiring design engineers are not really looking for a particular combination of keywords or titles. They are looking for what he calls heart. Asked what that looks like, he pointed to behavior. Look for the work a candidate locks into for hours without noticing the time. Look for projects they took on knowing nothing about part of them, deployments for example.
Both show up in an interview if you ask for them.
- Walk through one merged change. Ask what changed, what the diff looked like and what the reviewer pushed back on. Someone who reads their own diffs can explain a line they did not type.
- Ask where the hours went. What did you build that nobody asked for? gets at the first behavior faster than a skills grid.
- Pay for a small task in real conditions. At Linear, "the final stage is a paid work trial", a "2-5 day project" (How we hire at Linear). A smaller team can pay for one day: one change in a copy of your repository, reviewed by the engineer who would review the hire.
What leads weigh is shifting too. Design leaders in the AI in Design Report 2026, from Designer Fund and Foundation Capital, now weigh AI fluency and systems thinking more when hiring. Narrow specialization counts for less.
Step 5: Protect the design system before the first designer pull request
What engineers object to is code that leaves the design system. Think of a hardcoded hex where a token was, a second button next to the first, or a shared component bent for one screen. Four guardrails catch it, and you set them up once. Three run on every pull request. The fourth is a page of rules.
Tokens, enforced by lint
Keep colors, spacing and type in tokens, and make the checks reject anything else. In Tailwind v4, resetting a theme namespace removes the defaults and leaves "only your custom values" (Tailwind docs). That does not stop an arbitrary value such as bg-[#0000009e]. The no-arbitrary-value rule in eslint-plugin-tailwindcss does, keeping contributors on "the values defined in the Tailwind CSS config file". Its Tailwind v4 support is still partial, so check it against your version. For plain CSS, stylelint-declaration-strict-value does the same job. How to structure the tokens themselves is covered in the guide to design tokens.
A CODEOWNERS file on the design system
A CODEOWNERS file names who owns which paths in the repository. Put the design-system folders under the design-system team. GitHub's code owners docs explain what that does: "Code owners are automatically requested for review when someone opens a pull request that modifies code that they own." Then turn on "Require review from Code Owners" in the branch protection rule for main. A change to a shared component cannot merge without that team's approval.
# .github/CODEOWNERS
/components/ui/ @your-org/design-system
/styles/tokens/ @your-org/design-system
A design-system lead asked us the question this answers: if any designer can push, who manages the change? The code owner does, on every pull request that touches the system.
A preview link on every pull request
Reviewers judge a visual change by looking at it. On Vercel, "Each deployment gets an automatically generated URL, and you'll typically see links appear in your Git provider's PR comments." Netlify builds a Deploy Preview for each pull request. If the design system lives in Storybook, Chromatic runs visual tests on each pull request and flags what moved.
Written rules for what designers change alone
The last guardrail is a page, not a setting. Zaides, Eduardo Sonnino at Atlassian and one engineering team we worked with during a pilot each drew the line in a similar place. Designers change copy and pure UI, with no logic, no shared platform code and no edits to a shared component's source. Sonnino, a principal designer for AI, adds a rule for every change in Designers' workflow for shipping code: "Always create Pull Requests, never direct-merge." Write your version down, and review it after the first ten merges.
Chapter 6 lists those rules from the designer's side, in a walkthrough of a first pull request. Whether the AI tools themselves respect the system is a separate question, covered in how AI tools use your design system.
Step 6: Pair every designer with a named engineer
Lint catches mechanical errors, and code owners guard the system. A named engineer catches the rest, and that person is named before the first pull request opens. Zaides's team first posted designers' pull requests in a channel for anyone to pick up, and they sat there. His fix is one developer responsible for each non-developer's work.
Alan, a French health insurer, ran a version of this across the company. Ujala Anis, its design and research lead, and Alexandre Gerlic, its VP of engineering, wrote it up in Everyone can build. Each non-engineer was paired with a member of a setup crew, and the team "started with small text changes, layout tweaks, and quality improvements, and celebrated every merge." Alan reports 283 pull requests from non-engineers shipped, and "Engineering time is increasingly freed up for more complex problems."
At Intercom, the review is the gate. Designers there have their own local dev environment, and "their fix gets shipped straight to production after an Engineer has approved a quick code review." Thom Rimmer and Emmet Connolly describe the setup in Intercom's framework for AI.
Then measure what the engineer corrects, not how much the designer ships. In one pilot, we proposed counting the corrections the reviewer makes on each pull request, such as a component used wrongly or not used at all. When that count falls, widen what designers change alone.
What an AI-native design team looks like
In an AI-native design team, designers change the product through reviewed pull requests, and AI does most of the typing. The lead has built the guardrails that make it safe, and exploration still happens before the code.
Karri Saarinen is Linear's co-founder and CEO, and a designer. In Design is more than code, he wrote that he is "skeptical of the industry's drive toward grand unification, collapsing a nuanced process into code and calling it progress." His worry is that building straight to production by default leaves less room to consider the problem. Keep exploration in design, and let the pull request be where decided work lands.
Most teams are not there yet. The AI in Design Report found that few companies have formally changed how they evaluate, pay or hire designers. At companies of a few hundred to a few thousand people, we have seen a strong push for AI from the top while the team is still mostly prototyping.
Teams that would rather not give every designer a local setup can use a canvas on the codebase instead. Modeinspect is one such tool: designers edit the running product with its real components and tokens, and the work becomes a GitHub pull request that engineers review and merge. It works with Next.js React codebases that use Tailwind.
The next chapter collects the terms used across the guide: the glossary chapter.
