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 tech stack. React, TypeScript and C++ on the frontend; Ruby, Go and TypeScript on the backend.
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.
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.We cover more on how Figma’s engineering team operates in the podcast episode Building Figma Slides with Noah Finer and Jonathan Kaufman.
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:
The Figma Editor. This is for the Figma design project and is a vertical pillar.
The Creation Engine. This pillar is an infrastructure team, but focused more on the UI engine side of Figma, versus traditional web scale infrastructure.
What about specialized cases like site reliability engineer (SRE) folks, data team, ML engineers, etc? The way we handle these is similar to smaller functions. At the highest level, we’re trying to decide whether or not a group is actually a different function, with a different career ladder, different career path, versus the same function. If it's more of a distinct function or different domain with more specialization, then we're more willing to consider it a pillar of its own.
For example, we currently have a pillar called “Native,” a group with domain experts around iOS, Android and Electron. Engineers report into the Native pillar and also work across other pillars. They embed themselves and pair with teams, reporting through a different structure. That's the trade-off we're always making: most people report through the pillar structure, but certain specializations and functions also report outside of it.
Platform teams
Earlier in the company’s history, we had some smaller, platform-like teams. However, when we introduced our second product, FigJam, it became more obvious that the two products – Figma Design and FigJam – shared technology stacks. So it was helpful to create product-agnostic teams that can really focus on common themes and challenges across both products, and these are our platform teams.
Date-driven initiatives were another reason why we created platform teams. Such initiatives frequently swallowed up platform work for a team. So by carving out dedicated teams for important platform work, we could be more intentional about how much time we spent on platform work.
We just call these teams by their name, and don’t use special platform names. We try to keep our platform teams working very closely with product managers (PM) and product developers, so they're close to the end user. Even our platform teams stay close to end users which is something many people appreciate about Figma, and is something we want to keep.
Engineering manager-to-engineer ratios
Our EM-to-engineer ratio is around 1 to 8-10. How did we get to this ratio? It comes down to whether or not an engineering manager has the ability to adequately support their team. Engineering managers also need the bandwidth to work on things their team does to help the company be successful.
When the engineer-to-manager ratio gets too high, for example, more than 10 engineers to each manager, then you're either compromising a manager’s ability to support the team, or reducing their ability to think strategically about what their team can do, and what they can do for the company. Our current engineer-to-manager ratio seems like a happy balance.
Not every engineering team has a PM counterpart. For our more infrastructure-focused teams such as for web infrastructure, the PM / engineer ratio is lower. In a sense, engineers wear the PM hat on those teams.
Upper limit on headcount growth
We have been intentional about growing the workforce. In spite of how quickly the business is growing and how many problems we have, we said we'll never more than double in size during a year. We set that limit because we think faster growth would compromise the culture.
In practice, we’ve rarely gotten close to doubling the team within a year. As we’ve scaled up, headcount growth has been just enough to keep up with overall growth and the challenges of the business.
3. Getting things done
Projects are very collaborative. From the outside, it’d be natural to assume Product does one thing and Engineering another. But we both are very welcoming for input and we give each other ideas and feedback. On the Product side, Yuhki – Chief Product Officer at Figma – and I work very closely together. Engineers also tend to get involved early in the planning process.
We staff teams so they are full stack and can work across code boundaries.
Exploration vs execution
We separate exploration projects from execution ones, which helps us be realistic about whether or not a project is ready to be staffed in earnest for execution projects. If a project is more explorative, it shouldn’t occupy 100% of a team's or person's time.
Even with the split, we are intentional about involving all functions early during projects, be they exploration or execution ones. Our goal is for people to work collaboratively on figuring out the right problem and the right way to solve it.
In practice, this split is:
A project starts in an exploration phase
Later, it transitions to a “ready to be executed” state
Of course, iterations still happen during the execution phase, but this phase is concrete enough that we can staff it with more engineers.
Planning
The technical planning process works alongside the product process. We do Product Requirement Documents for lighter-weight things and Product Reviews for more complex projects. We sometimes break a Product Review down into Problem Alignment and Solution Alignment phases.
While product planning is happening, we present engineering concepts and engineering designs, and share design docs early and often – which is something I push for a lot. We encourage sharing works in progress in Slack, and have certain channels for this.
Seek out feedback early and often: this is one of our key values as an engineering organization. Some companies prefer engineering design docs to be polished artifacts and to follow a formal process. We don’t do this.
We prefer engineers to write down what they’re thinking as they think it, so they can get feedback. We encourage engineers to get feedback from people with strong opinions or prior experience, to do this as early as possible and to let it evolve over time. In this way, our engineering process is less formal.
Depending on the nature of the project, we sometimes run a more formal planning process. For example, if we’re talking about modifying a backend system with a lot of load which is critical to stability, we follow more defined steps.
Engineering pillars differ in terms of what level of formalism they expect for different categories of project. We want to give each team a little bit of flexibility, and aim to spread the spirit of planning across all teams. Basically, everyone should:
Document their decisions
Work in the open
Welcome feedback
Out of these three, the most important is getting feedback as soon as possible, and then to iterate in the open.
Project management
We're not overly prescriptive about how teams do project management. We have best practices which we encourage them to follow.
Using milestones is one common ask of teams; that every project be broken down into a series of milestones which the teams communicate early. The idea is to encourage everyone to create a culture of accountability so they can trust and rely on each other, versus being overly prescriptive about exactly how they do their work. Our use of milestones is one practice that’s stood the test of time.
Fixing bugs vs building new things
Fixing low-priority bugs within the features you build is something we do. When you're doing feature work, there's a much stronger service level agreement (SLA) around fixing even relatively low-priority bugs. If you notice a low severity bug which you introduced during the course of your feature work, then it's a high-priority fix because “now” is the right time to fix it. We don't want things to just accumulate over time, and it's much easier to fix them straight away when you have context, than later down the road.
At the same time, if something gets found three months after we launch the product, then it's really up to the team to prioritize it, relative to the overall impact they're trying to deliver.
There is no single “right” way to do things
Early in my career I jumped around more than many people in my position do. Thanks to this, I got exposure to a lot of different companies and the contrasts between Asana and Airbnb’s early days. In the end, both companies became successful in spite of being different.
Seeing very different paths to success made me realize there's no one right way to do things. It's really about agreeing upon the core principles and values. Sometimes, you need to do more clarifying as things get a little messier and more complex. However, in the end, you need to let people decide the right way to execute, while keeping the goals of the company in mind.
I've been very intentional about not trying to be overly prescriptive around drawing on past experience, because I've learned there's just many different ways to do things.
4. Tech stack
We use a monorepo for the majority of our code. We have a couple of dedicated repos for very special things or open source projects, but generally we try to encourage people to work in the same repo. It works pretty well in terms of encouraging code reuse and sharing.
Some of the technologies we use:
Frontend:
Mobile: native iOS and native Android
APIs: REST
Backend:
LiveGraph: a schema-based real-time database inspired by GraphQL. Built using a combination of TypeScript and Go.
Database: RDS with Postgres, AWS S3
Infrastructure: running on top of AWS
We are building a culture where engineers aren’t afraid to rethink how to architect an application in order to squeeze every last bit of performance and memory out of it. We encourage our engineers to not be limited by their specialization or abstraction boundaries. Instead, to leverage each other's collective knowledge to solve a hard problem when they face one. And when it comes to hard problems, don’t just avoid them or come up with a work around; solve them!
5. Figma’s engineering culture
Engineering values
Figma has codified four engineering values: