# Why Roles Are Not Rules - Figma Synced: [[2023_11_30]] 6:03 AM Last Highlighted: [[2023_09_05]] Tags: [[teams]]  ## Highlights [[2023_09_04]] [View Highlight](https://read.readwise.io/read/01h9fcm63m1he90pnxafdqvp7f) > Broadly speaking, I’ve found that there’s a fine line between leveraging the wisdom of others and spinning in circles without a clear direction of your own. In practice, there will be times when we need to work more independently, and times when we should go out of our way to bring others in. [[2023_09_04]] [View Highlight](https://read.readwise.io/read/01h9fcnxmss00ytt9h90yv27c5) > Engineers *are expected to write down early thinking*, and the goal is to get feedback from their collaborators *as they’re working on it*, not when it feels “polished.” [[2023_09_05]] [View Highlight](https://read.readwise.io/read/01h9bq4tvnyv8e7ne2em0kgcep) > On a foundational level, I like to think of our work at Figma as a tree of dependencies. Leaves can change rapidly with little risk to the rest of the tree, but the roots need to be solid. When you’re scoping a project at the root level, considerations are very different from something at the leaf level. If you’re building a database, you certainly don’t want to go off independently and “move fast and break things”—you have to be much more thoughtful about getting the right input when you’re working on lower level systems, compared to something higher up in the tech stack. If you’re working on a feature that changes the interface but leaves the underlying data model untouched, it’s often lower risk to experiment more independently—but you still shouldn’t “break things” for users. A big part of my role is separating the leaf nodes from the root nodes, clarifying for the team what they can move quickly on, and what requires a more principled approach, with feedback from key stakeholders [[2023_09_04]] [View Highlight](https://read.readwise.io/read/01h9fctkxh9b4224ec1k2c9v59) > On a foundational level, I like to think of our work at Figma as a tree of dependencies. Leaves can change rapidly with little risk to the rest of the tree, but the roots need to be solid. When you’re scoping a project at the root level, considerations are very different from something at the leaf level. If you’re building a database, you certainly don’t want to go off independently and “move fast and break things”—you have to be much more thoughtful about getting the right input when you’re working on lower level systems, compared to something higher up in the tech stack. If you’re working on a feature that changes the interface but leaves the underlying data model untouched, it’s often lower risk to experiment more independently—but you still shouldn’t “break things” for users. [[2023_09_05]] [View Highlight](https://read.readwise.io/read/01h9bq79frmhkq05h79fxfsvn6) > The most effective makers aren’t just deeply specialized in one area; they are the ones who invite a challenge and have the confidence to quickly learn new systems. They chase problems wherever they lead, and don’t let their roles constrain them [[T Shaped Skills]]