Qualitative data is also data.

Being data-driven means considering all the data, not just the data you like the best, or the data you perceive to be more “objective.” Thinking about this in context of developer experience and team performance, a thing I often hear is

“I know my team thinks it’s a problem, but I want to see what the data really says.”

My first rule about performance reviews?

ABSOLUTELY NO SURPRISES.

If you're "saving up" feedback to go over during a performance review -- don't.

Performance reviews are stressful enough.

No one needs to hear performance feedback for the the first time during that meeting. I have a 4-part blog series on painless and productive performance review.

A must-read for engineering managers (especially those at smaller companies without much process around reviews) but helpful to anyone.

Prepping for Performance Reviews
lauratacho.com/blog/prepping-…

Employee A is a solid performer and asks for a 10k salary increase.

But they're already at the top of the salary band, so it's not possible.

So they find a new job that pays them 15k more, and the company ends up spending 40k to hire and train a replacement. First, let me be clear: I'm always on the side of people being paid what they're worth.

But I've also been in enough doomsday meetings about runway and burn rate to understand why companies will make the "stupid" choice here.

(I'm mostly going to talk about startups.)

Developer productivity is something that's on every engineering manager's mind.

Get it right, and you can uncover bottlenecks & help your team succeed.

Get it wrong? You quickly lose your team's trust.

So here are 6 must-read articles about team performance & productivity: The SPACE Framework of Developer Productivity
🔗 bit.ly/3KfpgOy

Developer productivity

🔹 had multiple dimensions
🔹 must adapt to business goals
🔹 is more complex than we might think

SPACE gives you a framework to make it make sense.

Leaders often spend a lot of time trying to find the right answers

but not nearly enough time trying to ask the right questions. We often inject our own answers into questions. This

🔹 closes conversation
🔹 prevents our teams from sharing what they think

So try this instead:

When we think about data-driven teams, most of us will picture dashboards or business intelligence tools.

If we don't have access to this, we assume we can't be data-driven.

But here are 2 ways to use data to make better decisions, even without a data engineering team: This first one is possibly the coolest bit of math that I use regularly.

1️⃣ The Rule of Five.

Take 5 random samples from your target population.

You'll get a range that includes the median value (middle point) over 90% of the time.

Most engineering teams are used to async communication on Slack, GitHub, and in tickets.

But async communication doesn't have to be text-only.

Here are 4 async communication techniques that go beyond just words on a screen: My toolset here is pretty lightweight:
📢 Slack
📹 Loom
📝 Otter.ai

If you're afraid of being a micromanager

I can guarantee you are one.

It's the Micromanagement Spiral. 🌀

Let me explain: You delegate a project to your team.

You don't want to micromanage.

So you share just the big details in order to leave room for:

🔹 interpretation
🔹 creativity
🔹 alternatives
🔹 opposition

"How do you measure burnout on your team?"

Someone asked this question in my course today.

Required reading for any leader: Burnout can be hard to measure, because it's multi-faceted.

It's not necessarily about the amount of time someone is working.

Burnout happens when people are
🔷 overworked
🔷 chronically under stress
🔷 disconnected from results
🔷 lacking control over how they spend their time

I interview a lot of people, from C-suite to interns.

Want to nail your next interview and get a high offer?

Avoid these 5 mistakes. 🚫 Repeat your entire CV

Assume that everyone has read your CV.

You don't need to recap your whole career when asked to introduce yourself.

The interview questions themselves will give you an opportunity to highlight your accomplishments.

We've all heard about (and rolled our eyes at) the out-of-touch software engineering manager:

"Can we deliver faster by adding more people?"
"I want to see more PR activity."

But here's an interesting study on the definitions of productivity from managers and developers: 165 managers & developers responded to these questions.

➡️ How do you define productivity?
➡️ (for devs) How do you think your manager defines productivity?
➡️ (for managers) How do you think your team defines productivity?

The results?

Unexpected.

Scheduling your team at 100% capacity is a great way to ensure that nothing will be delivered on time. There is some cool math behind why this happens.

Let's take this example: each customer at a bank takes an average of 10 minutes to be served.

One new customer comes every ~10 minutes.

With one teller window open, the wait time is FIVE HOURS.
Not minutes. Hours.

I've spent 750+ hours coaching managers and executives to become more impactful leaders.

Here are 7 quick lessons to level up your leadership skills: 1/ Say no often

Focus is expensive. It's the most precious commodity in your business. Great leaders let their teams focus.

Great companies aren't made by saying yes.

They're made by saying no.

Anonymous coding challenges don't eliminate bias from engineering interviews.

Here's what the research shows (and what to do instead): Assessing coding exercises is just one of the many places where bias shows up in an interview process.

Your sourcing strategies, screening criteria, and interview panelists introduce bias as well.

Metrics from GitHub and JIRA can't tell you how productive an engineering team is. If a dashboard full of PRs, commits, and story points is how you’re measuring developer productivity right now, here’s what to do instead.

Let me tell you about the SPACE framework. 🪐

For engineers, it can be a struggle to set non-BS career development goals, which is top of mind as lots of people are in the middle of perf cycles.
Even if you have a career ladder, it’s still hard to turn that into *something you can actually do in your job*. Here’s what I do: This is all based on 4 Ps of being a software engineer: People, Projects, Process, and Partnerships.