I spent two years as a tech lead for a single squad, then stepped up to manage four. The biggest shift wasn’t the number of meetings—it was the distance from the work. I moved from direct control to influencing through tech leads as the main contact points. That change forced me to grow a new kind of leadership muscle and to confront the real cost of doing management well.

TL;DR

  • Lead through systems and rituals, not tasks.
  • Publish a clear, steady performance bar.
  • Protect candid, respectful communication.
  • Practice empathy while keeping ownership boundaries.
  • Write rationales for heavy, people-impacting decisions.

Here are five lessons that helped me scale across squads.

Lesson 1: Lead Through Systems, Not Tasks

As a tech lead, I could track each person’s work directly—and jump in when needed: pair on a tricky algorithm, review pull requests in detail, help someone through a tough ticket, or debug production issues side by side. As an engineering manager across multiple squads, that became impossible—and trying anyway would only slow everyone down. While I still get involved in production incidents when needed, day-to-day ticket-level collaboration is no longer part of my role. My job shifted from supervising tasks to building systems and rituals where my leads and teams can succeed without me watching over their shoulders.

That means sharing context and priorities instead of instructions, empowering tech leads to make decisions, and installing the right guardrails so the team can move fast without breaking alignment. Being hands-off doesn’t mean being absent; it means designing a system that makes good decisions even when I’m not in the room.

Practical takeaways

  • Share goals, constraints, and the “why”—not the step-by-step “how.”
  • Hold regular syncs with tech leads and occasional skip-levels with individual contributors (ICs) for reality checks.
  • Install guardrails: decision boundaries, escalation paths, and “stop-the-line” triggers.

Lesson 2: Set the Bar Early—and Hold It

One of my hardest lessons was about expectations and evaluation. It’s tempting to be lenient at first and tighten standards later; that feels kind in the moment and unfair down the line.

It’s better to define a reasonable, high-quality bar from the start and apply it consistently. People prefer clarity over shifting standards, even when the bar is demanding. Early on, I wasn’t clear or consistent; correcting that has taken time and careful communication to stay fair to everyone involved.

Practical takeaways

  • Write down what “good,” “great,” and “not yet” look like for each role.
  • Use the same rubric for feedback, promotion, and performance cycles.
  • If the bar changes, explain why and provide a path to meet it.

Lesson 3: Protect Candid, Respectful Communication

Healthy teams run on open, respectful communication. That sounds obvious—until you’re dealing with deadlines, disagreements, and cross-team dependencies. Protecting both candor and respect is one of my most important jobs as a manager.

Teams thrive when feedback is safe, disagreements surface early, and people feel heard even when their ideas aren’t chosen. A respectful culture doesn’t avoid conflict—it handles conflict well.

Practical takeaways

  • Default to public channels for decisions; document dissent and its resolution.
  • In conflict, restate the other person’s point in its strongest form before replying.
  • Praise in public, course-correct in private, and always separate the person from the problem.

Lesson 4: Practice Empathy, Keep Ownership

Product, design, and business partners have their own pain points. It’s easy for engineers to dismiss those as “not our problem,” and that only creates friction. Collaboration starts with empathy: listen to what’s hard for them and try to see the world through their perspective.

The same applies within engineering. Different squads have different priorities, deadlines, and constraints, so conflicts arise quickly when dependencies are involved. A little empathy across squads goes a long way toward avoiding “us vs. them” dynamics and turning conflicts into problem-solving conversations.

Practical takeaways

  • Start by asking what outcomes other teams or squads are measured on.
  • Acknowledge when another squad is under pressure while negotiating handoffs or deadlines.
  • Negotiate scope with explicit trade-offs and delivery planning, not vague “we’ll try.”

Lesson 5: Carry the Weight of Decisions

The biggest change for me was realizing how heavy good management is. Decisions carry real trade-offs that affect people’s careers, motivation, and trust. If you care about your team, the weight is taxing—that’s not a bug. It’s the job.

I’ve learned to slow down on the big calls, explain trade-offs openly, and accept there’s rarely a perfect answer. Leadership isn’t about avoiding hard decisions; it’s about carrying them with care.

It feels heavy because each call helps someone and lets someone else down—and you see both.

Practical takeaways

  • For people-impacting calls, write a brief rationale and sleep on it.
  • Name the trade-offs and follow up with those most affected.
  • Offer concrete next steps to those affected (support, timelines).

Closing

Advice to my first-year manager self: Be consistent from day one. Decide what “good” means, communicate it clearly, and apply it fairly. It’s kinder than raising the bar later.

Scaling as an engineering manager is less about doing more, and more about building systems where good decisions happen without you in the room. Influence through leaders, keep the bar steady, protect communication, and balance empathy with boundaries. The rest is repetition and care.

If you manage multiple squads, start with mechanisms: publish your bar, run a tight leads sync, and write decisions down.