What I Learned Leading Technical Teams for 6 Years

These Are Not Lessons I Read Somewhere

I have been leading technical teams for six years now. I have managed teams of three and teams of fifteen. I have shipped products that succeeded and products that failed. I have hired well and hired badly. I have had difficult conversations I handled with grace and others I botched completely.

What follows are six lessons I learned the hard way. None of them are original — you can find versions of all of them in management books. But there is a difference between reading a lesson and living it. These are the ones that changed how I work.

1. Hire for Curiosity, Not Just Skills

Early in my career as a lead, I hired almost exclusively based on technical ability. Could the candidate solve the coding challenge? Did they know the right frameworks? Could they whiteboard a system design? If the answer was yes, they were in.

I learned that skills get you through the first six months. Curiosity gets you through the next six years. The best engineers I have worked with were not necessarily the ones who walked in knowing everything. They were the ones who asked “why” relentlessly, who spent weekends tinkering with tools nobody asked them to learn, and who could pivot to a new technology stack without complaint because they genuinely enjoyed figuring things out.

I hired a junior developer once who had mediocre experience on paper but asked the most thoughtful questions I had ever heard in an interview. She wanted to understand why we chose our architecture, what tradeoffs we considered, what we would do differently. Within a year, she was one of the strongest contributors on the team. Meanwhile, a senior hire with an impressive resume plateaued quickly because he only wanted to work within patterns he already knew.

Now, I weight curiosity and learning speed as heavily as current technical ability. Skills can be taught. The drive to learn cannot.

2. Documentation Is Not Optional

I used to treat documentation as something you did when you had spare time, which meant it never got done. The codebase grew, knowledge lived in people’s heads, and every time someone left or went on vacation, the team slowed to a crawl while someone else reverse-engineered their work.

The turning point was losing a key engineer who had built a critical integration. He left on good terms, gave two weeks notice, and promised to document everything before his last day. He documented about 30% of it. Not because he was lazy — because you cannot document months of context and decisions in two weeks. The knowledge was too deeply embedded in his daily workflow to extract under pressure.

After that, I made documentation a deliverable, not an afterthought. Pull requests that introduce new systems must include documentation. Architecture decisions get written up in decision records. Onboarding guides are updated quarterly. It slows things down by maybe 10% in the short term. It saves you from catastrophic knowledge loss in the long term. That is a trade I will make every time.

3. Code Reviews Are Teaching Moments, Not Gatekeeping

I have seen two dysfunctional patterns in code review culture, and I have been guilty of both.

The first is the rubber stamp — approving pull requests with a quick glance because you trust the author or you are too busy to look carefully. This builds a false sense of security and lets bad patterns propagate.

The second is the gauntlet — senior engineers who treat code reviews as an opportunity to demonstrate their superiority. Every review becomes a list of everything wrong, delivered without context or suggestions for improvement. Junior developers dread submitting code and start avoiding risk to minimize criticism.

The best code reviews I have participated in read like conversations, not verdicts. “Have you considered this approach? Here is why it might handle edge cases better.” “This works, but I have seen this pattern cause issues at scale — here is what happened last time.” The reviewer shares knowledge. The author learns. The codebase improves.

I started requiring that every critical comment in a code review include either a suggestion or an explanation. Not just “this is wrong” but “this could be improved because…” It transformed the team’s relationship with code review from something they endured to something they valued.

4. Technical Debt Is a Business Decision, Not a Dev Problem

For years, I framed technical debt as an engineering concern and fought to get time allocated for refactoring. The business side never understood why we needed to “redo work” when there were features to ship. I was frustrated, and they were confused.

The breakthrough came when I started translating technical debt into business language. Instead of saying “we need to refactor the authentication module,” I said “our current login system takes the team three days to modify every time we need to add a new user type. If we invest one sprint rebuilding it, future changes will take half a day. Over the next year, that saves us roughly four weeks of developer time.”

That conversation went differently. The business side understood the tradeoff because I framed it in terms they cared about: time, cost, and risk. Technical debt is not a purity concern. It is a compounding interest problem. Every shortcut you take today makes tomorrow’s work slower and more error-prone. When you frame it that way, the people holding the budget usually agree to invest in paying it down. Not always, but more often than when you frame it as “the code is messy and it bothers us.”

5. The Best Engineers Communicate

There is a persistent myth in the industry that great engineers are introverted geniuses who do their best work in silence and communicate primarily through code. I bought into that myth early on and excused poor communication from technically strong team members because “that is just how engineers are.”

It cost me. A brilliant engineer who cannot explain their decisions, raise concerns early, or collaborate across teams creates as many problems as they solve. I had a developer who wrote exceptional code but never spoke up in planning meetings. He disagreed with a major architectural decision but said nothing until three weeks into implementation, when the problems he foresaw became real. The rework cost us a month.

After that, I started evaluating communication as a core engineering skill, not a nice-to-have. I look for people who can explain a complex system to a non-technical stakeholder, who flag risks before they become crises, and who write clear commit messages and pull request descriptions. These are not soft skills. They are engineering skills. A solution that nobody else on the team can understand or maintain is not a good solution, no matter how elegant the code is.

6. Know When to Build vs Buy

I am an engineer. My instinct when facing a problem is to build a solution. That instinct has led to some of the best work I have done and some of the worst decisions I have made.

Early on, I led a team that spent three months building a custom notification system. We wanted full control over delivery channels, templates, and scheduling. The result was technically impressive and a maintenance nightmare. Every edge case in email deliverability, push notification handling, and SMS gateway integration that the existing services had already solved, we had to discover and solve ourselves. We eventually scrapped it and integrated a third-party service in two weeks.

The lesson was not “never build.” It was “build where your value is, buy everywhere else.” If notifications are not your core product, you should not be maintaining a notification system. If user authentication is not your competitive advantage, use an identity provider. Save your engineering energy for the things that differentiate your business.

Now, every time someone on my team proposes building something, I ask: “Is this where we want to be experts?” If the answer is no, we look for an existing solution first.

Conclusion

Six years of leading teams has taught me that the technical challenges are rarely the hardest part. The hard part is building a culture where people learn, communicate, make smart tradeoffs, and do their best work. The tools and frameworks change every year. The human dynamics stay remarkably consistent.

If you are building a technical team or navigating the challenges of engineering leadership, I am always happy to talk through what I have learned. Reach out — I am better at giving this advice now than I was at following it six years ago.