Interpersonal Skills - Teamwork, Patience, and Empathy

Situation: Two engineers on my team had a conflict about ownership of a shared codebase component. Engineer A had been maintaining it for 18 months and felt a strong sense of ownership. Engineer B had been making changes to it as part of a new feature without coordinating, and had introduced a regression. The conversation between them had escalated into an email thread that had gone negative.

Task: As team lead, I needed to resolve the interpersonal conflict and create a structural answer to the ownership ambiguity that had caused it.

Action: I met with each person individually before bringing them together. My goal wasn't to hear "sides" — it was to understand what each person needed to feel effective and respected. Engineer A needed clarity that her expertise and institutional knowledge would be valued, not overridden. Engineer B needed to know he could make progress on his feature without being blocked by review delays on shared components.

What I learned from those conversations was that the conflict wasn't really about the specific regression — it was about a lack of clarity around who had decision authority over shared components. In the joint conversation, I reframed it: "This isn't about who was wrong. It's about a gap in how we handle shared ownership, and we're going to fix that together." I then facilitated an agreement: Engineer A would be the documented owner and approver for that component; Engineer B would bring a design doc before making structural changes; routine bug fixes could proceed with a lightweight review.

Result: The email thread ended. Over the following quarter, there were zero uncoordinated changes to the shared component. The structured ownership model was extended to three other shared components that had similar ambiguity.

Key takeaway: Most interpersonal conflicts at work are partially structural — they're fed by unclear ownership, competing priorities, or broken processes. Resolving the interpersonal piece without addressing the structural piece means the conflict will resurface.

Situation: I managed a junior developer who was technically capable but consistently struggled with estimating how long tasks would take. She would commit to timelines confidently in planning sessions and then consistently miss them — not by large margins, but reliably by 30–50%. After two sprints with the same pattern, I knew this needed a direct conversation rather than just managing around it.

Task: I needed to address the estimation problem without undermining her confidence, and I needed to understand whether the issue was skill, context, or something else.

Action: I opened the conversation by naming what I'd observed specifically — the pattern across two sprints, with examples — rather than a general statement about meeting deadlines. I then asked rather than told: "What's your experience been when you're estimating these tasks? What feels hard about it?" What emerged was illuminating: she was estimating based on how long the coding would take, not accounting for the review cycle, integration testing, and the debugging that almost always followed. Her estimates weren't reckless — they were structurally incomplete.

Rather than lecturing her on estimation, I walked through the last three tasks together and helped her reconstruct what the actual breakdown of time had been. Then I proposed a practice: for the next sprint, she'd break every estimate into coding, testing, review buffer, and contingency components, and we'd compare them to actuals at the end. I offered to review her estimates with her briefly at planning until she felt confident in the process.

Result: Her estimates improved significantly within two sprints. Four months later, she was helping onboard a newer team member and used the breakdown framework to teach estimation — a moment she told me had felt like a milestone for her.

What patience looks like professionally: It's not about tolerating underperformance indefinitely. It's about diagnosing the root cause, intervening at that level, and giving someone enough time to change with real support.

Situation: A team member — one of the most technically strong people on the team — started showing signs of disengagement: slower response times, shorter contributions in code review, and a general flatness in energy. It was a pattern change, not a single incident, and it happened gradually over about three weeks.

Task: As his team lead, I noticed the shift and felt it was worth addressing directly — not through a performance lens, but from genuine concern.

Action: I asked him for a one-on-one and opened it simply: "I've noticed you seem less engaged over the last few weeks, and I wanted to check in — not about performance, just about whether you're doing okay." That framing mattered. I wasn't there to counsel him or evaluate him; I was there to listen.

He told me his mother had been diagnosed with a serious illness two weeks earlier and he'd been trying to manage working remotely between hospital visits. He hadn't said anything because he didn't want it to affect how he was perceived at work.

I responded by acknowledging the weight of what he was carrying, without trying to fix it or minimize it. I then took two concrete steps: I worked with him to temporarily redistribute two of his project responsibilities to other team members so his sprint commitment was realistic given his situation, and I explicitly told him that taking the time he needed for his family was the right call and wouldn't be held against him. I also connected him to our company's employee assistance program, which he hadn't known offered mental health support.

Result: He thanked me in a follow-up message and said the redistribution and the conversation had made the next six weeks significantly more manageable. He remained on the team and returned to his full workload as his family situation stabilized. He later became one of the people who helped shape how we handled a similar situation for another team member.

What empathy requires: Noticing, naming it gently, and responding with practical support — not just acknowledgment.

Situation: We were in a particularly demanding sprint — tight deadline, a newly formed cross-functional team, and a product scope that had expanded in week two. Morale was low and communication had started fragmenting: people were working in silos, updates were sparse, and a few interpersonal tensions had surfaced.

Task: I wasn't the team lead on this project, but I could see the dynamic and I had enough relationships across the group to do something about it.

Action: I made a deliberate effort to be the connective tissue between the parts of the team that had stopped talking to each other. I started making brief check-in rounds with team members individually — not status checks, but genuine "how's it going?" conversations where I actually listened. Those conversations surfaced two pieces of information that the broader team hadn't shared: one engineer was blocked on a dependency she'd been too hesitant to escalate, and another had found a more efficient approach to a shared module that would save everyone time if he could share it. I organized a 30-minute informal sync that got that information in front of the whole team.

I also paid attention to tone in written communication — I found that when I modeled clear, non-defensive updates in our shared channel, others tended to follow. Interpersonal dynamics in teams are contagious in both directions.

Result: The sprint finished on schedule. In the retrospective, two team members cited the informal information-sharing session as a turning point. One colleague told me afterward that she appreciated the check-in conversations because she'd felt isolated for the first two weeks and hadn't known how to say so.

What interpersonal skills contribute to team success: It's less about individual likeability and more about reducing friction, surfacing information, and modeling the communication norms you want the team to have.

Situation: I led a team of five for 18 months that went through a significant period of change: two people left, two new people joined, a major project shifted priorities, and we operated remotely across three time zones. Maintaining a coherent, positive team culture under those conditions required deliberate effort.

Actions I took consistently:

Created structured space for honest communication. I ran a weekly 30-minute team retrospective that always included the same three questions: what's working, what's not, and what's one thing we should change this week. The questions were consistent so people knew what was expected. Over time, the team started raising real friction in that forum rather than letting it fester privately.

Addressed tension directly rather than letting it diffuse. When I noticed discomfort between team members, I addressed it directly and early — usually in a private conversation with each person, then a brief joint conversation if needed. Ignoring interpersonal friction doesn't make it go away; it makes it more expensive to resolve later.

Acknowledged people's specific contributions. Generic praise is quickly discounted. I made a habit of naming specific work in our team channel: "I want to call out how [Name] handled the client escalation on Tuesday — they stayed calm under pressure and found a resolution without needing to escalate it." This reinforced the behaviors I wanted to see and gave people visible recognition.

Modeled the norms I wanted the team to have. If I wanted people to acknowledge uncertainty, I modeled saying "I don't know yet." If I wanted people to surface problems early, I modeled doing it myself. Team culture is set more by what leaders do than by what they say.

Result: Both of the new team members told me in their 90-day reviews that the team culture was one of the reasons they felt set up to succeed quickly. One of them stayed for three years.