Finding Untapped Engineering Talent on LinkedIn

Are you hiring engineers right now?

I’m guessing the answer is yes, and I’m guessing it’s taking up anywhere between 25% and 75% of your time.

Someone asked me recently how they could make hiring go faster.

Here are a few of my go-to tricks when sourcing candidates on LinkedIn.

We all complain that LinkedIn is a steaming pile of recruiter spam. It’s rooted in truth though, because so many people are contacting the same candidates who are easily searchable. You aren’t going to get anywhere competing against 100s of other low-quality messages.

Instead, you need to find pockets of talent that often fly under the radar on LinkedIn. These are untapped groups who aren’t getting the recruiter spam, so you’re more likely to get a response:

• The Lurkers: People with light profiles but recent activity, so you know they’re still checking the platform. Candidates on LinkedIn are passive. They have no reason to keep their profile up to date unless they are a) looking for a job or b) selling something. Most recruiters will pass on reaching out to them because there isn’t enough info in their profile. Don’t make that mistake. High-performing individuals don’t need to market themselves in LinkedIn.

• The Flyovers: Target a region that’s not often associated with lots of tech talent. A personal example: I grew up in Wisconsin. I know that talented folks who graduated from college probably landed in Madison, Milwaukee, or Chicago for at least a few years in their early careers. They might have moved back to Wisconsin to be closer to family once they got a bit older. Most companies there can’t or won’t compete on salary, so there’s a huge opportunity to get amazing talent to join your team. This is especially true if you’re offering location-agnostic salary bands like Airbnb just announced. On LinkedIn, I’m going to search for a specific job title (level + language + “developer” or “engineer”), then set a location filter for Wisconsin, and then probably filter on previous employer if I have some reputable local companies in mind.

• The Bootcamp Grad: Bootcamps have been around for a while now. There are people who graduated from bootcamps who have now been engineers for 10+ years but will get passed over because they don’t have a CS degree (mistake) or because recruiters have been instructed not to reach out to people from a bootcamp (also mistake), regardless of their years of experience.

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.

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.

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.

What are some ideas for remote team building activities?

Sitting in yet another Zoom call to “socialize” and drink coffee probably isn’t on the top of your team’s wishlist. Remote team building doesn’t have to mean virtual, and some of the best ideas blend real life and internet life together

• GeoGuessr. Hands down, this is my favorite thing to do with remote teams. If you’re especially distributed, create a custom game with each person’s current town or hometowns as a location. Split up into teams and make the competition a little more interesting with a prize for the winners.

• Company recipe and grocery stipend. Anything with cooking during an in-person retreat has always been a highlight for my teams when we’ve done it (even for those folks who don’t ever set foot in a kitchen). Come up with a straightforward, accessible recipe and give each team member some cash to go buy ingredients. Create the space for everyone to get together and share their result, or post it to a Slack channel. Desserts are great here (especially no bake desserts), or a signature cocktail.

• LEGO sets. If people are going to sit in a Zoom call and drink a beverage of choice together, give them something to do! Later, people can have their LEGO sets in their office or in the background when they’re on a call. It’s a nice reminder that stays around longer than a cup of coffee.

• Online games. Jackbox allows for online multiplayer games where folks can use their smartphone or tablet to play. Drawful was a pandemic favorite. There are also plenty of online multiplayer browser games which are a great fit for remote teams.