Lessons from Marcel Weekes

Lessons from Marcel Weekes

Marcel Weekes is the VP of Product Engineering at Figma and formerly led engineering at Slack. He focuses on the practical mechanics of management and resolving the friction of team growth. This profile covers his approaches to bridging design and development, surviving the transition to management, and scaling engineering cultures.

Part 1: The Transition from IC to Manager

1. On the default path: "Management is often treated as a default reward for strong technical performance, rather than an entirely distinct discipline." — Source: First Round Review
2. On the death spiral: "New managers often fall back on coding when stressed, neglecting the actual management work their team desperately needs." — Source: First Round Review
3. On support structures: "Without proper training and mentorship, the failure rate for new engineering managers remains unacceptably high." — Source: First Round Review
4. On shifting focus: "You are no longer optimizing for your own technical output; your primary metric is the effectiveness and health of your team." — Source: Software Engineering Daily
5. On the first 90 days: "A new manager's early days should be spent listening and understanding team dynamics, not making sweeping technical changes." — Source: ELC Annual
6. On technical letting go: "Stepping away from the day-to-day codebase is painful but necessary to build a team that can operate independently." — Source: First Round Review
7. On imposter syndrome: "The transition inherently brings feelings of inadequacy, as the feedback loops for management are much longer than a passing test suite." — Source: First Round Review
8. On calendar management: "A manager's schedule must shift from maker time to manager time, accommodating interruptions and regular check-ins." — Source: LeadDev
9. On retaining context: "You don't need to write the code, but you must retain enough architectural context to guide technical decisions." — Source: First Round Review
10. On identifying potential: "The best engineers do not necessarily make the best managers; look for those who naturally gravitate toward unblocking others." — Source: First Round Review

Part 2: Engineering Leadership and Expectations

1. On setting context: "Leadership is less about dictating solutions and more about providing the necessary context so teams can make the right decisions." — Source: Software Engineering Daily
2. On psychological safety: "Engineers do their best work in environments where they feel safe raising concerns without fear of immediate retribution." — Source: ELC Annual
3. On clarity of purpose: "Every engineer should understand how their current ticket connects to the broader business objectives." — Source: LeadDev
4. On managing senior ICs: "Leading staff and principal engineers requires a shift from directing work to aligning their technical vision with company strategy." — Source: First Round Review
5. On the VP role: "At the VP level, your job is to build the machine that builds the product, optimizing the organization itself." — Source: Software Engineering Daily
6. On managing through change: "During high-growth phases, leaders must constantly communicate the reasons behind shifting priorities." — Source: ELC Annual
7. On delegation: "Effective delegation means handing over not just the task, but the authority to execute it." — Source: First Round Review
8. On measuring success: "The success of a leader is measured by what happens when they are not in the room." — Source: LeadDev
9. On continuous learning: "The best engineering leaders remain curious, constantly seeking out new frameworks for organizational design." — Source: First Round Review
10. On navigating ambiguity: "Leadership often requires making decisive choices with incomplete information and adjusting as new data arrives." — Source: Software Engineering Daily

Part 3: Feedback and Performance Management

1. On timely feedback: "Feedback should never be a surprise saved for a quarterly review; it needs to be continuous and immediate." — Source: First Round Review
2. On specific praise: "Generic praise is ineffective. Highlight exactly what an engineer did well so they can replicate it." — Source: First Round Review
3. On addressing underperformance: "Delaying difficult conversations about performance only harms the team and the individual struggling." — Source: First Round Review
4. On 1:1 meetings: "A one-on-one is not a status update; it is dedicated time for the engineer's career growth and surfacing hidden friction." — Source: LeadDev
5. On constructive criticism: "Frame criticism around the work and the impact, separating the behavior from the person." — Source: First Round Review
6. On calibrating expectations: "Clearly define what success looks like for each level on the engineering ladder to avoid subjective evaluations." — Source: ELC Annual
7. On peer feedback: "Encourage a culture where engineers feel comfortable providing constructive feedback directly to their peers." — Source: First Round Review
8. On career mapping: "Managers must actively work with their reports to chart a path for advancement, whether on the management or IC track." — Source: First Round Review
9. On recognizing invisible work: "Ensure that code reviews, mentoring, and incident response are factored into performance evaluations." — Source: LeadDev
10. On managing out: "When a role is no longer a fit, managing someone out respectfully is often the best outcome for both parties." — Source: First Round Review

Part 4: Collaboration Between Design and Engineering

1. On the historical divide: "Design and engineering have traditionally operated in silos, leading to friction during handoffs and compromised user experiences." — Source: Figma Blog
2. On shared vocabulary: "Establishing a common language for design tokens and components is the first step toward effective collaboration." — Source: Software Engineering Daily
3. On early integration: "Engineers should be involved in the design process early to provide feasibility constraints before pixels are finalized." — Source: ELC Annual
4. On tooling as a bridge: "Tools built specifically to translate design intent into technical reality reduce the cognitive load on developers." — Source: Figma Blog
5. On mutual empathy: "Engineers must understand the user experience goals, and designers must grasp the technical limitations of the platform." — Source: LeadDev
6. On reducing iteration cycles: "Tighter alignment between design and engineering drastically reduces the time spent going back and forth on minor UI adjustments." — Source: Figma Blog
7. On the source of truth: "The design file and the codebase must remain synchronized; drift between the two leads to organizational debt." — Source: ELC Annual
8. On prototype fidelity: "Decide early on the necessary fidelity of a prototype to avoid over-investing in throwaway code." — Source: Software Engineering Daily
9. On resolving design disputes: "When conflicts arise, default to what serves the end user best, rather than defending functional silos." — Source: Figma Blog

Part 5: Engineering Culture and Rituals

1. On establishing norms: "Culture is not what you write on the wall; it is the behaviors you reward and the poor performance you tolerate." — Source: First Round Review
2. On effective meetings: "Engineering rituals like stand-ups and sprint planning must be ruthlessly pruned if they stop providing value." — Source: ELC Annual
3. On blameless post-mortems: "When an outage occurs, focus on the systemic failure that allowed the error, not the individual who triggered it." — Source: LeadDev
4. On documentation: "A culture of writing things down is essential for scaling teams and onboarding new engineers effectively." — Source: Software Engineering Daily
5. On code review culture: "Code reviews should be seen as a collaborative learning opportunity, not a gatekeeping exercise." — Source: First Round Review
6. On celebrating wins: "Acknowledge team achievements frequently to build momentum and reinforce positive behaviors." — Source: ELC Annual
7. On technical debt: "Make technical debt visible and allocate consistent time for refactoring to prevent the codebase from becoming unmaintainable." — Source: LeadDev
8. On async communication: "Relying on asynchronous updates rather than synchronous meetings allows for deeper, uninterrupted focus time." — Source: First Round Review
9. On onboarding: "A reliable onboarding process is the strongest indicator of a healthy, mature engineering organization." — Source: ELC Annual

Part 6: AI's Impact on Engineering Workflows

1. On the shift in skills: "With AI handling boilerplate code, the critical skills for engineers shift toward architectural design and system thinking." — Source: Orso Media
2. On automated code review: "Language models can pre-review pull requests for basic errors, allowing human reviewers to focus on business logic and architecture." — Source: Trending with Mstre
3. On prompting as a skill: "Effectively communicating context to an AI assistant is becoming a fundamental competency for modern developers." — Source: Orso Media
4. On finding inefficiencies: "AI tools are increasingly adept at scanning codebases to identify performance bottlenecks and deprecated patterns." — Source: Trending with Mstre
5. On building trust: "Integrating AI into products requires engineering teams to prioritize transparency and predictable outcomes for the user." — Source: Intercom
6. On the pace of development: "AI accelerates the initial drafting of code, but the validation and integration phases remain largely human-driven." — Source: Orso Media
7. On legacy code: "Large language models offer a new approach to untangling and migrating legacy systems that were previously too risky to touch." — Source: Trending with Mstre
8. On the future of the IDE: "The development environment will evolve from a text editor into a conversational partner that understands the entire repository." — Source: Orso Media
9. On technical debt management: "AI can help suggest refactoring paths, but engineering judgment is still required to decide which debt to pay down." — Source: Intercom

Part 7: Scaling Teams and Product Growth

1. On building multi-org features: "Scaling a feature that bridges multiple distinct organizations requires a fundamentally different approach to security and data architecture." — Source: Software Engineering Daily
2. On Conway's Law: "As you scale, your software architecture will inevitably mirror your communication structures; design your organization accordingly." — Source: LeadDev
3. On cross-functional squads: "Organizing engineers, designers, and PMs into autonomous pods is the most effective way to maintain velocity during rapid growth." — Source: ELC Annual
4. On hiring for trajectory: "When scaling quickly, hire engineers for their growth trajectory and adaptability, not just their current skill set." — Source: First Round Review
5. On managing dependencies: "As the engineering organization grows, explicitly mapping and managing cross-team dependencies becomes critical to avoid gridlock." — Source: LeadDev
6. On standardizing tooling: "Allowing teams to choose their own stacks works early on, but scaling requires consolidation to maintain operational efficiency." — Source: Software Engineering Daily
7. On maintaining quality: "Growth often tempts teams to ship faster at the expense of quality; leaders must hold the line on testing and reliability." — Source: ELC Annual
8. On hypergrowth friction: "The processes that worked for a small engineering team will actively hinder a massive organization." — Source: First Round Review
9. On integrating acquisitions: "Merging engineering cultures post-acquisition is harder than merging codebases; it requires deliberate, patient integration." — Source: LeadDev

Part 8: The Future of Software Development

1. On the convergence of roles: "The strict boundaries between design, product, and engineering are blurring as tooling becomes more integrated." — Source: Figma Blog
2. On developer experience: "Investing in internal developer tooling is no longer a luxury; it is a primary driver of retention and velocity." — Source: Software Engineering Daily
3. On remote engineering: "Distributed teams force better documentation and asynchronous habits, which ultimately build a more resilient engineering culture." — Source: ELC Annual
4. On component-driven design: "The industry is moving toward a highly composable future where applications are assembled from standardized building blocks." — Source: Figma Blog
5. On the evolution of the frontend: "Frontend development is becoming increasingly complex, requiring rigorous engineering practices previously reserved for backend systems." — Source: Software Engineering Daily
6. On continuous delivery: "The expectation is shifting toward shipping smaller, safer changes multiple times a day rather than large, risky monthly releases." — Source: LeadDev
7. On the role of open source: "Leveraging and contributing back to the open-source ecosystem is essential for staying current and attracting top talent." — Source: ELC Annual
8. On balancing speed and security: "Modern development requires integrating security checks directly into the continuous integration pipeline, rather than treating it as a final hurdle." — Source: Software Engineering Daily
9. On the ultimate goal: "Technology is just the medium; the ultimate goal of any engineering organization is to solve concrete human problems efficiently." — Source: First Round Review