LCN Docs

Appearance

Building Trust with a New Team: A Leadership Guide ​

Table of Contents ​

Introduction ​

Trust is the foundation of effective technical leadership. As a Principal Software Engineer or Technical Lead joining a new team, your technical expertise alone won’t drive success—your ability to build trust will determine whether your team follows your vision, embraces your decisions, and performs at their best.

This guide explores the nuanced skill of building trust with a new team, particularly in distributed engineering environments where you’re leading across time zones, cultures, and technical contexts. Trust isn’t built through a single action or speech; it’s earned through consistent behaviors, transparent communication, and demonstrated competence over time.

Why This Skill Matters:

When you join a new team as a technical leader, you inherit a complex social system with existing relationships, norms, and skepticism. Engineers will evaluate whether you:

  • Understand their technical context and challenges
  • Respect their existing work and contributions
  • Have the competence to lead them technically
  • Care about their growth and success
  • Will shield them from organizational chaos
  • Can be counted on during critical moments

Without trust, even your best technical decisions will face resistance. With trust, you can navigate difficult conversations, drive architectural changes, and build a high-performing team culture.

1. Core Principles ​

1.1 Trust is Earned Through Consistency, Not Declared ​

Many new leaders make the mistake of trying to announce their leadership or declare their intentions. “I’m here to help you succeed” sounds hollow without evidence. Trust accumulates through repeated small actions that demonstrate reliability, competence, and genuine care.

The Trust Equation:

Trust builds from four components:

  • Credibility: Do you know what you’re talking about technically?
  • Reliability: Do you do what you say you’ll do?
  • Intimacy: Do you understand and care about individual concerns?
  • Self-Orientation: Are you focused on the team’s success or your own?

Trust = (Credibility + Reliability + Intimacy) / Self-Orientation

As a technical leader, you must score high on all three numerator factors while keeping self-orientation low. This means demonstrating technical competence while being humble, following through on commitments while being transparent about constraints, and showing genuine interest in people while avoiding political maneuvering.

1.2 The First 90 Days Set the Pattern ​

Your first three months establish the behavioral patterns your team will expect from you indefinitely. If you start with transparency and follow-through, that becomes the norm. If you start with promises you can’t keep or decisions without context, that becomes what people expect.

This is particularly critical when joining as a Technical Lead on an existing platform. The team already has working code, established patterns, and likely some technical debt they’re frustrated about. How you handle this inherited state signals everything about your leadership approach.

1.3 Technical Credibility is Necessary but Not Sufficient ​

Engineers need to believe you can handle the technical depth of their work. If you can’t understand their OData expression tree implementation challenges or why their Cosmos DB partitioning strategy matters, you won’t earn their respect. But technical credibility alone doesn’t build trust—plenty of brilliant engineers are poor leaders.

You need technical credibility to get in the door, but you build trust through how you use that credibility: to amplify others’ ideas, to make space for learning, to shield the team from chaos, and to make sound decisions under pressure.

1.4 Trust Requires Vulnerability ​

Counterintuitively, admitting what you don’t know builds more trust than pretending to know everything. When you say “I haven’t worked with this specific Azure Functions deployment pattern—walk me through your approach,” you demonstrate:

  • Intellectual honesty
  • Respect for the team’s expertise
  • Willingness to learn
  • Security in your own competence (you don’t need to know everything)

This is especially important when joining a domain you’re less familiar with. Your experience across fintech, insurtech, healthcare, and education gives you valuable pattern recognition, but each domain has unique constraints. Acknowledging this shows maturity.

1.5 Trust Scales Differently in Distributed Teams ​

Leading teams across US, India, Vietnam, and Vienna (as you’ve done) requires intentional trust-building because:

  • You can’t rely on hallway conversations and social osmosis
  • Written communication lacks tone and body language
  • Time zones limit real-time interaction
  • Cultural differences affect communication styles
  • Remote work can create isolation and disconnection

In distributed environments, trust building must be more explicit, documented, and structured. You can’t assume people “know you care”—you have to demonstrate it through accessible communication, proactive outreach, and visible support.

2. Practical Frameworks ​

Framework 1: The First Week Listen-and-Learn Protocol ​

Goal: Gather context and demonstrate respect before making changes.

Structure:

Days 1-2: Individual Conversations (30-45 min each)

  • Schedule 1:1s with every team member
  • Ask open-ended questions:
    • “What’s working well on this project?”
    • “What’s frustrating you technically?”
    • “What do you wish leadership understood about your work?”
    • “What’s one thing you’d change if you had authority?”
  • Critical: Take notes, but don’t make commitments yet
  • Close with: “I’m still learning the context. I’ll follow up after I’ve talked to everyone.”

Days 3-4: Technical Deep Dive

  • Review architecture documentation, code, and recent PRs
  • Identify patterns: What’s strong? What’s struggling?
  • Map technical debt to business constraints
  • Understand deployment/ops reality (not just the intended design)

Day 5: Synthesis and Early Signals

  • Identify 1-2 quick wins you can visibly deliver (unblock a dependency, clarify a requirement, remove a process bottleneck)
  • Share initial observations in a team meeting:
    • “Here’s what I’ve learned this week…”
    • “Here are the strengths I see in how you’re building…”
    • “Here are some areas I heard we want to improve…”
    • “I don’t have answers yet, but here’s how I’m thinking about next steps…”

Why This Works:

  • Demonstrates you value the team’s knowledge
  • Shows you won’t make uninformed decisions
  • Gives you real context for future decisions
  • Creates early credibility through visible learning

Example from Your Context:

When you joined Aperia Solutions as Technical Lead for the port management SaaS:

  • Week 1: Don’t immediately propose Cosmos DB optimizations or microservice refactoring
  • Instead: Understand why the current architecture exists, what constraints drove those choices
  • Talk to engineers about their biggest delivery pain points
  • Review recent incidents or performance issues
  • Then propose improvements with context: “Based on what I learned about our port workflow reliability needs and the issues we had last month with X, here’s what I’m thinking…”

Framework 2: The Consistency Engine ​

Goal: Build reliability through visible follow-through.

Structure:

1. The Personal Kanban

  • Keep a visible backlog of commitments (team Slack channel, shared doc, or project board)
  • Items include:
    • Technical decisions you promised to research
    • Blockers you said you’d unblock
    • Questions you said you’d get answers for
    • Code reviews you committed to
  • Update status weekly in team sync
  • If you can’t deliver, explain why transparently before the deadline

2. The Decision Log

  • Document significant technical decisions with:
    • Context: What problem are we solving?
    • Options considered: What alternatives did we evaluate?
    • Decision: What we’re doing
    • Rationale: Why this choice given our constraints
    • Tradeoffs: What we’re accepting and why
  • Share broadly, invite feedback
  • Revisit when context changes

3. The Communication Cadence

  • Establish predictable rhythms:
    • Weekly team sync (same time, same format)
    • Bi-weekly 1:1s (on calendar, rarely rescheduled)
    • Monthly architecture reviews (if leading multiple teams)
    • Immediate response to blockers (even if just “I see this, working on it”)

Why This Works:

  • Reliability is visible and measurable
  • People know when to expect communication
  • Broken commitments are exceptions, not patterns
  • Team can trust you’ll follow through

Example from Your Context:

You’re coordinating with architects, BAs, and infra teams at Aperia. Your consistency engine might look like:

Personal Kanban in Slack:

  • “This week I’m working on: (1) Reviewing Cosmos DB partitioning strategy with infra, (2) Unblocking the payment integration spec with BA team, (3) Deciding on error handling approach for port workflows”
  • Next week: “Status update: (1) ✅ Met with infra, decision documented in ADR-042, (2) ✅ Payment spec approved, (3) ⏳ Still evaluating - need one more day to review options”

Decision Log Example: When you’re migrating from Azure Functions to containers:

  • Document: “Migration Decision: Azure Functions to Containerized Microservices”
  • Context: “Our port management workflows have grown complex, and Azure Functions’ stateless model is creating coordination challenges…”
  • Options: Keep Functions with Durable Functions, Move to containers on K8s, Hybrid approach
  • Decision + rationale with tradeoffs clearly explained
  • Share with team before implementation begins

Framework 3: The Vulnerability Ladder ​

Goal: Build intimacy and psychological safety through graduated openness.

Structure:

Level 1: Admit Knowledge Gaps (Week 1-2)

  • “I haven’t worked with this OData implementation pattern before—can you show me?”
  • “I need to understand the port workflow business logic better before I can weigh in”

Level 2: Share Thinking Process (Week 3-4)

  • “Here’s what I’m wrestling with in this decision…”
  • “I’m uncertain between approach A and B because…”
  • “I need your input on this tradeoff…”

Level 3: Acknowledge Mistakes (Ongoing)

  • “I pushed for X last week, but after seeing the data, Y makes more sense”
  • “I missed that requirement—that’s on me. Here’s how I’ll prevent that…”

Level 4: Share Strategic Uncertainty (Month 2+)

  • “Leadership is asking for X timeline, but I’m not confident we can deliver that. Here’s what I’m thinking…”
  • “I don’t have a great answer for this organizational challenge. Here’s what I know…”

Why This Works:

  • Vulnerability is reciprocal—when you’re open, others open up
  • Demonstrates you’re human, not a facade
  • Creates permission for others to admit uncertainty
  • Builds psychological safety for the team

Anti-Pattern: Don’t confuse vulnerability with dumping problems. “I have no idea what we’re doing and leadership is a disaster” isn’t vulnerability—it’s abdication. Vulnerability is “I’m uncertain about X, here’s my thinking, here’s what I need from you.”

Example from Your Context:

When implementing the xAPI Learning Record System at YOLA that scaled to millions of records:

Level 1 (Early): “I’ve built event-driven systems, but xAPI specifically is new to me. Walk me through how you’re modeling the learning statements.”

Level 2 (After a few weeks): “I’m thinking we need to partition by learner ID rather than course ID for our query patterns, but I’m uncertain if that creates hotspots at scale. What am I missing?”

Level 3 (After a mistake): “I should have caught that the analytics queries would scan too much data with this schema. I was too focused on write performance. Let’s redesign this together.”

Level 4 (Strategic): “Product wants real-time analytics, but the cost at our scale is prohibitive. I need to push back, and I want you to understand the constraints I’m working with…”

Framework 4: The Amplification Strategy ​

Goal: Build trust by making others successful and visible.

Structure:

1. Public Credit Attribution

  • In team meetings: “Sarah’s solution to the Cosmos DB partition key issue was elegant—Sarah, can you walk everyone through your approach?”
  • In Slack/email: “Minh identified this bug in code review and proposed a fix that prevents a whole class of issues—great catch”
  • With leadership: “The team delivered this on time because Thanh drove the cross-team coordination really effectively”

2. Idea Elevation

  • When someone has a partial idea, help them develop it fully
  • “That’s interesting—have you considered extending that to…?”
  • Then attribute: “Building on An’s suggestion, what if we…”

3. Growth Opportunities

  • Delegate visible work strategically
  • “I want you to present this architecture to leadership because you designed it”
  • “Take the lead on this cross-team discussion—you understand the integration best”

4. Shield from Chaos

  • When leadership makes unreasonable asks, push back before it reaches the team
  • “I told them we need 3 weeks, not 1 week. Here’s why…”
  • Team sees you’re protecting their focus and sanity

Why This Works:

  • People trust leaders who make them successful
  • Demonstrates low self-orientation
  • Creates psychological safety (you’re not stealing credit)
  • Team members become advocates for your leadership

Example from Your Context:

At CoverGo, collaborating across domain teams:

Instead of: “I implemented the reporting architecture” Do: “The reporting architecture came together because the team did great work: Hung built the data collection layer that handles our volume, Linh designed the query optimization approach, and Phuong solved the cross-domain aggregation problem. I coordinated, but they executed.”

In 1:1s: “You did strong work on that Claims service integration. I want you to demo it at the all-hands. I’ll help you prepare, but you present.”

With leadership: “We hit the deadline because the team coordinated brilliantly across domain boundaries. Here’s specifically what each person contributed…”

Framework 5: The Early Wins Formula ​

Goal: Build credibility through visible, quick impact.

Structure:

Criteria for Early Wins:

  1. Visible: Team can see the improvement
  2. Achievable: You can deliver in 1-2 weeks
  3. Meaningful: Solves a real pain point
  4. Non-Disruptive: Doesn’t require major refactoring
  5. Builds Momentum: Creates energy for bigger changes

Process:

  1. From your first week conversations, identify top 3 frustrations
  2. Pick the one you can solve fastest
  3. Solve it, then communicate the fix clearly
  4. Connect it to bigger vision: “This is step 1 of improving X”

Example Wins:

  • Unblock a stuck deployment by clarifying a requirement
  • Fix a long-standing dev environment issue
  • Document an undocumented integration
  • Remove a painful manual process
  • Speed up CI/CD pipeline

Why This Works:

  • Demonstrates competence without requiring big changes
  • Shows you listened to early feedback
  • Creates goodwill for harder decisions later
  • Team sees you deliver, not just talk

Anti-Pattern: Don’t pick wins that undermine existing work. If you “fix” something that was actually a deliberate choice, you signal you didn’t understand the context. Early wins should be obviously helpful, not subtly critical.

Example from Your Context:

When you joined Valant Healthcare as Technical Lead (first Vietnam team for US client):

Instead of: “I’m going to refactor this entire HIPAA compliance layer in my first month”

Do: “I noticed the team spends 30 minutes each deploy verifying HIPAA controls manually. I documented the checklist and automated it in CI. This saves the team hours per week and reduces compliance risk. Next, I want to look at automating our security scanning…”

At Tricentis Analytics, coordinating across US, India, Vietnam:

Early win: “The teams were confused about the BI pipeline data model versioning. I created a shared document with clear ownership and sync schedules. Now everyone knows who owns what. This makes our bigger conversation about pipeline scaling easier…”

3. Common Mistakes ​

Mistake 1: The “I’m the New Sheriff” Approach ​

What It Looks Like:

  • First week: Announcing all the things you’re going to change
  • Criticizing existing architecture without understanding constraints
  • “Back at my old company, we did it this way…”
  • Making decisions before building context

Why It Destroys Trust:

  • Signals disrespect for the team’s work
  • Demonstrates poor judgment (making decisions without context)
  • Creates defensiveness and resistance
  • Team stops sharing information openly

Real Scenario:

Bad: You join Aperia Solutions and in your first team meeting say: “I looked at the code over the weekend. We need to refactor the port workflow module—it’s not following clean architecture principles. I’ve built systems like this before, and this approach won’t scale.”

Impact: The team shuts down. They stop explaining context. They think “this person doesn’t understand our constraints” or “they’re just here to criticize our work.”

Good: You spend the first week asking: “Tell me about the port workflow implementation. What drove this design? What constraints were you working with? What would you change if you could?”

Then in week 2: “Based on what I learned about our timeline pressure last year and the evolving requirements, I see why the architecture evolved this way. Now that we have some breathing room, I’d love to explore refactoring the workflow module together. Here’s what I’m thinking and why, but I want your input…”

Impact: Team feels heard. They’re open to improvement because you’ve demonstrated respect for their context.

Mistake 2: Over-Promising to Build Quick Rapport ​

What It Looks Like:

  • “I’ll get you more headcount”
  • “I’ll fix the organizational chaos”
  • “I’ll shield you from all the BS”
  • “We’ll definitely get that performance bonus approved”

Why It Destroys Trust:

  • You can’t control these outcomes
  • When you fail to deliver, trust evaporates
  • Team learns your words don’t mean anything
  • Creates cynicism about leadership

Real Scenario:

Bad: In your first 1:1 with a frustrated engineer: “I hear you about the tech debt slowing you down. I’m going to get us 3 months to just clean up the codebase. No new features, just improvement.”

Reality: You don’t have authority to make that call. Leadership wants features shipped. When you can’t deliver, the engineer thinks you either lied or you’re ineffective.

Good: “I hear you about the tech debt. Let me understand the specific pain points. I can’t promise 3 months of pure refactoring—that’s not my call alone—but I can advocate for incremental improvement and help prioritize the highest-impact debt. What would make the biggest difference?”

Impact: You’ve set realistic expectations. When you do secure time for refactoring (even if less than requested), it’s a win, not a broken promise.

Mistake 3: Staying Too Distant or Too Friendly ​

What It Looks Like:

Too Distant:

  • Only communicating in formal team meetings
  • Never having informal conversations
  • Showing no interest in people as humans
  • Being purely transactional

Too Friendly:

  • Trying to be “one of the team” and abdicating authority
  • Sharing too much personal information too quickly
  • Avoiding necessary hard conversations to maintain likeability
  • Making decisions based on friendship rather than merit

Why It Destroys Trust:

Too Distant: Team thinks you don’t care about them. They hesitate to bring up problems. They don’t feel psychological safety.

Too Friendly: Team doesn’t respect your authority. Hard decisions look like favoritism. You can’t give honest feedback without it feeling personal.

The Right Balance:

You’re friendly and approachable, but not trying to be their peer. You care about them as people and understand their context, but you maintain the authority to make hard calls when needed.

Real Scenario:

Too Distant: You only interact with the team in weekly status meetings. You never ask about their weekend, their career goals, or how they’re doing. When someone has a personal issue affecting their work, they don’t feel comfortable telling you.

Too Friendly: You regularly hang out socially with 2-3 team members. When you need to give one of them constructive feedback about code quality, they’re shocked because “we’re friends, why are you being critical?” When you assign a high-visibility project to one of them, others suspect favoritism.

Right Balance: You have regular 1:1s where you ask about career goals and challenges. You’re warm and approachable. You remember details about people’s lives. But you’re also clear: “My job is to help you grow and make sure the team succeeds. Sometimes that means having hard conversations, and that’s separate from me respecting you as a person and engineer.”

Mistake 4: Inconsistent Decision-Making ​

What It Looks Like:

  • Monday: “We need to prioritize code quality”
  • Wednesday: “Why isn’t this feature done yet? Just ship it”
  • Different standards for different people
  • Changing direction without explanation
  • Making exceptions to your own rules

Why It Destroys Trust:

  • Team can’t predict your behavior
  • They don’t know what you actually value
  • Creates cynicism and gaming behavior
  • Undermines any stated principles

Real Scenario:

Bad: Week 1: In team meeting you say “All code needs comprehensive tests before merge. No exceptions.”

Week 2: A deadline is tight, and you tell someone “Just skip the tests for now, we’ll add them later.”

Week 3: You block someone else’s PR for missing tests.

Impact: Team learns your rules don’t actually matter. They think you play favorites. They don’t know what you really expect.

Good: Week 1: “High code coverage is critical for platform stability. Our target is 80%+. If we’re in a situation where that’s not feasible, we need to explicitly discuss the tradeoff and document it.”

Week 2: Deadline pressure hits. In team meeting: “We have a delivery deadline conflict with our testing standard. Here are our options: (1) Push the deadline 2 days to maintain coverage, (2) Ship with lower coverage but create tickets to backfill, (3) Reduce scope. I’m leaning toward option 1, but I want your input because you understand the technical risk better…”

Impact: You’ve maintained consistency (quality matters), shown transparency (explaining the conflict), and involved the team (respecting their expertise). Even if you make an exception, it’s an explicit, explained decision, not arbitrary.

Mistake 5: Hoarding Information ​

What It Looks Like:

  • Not sharing organizational context
  • Keeping leadership discussions private
  • Making decisions without explaining rationale
  • “You don’t need to know that”
  • Filtering information asymmetrically (telling some people, not others)

Why It Destroys Trust:

  • Team feels like you’re hiding things
  • They can’t make informed decisions
  • Creates impression of political maneuvering
  • Team assumes the worst about hidden information

Real Scenario:

Bad: Leadership tells you there might be layoffs in 6 months. You don’t tell the team. When layoffs happen, team is shocked and angry: “Did you know about this?” Either you lie (“No”) and they distrust you, or you admit it (“Yes”) and they’re furious you didn’t warn them.

Good: Leadership tells you there might be layoffs. You push back: “I need to tell my team. I can’t lie to them, and hiding this will destroy trust when it happens.”

Leadership says you can’t. You respond: “Then I need to share what I can transparently: ‘The company is evaluating options during this business challenge. I don’t have complete information yet, but I’ll share what I can when I can. In the meantime, keep doing great work—that’s always the best protection.’”

Impact: You’ve been as transparent as possible within constraints. When information becomes clearer, you share it. Team trusts you’re telling them what you can.

In Distributed Teams:

This is even more critical. When some team members are in meetings and others aren’t (due to time zones), you must proactively share information asynchronously. Don’t let information asymmetry create an “inner circle” and “outer circle.”

Example: After a leadership meeting at 9am US time (10pm Vietnam time), don’t just rely on Vietnam team members to “catch up later.” Post a summary in Slack: “Today’s leadership meeting covered X, Y, Z. Here are the decisions and context. Questions welcome.”

4. Real Scenarios: Good vs. Bad ​

Scenario 1: Inheriting Technical Debt ​

Context: You join as Technical Lead on an existing platform with significant tech debt. The team is defensive about the state of the code.

Bad Approach: “I reviewed the codebase. There’s a lot of technical debt here—duplicated code, poor separation of concerns, no tests in some modules. We need to stop feature work and spend a month cleaning this up.”

Why It’s Bad:

  • Implies the team did bad work
  • Doesn’t acknowledge business constraints that led to debt
  • Proposes unrealistic solution (full stop on features)
  • Team becomes defensive and resentful

Good Approach: “I spent time in the codebase this week. I can see the team has delivered a lot of value under tight timelines. I also see some areas that are making changes slower now—the X module has duplication, Y module needs test coverage, Z module has tight coupling. This is typical for any platform that’s evolved under pressure.

I’d like to work with you to understand which debt is causing the most pain and address it incrementally. What’s slowing you down most right now? Let’s tackle that first while we continue delivering features. I’m not interested in a big-bang refactor—I want sustainable improvements that make your lives easier.”

Why It’s Good:

  • Acknowledges business reality
  • Respects the team’s past work
  • Proposes collaborative approach
  • Focuses on team’s pain points, not your judgment

Follow-Up Actions:

  • Schedule a tech debt brainstorm session
  • Ask team to rate pain points by impact
  • Propose incremental approach: “Let’s dedicate 20% of each sprint to improvement”
  • Track progress and celebrate wins

Scenario 2: Making an Unpopular Technical Decision ​

Context: You need to choose between continuing with Azure Functions or migrating to containerized microservices. The team has mixed opinions, and some have invested heavily in the Functions approach.

Bad Approach: In team meeting: “I’ve decided we’re migrating to containers. Azure Functions won’t scale for our needs. Start planning the migration.”

Why It’s Bad:

  • No explanation of tradeoffs
  • Team doesn’t understand reasoning
  • People who invested in Functions feel their work was wasted
  • Creates resentment and resistance

Good Approach:

Step 1: Transparent Analysis (Before Decision) Share a written analysis:

Decision: Azure Functions vs. Containerized Microservices

Context: Our port workflow orchestration is growing complex, and we're hitting Azure Functions limitations around state management and coordination.

Options:
1. Continue with Azure Functions + Durable Functions for orchestration
2. Migrate to containerized microservices on Kubernetes
3. Hybrid: Keep simple workflows in Functions, move complex orchestration to containers

Evaluation Criteria: Development velocity, operational complexity, cost, team expertise, scalability

My Initial Analysis:
[Detailed comparison with pros/cons of each]

I'm leaning toward Option 2, but I want your input:
- What am I missing in this analysis?
- What technical risks do you see?
- What organizational factors should I consider?

Step 2: Gather Feedback Run a meeting to discuss. Listen to concerns. Adjust analysis based on team input.

Step 3: Make & Communicate Decision

Decision: Migrating to Containerized Microservices

After discussion and incorporating your feedback, here's my decision and reasoning:

Why containers:
- Our orchestration complexity exceeds what Durable Functions handles well
- Team has K8s experience from previous projects
- Gives us flexibility for future growth
- Better local development experience

What I heard from you that shaped this:
- Concerns about operational complexity → We'll phase this migration, starting with new services
- Investment in existing Functions → We'll keep simple workflows in Functions where they work well
- Learning curve for team members new to K8s → We'll run internal training sessions

Tradeoffs I'm accepting:
- More operational overhead (but we have infra team support)
- Migration cost in the short term (but better long-term velocity)

Next steps:
- I'll create detailed migration plan
- We'll start with one new service as a pilot
- You'll all review the plan before we commit

Why It’s Good:

  • Team understands the full context
  • Their input shaped the decision
  • Acknowledges tradeoffs honestly
  • Creates buy-in even from those who disagree

Scenario 3: Handling a Performance Issue in Production ​

Context: A performance issue hits production. A team member’s code is the root cause. The team is watching how you handle it.

Bad Approach: In team Slack: “@An, the performance issue in production is caused by your query in the reporting module. This should have been caught in code review. Why wasn’t this load tested?”

Why It’s Bad:

  • Public blame
  • Focuses on the person, not the process
  • Creates fear and defensiveness
  • Team learns to hide mistakes

Good Approach:

Immediate Response (Public): In team Slack: “We have a production performance issue in the reporting module. I’m working with An to diagnose. Will update when we have more information.”

Private 1:1 with An: “Let’s figure out what happened and fix it. Walk me through your implementation and what you tested.”

[An explains]

“Okay, I see the issue. The query makes sense for small datasets, but at production scale, it’s scanning too much data. This is a common trap—our staging environment doesn’t have production data volume. Let’s fix it together.”

Root Cause Analysis (Public): After incident is resolved, team Slack: “Post-mortem on yesterday’s reporting performance issue:

Root cause: Query was optimized for small datasets but scanned full table at production scale.

Why it wasn’t caught:

  • Staging environment doesn’t have production data volume
  • Load testing wasn’t part of our standard PR checklist
  • Code review focused on logic, not performance characteristics

Fixes implemented:

  • Added index to improve query performance (deployed)
  • Created representative dataset in staging (in progress)
  • Added performance testing checklist to PR template (done)

Good catch by monitoring team for alerting quickly. An responded fast to help diagnose and fix.

Learning: This is a process gap, not an individual mistake. We’ll prevent this class of issue going forward.”

Why It’s Good:

  • Focuses on system improvement, not blame
  • An doesn’t feel thrown under the bus
  • Team learns psychological safety (it’s safe to make mistakes if you fix them)
  • Creates better processes to prevent future issues

Signal to Team: When things break, we fix the system, not blame people. This builds trust that they can take reasonable risks and be honest about problems.

Scenario 4: Managing Cross-Team Coordination Challenges ​

Context: You’re at CoverGo, coordinating across domain teams for reporting integration. One domain team is consistently late with their API changes, blocking your team’s progress.

Bad Approach: In cross-team meeting: “We’re blocked again because the Claims team hasn’t delivered the API we need. This is the third time this month. We can’t hit our deadlines if you don’t deliver on time.”

Why It’s Bad:

  • Public blame of another team
  • Assumes bad intent or incompetence
  • Creates adversarial relationship
  • Doesn’t solve the underlying coordination problem

Good Approach:

Step 1: Private Conversation with Claims Team Lead “I want to understand what’s happening with the API delivery. We’ve had a few delays and I want to make sure I understand your constraints. What’s making this difficult?”

[Claims Lead explains: Their team is understaffed, they have conflicting priorities, they didn’t realize reporting was on critical path]

Step 2: Joint Problem Solving “Thanks for the context. Here’s what I’m thinking:

  • Can we get the reporting integration on your team’s priority list? I can escalate to leadership if needed.
  • Would it help if my team created the API stubs and you reviewed/approved them?
  • Should we schedule weekly sync to catch issues earlier?

I want to make this easier for both our teams, not harder.”

Step 3: Escalate Appropriately If private conversation doesn’t resolve it, escalate to leadership with joint proposal: “The Claims and Reporting teams have a coordination challenge around API integration. We’ve discussed and propose:

  • Dedicated Claims team capacity for reporting integration
  • Joint planning sessions to align priorities
  • Clear API contract defined upfront

This will unblock us and reduce rework for Claims team.”

Why It’s Good:

  • Assumes good intent
  • Seeks to understand constraints
  • Proposes collaborative solutions
  • Escalates with solutions, not complaints
  • Builds cross-team trust

Signal to Your Team: “I’m working with the Claims team to solve our coordination challenges. They have real constraints, and we’re figuring out the best path forward together.”

Your team learns: You solve problems constructively, not by blaming others. This builds confidence in your leadership.

Scenario 5: Receiving Pushback on Your Technical Decision ​

Context: You’ve decided to implement event-driven architecture for the port management workflows. A senior engineer disagrees and pushes back strongly in a design review.

Bad Approach: “I’ve been doing this for 15 years. I’ve built event-driven systems at scale. I know what I’m doing. This is the approach we’re taking.”

Why It’s Bad:

  • Shuts down discussion
  • Relies on authority, not reasoning
  • Senior engineer feels disrespected
  • Team learns not to challenge your decisions

Good Approach: “That’s a fair concern. Walk me through your reasoning. What risks do you see with event-driven architecture here?”

[Senior engineer explains: Worried about debugging complexity, team inexperience with event sourcing, operational overhead]

“Those are legitimate concerns. Let me think about this more carefully:

Debugging complexity: You’re right that distributed tracing is harder. We’d need to invest in proper observability. Is that your main concern, or are there other aspects?

Team inexperience: Good point. Not everyone has built event-driven systems. We’d need training and mentorship built into the plan.

Operational overhead: Event infrastructure does add complexity. The question is whether it’s worth it for the benefits.

Let me revisit the decision with these factors weighted more heavily. Can you help me think through alternatives? What if we:

  • Started with a simpler choreography pattern instead of full event sourcing
  • Built one workflow event-driven as a pilot to assess team learning curve
  • Kept synchronous where the overhead doesn’t justify the benefits

I want to make sure we’re making the right call here, not just the call I’m comfortable with.”

Why It’s Good:

  • Treats pushback as valuable information
  • Demonstrates intellectual humility
  • Makes senior engineer feel heard and respected
  • Models healthy decision-making for whole team

Follow-Up: After discussion, you might:

  • Adjust the decision based on feedback
  • Keep original decision but document the concerns and mitigations
  • Run a proof-of-concept to validate approach

Either way, communicate transparently: “After our discussion and considering the concerns, here’s my updated thinking and why…”

Signal to Team: You’re confident but not dogmatic. You listen to strong reasoning. This builds massive trust with senior engineers.

5. Practice Exercises ​

Exercise 1: The First Week Audit ​

Goal: Develop your listening and observation skills for building trust quickly.

Setup: Imagine you’re joining a new team next week. Before you start, prepare your “first week trust-building protocol.”

Tasks:

  1. Write 10 open-ended questions you’ll ask in initial 1:1s
  • Focus on understanding, not judging
  • Mix technical and cultural questions
  • Include questions about frustrations and hopes
  1. Create a “day 1 listening log” template
  • What patterns am I seeing?
  • What strengths does this team have?
  • What pain points keep coming up?
  • What assumptions do I need to test?
  1. Draft your “end of week 1” message to the team
  • What have I learned?
  • What do I appreciate about the team?
  • What am I still learning?
  • What are my next steps?

Self-Assessment:

  • Do my questions assume I have the answers, or am I genuinely curious?
  • Am I listening to understand, or listening to fix?
  • Is my end-of-week message about me, or about the team?

Exercise 2: The Decision Communication Template ​

Goal: Practice transparent decision-making that builds trust.

Setup: Think of a technical decision you’ve made in the past or will make soon (architecture choice, technology selection, process change).

Tasks: Create a decision document with these sections:

  1. Context
  • What problem are we solving?
  • Why does this matter now?
  • What constraints are we working within?
  1. Options Considered
  • At least 3 options (including “do nothing”)
  • Honest pros/cons of each
  • Evaluation criteria
  1. Decision & Rationale
  • What we’re doing
  • Why this option given our constraints
  • What this enables us to do
  1. Tradeoffs
  • What we’re giving up
  • What risks we’re accepting
  • How we’ll mitigate
  1. What I Need from You
  • Specific feedback requested
  • Ways team can contribute
  • Timeline for input

Self-Assessment:

  • Is this decision document defensive (proving I’m right) or transparent (showing my thinking)?
  • Have I acknowledged legitimate concerns?
  • Am I asking for genuine input, or just announcing?
  • Would someone who disagrees feel heard in this document?

Practice:

  • Share this with a trusted peer and ask: “Would you trust a leader who communicated this way?”
  • Iterate based on feedback

Exercise 3: The Vulnerability Script ​

Goal: Practice authentic vulnerability that builds intimacy without undermining authority.

Setup: Write scripts for these vulnerability moments:

Scenario A: Admitting a Knowledge Gap You’re joining a new domain (healthcare/fintech/edutech) and don’t understand a critical business concept.

Bad script: “I don’t know what that is.”

Good script: [Your version - what do you say?]

Scenario B: Acknowledging a Mistake You pushed for a technical approach that turned out to be wrong.

Bad script: “Well, we couldn’t have known that would happen.”

Good script: [Your version - what do you say?]

Scenario C: Sharing Strategic Uncertainty Leadership is asking for a timeline you’re not confident in.

Bad script: “Sure, we can do that in 2 weeks.” (over-promising)

Good script: [Your version - what do you say?]

Self-Assessment:

  • Does my script maintain authority while being vulnerable?
  • Am I taking appropriate accountability?
  • Am I sharing uncertainty in a way that builds trust, not anxiety?

Practice:

  • Role-play these with a peer
  • Notice your discomfort—vulnerability should feel slightly uncomfortable
  • Adjust until it feels authentic, not performative

Exercise 4: The Feedback Simulation ​

Goal: Practice giving feedback in trust-building ways.

Setup: Write feedback for these situations:

Situation 1: Code Quality Issue A team member consistently delivers working code that’s hard to maintain (poor naming, no tests, tight coupling).

Task: Write the conversation script

  • How do you open the conversation?
  • How do you describe the issue without attacking the person?
  • How do you collaborate on improvement?
  • How do you follow up?

Situation 2: Delivery Commitment Miss An engineer committed to delivering a feature by Friday. It’s Thursday and they haven’t started.

Task: Write the conversation script

  • What assumptions do you avoid making?
  • What questions do you ask first?
  • How do you address the broken commitment?
  • How do you prevent this pattern?

Self-Assessment:

  • Am I curious or accusatory?
  • Do I focus on behavior or character?
  • Do I collaborate on solutions or dictate?
  • Would this conversation build or damage trust?

Practice:

  • Role-play with a peer
  • Pay attention to your tone and word choice
  • Iterate until the feedback feels constructive, not punitive

Exercise 5: The Distributed Team Equity Audit ​

Goal: Ensure you’re building trust equitably across time zones and locations.

Setup: Review your last month of team interactions.

Tasks: Create a spreadsheet tracking:

  1. Communication Distribution
  • Who do I have 1:1s with most frequently?
  • Who am I responding to fastest in Slack/email?
  • Who gets included in ad-hoc decisions?
  • Who presents in team meetings?
  1. Visibility Distribution
  • Who gets credit in leadership meetings?
  • Who gets high-visibility project assignments?
  • Who do I mention positively in public channels?
  1. Time Zone Analysis
  • Are my meeting times fair across zones?
  • Do I share information asynchronously so everyone has access?
  • Do I over-rely on synchronous communication with my local team?
  1. Access Distribution
  • Who has access to me for quick questions?
  • Who feels comfortable disagreeing with me?
  • Who brings me problems early vs. hiding them?

Self-Assessment:

  • Are there patterns of inequity?
  • Am I building stronger trust with some team members than others?
  • Is geography/time zone creating an inadvertent inner circle?

Corrective Actions:

  • If you’re under-investing in relationships with remote team members, schedule intentional 1:1s
  • If you’re not sharing information asynchronously, create better documentation practices
  • If certain team members get more visibility, actively create opportunities for others

Exercise 6: The Consistency Tracker ​

Goal: Build self-awareness about your reliability and follow-through.

Setup: For the next month, keep a personal log of commitments and follow-through.

Structure:

Each week, document:

Commitments Made

DateTo WhomWhat I PromisedDeadlineStatus
2/1TeamReview arch doc2/3✅
2/1MinhUnblock API spec2/2✅
2/2Sarah1:1 rescheduled2/5❌ (forgot)

Patterns

  • What commitments do I consistently keep?
  • What commitments do I break?
  • Why? (Overcommitting? Poor prioritization? External factors?)

Impact Analysis

  • When I break a commitment, how do I handle it?
  • Do I proactively communicate delays?
  • Do I explain the context?
  • Do I make amends?

Self-Assessment Questions:

  • If I were on my team, would I trust my follow-through?
  • What patterns do I need to change?
  • Am I over-committing to seem helpful?
  • Am I under-communicating when things slip?

Corrective Actions:

  • Set up systems to track commitments (personal Kanban, reminder system)
  • Practice saying “let me check my capacity” instead of reflexive “yes”
  • When you must break a commitment, communicate proactively before the deadline

6. Key Takeaways ​

The Fundamentals ​

  1. Trust is Earned Through Consistency, Not Declared
  • You can’t announce your way into trust
  • Small, repeated actions build credibility
  • The first 90 days set the pattern permanently
  1. Technical Credibility is Necessary but Not Sufficient
  • You need technical chops to earn initial respect
  • But trust comes from how you use that credibility
  • The best technical leaders amplify others, not themselves
  1. Vulnerability Builds Intimacy
  • Admitting what you don’t know demonstrates security
  • Acknowledging mistakes creates psychological safety
  • Sharing uncertainty invites collaboration
  • But vulnerability must maintain authority
  1. Transparency is the Default
  • Share your reasoning, not just your conclusions
  • Explain tradeoffs and constraints
  • Make decision-making visible
  • Information hoarding destroys trust
  1. Reliability is Visible
  • Keep commitments or communicate delays proactively
  • Create predictable rhythms
  • Follow through on small things to build trust for big things

For Distributed Teams ​

  1. Trust Doesn’t Scale Through Osmosis Remotely
  • You can’t rely on hallway conversations
  • Explicit communication matters more than face-to-face
  • Asynchronous transparency prevents information asymmetry
  • Time zones require intentional equity
  1. Public Credit, Private Criticism
  • Amplify team members’ contributions visibly
  • Handle mistakes privately and constructively
  • Use failures to improve systems, not blame people

For Technical Leaders ​

  1. Respect the Code Before You Change It
  • Existing architecture exists for reasons
  • Understanding context before suggesting improvements shows respect
  • “Here’s what I’d do differently” without “here’s why you did it this way” is destructive
  1. Make Decisions Transparently, Not Unilaterally
  • Share your thinking process
  • Invite feedback, especially from those who disagree
  • Separate ego from decision-making
  • Treat pushback as valuable information
  1. Early Wins Build Momentum for Hard Changes
  • Quick, visible improvements create goodwill
  • Demonstrate competence through action, not promises
  • Use early wins to fund trust for difficult decisions later

The Long Game ​

  1. Trust Compounds
  • The first time you follow through, people are surprised
  • The tenth time, they expect it
  • The hundredth time, they advocate for you
  • Consistency over time creates exponential returns
  1. Trust is Fragile
  • Years of trust can be destroyed by one major betrayal
  • Broken commitments, hidden information, or public blame erode trust quickly
  • Repair is possible but requires explicit acknowledgment and changed behavior
  1. Trust Enables Everything Else
  • Technical decisions are accepted faster
  • Feedback is received constructively
  • Team performs better under pressure
  • Difficult conversations are productive
  • Innovation happens because people feel safe

Daily Practices ​

What to Do:

  • ✅ Listen more than you speak in the first month
  • ✅ Ask questions before making judgments
  • ✅ Acknowledge constraints that led to current state
  • ✅ Follow through on small commitments
  • ✅ Share credit publicly and specifically
  • ✅ Admit when you don’t know something
  • ✅ Explain your reasoning when making decisions
  • ✅ Treat pushback as information, not defiance
  • ✅ Communicate proactively, especially when things go wrong
  • ✅ Show up consistently for your team

What to Avoid:

  • ❌ Making big changes in your first week
  • ❌ Criticizing existing work without understanding context
  • ❌ Over-promising to build quick rapport
  • ❌ Hoarding information or creating information asymmetry
  • ❌ Blaming people instead of fixing systems
  • ❌ Making exceptions to your own rules
  • ❌ Being distant and purely transactional
  • ❌ Changing direction without explanation
  • ❌ Relying on authority instead of reasoning

Remember ​

Trust is not about being liked. It’s about being reliable, competent, and genuinely focused on the team’s success. You can make hard decisions, give tough feedback, and push for high standards—all while building trust—if you do it transparently, consistently, and with the team’s best interests in mind.

Trust is not about being perfect. You will make mistakes. You will break commitments sometimes. You will make decisions that turn out wrong. What matters is how you handle those moments—with honesty, accountability, and a focus on learning and improving.

Trust is the foundation for everything else you want to accomplish as a leader. Without it, your best technical ideas will face resistance. With it, you can navigate the hardest challenges, drive meaningful change, and build a team that performs at its highest level.

Build trust through your actions, one day at a time. The investment compounds.

  1. Before Your Next Team Interaction:
  • Review the “First Week Listen-and-Learn Protocol”
  • Prepare your initial 1:1 questions
  • Create your commitment tracking system
  1. This Week:
  • Audit your recent team communications for consistency
  • Identify one area where you can be more transparent
  • Schedule 1:1s with team members you interact with least
  1. This Month:
  • Implement the Decision Log framework for your next significant decision
  • Practice vulnerability in a low-stakes situation
  • Review your distributed team equity patterns
  1. Ongoing:
  • Track commitments and follow-through weekly
  • Reflect on trust signals from team (do they bring problems early? challenge your ideas? share credit with each other?)
  • Adjust your approach based on team dynamics and feedback

Trust building is not a destination—it’s a continuous practice that requires intention, self-awareness, and genuine commitment to your team’s success. Use this guide as a reference, but adapt it to your context, your team, and your authentic leadership style.

The goal is not to perform trust-building behaviors, but to internalize the principles so they become how you naturally lead.

Interview Practice: Building Trust with a New Team ​

Q1: "How do you approach your first 30-90 days as a technical leader with a new team?" ​

Why interviewers ask this They want to see if you have a deliberate, structured approach to onboarding as a leader — not just as an individual contributor. This reveals whether you understand that leadership transitions require different behaviors than engineering transitions.

Sample Answer

My first priority in a new team is to listen before I lead. I spend the first two weeks in observation mode — one-on-ones with every team member, attending standups without driving them, reviewing code and architecture docs, and asking questions more than making statements. The goal is to understand what's working, what's frustrating the team, and what's been tried before. I explicitly avoid making changes in the first 30 days, because changes made without context often solve the wrong problems. Around day 30, I start to form a point of view. I share it transparently: "Here's what I've observed, here's what I think we should improve, and here's what I think is working well." By day 90, I'm making decisions with the context to back them up. The teams I've seen damaged by new leaders are almost always damaged by someone who acted too fast — before they'd earned enough trust to have their judgment trusted.

Q2: "How do you build credibility with a team that has deeper domain expertise than you in certain areas?" ​

Why interviewers ask this This tests intellectual humility and your ability to lead people who know more than you in specific domains — a common reality for technical leads and principals. They want to see if you try to fake expertise or leverage it.

Sample Answer

I make it explicit early: "You know this domain better than I do, and I expect to learn from you." That's not a weakness statement — it's accurate, and engineers respect accuracy. My credibility doesn't come from being the best at everything; it comes from decision-making, context-setting, and creating conditions for the team to do great work. What I do bring to the table is cross-domain perspective, systems thinking, and the ability to translate between technical reality and business constraints. Where the team has deeper expertise, I ask questions and listen carefully. When I need to make a call, I'm explicit about what I know and what I'm inferring: "I'm less certain about the specifics of your domain here — my read based on the data is X, but I want your view before I decide." Teams respond very well to that honesty. What erodes credibility fast is pretending to know things you don't.

Q3: "Describe a time you had to build trust with a team that was skeptical of you or resistant to your leadership." ​

Why interviewers ask this Almost every leadership transition involves some skepticism. Interviewers want to see how you navigate that — whether you try to assert authority or whether you invest in the relationship patiently and consistently.

Sample Answer

I took over a team that had just gone through a painful reorg — two engineers had left, delivery had been rough, and there was real cynicism about management. The first thing I did was not try to motivate them with enthusiasm. I acknowledged the situation directly: "I've read the retros. I understand this has been a hard six months. I'm not here to tell you everything's fine — I'm here to understand what happened and make it better." I then focused entirely on removing friction from their immediate work — clearing a backlog of unresolved blockers, advocating for them in sprint planning, and delivering on small commitments consistently. By month two, the team started bringing me problems before they escalated. Trust wasn't declared — it was built incrementally through follow-through. The principle I operate by: never promise what you can't deliver, and always deliver what you promise. That compounding consistency is the foundation.

Q4: "How do you build trust with engineers on a distributed or remote team where you rarely meet in person?" ​

Why interviewers ask this Remote trust-building requires different strategies than co-located teams, and interviewers want to know if you've thought about this systematically — especially important for distributed engineering organizations.

Sample Answer

In distributed teams, the biggest trust risks are visibility inequity and asynchronous misunderstanding. I address the first by deliberately amplifying quieter voices — if someone in a different timezone contributes something valuable asynchronously, I call it out explicitly in the team channel. I try to make sure contribution is visible regardless of when or where it happens. For asynchronous misunderstanding, I over-invest in written context. When I make decisions, I document the reasoning clearly — not just what I decided but why, what I rejected, and what I'm uncertain about. This gives remote team members the context they need to understand and trust the decision even if they weren't in the room. On a personal level, I block time for informal conversation — not every one-on-one needs an agenda. Sometimes just checking in on someone's work, asking what's interesting them, builds more trust than any formal process.

Q5: "How do you balance showing vulnerability as a leader without undermining your credibility?" ​

Why interviewers ask this Vulnerability is a leadership skill, but done wrong it feels like incompetence. Interviewers want to see if you understand the distinction — appropriate openness that builds trust versus oversharing that creates anxiety.

Sample Answer

There's a meaningful difference between process vulnerability and outcome uncertainty. Sharing that I'm still learning an area, that I made a call I'd make differently in hindsight, or that I don't have all the information I'd want — that builds trust. It signals that I'm honest and self-aware. What doesn't work is expressing doubt about the team's ability to succeed, or sharing concerns that create fear without creating direction. I had a moment early in a migration project where I was genuinely unsure if we could hit the deadline. I didn't hide that from the team — I named it: "I want to be honest — I think this timeline is aggressive and I'm not certain we can hit it. Here's what I think we need to monitor closely, and here's what I'll do to protect the team if we need to renegotiate." That created confidence, not anxiety. The team knew I was watching the right things and would act on what I saw. Vulnerability lands well when it's paired with a plan.

Q6: "What's the biggest trust-damaging mistake you see new technical leaders make?" ​

Why interviewers ask this This question tests the depth of your leadership reflection. Strong candidates can articulate patterns across their experience — not just their own mistakes, but mistakes they've observed and learned from.

Sample Answer

The most common one is over-promising during the honeymoon period. A new leader wants to build excitement and buy-in, so they commit to things that feel reasonable in week one but turn out to be harder as reality sets in — headcount requests, architectural rewrites, process improvements that require cross-team buy-in. When those promises aren't delivered, the trust damage is severe and lasting. Engineers have long memories for commitments not kept. The second most common mistake is inconsistency — making decisions that feel arbitrary, changing positions without explaining why, or treating team members differently in similar situations. Inconsistency creates anxiety: people can't predict how I'll behave, so they stop trusting that they know what I stand for. The pattern I set in the first 90 days is the pattern I'll be held to. I try to be very deliberate about what I commit to, and even more deliberate about following through.

Q7: "How do you demonstrate technical credibility without micromanaging or coding everything yourself?" ​

Why interviewers ask this Technical leaders need to stay credible without becoming individual contributors again. This tests whether you can maintain technical authority through leadership behaviors rather than hands-on execution.

Sample Answer

I stay technically credible through depth of engagement, not breadth of execution. In code reviews, I ask specific, probing questions about trade-offs — not to catch errors but to understand the reasoning. In architecture discussions, I challenge assumptions and think through failure modes with the team. I read — new patterns, incident post-mortems, engineering blogs — so I can bring outside context to technical conversations. What I don't do is rewrite their code or solve the problem for them when they bring it to me. I ask questions that help them think through it: "What happens to this system under 10x load? What's the failure behavior if this dependency is slow?" That's how you stay technically relevant without becoming a bottleneck. It also builds autonomy in the team — they get better at asking themselves those questions, and they stop needing me to ask them.

Q8: "How do you handle a situation where an early trust-building action backfires?" ​

Why interviewers ask this Not every leadership action lands as intended. This tests whether you can recover gracefully when a trust-building attempt creates the opposite effect — which is a realistic scenario for new leaders.

Sample Answer

Early in a new role, I made what I thought was a transparency move — I shared a rough draft of my team roadmap in a broader team channel to get input before finalizing it. What I didn't anticipate was that engineers from other teams would interpret it as committed plans and start making dependencies on work that wasn't confirmed yet. It created confusion and some frustration in planning. I acknowledged the mistake directly in the same channel: "I created confusion by sharing a draft as if it were a plan — that was my error. Here's what's actually confirmed, here's what's still being evaluated." The recovery was quick because I owned it cleanly. The lesson was about audience and framing: transparency is good, but the context in which you share information shapes how it's received. The trust recovery after the acknowledgment was actually faster than I expected — people forgive mistakes more readily when they're named honestly.

Released under the MIT License.

Copyright © 2026 LCN