figma·Apr 28, 2026·3 min readCurated summary

FigJam Is Now Your Coding Agent’s Whiteboard Too | Figma Blog

FigJam is being positioned as a shared whiteboard for coding agents and engineering teams. New MCP skills let agents generate architecture and ER diagrams, write to and read from FigJam, and turn research or project plans into collaborative visual boards. The workflow connects agent-generated planning, human review, and implementation, reducing architectural confusion as teams ship code faster. ## Turning Agent Output into Visual Plans - The author built on Figma’s existing `generate_diagram` MCP tool to support more complex architecture and ERD layouts. - The new `figma-use-figjam` MCP skill allows agents to read and write directly to FigJam boards. - Skills such as `generate-project-plan` can transform documentation, codebases, and conversations into visual project plans. - Diagrams can include: - Architecture and entity-relationship diagrams - Notes and annotations - Code blocks - Implementation context and technical decisions ## Step 1: Research, Plan, and Visualize - The coding agent gathers relevant documentation, codebase structure, existing patterns, and implementation constraints. - It evaluates possible solutions, researches tradeoffs, identifies affected services and files, and proposes stacked PRs and testing strategies. - Instead of leaving the plan in a dense Markdown document, the agent exports it to FigJam as an interactive architecture review. - Visualizing the options helps teams understand the system and identify the cleanest approach more quickly. ## Step 2: Collaborate Before Coding - Engineers share the FigJam board with teammates for asynchronous or live review. - Team members can comment on concrete design questions, such as: - Whether a tool should support multiple file types - Whether it should accept a `folderId` - Where newly created files should be stored - FigJam provides a collaborative format that preserves technical context for distributed teams. - Teams can review and refine agent-generated diagrams before implementation begins. ## Step 3: Feed Decisions Back to the Agent - After review, the author uses the `get_figjam` tool to retrieve the board’s diagrams, comments, and decisions. - The coding agent uses that context to update the implementation plan and begin coding. - Pull requests can link back to the FigJam board, preserving the architectural rationale alongside the code. - Because the design has already been reviewed, the resulting PR is easier to evaluate and merge. ## Broader Figma Integration - The workflow builds on `use_figma`, which lets agents create or edit designs directly on the Figma canvas using real components. - `create_new_file` allows agents to generate designs in new Figma files. - Together, these capabilities extend agent collaboration beyond code into design, architecture, planning, and technical communication. Teams adopting coding agents can use FigJam as a reviewable source of shared context: let agents generate the initial plan, have humans refine the architecture visually, then return the approved decisions to the agent for implementation.

Read original(opens in new tab)

Software ArchitectureFigmaAI AgentsFigjam+3

toss·Feb 26, 2026·3 min readCurated summary

Easy-to-use Toss Front SDK

The post argues that an SDK’s stability depends not only on its internal implementation but also on how safely users can interact with it. Low-level APIs may expose every operation clearly, yet still allow human errors such as missing event handlers or cleanup. The recommended solution is an intent-driven Facade interface that simplifies common workflows, prevents misuse, and still provides low-level escape hatches for advanced cases. ## Designing an SDK That Is Easy to Use - Toss Place develops an external SDK for Toss Front payment terminals. - The SDK allows third-party developers to build plugin apps that integrate with Toss services and run on the terminal. - A simple-looking server API might require users to: - Open a server. - Register connection, message, and error handlers. - Remove handlers. - Close the server. - This approach exposes implicit responsibilities to SDK users: - A message callback might never be registered after a connection. - Handlers might not be removed before shutdown. - Improper cleanup can cause memory leaks and operational issues. - Therefore, third-party implementation mistakes can directly affect platform reliability. - A safer interface hides unnecessary internal steps: ```ts const server = await sdk.start({ onConnection, onMessage }); await server.stop(); ``` ## Facade as an Intent-Driven Interface - The Facade pattern is commonly described as wrapping a complex subsystem with a simpler interface. - In SDK design, its deeper purpose is to reorganize complexity around user intent rather than merely hide functionality. - Users should express goals such as: - “Start a server” - “Upload a file” - “Request a payment” - Internal concerns—including authentication, retries, state management, listener registration, and cleanup—should be handled by the SDK. - AWS CDK illustrates this distinction: - **L1 constructs** closely represent raw CloudFormation resources and provide fine-grained control. - **L2 constructs** provide intent-based APIs, such as creating a versioned S3 bucket with `versioned: true`, while handling the underlying configuration automatically. - The goal of a Facade is to reduce cognitive load and coupling, not simply to conceal every lower-level capability. ## Combining High-Level and Low-Level APIs - A well-designed SDK should provide both abstraction levels: - **High-level Facade:** Handles the roughly 80% of common use cases through complete workflows. - **Low-level APIs:** Serve as escape hatches for the roughly 20% of specialized cases requiring precise control. - In the example: - The Facade’s `start()` method opens the server, registers listeners, coordinates connections, and returns a unified server handle. - Low-level APIs separately expose operations such as `open`, `close`, `send`, `disconnect`, and event listeners. - This layered design improves immediate developer experience while preserving long-term compatibility and extensibility. ## Trade-offs and Escape Hatches - Higher-level abstractions inevitably reduce some flexibility. - Specialized requirements—such as keeping one connection while closing others—may not fit the Facade workflow. - As orchestration becomes more sophisticated, the SDK maintainers inherit additional implementation and maintenance costs. - Low-level escape hatches are therefore essential: users should be able to bypass the Facade when they need detailed control. ## Practical Recommendation Design SDK APIs around user intent and automate error-prone lifecycle management wherever possible. Offer a concise Facade for common workflows, but retain well-defined low-level interfaces so advanced users are not blocked by the abstraction.

Read original(opens in new tab)

Software ArchitectureAPI DesignInterface DesignFrontend+4

github·Feb 19, 2026·3 min readCurated summary

How AI is reshaping developer choice (and Octoverse data proves it)

AI is reshaping software development not only by increasing coding speed, but also by changing which languages and tools developers choose. Octoverse 2025 shows this shift clearly: TypeScript became GitHub’s most-used language in August 2025, overtaking Python and JavaScript. The article argues that AI reduces the friction of complex technologies, while teams must establish strong architectural and testing practices to prevent faster development from producing faster degradation. ## The Convenience Loop Changes Developer Behavior - Developers form associations between convenience and particular technologies, much like sensory cues can trigger strong memories. - Eighty percent of new GitHub developers use Copilot within their first week, establishing AI-assisted development as their baseline experience. - When AI handles boilerplate and difficult syntax, developers become more willing to use powerful but traditionally costly tools. - Recent adoption figures reflect this change: - TypeScript grew 66% year over year. - JavaScript grew 24%. - Shell scripting in AI-generated projects increased 206%. - The rise in shell usage suggests developers are choosing tools based on suitability rather than avoiding them because of friction. ## Why Strong Typing Helps AI-Generated Code - Strongly typed languages provide clearer constraints for AI models. - A TypeScript declaration such as `x: string` rules out invalid operations that would remain possible in JavaScript. - These constraints help AI produce more reliable and contextually appropriate code. - More than 1.1 million public repositories now use LLM SDKs, showing that AI integration has become mainstream. - Adoption is concentrating around languages and frameworks that work effectively with AI-assisted workflows. ## Moving Faster Without Damaging Architecture ### Guidance for Developers and Teams - Establish coding patterns before generating large amounts of code; AI follows clear existing structures better than it invents them. - Use type systems as guardrails, not as proof that business logic is correct. - Test AI-generated code rigorously, even when it appears correct or passes initial checks. ### Guidance for Engineering Leaders - AI-assisted development can increase throughput by roughly 20–30%, but architectural drift can accumulate just as quickly. - Standardize practices before scaling AI adoption through documentation, template repositories, and explicit architectural decisions. - Monitor the nature and quality of generated code, not only productivity or acceptance rates. - GitHub’s Copilot usage metrics dashboard tracks active users, agent adoption, lines added and deleted, language and model usage, and other organizational patterns. - Teams can use these metrics to identify defect-prone languages, models, or workflows and target training or stricter review processes. - Greater developer productivity increases the importance of senior engineering capacity for architectural review. AI makes more technologies accessible and is actively influencing the future popularity of languages and frameworks. Organizations should embrace the productivity gains while pairing them with standardized patterns, strong type systems, rigorous testing, and continuous architectural oversight.

Read original(opens in new tab)

Software ArchitectureTypeScriptPythonJavaScript+4

spotify·Feb 9, 2026·3 min readCurated summary

Our Multi-Agent Architecture for Smarter Advertising | Spotify Engineering

The post argues that fragmented advertising workflows, not backend infrastructure, are the core problem. Although buying channels share services and data, their planning and optimization logic is repeatedly reimplemented across channels and surfaces, causing drift and technical debt. The proposed solution is a shared agentic decision layer that interprets advertiser goals, orchestrates existing Ads APIs, and applies consistent reasoning across products. ## Fragmented Workflows Across a Shared Backend - Direct, Self-Serve, and Programmatic buying use largely consolidated infrastructure but retain different workflows and decision logic. - Spotify Ads Manager, Salesforce, Slack, and internal tools contain overlapping automation. - Budget allocation, inventory selection, reach, efficiency, and STR decisions are repeatedly implemented in different places. - Incremental workflow changes therefore create duplicated maintenance work and inconsistent behavior. ## Why Conventional Workflow Services Fall Short - Hard-coded state machines and REST services are poorly suited to combinatorial planning tasks. - Campaign planning depends on: - User and advertiser characteristics - Available inventory and audiences - Business priorities - Forecasts, performance, and optimization goals - A workflow optimized for one channel or “happy path” will not adapt well as requirements change. - Improvements to decision logic must be replicated across every product surface, increasing the risk of divergence. ## The Missing Intent Layer - Existing systems can perform individual actions such as creating line items, running forecasts, and retrieving insights. - They do not consistently translate high-level objectives into: - A sequence of tool calls - Explicit tradeoffs - Validation and safety checks - An objective such as maximizing reach in Brazil while protecting video inventory and meeting STR requires coordinated reasoning across multiple capabilities. ## A Modular Agentic Architecture - Campaign planning and management are modeled as cooperating specialized agents. - Agents use shared signals, including: - Inventory - Audiences - STR - Quality and risk - Historical performance - They jointly optimize advertiser goals and Spotify’s business constraints. - Existing Ads services become tools that agents orchestrate, rather than capabilities being rebuilt in each workflow. - A long-running orchestration layer delegates tasks while agents share context and evaluation logic. - The same decision engine can support every buying channel and surface. ## Engineering Implications - APIs need to be designed as agent tools, rather than only as CRUD interfaces. - Testing must include behavioral evaluation in addition to unit and integration tests. - Observability should explain what an agent decided and why, not merely track latency and errors. - Safety requires guardrails for semi-autonomous decisions, beyond ordinary input validation. - The approach avoids both duplicated deterministic workflows and a brittle, centralized rules engine for probabilistic, ML-heavy advertising logic. The overall recommendation is to centralize campaign decision-making in a reusable agentic platform while keeping existing services as specialized tools. This should reduce duplicated workflow logic, make improvements consistent across products, and allow advertising workflows to evolve without repeatedly rebuilding them.

Read original(opens in new tab)

Software ArchitectureAI AgentsMachine LearningAPI Design+3

github·Feb 2, 2026·3 min readCurated summary

How to maximize GitHub Copilot’s agentic capabilities

GitHub’s guide presents Copilot’s agent mode as a partner for architecture, refactoring, and coordinated multi-file changes—not a replacement for engineering judgment. It argues that Copilot is most useful when developers first define system boundaries, assess cross-cutting effects, and then use the agent to implement and document changes. The examples build toward extending a modular Notes Service with tagging, validation refactoring, migrations, and test modernization. ## Preparing for Agentic Work - The guide assumes: - Copilot agent mode is enabled. - Familiarity with service-layer architectures. - Access to a GitHub Skills exercise template. - Willingness to review and challenge Copilot’s proposals. - Earlier-career engineers can use the exercises to learn how senior engineers evaluate architecture and risk. ## Using Copilot for System Design - Developers should begin by identifying boundaries between: - Domain logic - Data access - Interfaces - Module interactions - Copilot can analyze a service for: - Poor module boundaries and tight coupling - Async and transaction risks - Duplicated responsibilities - Testability and observability problems - It can also compare architectural approaches, such as hexagonal and layered architecture, and explain tradeoffs based on the codebase’s constraints. ## Building Modular Services - Once the architecture is understood, Copilot can coordinate implementation across: - Domain modules - Controllers - Repository abstractions - Suggested practices include dependency inversion and documenting module contracts and assumptions. - Copilot may generate interfaces, repository abstractions, controller logic, and Markdown documentation, reducing boilerplate while exposing developers to established design patterns. ## Adding a Tagging Subsystem - A seemingly simple tagging feature requires decisions about: - Embedded tags versus normalized or many-to-many data models - Search indexing, filtering, and relevance - Whether tags are API resources or internal details - Validation and invariant boundaries - Additive migrations, compatibility, and rollback - Copilot can first map the feature’s architectural impact, including migration requirements, caching, indexing, regressions, tests, and external consumers. - Implementation may span the domain model, database schema, repositories, controllers, tests, and documentation. - The example uses a `tags` column with a default empty array and adds `Tag[]` to the note model, illustrating how agent mode maintains consistency across files. ## Safe Schema Changes - The guide emphasizes that migration design involves more than writing SQL. - A production-ready change should be: - Backward compatible - Reversible - Safe under load - Transparent to dependent systems - Copilot can assist with reasoning about rollout strategies, but engineers must inspect its recommendations and validate them against operational constraints. The practical recommendation is to use Copilot agent mode as an architecture-aware collaborator: ask it to analyze and compare options first, then implement changes across the system while requiring explicit assumptions, diffs, tests, and documentation.

Read original(opens in new tab)

Software ArchitectureTypeScriptGithub CopilotAPI Design+3

airbnb·Jan 12, 2026·3 min readCurated summary

Pay As a Local

Airbnb launched more than 20 locally preferred payment methods across global markets in just over 14 months. The initiative aimed to improve checkout conversion, reach customers with limited access to cards, and provide familiar payment options. Airbnb achieved this by combining a replatformed, domain-oriented payments architecture with reusable PSP connectors and standardized payment-flow patterns. ## Why Local Payment Methods Matter - Local payment methods (LPMs) include: - Digital wallets such as M-Pesa and MTN MoMo - Online bank transfers - Real-time payment systems such as PIX and UPI - Regional payment schemes such as EFTPOS and Cartes Bancaires - They help Airbnb: - Increase conversion by offering trusted local options - Enter markets where card usage is limited - Serve customers without credit cards or traditional banking access - Airbnb identified more than 300 payment options worldwide. - For the initial rollout, it evaluated the top 75 travel markets and selected one or two methods per market, producing a shortlist of just over 20 integrations. ## Payments Platform Modernization - Airbnb separated payment capabilities from its core stays, experiences, and services businesses. - Its Payments LTA modernization replaced a monolith with domain-oriented services. - Core payment subdomains include: - Pay-in and payout - Transaction fulfillment and processing - Wallets and payment instruments - Ledger - Incentives and stored value - Issuing - Settlement and reconciliation - This structure improved reuse, extensibility, time to market, and team autonomy. ## Connector Architecture and Multi-Step Transactions - The processing domain uses connector and plugin-based integrations for payment service providers (PSPs). - Plugins support: - API- and file-based integrations - Payment routing and switching - Market-specific PSP behavior - Airbnb also introduced Multi-Step Transactions (MST), a PSP-agnostic framework for payments requiring multiple stages. - MST represents intermediate operations as Actions, including: - Redirects to external apps or websites - Strong customer authentication challenges - Payment-method-specific interactions - PSP plugins normalize these requirements into an `ActionPayload` and return an `ACTION_REQUIRED` transaction status. ## Three Standardized LPM Flow Types Airbnb analyzed its payment methods and grouped them into three reusable archetypes: - **Redirect flow:** The guest is sent to an external site or app, then returned to Airbnb. Examples include Naver Pay, GoPay, and FPX. - **Async flow:** The guest completes payment later through a QR code, push notification, or wallet app, while Airbnb receives confirmation through a webhook. Examples include Pix, MB Way, and Blik. - **Direct flow:** Payment credentials are entered within Airbnb and processed immediately, similar to card payments. Examples include Cartes Bancaires and Apple Pay. This classification reduced duplicate engineering work and made new integrations more predictable. ## Orchestrating External Payment Actions - For redirect payments: - Airbnb sends a charge request to the local vendor. - The vendor returns a `redirectUrl`. - The guest completes payment externally. - Airbnb receives a result token and uses it to confirm the transaction securely. - For asynchronous payments: - Airbnb sends a charge request and receives `qrCodeData`. - The checkout displays the QR code. - The guest pays in an external wallet. - The vendor sends a webhook, allowing Airbnb to mark the payment successful and confirm the order. - These flows required careful handling of app switching, session handoff, delayed confirmation, and synchronization between Airbnb and external providers. ## Outcome Airbnb’s rollout demonstrates that broad local-payment coverage depends less on building every integration independently and more on creating reusable abstractions. A modular payments platform, standardized flow archetypes, normalized PSP actions, and plugin-based connectors enabled the company to support diverse regional payment behaviors at global scale.

Read original(opens in new tab)

Software ArchitectureMicroservicesApi IntegrationWebhooks+3

woowahan·Dec 5, 2025Original article

아한형제들 기술블로그 (opens in new tab)

The 7th Woowacourse crew has successfully launched three distinct services, demonstrating that modern software engineering requires a synergy of technical mastery and "soft skills" like product planning and team communication. By owning the entire lifecycle from ideation to deployment, these developers moved beyond mere coding to solve real-world problems through agile iterations, user feedback, and robust infrastructure management. The program’s focus on the full stack of development—including monitoring, 2-week sprints, and collaborative design—highlights a shift toward producing well-rounded engineers capable of navigating professional environments. ### The Woowacourse Full-Cycle Philosophy * The 10-month curriculum emphasizes soft skills, including speaking and writing, alongside traditional technical tracks like Web Backend, Frontend, and Mobile Android. * During Level 3 and 4, crews transition from fundamental programming to managing team projects where they must handle everything from initial architecture to UI/UX design. * The process mimics real-world industry standards by implementing 2-week development sprints, establishing monitoring environments, and managing automated deployment pipelines. * The core goal is to shift the developer's mindset from simply writing code to understanding why certain features are planned and how architecture choices impact the final user value. ### Pickeat: Collaborative Dining Decisions * This service addresses "decision fatigue" during group meals by providing a collaborative platform to filter restaurants based on dietary constraints and preferences. * Technical challenges included frequent domain restructuring and UI overhauls as the team pivoted based on real-world user feedback during demo days. * The platform utilizes location data for automatic restaurant lookups and supports real-time voting mechanisms to ensure democratic and efficient group decisions. * Development focused on aligning team judgment standards and iterating quickly to validate product-market fit rather than adhering strictly to initial specifications. ### Bottari: Real-Time Synchronized Checklists * Bottari is a checklist service designed for situations like traveling or moving, focusing on "becoming a companion for the user’s memory." * The service features template-based list generation and a "Team Bottari" function that allows multiple users to collaborate on a single list with real-time synchronization. * A major technical focus was placed on the user experience flow, specifically optimizing notification timing and sync states to provide "peace of mind" for users. * The project demonstrates the principle that technology serves as a tool for solving psychological pain points, such as the anxiety of forgetting essential items. ### Coffee Shout: Real-Time Betting and Mini-Games * Designed to gamify office culture, this service replaces simple "rock-paper-scissors" with interactive mini-games and weighted roulette for coffee bets. * The technical stack involved challenging implementations of WebSockets and distributed environments to handle the concurrency required for real-time gaming. * The team focused on algorithm balancing for the weighted roulette system to ensure fairness and excitement during the betting process. * Refinement of the service was driven by direct feedback from other Woowacourse crews, emphasizing the importance of community testing in the development lifecycle. These projects underscore that the transition from a student to a professional developer is defined by the ability to manage shifting requirements and technical complexity while maintaining a focus on the end-user's experience.

Software ArchitectureAndroidDistributed SystemsMonitoring+4

toss·Nov 13, 2025Original article

Frontend Code That Lasts 1 (opens in new tab)

Toss Payments evolved its Payment SDK to solve the inherent complexities of integrating payment systems, where developers must navigate UI implementation, security flows, and exception handling. By transitioning from V1 to V2, the team moved beyond simply providing a library to building a robust, architecture-driven system that ensures stability and scalability across diverse merchant environments. The core conclusion is that a successful SDK must be treated as a critical infrastructure layer, relying on modular design and deep observability to handle the unpredictable nature of third-party runtimes. ## The Unique Challenges of SDK Development * SDK code lives within the merchant's runtime environment, meaning it shares the same lifecycle and performance constraints as the merchant’s own code. * Internal logging can inadvertently create bottlenecks; for instance, adding network logs to a frequently called method can lead to "self-DDoS" scenarios that crash the merchant's payment page. * Type safety is a major hurdle, as merchants may pass unexpected data types (e.g., a number instead of a string), causing fatal runtime errors like `startsWith is not a function`. * The SDK acts as a bridge for technical communication, requiring it to function as both an API consumer for internal systems and an API provider for external developers. ## Ensuring Stability through Observability * To manage the unpredictable ways merchants use the SDK, Toss implemented over 300 unit tests and 500 E2E integration tests based on real-world use cases. * The team utilizes a "Global Trace ID" to track a single payment journey across both the frontend and backend, allowing for seamless debugging across the entire system. * A custom Monitoring CLI was developed to compare payment success rates before and after deployments, categorized by merchant and runtime environment (e.g., PC Chrome vs. Android WebView). * This observability infrastructure enables the team to quickly identify edge-case failures—such as a specific merchant's checkout failing only on mobile WebViews—which are often missed by standard QA processes. ## Scaling with Modular Architecture * To avoid "if-statement hell" caused by merchant-specific requirements (e.g., fixing installment months or custom validation for a specific store), Toss moved to a "Lego-block" architecture. * The SDK is organized into three distinct layers based on the "reason for change" principle: * **Public Interface Layer:** Manages the contract with the merchant, validating inputs and translating them into internal domain models. * **Domain Layer:** Encapsulates core business logic and payment policies, keeping them isolated from external changes. * **External Service Layer:** Handles dependencies like Server APIs and Web APIs, ensuring technical shifts don't leak into the business logic. * This separation allows the team to implement custom merchant logic by swapping specific blocks without modifying the core codebase, reducing the risk of regressions and lowering maintenance costs. For developers building SDKs or integration tools, the shift from monolithic logic to a layered, observable architecture is essential. Prioritizing the separation of domain logic from public interfaces and investing in environment-specific monitoring allows for a highly flexible product that remains stable even as the client-side environment grows increasingly complex.

Software ArchitectureObservabilityTypeScriptElasticsearch+3

figma·Oct 5, 2025·2 min readCurated summary

Turn Your ChatGPT Brainstorms Into FigJam Diagrams | Figma Blog

Figma’s new ChatGPT app turns brainstorms, sketches, uploaded files, and technical documents into editable FigJam diagrams. It supports flowcharts, sequence and state diagrams, and Gantt charts, helping users move quickly from exploration to collaborative artifacts. The feature is powered by Figma’s remote MCP server and is available to logged-in ChatGPT users outside the EU. ## Turning Conversations into Diagrams - Users can mention Figma in a prompt, such as “Figma, make a diagram from this sketch.” - ChatGPT can recommend the Figma app when diagramming is relevant. - Photos, drawings, PDFs, and other files can provide context. - Generated diagrams can be revised, expanded, or represented in alternative formats. - Figma plans to add more diagram types over time. ## Accelerating Design Iteration - Hand-drawn sketches can become shareable FigJam files. - Designers can ask ChatGPT to update diagrams or explore different visualizations. - Dense documents can be uploaded so ChatGPT can produce an initial draft. - This helps teams move ideas from informal notes or whiteboards into a collaborative workspace. ## Clarifying Technical Systems - Developers can use uploaded documentation and screenshots to create or update software architecture diagrams. - ChatGPT can research technical approaches using blogs and case studies, then visualize them. - Screenshots, such as a pricing page, can be used to map likely React component structures. - The resulting diagrams support system design discussions, technical communication, and interview preparation. ## Planning Products and User Experiences - Product managers can visualize tradeoffs, such as simplicity versus power in a permissions flow. - PRDs can be converted into user journey or process flowcharts. - Product, engineering, and design requirements can be combined into Gantt charts for launch planning. - ChatGPT supports individual exploration, while FigJam enables teams to review and iterate together. The feature is currently live for logged-in ChatGPT users outside the EU. It offers a practical workflow for using ChatGPT to generate a first visual draft and FigJam to refine, discuss, and collaborate on it.

Read original(opens in new tab)

Software ArchitectureFigmaFigjamReact+4

figma·Jan 16, 2019·2 min readCurated summary

Figma's engineering values | Figma Blog

Figma’s engineering values were created to preserve effective collaboration as the team grows without promoting a monoculture. They are intended to describe existing behaviors, guide decisions, and make explicit the tradeoffs behind how the team works. The post focuses on communication, teamwork, feedback, inclusion, and sustainable growth. ## Communicate Early and Often - Share design documents, product specifications, architecture sketches, and works in progress before implementation is complete. - Early communication helps teams: - Identify problems before significant effort is invested. - Solve problems collaboratively rather than in isolation. - Encourage people to ask for help and exchange knowledge. - Feedback must be welcomed as seriously as it is requested; sharing is useful only when people are receptive to changing direction. - Communication is not a rigid process: - Code may be the clearest way to discuss an idea. - Simple bug fixes or obvious changes may not require extensive discussion. - This value rejects the “solo genius” model in favor of using the team’s collective expertise. - The tradeoff is slower decision-making: involving more people can require additional discussion and iteration to ensure diverse voices are heard. ## Lift Your Team - Engineers should help one another grow, prioritize teammates’ success and well-being, and create an inclusive environment. - The emphasis is on lifting the team—not sacrificing individual sustainability for the company’s interests. - The value supports: - Continuous learning and mentorship. - Weekly technical talks. - Formal onboarding mentorship. - Encouragement to develop new skills. - Feedback should focus on ideas and work rather than attacking individuals. - Insults, condescension, and belittling are considered ineffective feedback. - Team members are also expected to receive feedback thoughtfully and remain open to others’ ideas. Figma’s approach is to make collaboration and mutual growth explicit expectations while acknowledging their costs. Teams adopting similar values should define concrete behaviors, ensure feedback is genuinely welcomed, and state the tradeoffs they are willing to accept.

Read original(opens in new tab)

Software ArchitectureCollaborationCode ReviewSoftware Engineering+2