Inside Figma’s Engineering Culture
A deep dive into how the dev team works at Figma and their “build with deliberation, build with pride” engineering culture. As told by Figma’s CTO, Kris Rasmussen.
Figma is a design platform for teams to build products. Founded in 2012, the company launched its first paid product in 2016, which exploded in popularity for Figma to become the market-leading designer collaboration tool it is today.
In September 2022, Adobe acquired Figma for $20B, in what was Adobe’s biggest acquisition to date. At the time of publishing, Figma employs more than 1,000 people, and about 300 of these work in tech.
Clearly, Figma has done plenty of things right to become the go-to tool for designers, out-competing companies including Sketch and Adobe. I was interested to learn how the company operates from an engineering perspective, and what inspiration other tech companies could take from Figma. So I reached out to CTO Kris Rasmussen, who was generous in sharing his insights during a conversation which lasted more than two hours.
In this issue, we dig into the engineering culture at Figma, as Kris walks us through these topics:
The engineering team’s evolution and what’s unique about Figma’s culture.
Engineering structure: pillars, platform teams, EM/engineer ratios.
Getting things done. Exploration vs execution, the planning process and prioritizing fixing bugs.
The engineering culture. Dogfooding, experimentation, quality weeks, onboarding engineers and internal mobility.
The engineering career ladder. When and how it was built, and its levels.
The tech stack. React, TypeScript and C++ on the frontend; Ruby, Go and TypeScript on the backend.
Engineering challenges. Client-side performance, distributed databases and scale.
Tech can be a small world, and in 2016 when at Uber I worked on a major app rewrite with Yuhki Yamashita, who’s Figma’s Chief Product Officer. He shares details on how Figma builds products in
, which is a nice accompaniment to this issue from a product point of view.With that, it’s over to CTO Kris, who shares details on the engineering side of things at Figma. What follows are his words.
1. The engineering team’s evolution
During its early days in 2012-2016, Figma was a very small team working on a very ambitious minimum viable product (MVP,) at the peak of the Web 2.0 movement. Back then, the conventional wisdom was to measure success by whether you could launch something within six months: any longer was too slow.
But the reality is that if you’re ambitious about what you're trying to bring to the Web, then it just takes more time to build a quality app, as Figma has proved by ignoring conventional wisdom.
Figma started to ramp up hiring around 2016, when the MVP was ready and looked promising, and the company had 12 engineers. That same year, I started as a contractor, joining full-time in 2017 when the eng team had 15 members.
When I joined, engineering was a single team with one engineering manager. We decided to split the team into two functional areas:
Team blockers: focused on the differentiators and collaboration story.
Individual blockers: focused on filling in the long tail of feature gaps that blocked product designers from persuading teams to switch tools.
We stuck with this structure until we felt enough blockers were filled. Then the team grew to be large enough that we needed to split it again.
We organized teams around focus areas by examining what the most urgent challenges were, and how to temporarily organize teams to resolve them as fast as possible. We were intentionally not seeking a long-term structure for the organization. We ensured everyone understood it was a temporary and fluid approach.
These temporary structures stayed in operation until around 2019 when the team was big enough to start thinking about creating higher-level structures to promote greater continuity and stable ownership over time.
As a company gets larger and more mature, you need to generate a sense of longer-term ownership. We came to this conclusion as the engineering team grew. In some cases, engineers want to feel ownership and responsibility for shepherding forward some part of the product or technology. Another driver was to define ownership in the longer-term, as there are often many areas in need of continuous improvement and iteration, on a longer time horizon.
One thing Figma has done well is to stay very detail-oriented. We do not always just focus on the next big thing, but also on the small details that really make a design tool fluid, efficient and something people love to use. Engineers want to feel more ownership, and the product also needs more love in specific areas.
Unique things about Figma’s engineering culture
Lift your team. In the early days of Figma, we created the value: ‘Lift your team.’ This stood out to me when I first got involved with Figma and I observed how supportive and focused people were on uplifting colleagues, not competing with each other.
I think that's carried through in the culture in the sense people don’t try to win arguments and similar individualistic behaviors. It's really about the right solution as a group and being very open to feedback. An example of this in action is that our design team has a process called “design crits.”
Design crits. A unique thing about our design team is that they’re very welcoming of engineers, who often join design crits to share and hear feedback. It helps make the early exploration phase of projects more collaborative, versus designing something and then handing it to engineering.
Close to customers. We encourage engineers to be very close to customers. While we do have a user research function, engineers still frequently observe user research studies. They engage with customers in private beta channels in Slack, and we try to work closely with customers.
To give an extreme example, both Dylan – the CEO and cofounder of Figma – and I engage with people in support and answer queries on Twitter. I still occasionally jump onto Zoom calls to debug customer issues, to ensure I know what the problems are.
2. Engineering structure
Engineering pillars
In the early days, we wanted people to work full stack and own things top to bottom. As we grew, we divided the organization into a “sandwich structure.”
Figma currently has seven engineering pillars. A pillar is like a product group or a tech group. At the top level, there’s pillars focused on vertical products, still thinking about end-user needs. At the mid-level, we're thinking about common features of those products. At the lower level, we're thinking about the shared systems and frameworks which enable everything above.
We try to model different functions around this higher-level pillar structure. Engineering usually is a bit ahead in terms of headcount, compared to functions like product. The management structure tracks the pillar structure almost one-to-one, if not exactly. Product and engineering is also organized according to the pillars.
Two examples of pillars: