I once had a dev partner struggling to make good deliveries. After some time talking about the project, he opened up about feeling unable to speak freely in meetings, the pressure of being new, and the fear of being fired.

The solution: Create opportunities for him to talk in meetings and scheduled frequent 1:1s.

Care about your partners devs, designers, QAs.

If you’re a tech lead, do 1:1s to understand their struggles, project difficulties, and yeah, how they’re doing in life. You don’t need to know everything about them, but create a relationship where they can say when something doesn’t feel right.

Even being an IC (Individual Contributor), you can have 1:1s with your colleagues.

The Benefits Are Real:

You Create Authority

Your partners know more about you. You gain their confidence because now they know who to reach first when something happens—the person who’s easier to find and actually listens. Authority isn’t about titles. It’s about being the person people trust.

Improve Context

Each person knows more about a specific piece of the project. Understanding “who is who” makes you quicker to reach the correct person and absorb different knowledge about the project.

Context is everything. The person who understands the system and the people building it has superpowers.

Early Problem Detection

Problems rarely appear suddenly—they brew over time. Regular 1:1s help you spot issues before they become critical:

• Burnout signals
• Misaligned expectations
• Tech debt nobody’s talking about
• Team conflicts brewing under the surface

Real example: In one 1:1, a backend dev mentioned feeling “a bit overwhelmed” with the new architecture. Two weeks later, we discovered he’d been silently struggling for a month.

Early detection = early solution.

Build Psychological Safety

When people feel safe to share struggles, mistakes, and “stupid questions”, the whole team levels up. 1:1s are where you build that foundation.

Knowledge Transfer That Actually Works

Forget lengthy documentation nobody reads. 1:1s and workshops are where real knowledge transfer happens:

• “Why did we choose Postgres here?”
• “What’s the story behind this API endpoint?”
• “Who should I talk to about the payment flow?”

These conversations create knowledge that survives team changes.

Career Development (Yours and Theirs)

Even as an IC, helping others grow helps you grow:

• Practice leadership before becoming a lead
• Build reputation as someone who develops others
• Create a network of people who’ll vouch for you
• Learn communication skills that matter more than frameworks

Hot take: The best tech leads aren’t the best coders. They’re the best at making other people better.

---

How to Actually Do This:

For ICs:

Start Small:

• “Hey [colleague], want to grab coffee? I’d love to hear about how you approached [that feature].”
• Make it Regular: Weekly or bi-weekly. 30 minutes. Consistency beats intensity.

Questions to Ask:

• What’s the hardest part of what you’re working on?
• Is there anything blocking you that I might help with?
• What’s something you learned recently?
• How are you feeling about the project?

For Tech Leads:

Schedule it sacred:

Block time. Don’t cancel unless emergency. Your calendar reflects your priorities.

The First 1:1:

• Get to know them (background, interests, work style)
• Understand their goals (career, learning, life)
• Set expectations
• Ask: “What makes a good 1:1 for you?”

Here’re some example of questions and topics for a good 1:1:

• How are you? (genuinely)
• What’s top of mind?
• Project updates/blockers
• Growth opportunities
• Action items
• Review action items from last meeting

Red Flags:

• Avoiding eye contact
• Sudden drop in code quality
• Missing meetings
• Short, defensive answers
• Working excessive hours
• Isolation from team

Mistakes I Made: ❌ Making it a status update: 1:1s aren’t standups. Talk about the human stuff. ❌ Only doing it when there’s a problem: By then it’s too late. Build the relationship during calm times. ❌ Talking more than listening: Aim for 70% listening, 30% talking. ❌ Not taking notes: You will forget. Write it down. Follow up next time. Create action items so you have TRANSPARENCY on what needs to improve. ❌ Skipping the “how are you” part: Don’t jump straight to work. First 5 minutes set the tone.

Software is built by humans, not machines. Best codebases come from teams that communicate well, trust each other, and feel safe to fail. 1:1s aren’t “nice to have”, they’re infrastructure for high-performing teams.

You don’t need permission to start caring about your teammates.

Start small. Ask one colleague for coffee this week. See what happens.

Questions for you:

When was the last time you had a real conversation with a teammate beyond the current sprint? Who on your team might be struggling silently right now? What’s stopping you from scheduling that first 1:1?

Drop your thoughts if you have time to. I’m curious about your experiences with 1:1.

---

love more <3