Collaboration Has a Shape
Product development has become a multiplayer activity. Engineers at Figma no longer wait for a finished design and a scoped roadmap before they start thinking. The expectation, as Chief Technology Officer Kris Rasmussen puts it, is that engineers figure out what to build, not just how to build it. That shift is driven by the same forces that made tools like Figma possible in the first place: lower-level browser APIs such as WebGL and Web Assembly, a generation raised on Google Docs, and years of hybrid work that made synchronous collaboration the default.
But more collaboration is not automatically better. Rasmussen warns that there is a fine line between drawing on the wisdom of others and spinning in circles without a clear direction. The right balance between diverging and converging depends on the culture, the product, and what the team is optimizing for. Figma has found its own sweet spot through a few deliberate practices.
Bringing Engineers Into the Open
The first practice is writing things down early. Engineers are expected to capture their early thinking in a document and share it with cross-functional peers while the work is still in flux, not when it feels polished. Virtually every project has some kind of concept doc that evolves with input from designers, product managers, and other engineers.
To make sure that feedback actually happens, Figma runs regular engineering "crits" across its design and engineering orgs. These sessions are a dedicated time and place to source feedback from other teams. Rasmussen is explicit about what crits are not: they are not an approval process. Nothing is decided or resolved in a crit meeting; the goal is to lift a technical design to a point where it doesn't need approval. Crits are run in FigJam so everyone can participate in real time.
Knowing When to Converge
Too many inputs can stall a project, especially when the tradeoffs are hard and the ambiguity is high, like defining a first pricing model. Figma's answer is to break projects down into milestones. Clearly defining and communicating milestones manages expectations with stakeholders and signals when it is time to converge for the sake of momentum. Momentum is a fragile thing: when the team has it, progress feels imminent; when it is lost, people start to question what they are doing.
Milestones also expose when projects are at risk across teams. When something is not tracking to plan, teams can lend each other expertise or resources early. That is precisely when more input is useful. Rasmussen says people are still surprised when he dives deep into a specific area despite his title, but he believes no one should get too distant from the details that keep them grounded.
Leaves and Roots
Rasmussen frames Figma's work as a tree of dependencies. Leaves, such as UI tweaks that leave the data model untouched, can change rapidly with little risk to the rest of the tree. Roots, like a database or a new design primitive, need a more principled approach because changing them later can break existing workflows. A large part of his role is separating leaves from roots: clarifying what the team can move fast on and what requires careful input from key stakeholders.
Product changes are often root nodes too. When Figma considered a new design primitive like auto layout, the team had to be confident in the new properties they exposed, because changing them after the fact could break existing designs. Many of Figma's most significant launches required thinking along entire branches, from leaf to root, beyond the boundary of a single framework, language, or abstraction.
That kind of thinking is a change for engineers used to specializing, such as front-end developers new to systems programming or infrastructure. Figma deliberately staffs teams so engineers work on both leaves and roots, enabling them to move up and down the tech stack. Rasmussen argues that people underestimate their ability to learn quickly. The most effective makers are not just deeply specialized; they chase problems wherever they lead and do not let their roles constrain them.
Principles Over Titles
There is no single right way to run engineering, and Rasmussen has seen enough frameworks at high-growth companies to know that successful companies often succeed in spite of some of those decisions. The risk is over-indexing on canonical definitions of a role or process rather than what is required in practice. His advice is to think from first principles, keep the ego low, and go beyond the constraints of what has been tried before. Roles can define a starting point, but they should not become rules that limit how a team solves a new problem.
