Lessons from Nick Caldwell

Lessons from Nick Caldwell

Nick Caldwell has managed engineering teams at Microsoft, Reddit, Looker, and Twitter, working through both corporate structure and rapid startup growth. He is best known for his blunt advice to new managers: stop writing code and focus on your people. This profile collects his practical views on building teams, scaling organizations, and career development.

Part 1: Defining Engineering Management

1. On management's core function: "The engineering manager's primary job is to staff a team that can deliver on objectives at a predictable cadence and a known quality level." — Source: Reforge
2. On the manager versus architect path: "My 'Voight-Kampff test' for management is simple: do you care more about debugging code or debugging people? If it's the latter, you belong on the management track." — Source: Medium
3. On treating engineers as adults: "Engineers are not code factories. Every minute you spend explaining the 'why' behind a project is a minute well-spent." — Source: First Round Review
4. On avoiding IC work: "As you move up, you have to 'get off the floor.' You can no longer measure your worth by the number of commits you push." — Source: First Round Review
5. On the transition to leadership: "A manager ensures the team completes the work correctly. A leader takes responsibility for the future of the organization and provides the vision to get there." — Source: Lattice
6. On setting direction: "Provide your team with the inspiration, tools, and processes they need to move together. Then get out of their way." — Source: Medium
7. On engineering retrospectives: "A good retrospective goes beyond listing what broke; it uncovers the systemic communication or tooling failures that allowed the break to happen." — Source: Reforge
8. On predictability: "Stakeholders want speed, but they prioritize predictability. A manager's job is to build a machine that delivers features on a reliable timeline." — Source: Reforge
9. On coaching: "You are no longer the best engineer in the room. Your value is now measured by how many better engineers you can create." — Source: Medium
10. On alignment: "A manager must act as the translation layer between business objectives and technical execution." — Source: Reforge

Part 2: Empathy and People-First Culture

1. On empathy as strategy: "Empathy is not a soft skill. Understanding the stressors on your team is directly tied to their overall effectiveness and the company's success." — Source: Lattice
2. On psychological safety: "People do their best work when they feel safe to take risks. You build that safety through transparency, especially when things go wrong." — Source: Medium
3. On understanding team context: "When you join a new organization, trust is not granted by your title. It is earned by taking the time to understand the unique stressors of the existing team." — Source: Lattice
4. On burnout: "You cannot squeeze more productivity out of a burnt-out team by demanding more hours. You have to fix the broken systems causing the friction." — Source: Medium
5. On listening: "The most important tool an engineering leader has is the one-on-one meeting. Use it to listen, rather than to assign tasks." — Source: First Round Review
6. On the limits of process: "Process cannot replace empathy. If your team is struggling, adding another Jira workflow will not solve the underlying human problem." — Source: Medium
7. On vulnerability: "Leaders need to be willing to say 'I don't know.' It gives the team permission to learn together instead of pretending they have all the answers." — Source: Lattice
8. On recognizing effort: "Celebrate the invisible work. The engineers who prevent fires are equally valuable as the ones who put them out." — Source: InfoQ
9. On work-life boundaries: "You are managing people with lives outside of work. Acknowledging that reality makes you a more effective leader." — Source: Lattice

Part 3: Scaling Teams and Hypergrowth

1. On early hypergrowth: "When you are tripling the size of your engineering team in a year, your first priority must be formalizing the management structure." — Source: InfoQ
2. On defining roles: "During rapid scaling, you must explicitly answer the question, 'What does a manager actually do here?' Otherwise, everyone will invent their own definition." — Source: InfoQ
3. On hiring for scale: "You cannot rely on one-off leadership hires when growing fast. You need a systematic approach to identifying and igniting potential internally." — Source: InfoQ
4. On communication overhead: "As teams grow, coordination overhead increases exponentially. Your job as a leader is to continuously redesign the organization to reduce that overhead." — Source: First Round Review
5. On the jazz band analogy: "A scaled team operates like a jazz band. They know the foundational structure so well that they can improvise and play off one another seamlessly." — Source: Lattice
6. On discarding old processes: "The procedures that got your team to thirty engineers will break when you hit one hundred. Be prepared to throw away systems you built yourself." — Source: Medium
7. On maintaining culture: "Culture is not what you write on the wall; it is the behavior you tolerate when the team is under pressure to ship." — Source: Medium
8. On onboarding: "A fast-growing team lives or dies by its onboarding process. If it takes three months for an engineer to become productive, you cannot scale." — Source: InfoQ
9. On decentralized decision making: "Move decision-making power down the org chart. The people closest to the code usually have the best context to make the call." — Source: First Round Review
10. On managing chaos: "Hypergrowth is inherently chaotic. Your role is not to eliminate the chaos entirely, but to channel it into productive output." — Source: Reforge

Part 4: Career Development and Advancement

1. On bad advice: "The worst career advice I ever received was to wait for my manager to leave so I could get promoted. Never wait for a structural vacancy to advance." — Source: Medium
2. On mentors versus sponsors: "A mentor talks to you and gives advice. A sponsor talks about you in the rooms where career-defining decisions are made." — Source: Intercom
3. On leaving comfort zones: "I stayed at Microsoft for fifteen years. Leaving that safety net taught me that your skills are far more portable than the security of a single company." — Source: Medium
4. On goal tracking: "Write down your career goals and review them over a decade. Discipline in tracking your ambitions separates wishing from achieving." — Source: FreeCodeCamp
5. On taking risks: "The biggest career leaps rarely come from safe, incremental steps. They come from taking roles where you might actually fail." — Source: First Round Review
6. On advocating for yourself: "Do not assume your manager knows what you want to do next. You have to explicitly state your ambitions if you want support in reaching them." — Source: Medium
7. On lateral moves: "Sometimes the best way to move up is to move sideways into a completely different technical domain to expand your context." — Source: Medium
8. On continuous learning: "The half-life of technical knowledge is shrinking. If you fail to dedicate time to learn new paradigms, your expertise will expire." — Source: Medium
9. On failure as data: "Treat career setbacks as you would a production outage. Run a personal post-mortem, figure out what broke, and update your runbook." — Source: Medium

Part 5: Diversity, Equity, and Inclusion

1. On diversity as a strategy: "Diversity is a core discipline that founders must prioritize in the same way they treat product or sales." — Source: First Round Review
2. On building networks: "Organizations like /dev/color exist because underrepresented engineers need a dedicated space to share knowledge and build career-accelerating networks." — Source: Intercom
3. On retention: "Hiring diverse talent is useless if your internal culture drives them away. Inclusion is the mechanism that makes diversity sustainable." — Source: Medium
4. On representation in leadership: "You cannot be what you cannot see. Promoting diverse leaders is essential for showing junior engineers that a path exists for them." — Source: Medium
5. On systemic barriers: "Tech has a pipeline problem, but it also has an evaluation problem. We often filter out great talent because they fail to match our narrow definition of what an engineer looks like." — Source: First Round Review
6. On sponsorship for minorities: "Sponsorship is disproportionately critical for Black engineers and other minorities who often lack access to traditional, informal executive networks." — Source: Intercom
7. On addressing bias: "Bias in hiring is rarely overt. It often looks like 'culture fit,' which is frequently code for 'people who remind me of myself.'" — Source: Medium
8. On community support: "Giving back through mentorship and scholarships is an investment in the future foundation of the tech industry." — Source: FreeCodeCamp
9. On accountability: "If your leadership team is entirely homogeneous, you are operating with a blind spot that will eventually cost the business." — Source: Medium

Part 6: Building Trust with Product and Stakeholders

1. On the engineering-product divide: On First Round In Depth, Caldwell discusses how leading both product and engineering at Looker gave him a clearer view of why those two organizations, often at odds, need to team up around shared outcomes. — Reference: First Round In Depth episode on Caldwell leading product and engineering at Looker and aligning the two orgs
2. On building alignment: "To build trust with product managers, engineers must show that they care about the business outcomes equally as much as the architecture." — Source: Reforge
3. On pushing back: "A capable engineering leader avoids a simple 'no' to product requests. Instead, they explain the cost of the request and provide alternative approaches." — Source: Reforge
4. On technical debt: "You have to translate technical debt into business risk. Stakeholders will fund a refactor if you show how it prevents customer churn." — Source: Medium
5. On shared goals: "Align product and engineering around the same success metrics. If engineering is measured on uptime and product is measured on shipping features, you have designed a conflict." — Source: Reforge
6. On transparency: "Never hide engineering struggles from the product team. If a deadline is slipping, communicate it early so the business can adjust." — Source: Reforge
7. On the value of shipping: In the Intercom interview summary, Caldwell frames engineering leadership around two jobs: execute and deliver high-quality software on a predictable schedule, and build the people skills needed to attract, retain, and develop strong talent. — Reference: Intercom interview summary on engineering leaders executing and delivering high-quality software predictably
8. On customer empathy: "Engineers should talk to customers. Reading a ticket is a poor substitute for hearing user frustration firsthand." — Source: Medium
9. On production loops: "Establish tight feedback loops between what you ship and how it performs in production. That data is the only objective way to settle product debates." — Source: Reforge
10. On cross-functional respect: "Assume good intent from your stakeholders. They are asking for features to grow the business, not to ruin your weekend." — Source: Reforge

Part 7: Navigating Change and Transitions

1. On acquisitions: "During an acquisition, the hardest part is rarely the technical migration. It is merging two distinct cultures without destroying the morale of either." — Source: Medium
2. On changing company sizes: "When you move from a massive corporation to a startup, you have to unlearn the instinct to wait for permission." — Source: First Round Review
3. On structural transitions: "Moving from individual contributor to manager is a career change, not a promotion. It requires an entirely different set of daily tools and metrics for success." — Source: First Round Review
4. On zero-to-one projects: "Building something from scratch inside a large corporation requires protecting the team from the company's own bureaucratic immune system." — Source: First Round Review
5. On managing reorganization: "Reorgs are painful. Communicate exactly why the structure is changing and how it aligns with the company's new reality." — Source: Medium
6. On letting go of control: "As a director, you have to accept that you will no longer know how everything works under the hood. You must trust the leaders you hire." — Source: First Round Review
7. On legacy code: "Never walk into a new company and immediately insult the legacy architecture. The code you hate is the code that paid for your salary." — Source: Medium
8. On adapting to executive roles: "The skills that made you a great engineering manager will not automatically make you a great VP. The higher you go, the more the job relies on communication." — Source: First Round Review
9. On survival: "In tech, the only constant is change. Your ability to adapt your leadership style to new contexts is your ultimate survival mechanism." — Source: Medium

Part 8: Philosophy of Engineering and Code

1. On software as a tool: In the Intercom interview, Caldwell ties engineering work to customer understanding: teams need telemetry to see what is actually used and qualitative user empathy to experience what users experience. — Reference: Intercom interview on telemetry, monitoring, and user empathy in product engineering
2. On simplicity: "The best engineers write code that junior developers can easily understand. Complexity is usually a sign of a rushed design." — Source: Medium
3. On engineering fundamentals: "Frameworks will come and go. Deeply understanding data structures, systems design, and performance fundamentals is what builds a lasting career." — Source: Medium
4. On the cost of maintenance: "Every line of code you write is a liability that someone else will have to maintain. Write less code." — Source: Medium
5. On the nature of bugs: "Bugs are rarely pure logical errors. They are frequently the result of misunderstood requirements or poor communication between teams." — Source: Medium
6. On automation: "If you have to do a task three times, automate it. Engineering time is too expensive to spend on manual toil." — Source: InfoQ
7. On architectural choices: "Choose boring technology. Save your innovation tokens for the core business problem, rather than for the database layer." — Source: Medium
8. On code reviews: "A code review should be a conversation aimed at improving the codebase, rather than a test of ego or dominance." — Source: Medium
9. On the ultimate goal: "Ultimately, our job is to ship value to users. The tech stack, agile methodology, and org chart serve entirely as a means to that end." — Source: Medium