How to Build Trust as a New Tech Lead: The First 60 Days

The day I became a tech lead for a new team, I walked in with a plan to change everything. New coding standards. New deployment process. New architecture for the core service. I was going to show them what a real tech lead could do. Within three weeks, half the team was passively resisting every change I proposed, and the senior developer had asked to transfer to another team.

My mistake was obvious in hindsight: I tried to lead before I earned the right to. Trust is not granted with the title. It is earned through actions, over time, starting from day one. After going through this transition five times with different teams, I have a playbook that works.

The Trust Equation for Tech Leads

Trust in a technical context is built on four pillars:

• Competence: Does this person know what they are talking about technically?
• Reliability: Does this person follow through on commitments?
• Empathy: Does this person care about my success, not just the project's?
• Transparency: Does this person share information honestly, even when it is uncomfortable?

Deficit in any one area undermines the others. A technically brilliant lead who does not follow through on promises will lose trust. A reliable, empathetic lead who lacks technical depth will lose credibility. You need all four.

Week 1-2: Listen Before You Lead

Your first two weeks should be 80% listening and 20% doing. Schedule one-on-ones with every team member. Not to deliver your vision. To ask questions:

• "What is working well on this team that I should not change?"
• "What is the biggest pain point in your daily work?"
• "What did the previous tech lead do well? What would you change?"
• "What would help you do your best work?"

Take notes. See the patterns. Your team will tell you exactly what they need if you create the space for honesty. And the act of asking, genuinely asking and listening, is itself a trust-building action.

During these two weeks, change nothing. Resist the urge to fix things. You do not have enough context yet, and premature changes signal that you think you know better than people who have been living with this codebase for months or years.

Week 3-4: Quick Wins and Demonstrated Competence

After two weeks of listening, you should have a clear picture of the team's biggest pain points. Pick the smallest, most impactful one and fix it. Not a multi-sprint initiative. Something you can ship in a few days.

Examples of good first wins:

• Fix the flaky CI pipeline that wastes 20 minutes per build
• Automate a manual deployment step that everyone hates
• Write the documentation for an undocumented system that causes on-call pain
• Resolve a long-standing code review bottleneck

The point is not the fix itself. The point is demonstrating three things: you listened, you acted, and you can ship. That combination builds trust faster than any speech or grand strategy document.

Week 3-4: Demonstrate Technical Depth

Your team is evaluating your technical credibility from day one. They watch your code reviews, your architecture comments, your debugging approach. You do not need to prove you are the best coder. You need to prove you understand the systems and can add value to technical discussions.

Some ways to build technical credibility:

• Do a thorough code review that catches something others missed. Not a nitpick. A real architectural concern or a subtle bug.
• Pair program with different team members. This shows your technical skills in action and builds personal connections simultaneously.
• Ask smart questions in design discussions. "What happens to this service if the downstream dependency is unavailable for 30 seconds?" shows you think about failure modes, which is what tech leads are paid to do.

Week 5-8: Establish Reliability

By now, you have listened, shipped a quick win, and demonstrated technical competence. Time to build the reliability pillar. This is straightforward but requires discipline:

1. Never miss a one-on-one. If you need to reschedule, do it proactively and immediately rebook. Cancelling one-on-ones tells your team they are not a priority.
2. Follow up on every commitment. If you said "I will talk to the infrastructure team about getting us more staging environments," do it within 48 hours and report back.
3. Be consistent in your feedback standards. If you flagged a code quality issue last week, flag the same issue this week. Inconsistency breeds confusion and distrust.
4. Meet your own deadlines. If you committed to writing a design doc by Friday, deliver it by Friday. Your team will match your standards.

Building Trust Through Transparency

Transparency is the trust accelerator. When you are transparent about your reasoning, your constraints, and your mistakes, you create an environment where others feel safe doing the same.

Share Your Reasoning

When you make a technical decision, explain the why. "We are going with option B because of [reason], even though option A has [advantage]. The trade-off is [what we are giving up]." This lets your team evaluate your judgment and build confidence in your decision-making process.

Admit What You Do Not Know

"I do not have experience with Kafka. Sarah, you used it at your last company. Can you help me understand the operational complexity?" This is not weakness. It is intellectual honesty. Your team already knows what you do not know. Admitting it openly makes you trustworthy. Pretending makes you a fraud.

Share Information From Above

When leadership is considering a reorg, when the company's financial situation changes, when there are shifts in strategy, share what you can. Your team will hear rumors regardless. Hearing it from you, with context, builds trust. Hearing it from the rumor mill after you stayed silent destroys it.

Trust Destroyers to Avoid

Trust takes weeks to build and minutes to destroy. Avoid these at all costs:

• Taking credit for the team's work. In public, always say "the team" delivered it. In private, name specific people. Never present work as yours.
• Throwing people under the bus. When something goes wrong, you own it externally. You address the root cause internally, privately, with constructive feedback.
• Making decisions without explanation. Even if you have the authority to decide unilaterally, unexplained decisions feel arbitrary and build resentment.
• Playing favorites. If one developer gets better assignments, more face time, or less scrutiny in code reviews, the rest of the team notices. Be equitable.
• Breaking confidentiality. If someone shares a personal concern in a one-on-one, it stays there. Full stop.

Trust is asymmetric: it compounds slowly through consistent positive actions and collapses instantly through a single betrayal. As a new tech lead, you are building a trust account starting from zero. Every interaction is either a deposit or a withdrawal. Be intentional about making deposits.

The 60-Day Checkpoint

After 60 days, evaluate your trust progress. Are team members bringing you problems proactively? Are they pushing back on your ideas constructively, which means they feel safe disagreeing? Are one-on-ones turning into genuine conversations rather than status updates? These are the signs that trust has been established.

If you have followed this playbook, you are now ready to propose bigger changes: architectural improvements, process adjustments, or team structure changes. The foundation of trust means your proposals will be received as genuine improvements rather than the uninformed opinions of a new person who does not understand the context. That is the difference between a successful first 90 days and a rocky start that takes months to recover from.