Why roles are not rules

I joined Figma as a contractor in 2016 when we had 12 engineers. Before joining, I’ll admit I was skeptical that we could build a collaborative, performant tool in a web browser. Now, that feels like a lifetime ago, but at the time, there was a renewed emphasis on, and excitement around, apps and mobile devices, as well as a number of notable failed attempts to build web experiences that lived up to their native counterparts. It took a major shift, driven by technical and cultural changes, to make Figma possible. The introduction of lower-level browser APIs—like WebGL and Web Assembly—allowed us to reimagine what was possible on the web. This was compounded by a generation that grew up on tools like Google Docs, and later accelerated by the last few years of hybrid and remote work, which pushed us to fully appreciate the value of synchronous collaboration.

Today, the expectation is that our tools are increasingly multiplayer by default. And it’s not just the expectations of our tools that have changed, but how we relate to each other, and our expectations of one another. Going from those early days as a contractor writing code, to leading the team, I’ve thought a lot about what that uniquely means for engineers. How is our role evolving as product development becomes increasingly nonlinear

? What should collaboration actually look like as an engineer? And is it always a good thing?

It’s easy to anchor on the extreme. If working closely leads to stronger outcomes, why wouldn’t we want to get feedback and iterate all the time? Broadly speaking, I’ve found that there’s a fine line between leveraging the wisdom of others and spinning in circles without a clear direction of your own. In practice, there will be times when we need to work more independently, and times when we should go out of our way to bring others in. I’ve learned from experience that the ideal balance between diverging and converging is different for everyone—based on your culture, the products you’re building, and what you’re optimizing for. As you find the right balance, I wanted to share how we think about our own collaborative sweet spot, within engineering and across product development.

It’s no longer the case that product development starts at design and ends at engineering. Still, in many orgs, product managers and designers are responsible for setting the roadmap, while engineers execute on that roadmap. This is something that Yuhki Yamashita, my counterpart on the product team, and I wanted to get right. We work very closely together, and that waterfalls to the rest of our org. Engineers don’t just define how to make things, they also figure out what to make by working closely with their cross-functional peers, and hearing feedback from customers.

When it comes to starting new streams of work, we always encourage teams to draw from a range of perspectives as early as possible, allowing a concept doc to evolve based on input from the rest of the product development team. Engineers are expected to write down early thinking, and the goal is to get feedback from their collaborators as they’re working on it, not when it feels “polished.” Virtually every project has a document of some sort to capture this early thinking; the challenge is getting quick feedback from teams when they’re sprinting on their own work.

That’s why we hold regular engineering “crits” across our design and engineering orgs: to ensure there’s always a dedicated time and place to source feedback from other teams. The engineering crit plays a very specific role. It’s a place to solicit feedback early and often. It is a forum to get expert support on technical designs. It is not an approval process. Nothing is decided or resolved in eng crit meetings, and that’s by design. The goal is to help lift up the design to a point where it doesn’t really need approval. We use FigJam to run these meetings so everyone can participate in real time—they are a lot of fun!

But what happens when there are too many inputs, or conflicting feedback? I’ve seen projects go off the rails when there isn’t the right mix of being generative and explorative, while also moving things forward. It's especially hard when there are difficult tradeoffs and a lot of ambiguity to navigate, like defining your first pricing model; too many competing perspectives and new ideas can easily translate to getting stuck.

That’s why we break projects down into milestones. It may sound simple, but clearly defining and communicating milestones helps us manage expectations with other stakeholders and reminds us when it’s time to converge for the sake of progress and momentum. Momentum is a very important thing. When we have momentum, we feel like we’re always just a few steps away from our goals. When we lose momentum, we start to spin and question what we’re doing.

At Figma, milestones don’t just help us converge within teams, they also allow us to identify when things aren’t tracking to plan across teams. By communicating when things are at risk early, we can lend each other expertise or resources and rebuild momentum. This is exactly when more input is useful. Sometimes, if I see that a project is stalling, I’ll dive in. People are still surprised when I go deep on specific areas simply because of my title, but it’s important that we help unblock each other and that none of us gets too distant from the details that keep us grounded.

On a foundational level, I like to think of our work at Figma as a tree of dependencies. Leaves can change rapidly with little risk to the rest of the tree, but the roots need to be solid. When you’re scoping a project at the root level, considerations are very different from something at the leaf level. If you’re building a database, you certainly don’t want to go off independently and “move fast and break things”—you have to be much more thoughtful about getting the right input when you’re working on lower level systems, compared to something higher up in the tech stack. If you’re working on a feature that changes the interface but leaves the underlying data model untouched, it’s often lower risk to experiment more independently—but you still shouldn’t “break things” for users. A big part of my role is separating the leaf nodes from the root nodes, clarifying for the team what they can move quickly on, and what requires a more principled approach, with feedback from key stakeholders.

Product changes are often root nodes, too. For example, when we’re considering a new design primitive, like auto layout, we have to ensure that we’re really confident in the new properties that we expose because changing them after the fact could break existing workflows and designs. Many of our most significant launches and technical feats required us to think along entire branches, from leaf to root, beyond a single framework, language, or abstraction boundary.

This can be a change for engineers who are used to specializing, like those with experience on the front-end who are new to systems programming or infrastructure work. The thing is: we all underestimate our ability to learn quickly. That’s why we intentionally staff teams so that engineers can work on both leaves and roots, providing a structure that enables working up and down the tech stack. Together, we can lean on each other’s expertise and face challenges head-on, instead of working around them. The most effective makers aren’t just deeply specialized in one area; they are the ones who invite a challenge and have the confidence to quickly learn new systems. They chase problems wherever they lead, and don’t let their roles constrain them. It’s this way of working that gave us the courage to bring product design to the web in the first place.

I’ve seen enough different principles, frameworks, and processes at different high-growth companies to know that there’s no one “right” way to do things. In fact, the most successful companies often succeed in spite of some of these decisions. As we navigate an ever-changing landscape of engineering and collaboration together, we can’t let prior experiences limit our team’s ability to solve the nuances of new problems. Likewise, we should resist the urge to limit ourselves to our roles and titles. It’s easy to over-index on a canonical definition of a role or process, rather than what’s required of us in practice—to think from first principles, come from a place of low ego, and go beyond the constraints of what’s been tried before.