Engineering Crits at Figma: Interview with Laura Pang
Industry lessons on technical design reviews and feedback
đ Intro to Laura
In this week's issue, we meet Laura Pang, a software engineer at Figma.
Laura recently wrote the article, How we run eng crits at Figma which shares Figmaâs unique approach to sourcing technical feedback on FigJam, Figma's collaborative whiteboard tool. Figma calls these feedback sessions âeng crits.â You may know them as technical design reviews or tech spec reviews.
I had the pleasure of interviewing Laura and asking follow-up questions about Figmaâs process and her experience.
In this article, Iâll share our dialogue and the lessons we can learn on running crits better, giving feedback, receiving feedback, and more.
â ď¸ Disclaimer: For brevity, I've paraphrased the discussion, retaining the tone and essence of what was said. This format allows for a more personal and detailed exploration of the topics.
âď¸ Main Takeaways
The level of detail to include in your crits
How to lead crit meetings and what senior engineers do differently
How to approach both giving and receiving feedback in crit meetings
Level of detail to include in the crit
Jordan: I noticed the author sometimes includes code snippets as part of their crit. As the author, how do you decide on the level of detail to include?
Laura: Yeah, I think there are a couple of factors here. It's mostly around setting you as the presenter and the reviewers up for success in gathering feedback effectively. It depends on the breadth and depth of the feedback youâre looking for.
If youâre just coming up with a new idea, maybe it would be crazy to already have a code snippet prepared since thatâs a pretty detailed stepâso you might just have a high-level diagram.
If youâve already tried prototyping a few directions and find that having code will help your reviewers provide direction, then including code can be a good approach.
Code snippets have also been useful in crits for internal developer-focused teams. They are building with developer ergonomics in mind, so itâs helpful to see what the ergonomics will be and compare it against the current system.
Jordan: That makes sense. If I hear you correctly, it seems like youâre saying the level of detail to include is based on what is needed to make a decision or give the proper level of feedback youâre looking for?
Laura: Yeah, exactly.
Leading crits better
Jordan: How do you structure the crit review meeting? I saw there is a silent portion?
Laura: Yeah, we start the meeting by setting the expectations of what weâll be reviewing and the level of feedback weâre looking for. Sometimes, weâre looking for feedback on a large app redesign. Other times, it might be about reading code snippets and giving feedback.
After that, we go into a silent portion where people leave stickies with their thoughts. At the end, we have an optional part where we pull it back into a synchronous meeting for the last 5-10 minutes to make sure we discuss the hotspot topics with a lot of opinions around them.
The meeting in total is 30 minutes.
Jordan: How do you ensure the crit process is successful?
Laura: It varies by project and scope, but the goal of the crit is to empower the team working on the feature to feel confident about their direction. Reviewers have this in mind, and the feature team will clarify expectations of what they need the most help with or thoughts on throughout the process. That ensures the reviewers can give them what they need the most and empower them to feel confident moving forward.
Jordan: I saw that the whole engineering org is invited to every crit meeting. How do you ensure the people you need to review it are there?
Laura: We have a predefined slot blocked off for all engineers for eng crits, which makes scheduling easy. I will usually DM that group of people to let them know the change impacts their system and that it will be good to get their review. We also have a section in our crit template to include key reviewers and approvers.
Jordan: Have you noticed any differences in how more senior engineers structure their crits, especially regarding meeting prep and document writing?
Laura: In general, a good crit is when youâre intentional about framing what youâre trying to get. Giving a firehose of information is easy, but itâs hard to curate it. Senior engineers can guide the direction based on the feedback theyâre looking for.
Theyâre also less shy about giving and receiving feedback. Theyâre open to sharing early-stage ideas and seeking feedback. Iâve seen cases where junior engineers feel like they always need to present super polished ideas, but Senior engineers focus on getting early feedback and course correcting.
Senior engineers also spend more time on meeting preparation and have a clear agenda that they clarify upfront. You should know why you have 20 people in the room and what outcome you want.
Jordan: I love this. It resonates with some of the tips I shared in my recent article on leading meetings and clearly stating the expected outcome. If you donât make the outcome clear up front, everyone will have a different outcome in their head and be trying to âtug-of-warâ in that different direction without you even realizing it.
Approaching feedback
Jordan: How do you handle so many comments and the entire engineering org being invited to a critique? Does it ever get overwhelming?
Laura: Yeah, we usually watch for hotspots in FigJam and see if there are many comments in one area. We spend the most time there. Sometimes, those areas need a follow-up meeting because of the changes that might be needed. We also have AI features in FigJam that help summarize the common themes of feedback.
Jordan: How has participating in engineering crits impacted your approach to giving and receiving feedback?
Laura: Yeah, Iâve realized that crits and giving and receiving feedback are similar. You want to give and receive feedback early and often. You donât want to find out on your performance review that youâre doing poorly. It works the same way for eng crits. Hopefully, youâre having ongoing discussions with your manager and peers.
I try to give feedback as early and often as I canâwhether itâs positive reinforcement or more on the constructive side, itâs helpful to point things out as you see them rather than waiting until itâs too late or much harder to change.
As a junior engineer, I was spooked by feedback, but in hindsight, I realized it was a gift. They gave it to me early enough, and it never made it to my performance review because I could act on it.
In general, the core philosophy of our crits is, âWeâre here to lift other ideas up and not put each other down.â That intent appears throughout eng crit feedback and feedback outside of eng crits.
Jordan: Itâs cool to hear how itâs impacted how you approach feedback. Part of the reason I was curious is that looking at the image of a crit, there can be so many comments at times that I wondered how it would make the author feel. But I imagine it is ingrained into the culture as a positive thing you get used to rather than a culture where rare feedback becomes scary.
Laura: Exactly. I always get the sense that the intent is to help you grow. No one is being overly critical.
Jordan: As a reviewer, do you have a process you recommend for reviewing someone else's document or crit?
Laura: If possible, I pre-read the document or crit before the meeting. This helps me digest the information and formulate my thoughts.
During the crit, I make sure I understand what the team is looking for and give feedback on that so that I donât overload them with information not relevant to them.
After the crit, I keep up with the discussion in Slack. Presenters often post a summary of themes of feedback, edge cases they plan to follow up on, and how they plan to move forward. That is super helpful for me as a reviewer to know what I should expect moving forward.
Crit Template
Jordan: Can you walk me through the key sections of the crit template in FigJam and why each section is included?
Laura: Yeah, we got to this template purely through trial and error, running crits over time. Weâd add one section at a time until we felt we needed another.
The first section is âWhat feedback are you looking for?â We realized itâs important to set expectations right away because there are so many reviewers across the org.
The second section is âRelated materialsâ because there might be helpful context for a reviewer to be aware ofâlike bringing this same feature to crit before.
The third section is for âKey reviewers and stakeholders.â Since everyone from the eng org is invited, it might not be clear who will be impacted. This also allows the people who attend crit to mark themselves as stakeholders so they can be in the loop moving forward if they have a downstream dependency.
The last 2 sections are the UX requirements of the feature and the technical proposal.
The goal of the technical proposal section is to explain how we can satisfy those UX requirements from a technical perspective. You can share all the different approaches you considered. Reviewers can also share additional options in this section. We include the pros and cons for each one.
Jordan: I love that. I also liked how the Technical Proposal(s) section in FigJam is laid out; itâs easy to visually separate multiple options.
Jordan: Do you have any recommendations for someone wanting to try this approach to crits, especially if their team hasn't used FigJam before?
Laura: Yeah, the crit template is a great start. Itâs the one we use internally. In the template, there is a âQuick Tipsâ section, which helps a lot, especially if youâre new to FigJam. Be open-minded to a new process. In my experience, itâs very different from how technical reviews tend to go in other companies. But once you try it, itâs really nice. How we run eng crits at Figma builds a very specific culture that is collaborative and fun.
Jordan: Thatâs awesome and a great way to close out. And just to share a fun personal anecdote, I used FigJam in the past to do an Impact / Effort matrix mapping for yearly planning with eng leadership. It was one of my most memorable moments because of how collaborative it was and got everyone aligned on words and visuals.
đ TL;DR
Level of detail to include in the crit
Include the amount of detail needed for the goal you want to achieve.
Use high-level diagrams in the early stages and actual code snippets for more detailed discussions.
Leading crits better
Set expectations for the outcome and feedback you want.
Spend more time preparing for the meeting. Have a clear agenda, include it in the invite, restate it at the beginning, and follow up afterward.
Approaching feedback
Embrace feedback as a tool for refining ideas and improving the product. Feedback is a good thing.
As a reviewer, pre-read the document to digest the information and formulate your thoughts before the meeting.
Crit template
The template used at Figma is:
What feedback are you looking for
Related links
Key reviewers
Use case & UX requirements
Technical Proposal(s)âallowing the design of one or more options, with a pros and cons section for each and a voting section of whether the option meets our needs.
You can try Figmaâs Crit Template in FigJam with your team
đŁ Shout-outs of the week
How we run eng crits at Figma by Laura Pang â The original article that this article is a follow-up to. See the exact process Figma uses to run eng crits.
Stories of three employees requesting raises. Lessons on increasing your income by
on â I love Daveâs stories and understanding the perspective of a manager in these types of situations. Amazing read.Context switching - one of the worst productivity killers in the industry by
and on â Great practical advice on managing your time, attention, and energy to get more done.
Thank you for your continued support of the newsletter and the growth to 53k+ subscribers đ
- Jordan
P.S. Here are a few other things you may be interested in:
Path to Senior Engineer Handbook (7.9k+ stars)âEverything you need to get to Senior
My LinkedIn: I write daily content to 58k+ engineers. Iâm also ramping on Twitter/X
Newsletter sponsorships: Feel free to reply to this email or check the Sponsorship packages
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like â¤ď¸ button at the bottom of this email to help support me or share this with a friend. It really helps!
Interesting read, Jordan! I believe the most important point is to have the reviewers go through the documents beforehand and formulate their opinion.
I loved this quote about feedback being a gift by Laura:
âIâve realized that crits and giving and receiving feedback are similar. You want to give and receive feedback early and often. You donât want to find out on your performance review that youâre doing poorly. It works the same way for eng crits. Hopefully, youâre having ongoing discussions with your manager and peers.
As a junior engineer, I was spooked by feedback, but in hindsight, I realized it was a gift. They gave it to me early enough, and it never made it to my performance review because I could act on it.
In general, the core philosophy of our crits is, âWeâre here to lift other ideas up and not put each other down.â
Thatâs the way to do design reviews, and to do performance reviews đđźđđźđđź