Design Systems at Scale with Szymon Chudy

🎧 New Señors @ Scale Episode

This week, I spoke with Szymon Chudy, Software Engineer at Netflix, where he works on the Hawkins team building the design system that helps thousands of engineers ship consistent experiences across the company's applications.

Szymon spent two and a half years at Lokalise before Netflix, growing from senior to staff frontend engineer and leading frontend direction across teams. Earlier still he was a touring guitarist in Poland, building websites for local businesses in the winters between concert seasons. He writes about pragmatic engineering, design systems and growing in tech at chudy.me.

In this episode, we dig into what a design system is for once components are a solved problem, where the source of truth lives, why Hawkins has two branches and neither is open source, how the UI paved road changed what freedom and responsibility means, what adoption rate as a success metric does to a platform team, how codemods and agent skills carry a migration across every app, and what it feels like to lead a visual refresh as an informed captain.

⚙️ Main Takeaways

1. Components are the easy part

Szymon starts his definition somewhere other than the component library.

• What people picture: A library of reusable components. He pushes back on that picture when he sells design systems internally: "design systems are not only about components, because to be fair, components are solved things already."
• His North Star: "I'd like to enable our product engineers to focus solely on product, on business logic, on business value, on solving the product problems, not caring about whether the dropdown is accessible or not."
• How far that goes at Netflix: The platform UI team tries to take on dependency updates too, so a product engineer's job narrows to business needs.
• The longer history: "The history of design systems is way longer than the history of the internet." He means brands repeating patterns across their publications, or the fashion industry. It is also the way an organization communicates, and you include as much of that as your organization needs.

2. The source of truth lives in code

He asked me to repeat this one before answering.

• The ideal: One ubiquitous language, APIs synced between Figma and code, everything matching, and agents generating layouts in a single pass. "In reality, this is not possible because design systems are living organisms, and that's why we still need teams to maintain them."
• His answer: "The source of truth, in my opinion, lies in code. It's not an ideal situation, but the drift is always there." Design debt and tech debt both exist, so code does not always match Figma even when it should.
• Why code wins: It is what reaches the people who matter. "By users I don't mean customers of our package but the people that are clicking applications in the end."
• On a markdown description as the source of truth: I brought up an article from Vitaly Friedman's newsletter proposing an MD file an AI turns into Figma and code. His objection was determinism: "when I'm considering something to be a source of truth, I'm automatically thinking it should be deterministic. I should get the same answer every time, which is not the case for LLMs."
• The refinement: Maybe it shouldn't live in code, but it does. He's reading about component definitions that live in a separate system, the way tokens already do, described as JSON and consumed by Figma, by documentation generators and by agents.
• Why Figma deserves developer attention now: "Figma is not seen directly by our customers, but it can be seen by our agents."

3. Two branches of Hawkins, neither open source

Hawkins is two systems under one name, and the open source question comes up before either of them.

• Open source is a deliberate no: Netflix open sourced some things in the past, found them hard to tweak for internal needs, and ended up forking its own release to maintain a private version. The design system stays internal for now.
• The side of Netflix you don't see: "Netflix is not only what you see in your television, phone and so on. Maybe it's obvious for you. It wasn't for me." Friends still ask him to move a button in the app. He works on the corporate side, which is far bigger in headcount: the tools used in video and movie production.
• Hawkins Consumer: The UI that touches end users on TVs and phones.
• Hawkins Professional: His team's responsibility. "We have a big professional layer, which are thousands right now applications that consume Hawkins Professional." Designers, engineers and managers all sit in that branch, and what ships is a package called Hawkins Professional plus related tooling.
• Where the experiments are: They use Figma, but treat this as a transition period and explore widely. They are a long way into an experiment that moves component definitions out of Figma and makes them autonomous.

4. Make the right path the obvious path

Consistency versus product-team freedom is, in his words, his everyday concern.

• The two extremes: "If you have design police chasing everyone for every little divergence, and you have full freedom here, like take it, use it as you wish, I'm probably somewhere in the middle."
• Where he leans now: Toward more governance and a strict, clear paved road, and AI is the reason. "The easier it is to pick the right path, the more obvious it is, the bigger are the chances that AI agents will use that path. And not only AI agents, people as well."
• The personal version: "I have two bathrooms in my home and I have the same tiles, because I value consistency."
• The limit of prescription: "We shouldn't prescribe solutions for people because we are not aware of those solutions." The system exists so people can focus on the right things, and his team cannot know every problem a product team is solving.

5. Design systems are slower than product, on purpose

He described the lifecycle of a component and why the lag is built in.

• The complaint and his answer: "Design systems are slower than product. People usually are angry about that, but I think this is a feature, not a bug, because design systems are following product teams."
• The ideal lifecycle: A product team invents something, it gets promoted to another use case, and then another team picks it up. By then there is data on how people use it and how it applies in different contexts, and that is a valid case for a new component.
• Legal hacking: People will always diverge, so expose sanctioned ways to do it. "If someone wants to change our brand color to magenta, it's not our job, it's their job."
• The boundary that comes with it: "The moment you start hacking our styles, you cannot be sure that when we ship the next major, you will have all the migration done without any effort, because we cannot predict every possible hack people used."

6. Shipping context for agents is now everyone's job

Should a design system ship with skills and an MCP server?

• The goal has not changed: The platform still exists to get product engineers out of the plumbing. "We want it to be user friendly, agent friendly." The more the platform takes on, from layouts to logging, the more the context it ships matters.
• Why agents need it more than humans do: "When you have a human trying to solve some problem, they can go from one place to another. They can even ask a colleague. And agents cannot do that. And it's our job to predict it to some extent, whenever it is possible."
• What to predict: What information an agent may need, what happens if it is wrong, how it can recognize that, and what it can do about it.
• Beyond the design system: "Providing the right context is, nowadays, everyone's job." Product teams should care whether their agents know the problem being solved in the big picture.
• How fast this moved: "Two years ago we wouldn't be talking about skills, and now it's obvious: you have a large migration, please provide a skill for us so agents can do the migration, at least the heavy lifting."

7. A design system is never finished

Why the maintenance never stops.

• The forces: Business priorities, the things being built, the platforms they target and the underlying technology all keep moving.
• The answer: "The reason they are not finished is not that we need to rewrite buttons every now and then. It's for us to follow the needs of the organization."
• The new regular work: Providing skills for migrations, for his team and for others.

8. What freedom means on the UI paved road

A company famous for letting teams choose anything ended up with one recommended stack.

• The history: Freedom and responsibility meant teams picked everything themselves for years. If a team felt another framework fit the project, they could use it, and they still can. In practice the vast majority of the frontend is React.
• The question they ask now: "Does freedom mean that you can pick any framework you like? Or does freedom mean that you can trust us, your platform team, that we will supply you with all you need so you can focus on business value?"
• What the paved road includes: A few commands set up an application with staging and production environments, and internal support engineers are on hand when anything breaks. "If you choose the UI paved road, you choose everything we provide, and we provide a lot."
• The trade: Pick React Native for a good reason, as a few applications have, and the choice is yours. "You have to take that burden of maintaining all the things we take care of for you if you follow the paved road."
• Where the idea comes from: He pointed at Elizabeth Stone's recent appearance on Lenny's Podcast and her case for engineers who think in systems. "We try to take one problem and find the best for us solution to solve it and make it effortless for people to pick, and for agents as well."
• One library: Hawkins ships a React library only, with React Router on top. A component definition living outside Figma would eventually need a compiler that targets other formats.

9. Feedback from thousands of apps

How requests come in, and how the team weighs them.

• The mindset: Teams can opt out, so "we have to think like a product team. We have to sell our products to people."
• Ways in: Open meetings anyone can join, run in both US and EMEA time zones, plus a standing invitation to talk to the team directly.
• The support layer: Netflix has internal support for engineers, with trained support engineers as first contact. If a Hawkins problem is a bug, it gets promoted to a ticket.
• On call: A weekly rotation, so there is always a Hawkins engineer on call and urgent bugs get handled with priority.
• Why feature ideas move slowly: "Every decision we make is being multiplied by the amount of applications and people that will need to digest the consequences of our choices." Someone's chart idea does not ship next week, because "our job is to find the generic solutions that will work for the majority, not support certain use cases."

10. Adoption rate is the metric, so migrations become the product

I asked whether freedom of choice creates an adoption problem. His answer is about what the metric forces.

• The metric: "The way we set our metrics for success is adoption rate." It pushes the team to build tooling that makes migrations painless, where the alternative is a doc that says a prop was renamed.
• Codemods first: For major migrations with breaking changes, "everything we can define with a codemod, this is our job to provide for people."
• Skills where codemods fall short: A colleague recently migrated their table solutions. Mapping one property to another was not enough, so it required a skill, and he says the colleague did an amazing job.
• Human in the loop: Szymon currently leads a visual refresh of components that had not been updated for years. Those changes have to be seen by people, because he cannot promise every page will work the same way.
• The target: "For people to have a PR automatically prepared for them with all the codemods and skills run, for people to verify and iterate on top of that."

11. The argument that sells Hawkins is that you stop caring

Adoption used to be a fight.

• The origin: "Hawkins appeared not as a strategic organizational move, it appeared almost 10 years ago, and that was coming from a real use case from engineers." People noticed they were duplicating the same work X times and built a shared library.
• The ambassador years: The early maintainers spent years chasing teams to adopt it.
• Today's choice: "Either you take everything the platform prepared for you, batteries included, and you don't care about anything, or you care about everything yourself and you are responsible for yourself." Hawkins comes with the AI skill set included.
• The detail arguments: Regular accessibility audits and a refreshed look for a cohesive experience, on top of the work of hundreds of people preparing a platform for you. "The biggest win is that you don't need to care about it."

12. You may not need a design system

His first tip for anyone building one.

• The temptation: Starting a project by building the design system first. He thinks that route is wrong.
• Why: "For many startups or early products, usually it doesn't matter if your application is fully cohesive." Open source solutions do a great job for the vast majority of cases.
• The scale requirement: "Design systems, to be run in a maintainable way, in a way that brings value to organizations, require some scale."
• His own evidence: At Lokalise there were ten or fifteen frontend engineers. "It was hard to justify that from the business perspective." Even with his passion for frontend foundations, he could see the ROI was not there, which is why he went looking for a bigger company.
• When to start: When a second application appears and reuse becomes real. Start with some components, without perfecting everything.

13. What a visual refresh involves

I asked about workflow, variants, tests and Storybook.

• The standard pipeline: Figma defines the component, code implements it, Code Connect maps the Figma API to the code API so the Figma MCP works better, then a rendering environment, whether Storybook or a documentation package that renders live components.
• The CodePen-style tool: Hawkins offers a StackBlitz-like environment where people can play with a component on the latest version. Its other purpose is bug reports: "it allows us to detach the business context from them."
• The shallow description: "My job is basically to make components prettier. That's the shallow way of perceiving that."
• The real work: Two Figmas to diff, with some variants deprecated and others reused. There is a gap between how things are implemented in code and in Figma, so removing a variant in Figma rarely maps to deleting a single enum entry in code.
• The questions each change raises: If a variant goes, where do users migrate? If the default color changes, do you ship that as a visual breaking change or give people a way to keep the old color? "In the end we are going to be responsible for migrations, and if adoption will be low, we will treat it as our failure."
• How new components arrive: A product team built the query builder and had it approved by designers. The new table was written in-house, with old and new maintained side by side so people had time to migrate.

14. Alpha, beta, GA, and the team migrates the early adopters itself

The release process for a breaking change.

• What they avoid: "Going atomic, I mean with the nuclear bomb, that would be the disaster. I would take a vacation the next week probably."
• The phases: Alpha, then beta, then general availability.
• What alpha is for: Early adopter teams, and the Hawkins team joins them. "We plan to join those teams and migrate the applications for them," running the codemods and skills themselves.
• Why: They expect edge cases nobody thought through and hacky solutions the team could not have known about. Each one refines the tooling until it is worth automating across all applications, after which the team supports anyone who gets stuck.
• Tokens too: A lot of tokens will be consumed when those repositories migrate, and the team triggers that.

15. What an incident looks like on a design system team

The on call rotation handles a different kind of failure than a product team's.

• A recent one: A change introduced a regression where keyboard navigation stopped working in the list box. He ranks it below a drop-everything P0 and still a priority, because "people trust our solutions and trust is the thing we value most when it comes to our relationship with our users."
• The token risk: Tokens live in a separate source of truth, fetched from an API and shared between Figma and code. Someone accidentally removing a token, combined with tests that miss it during release, means missing styles in production.

16. Informed captain, farming for dissent, disagree and commit

I asked whether No Rules Rules is still true inside. He came in skeptical.

• The baseline: "I'm super skeptical about all that coaching, self growth things." Coaching had a bad name in Poland for years, and he became allergic to soft skills books.
• How he got there anyway: A colleague already at Netflix told him he would fit the culture. His answer was no way, he would never work for big tech. The colleague shared real examples and got him hooked.
• After five or six months: "I feel that culture from my perspective is a real thing. Does it mean that everyone lives by it? I don't think so."
• The default answer to any question: Ask a manager or colleague whether to do X or Y and you hear "do what's best for Netflix's interest."
• Informed captain: As the leader of the visual refresh he is the deciding person. "I'm expected to farm for dissent. I'm expected to invite people to disagree with me, to challenge my assumptions. But in the end, I'll be making the final call and I'll be responsible for that call." The people who challenged him then commit.
• Why button colors matter: "For some people it would be, you're just changing button colors, right? But for me, I'm changing 2000 applications, and those applications are being used to create a new season of my favorite show."

17. The keeper test, said out loud

The management practice that surprised him most was the one he had read about in the book.

• The mechanism: A 360 feedback run once a year, where you invite people to leave you feedback. After it, the manager runs the keeper test: "should I keep hiring you? That's the rough way of framing it."
• Why it's less brutal than it sounds: You build a relationship with your manager, so if something is wrong you expect candor well before the test.
• What was new: In previous jobs the signal was shady, a nudge about a PR taking too long. Hearing "I will think if I should keep you or maybe give you a raise, and this will happen in three months, so be prepared" was different.
• What he admires: "No matter what's your tenure, no matter your position, no matter what your level, you are free to share your opinion and express it."

🧠 What I Learned

• A design system exists to let product engineers focus on business logic; the component library is the smallest part of that.
• The source of truth lives in code because code is what reaches the people clicking the application, and an LLM-generated artifact fails the determinism test a source of truth needs.
• Netflix runs two branches of Hawkins, Consumer and Professional, and the Professional branch serves thousands of internal production tools.
• The easier the right path is to pick, the more likely both agents and people take it, which is the reason he now leans toward governance.
• Design systems lag product teams by design; a component earns its place after a product team invents it and a second use case proves it.
• Shipping context for agents, from skills to the signals that tell an agent it is wrong, belongs to whoever maintains the platform.
• The UI paved road turns freedom and responsibility into a single choice: take everything the platform provides, or take on all the maintenance yourself.
• Measuring a design system team on adoption rate forces it to ship codemods and skills with every breaking change.
• You may not need a design system; with ten or fifteen frontend engineers the ROI was not there, even for someone who loves foundational work.
• A migration goes alpha, beta, GA, and during alpha the design system team migrates early adopter apps by hand to refine the tooling.
• Trust is the asset a design system team protects, so a keyboard regression in a list box gets priority even when nothing is down.
• Informed captains farm for dissent and then make the call they will be held responsible for; everyone else disagrees and commits.

💬 Favorite Quotes

"Design systems are not only about components, because to be fair, components are solved things already."
Szymon Chudy

"By users I don't mean customers of our package but the people that are clicking applications in the end."
Szymon Chudy

"The easier it is to pick the right path, the more obvious it is, the bigger are the chances that AI agents will use that path. And not only AI agents, people as well."
Szymon Chudy

"Design systems are slower than product. People usually are angry about that, but I think this is a feature, not a bug."
Szymon Chudy

"Does freedom mean that you can pick any framework you like? Or does freedom mean that you can trust us, your platform team, that we will supply you with all you need so you can focus on business value?"
Szymon Chudy

"Every decision we make is being multiplied by the amount of applications and people that will need to digest the consequences of our choices."
Szymon Chudy

"Going atomic, I mean with the nuclear bomb, that would be the disaster. I would take a vacation the next week probably."
Szymon Chudy

"For some people it would be, you're just changing button colors, right? But for me, I'm changing 2000 applications, and those applications are being used to create a new season of my favorite show."
Szymon Chudy

🎯 Also in this Episode

• Szymon's years as a reggae guitarist in Poland, after the singer he worked with reached the finals of the Polish Got Talent, and the hundreds of concerts a year that followed
• A master's in jazz performance, a seasonal touring schedule, and freelancing as a web developer in the winters, building sites with tables and Photoshop
• Why running an indie band taught him the product mindset the Hawkins team now works with, and why running a meetup feels like being on stage
• The article from Vitaly Friedman's newsletter arguing the source of truth should be a markdown description an AI turns into Figma and code
• A friend's design system that generates a web package and native packages for Android and iOS from one definition, and why Hawkins stays React-only for now
• How he went from one or two books a year to twenty-something this year, because he got tired of reading the same AI voice everywhere
• John Grisham paperbacks and why he likes how old books smell
• Jack Reacher and the Hercule Poirot movies

Resources

More from Szymon:

• chudy.me: his freshly redesigned site about pragmatic engineering, design systems and growing in tech

Tools & concepts mentioned:

• Hawkins Professional and Hawkins Consumer: the two branches of Netflix's internal design system
• UI paved road: Netflix's batteries-included frontend stack, React with React Router on top
• Figma Code Connect and the Figma MCP: mapping the Figma API to the code API
• StackBlitz-style playgrounds: for trying components and reproducing bugs without business context
• Codemods and agent skills: the migration tooling behind every breaking change
• Design tokens served from an API shared between Figma and code
• Informed captain, farming for dissent, disagree and commit, the keeper test and the 360: Netflix culture terms from the conversation
• Lenny's Podcast with Elizabeth Stone: on engineers who think in systems

Books mentioned:

• No Rules Rules, Reed Hastings and Erin Meyer: the Netflix culture book, with an audiobook read by two actors
• The Culture Map, Erin Meyer
• Grokking Web Application Security: his pick, from the Grokking series that started with Grokking Algorithms
• The Pelican Brief, John Grisham: the 1992 movie came up too
• Master Security: my free web security course, which Szymon plugged before I could

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 56 minutes on what a design system is for, where the source of truth lives, the UI paved road, adoption rate as the metric, codemods and skills for migrations, and what Netflix culture looks like from inside after six months.

Whether you maintain a component library ten teams depend on, or you are deciding whether your startup needs a design system at all, this one has an answer from someone maintaining a design system for two thousand applications.

Happy paving,
Dan