Coaching Your Team Through Interpersonal Conflicts

This week’s query is about conflict and complaining.

“As a manager, what should I do when one of my direct reports complains about the behavior of another teammate during a 1-1?”

If this hasn’t happened yet, it will. It’s so natural for humans to surface problems this way. Escalating conflict is engrained in us from a very young age, starting with our parents, then our teachers. Parents, teachers, and managers all share one common trait: formal authority. And part of the social contract is that people with formal authority are responsible for fixing our problems.

So it’s not surprising that as a manager, you likely hear a lot of complaints. Feedback is great, and listening is important as a manager. I always give some space during 1-1s for ranting, because I’d rather them bring frustrating issues to me so we can work through them together, versus having it simmer under the surface. But once the rant is done and the information is shared, what exactly are you supposed to do? Should you mediate, protect anonymity, or do nothing?

You’re not responsible for fixing every problem.

As a manager, you probably feel responsible for fixing your team’s problems so they can get their work done. Naturally, you’re going to go into solution mode if somebody surfaces an interpersonal conflict. You need to fight this urge and recognize that jumping in to help is actually preventing your team from developing conflict resolution skills and building trust and resiliency. Interpersonal means “between persons”. You are not one of those persons, so your job is to stay out of the conflict, and instead coach the involved parties to resolve it themselves.

Your direct report may have just wanted to rant and trusted you to provide space to blow off that steam. Before assuming that they want you to resolve it for them, it’s worth checking in with a question like “did you just need some space to get that off your chest, or do you need help with a solution?”

Teach conflict resolution skills

If the complaining is about behavior and not about business impact (i.e., “this person was a jerk to me”, and not “this person was careless and caused a service outage”), the first course of action is to refocus the conversation on what your direct report is going to do about it. “How did they respond when you shared this feedback with them?” is usually the first thing I ask.

If your direct report hasn’t had a direct conversation with the other person, that is the first step to take. Especially in software engineering, where great technical skills can cover up gaps in professional skills, it might be that your direct report has never had to give direct feedback before. They might have relied on managers to deliver feedback on their behalf. Breaking this cycle is your challenge.

A simple conversation framework

Equip your direct report with some conversation frameworks so they aren’t fumbling for words when they approach their teammate. Even better, practice or model the conversation with them.

One simple conversation framework has four steps: purpose, feedback, feedback, solutions.

• State your purpose, and let the other person know you have feedback to discuss

  • “I want to give you some feedback about the project we’re working on. Are you up for it?”

• Share your feedback, and be sure to include the impact it’s having on your team, or on your personally.

  • “When you started working on tickets that I said I would take, I felt like you didn’t listen to the plan the team made in sprint planning, or that you don’t trust me to work on a feature that you originally built.”

• Ask the other person to share their perspective. Listen to them and try to understand the cause of the problem.

  • “Okay, so from your point of view, I hadn’t added myself as the owner of the tickets, so you thought the plan wasn’t concrete.”

• Discuss potential solutions, and decide on a solution together.

  • “I’ll add myself to tickets I plan to work on, and you’ll check in before you start working on something without an owner, if we discussed it already in sprint planning.”

Coaching your team member to have a conversation like this will empower them to handle future situations independently. It also prevents you from becoming a mediator and problem solver, which is not a healthy place for a manager.

---

P.S. I’ve just launched a course called Hard Feedback. If you dread giving hard feedback, this course is for you.

Giving Better Code Review Feedback

Have you ever been met with an emotional reaction when you asked a logical question? This happens all the time in code reviews. They easily get personal, even when it’s about the code.

As a reviewer, it’s hard to see the history of constraints and tradeoffs the author is working with. What’s in the PR might be the 5th approach to solve the problem, because the first four tries led to dead ends. To the author, the points you raise for discussion can easily seem like you’re not understanding the constraints the person is dealing with, or simply that you think you know better. It’s a recipe for defensiveness and misunderstanding.

Fortunately, there are a couple ways that you can frame your PR comments so that your intention is clear, leading to more productive code reviews.

Check your mindset

It’s easy for your feedback to flow quickly from your head to your keyboard. Take a moment to think about your own mindset. Are you pissed off? Annoyed? Confused? That’s going to show up in your review. These reviews are open for the rest of your team to read, so think about how you want to show up.

Know if you’re seeking to understand, or seeking to correct

Get clear on the purpose of your comment before you press Send. Are you genuinely curious, just need more information, or need something to be fixed before it can be shipped? Not all review comments need a long back and forth. If you’re seeking to correct, be polite and clear. “Check our style guide here for details on how to organize routes.” If you need more information, make sure your questions are formulated in a way that gives the author space to explain, and doesn’t put them on the defensive from the start.

Some question formats are judgemental

“Why didn’t you use threads here?”

A question phrased like this puts the author on the defensive straight away. While your intent may be to understand why they chose one approach over the other, what you’re asking them to do is to defend their choice. Embedded in this question is a judgement — that you think threading would be a better solution, or even that you suspect the might not have considered the solution at all.

Try instead: “What other approaches did you consider?” or “Do you have some data about performance when doing this single vs. multi-threaded?” These assume that the author already considered threading, but chose a different approach for a good reason.

“But what about X?”

This easily translates to “I think you forgot about X.” Maybe that’s what you mean, and maybe that’s what happened. But if the author carefully considered X, but had to choose a different approach, your question can easily seem accusatory.

Try instead: “I’m curious what happens when X.” or “Coverage of X edge case isn’t obvious to me from the code. Can you explain?” If they forgot about it, they’ll likely come back with "good catch, thank you.” Same result in the end, but a more positive interaction.

Move to a different discussion format

For most of us, it takes longer to type than to speak. Sometimes the format of the discussion can get into our way. Adding to that is the fact that words are just one part of communicating. Body language, facial expressions, tone of voice — these all add meaning to what you’re saying. If you’re hitting a dead end when discussing in the PR review, or if the feedback is relatively complex, switch to a different format. Just make sure to take notes and share them in the PR so you have a record of the discussion. Your future self and your future team will thank you in 6 months when no one remembers the conversation anymore.

Are 1-1s a waste of time?

They shouldn’t be. But if they are, ask better questions, and make sure your team member is driving the agenda. It’s their time, not your time for a status update.

We all have meetings we dread each week. Maybe they’re boring, repetitive, or could have been an email. Some just feel like a waste of time. 1-1s can often start to feel like this, especially for your team members. Make sure you’re valuing their time by setting up your 1-1s intentionally.

Is your 1-1 just another status update?

1-1s are meant to be development conversations for your direct report. This is a time to talk about goals, feedback, and mid- or longer-term topics. This is not a status update meeting, so if you’re just going through projects and checking in, it’s going to feel like a drag for both of you. Find a better place to get status updates so your 1-1 time can be free for different kinds of conversations.

Is your direct report in control of the agenda?

A 1-1 is their time, not yours. You might have a couple items to share with them, like feedback, or making sure you’re aligned on important priorities and goals, but they should own the agenda. You need to be clear about this expectation, and be explicit. Do you want to keep a shared notes document? And is it okay for them to cancel the 1-1 if they have no topics?

Are you asking boring questions?

Boring questions get boring answers. Some questions close down conversation by leading your conversation partner to a certain answer (like yes or no questions). Here are a couple questions that can get you into discussion mode:

• How do you think that went?

• What will you do differently next time?

• What’s the consequence if we don’t do that?

• What other approaches have you tried?

Are you too worried about “productive” conversation?

Relationships take effort. You need to build trust and rapport with someone over time in order for your working relationship to withstand some trials and disagreements. Some of that trust will come from professional interactions, like being fair and always doing what you say you will. But the rest comes from ”human time,” or the more personal interactions that are more about relating as people than relating as professionals. Chatting about what you ate over the weekend, your favorite shows, your family, sports, travelling, past jobs — these are all worthwhile conversations to connect on a human level. Not everything needs to be tracked in Jira.

Should we use CODEOWNERS?

CODEOWNERS will probably create more problems than it solves. But, like all great questions, the answer is “it depends.”

I would classify the CODEOWNERS file itself (more about workflows later) as fairly lawful neutral. It’s meant to be a centralized place to give credit and ownership for chunks of the codebase. Having this paper trail can be helpful in onboarding, and even streamline the resolution of questions that come up during the course of development since you know who to ask.

Where CODEOWNERS dips into the unproductive is when the owners listed for each feature or file can block the PR. GitHub and GitLab both allow branch protection rules that require review from CODEOWNERS before a PR can be merged. Most teams that start using CODEOWNERS do so with the intention of using these features.

On a small team, this PR gatekeeping will mostly hurt the team. Minimally, it slows the team down, especially when the team is small enough to work out disagreements in architecture earlier in the development process. At its worst, it prevents the author of the code change from feeling real agency and ownership over the changes, which leads to lower quality. If your team works on a set of features with a lot of iteration, there will come a time when the new changes proposed are materially more important than the original design. Who owns it then? CODEOWNERS gets outdated quickly and turns into unnecessary overhead.

On bigger teams, a complex PR might touch files with multiple sets of CODEOWNERS. Now you’re stuck with a PR that needs half a dozen reviews before it can be shipped. And for people who are CODEOWNERS, it can be hard to determine where their reviews are needed or helpful, because they’re being automatically generated. In some ways, CODEOWNERS can punish highly productive engineers or the ones with the most tenure by flooding them with PR review requests.

What to do instead:

• Get clear on big changes before the work gets to a PR stage. Waiting to surface these until all the code is written is just too late.

• Get clear on what quality looks like. It’s not fair to only CODEOWNERS to be enforcing best practices or patterns.

• Find other ways for teams to stay notified about recent changes. PR review is often used as a knowledge sharing tool, but in reality, it’s not often very effective. Instead, find something that is more useful for your team, like live demos, sharing design docs, or an internal presentation.

• If regressions are a concern, look at your automated testing and CI processes. If it’s possible for a large regression to make it to prod without a perfectly careful review of a PR, you have some work to do when it comes to testing and monitoring.

• Want to a place to keep track of who worked on what? You probably already use Notion or another team wiki. That’s a great place to store info about release teams along with other documentation (user interviews, discovery docs, arch diagrams) that went into the feature.

Since the answer here is “it depends,” CODEOWNERS might be a good choice if you’re working on components that commonly receive PRs outside of the core team. This might be in OSS, where specific maintainers have been appointed, or in a large organization.

I really understand the human need for ownership. CODEOWNERS is an enticing way to both give recognition and assuage fears of something big changing without enough warning. Just make sure it’s not covering up other smells on your team, or creating unnecessary gatekeeping that robs people of agency.

20+ Career Development Goals for Software Engineers

For software engineers, it can be a struggle to set meaningful career development goals for themselves. With so many performance cycles starting at the beginning of the year, chances are that you or your team are trying to figure out some growth goals for the next quarter or year.

If you have a great career ladder, you can start there. But it’s still hard to turn that into something you can actually do in your job. These are often high level (by design) so it can be difficult to translate that into a tangible goal.

Here’s a framework that I use to categorize career development goals, and plenty of examples that you can use.

This is all based on 4 Ps of being a software engineer: People, Projects, Process, and Partnerships.

People

Want to show leadership, have influence over your team, and help others succeed? Some growth opportunities on the people side might be:

• Leading onboarding of a new employee

• Participating in interviews (or training others how to interview)

• Mentoring a junior engineer

• Volunteer to lead a brownbag session

• Share your learnings from a conference you attended

• Find a great training opportunity for your team

• Offload some of your knowledge to other employees so you can go do other stuff

Projects

These goals are all about getting stuff done and strengthening your execution skills, including your subject matter expertise.

• Attend a training or a workshop to deepen your own skills (just make sure that training relates back to a business priority).

• Lead a roadmap project or take ownership of a collection of projects (like security-related stuff, migrating to Typescript, or becoming the expert on a 3rd party API).

• This could also include things like choosing a vendor for an external pentest.

• Improve CI/CD build times

• Propose a stability/reliability project.

If you have a goal of paying down technical debt, here’s a guide on how to pitch the project.

Process

Just enough process helps teams move faster because people don’t have to try to figure out what to do next - they can just follow a set of standards, and everyone knows what to expect. You might consider:

• Leading the bug triage process

• Proposing a new way for marketing and sales to get informed about new releases

• Getting more involved in product discovery

• Running sprint ceremonies.

• Figuring out holiday on-call schedules

• Improving your post-mortem template

• Figuring out the right way to do architectural review before you start building.

Partnerships

You don’t work in a vacuum, and sometimes work that crosses department lines can be very visible, like working on sales/marketing enablement to prep for a big release. More visibility means more people seeing your great work, and a stronger argument for promotion or a comp bump. You can also consider

• Becoming a point person for another team that depends on your work, like customer support.

• On the product and design side, join customer calls or user research interviews.

• I also count community involvement here, so speaking at a meetup or conference, blogging more, or mentoring someone from the community.

---

Check out my course on Measuring Development Team Performance if you’re interested in setting goals to help your team have more impact.

Does my team need a Definition of Done?

You have one, even if it’s not written down. Writing it down can be a useful step to make sure that everyone has the same expectations, and to surface any points of misalignment early.

A Definition of Done is a set of criteria to define when work is finished. Very literally, it defines what needs to be finished in order to drag a ticket from In Progress to Finished.

Within your team, it describes the quality and completeness of work you expect from yourselves. When working with external teams - or contractors - it’s useful as a contract or interface between teams. It’s clear what’s the responsibility of your team, because it will be in the DoD.

DoD doesn’t always need to be synonymous with “shippable to prod”, but most times it is.

I use this very quick and dirty template as a starting point for defining DoD. It’s easy to remember. You’ve finished something: TADA! 🎉

T: Tests. Must have suitable automated test coverage (unit and integration) and pass any security scans and GitHub Checks.

A: Alerts. New code must be instrumented with alerts/monitoring so we know it's working as expected. If there are alerts that will trigger a PagerDuty incident, a runbook must be linked to the alert or incident type.

D: Documentation. Internal and external documentation must be completed.

A: Analytics. All new user behaviors need to be instrumented with analytics events so we can track how customers are using the feature.

You might want to augment this with other security requirements, linting, code review standards, etc.

Definition of Done has deep roots in agile and scrum, so there’s no shortage of resources or opinions on what it should or shouldn’t be. Here’s an example that gets more specific than my template above. Enjoy!

How do you actually measure MTTR?

First step? Figure out which MTTR you’re talking about.

MTTR usually stands for Mean Time To Recovery, or Mean Time To Restore. This is a metric that tracks how long it takes a defect or outage to be patched in customer-facing systems. It could also stand for Mean Time To Resolve (how long was that ticket open?) or Mean Time To Repair (how long did it take to perform a repair on the system?), so make sure to check what flavor of MTTR you’re reading about if you’re referencing something.

I’m going to use Mean Time To Recovery, as it’s most common and most relevant for software engineering teams.

At the very basic level, MTTR is a measurement of the average (mean) total time elapsed between when the defect impacts production and the time when that defect is repaired for all customers.

MTTR = downtime/number of incidents

The hard part here is figuring out what counts as downtime. In some cases, the clock will start running as soon as the offending PR is deployed to production. In other cases, you’ll want to pinpoint the time of “first failure,” or when the defect appears for a customer in prod for the first time. It’s okay to have a different internal definition for downtime than what is in your customer SLAs.

But to improve this metric, you’ll want to break things down a little more.

See if you can identify timestamps for each of these distinct phases:

• How long it takes from the release/first failure to when your team realizes something is wrong

• How long it takes your team to identify the what’s happening

• How long it takes your team to develop a fix

• How long it takes your team to write tests for the fix

• How long it takes to complete the PR/deployment process

• How long it takes for the change to propagate to all impacted systems

• How long it takes to verify the fix works

You might notice bottlenecks, process issues with your on call routines, or alerts that are missing altogether.

Have a Management Query? Let me know at questions@lauratacho.com or on Twitter.

Should I extend a job offer to someone who has salary expectations higher than our salary bands?

Yes! But avoid surprises: the candidate shouldn’t be surprised by a lower number, and you shouldn’t be surprised when your offer is turned down.

Salary expectations should be discussed at an early stage to make sure compensation is transparent from the beginning. If it's something the candidate can’t work with, they’ll withdraw and not waste their time (or your team’s time). But if they stick around to final stage interviews, you know there is something about the team or your mission that’s motivating the candidate and keeping them in the game. Some folks might be optimizing for learning, time off, or flexibility. Some folks will optimize for comp.

Cash compensation is just one factor in an offer. If you have pre-tax benefits (commuting, child care, healthcare), reimbursement for internet or home office equipment, or other stipends, the value of these perks may have more impact on a person’s take home pay than another 10k or 15k in base salary.

Each country has different tax rates, but I find it helpful to run the numbers through a take home pay calculator so you can see exactly what your candidate can expect to earn to in an average month. Here’s one for the USA, UK, and Germany.

Some people really value equity, other people view it as fake monopoly money, so that part of the comp package will also play a role. Sharing expected valuation of the equity offer, along with real number of expected take home pay, will help your candidates have all the data they need to make a decision.

Have a Management Query? Let me know at questions@lauratacho.com or on Twitter.