Engineering Management for the Rest of Us

by Sarah Drasner

In this situation, you don’t start by giving feedback, you start by asking for feedback. Typically your team will be able to give you some context for why things went awry and what you could have done better.

You’re in charge of a system of people, you need to make sure you are taking the wider group’s health and safety seriously. It sucks, I know.

I tend to give myself a section to just write through the facts of what happened, and then another to write through my feelings of what went poorly and what could have been better. It helps to check in with the facts separately because our human brains can sometimes try to protect us by amplifying a particular version of an event. This can be hard to do, but checking in with just the facts helps ground that a bit.

As a manager, you can also ask for feedback, so that you can grow, iterate, and evolve your ability to lead and help your team. A nice side effect of this practice is that it cultivates a culture in which growth and learning are valued and seen as a natural parts of work. It can move feedback away from a place of fear and into that place of care we were talking about earlier.

it is a good idea to let people know ahead of time that you will be asking for feedback so that you don’t throw them off guard. Power dynamics can make it tough for people to assess what they’re comfortable sharing on the spot.

This may seem hard, and that’s because it is. But over time, and the more you do it, the more natural it becomes. I keep returning to the importance of going first as a leader, because I believe you have to repeat what’s important. When it comes to trust and vulnerability, you have to model the behavior. People are looking to you for clues on what behavior is acceptable and what’s celebrated. Show them.

Feeling defensive can be a great indicator that we have a blind spot. When something feels particularly threatening, try to consider it as an indicator that you may have some internal exploring to do.

Asking questions not only gives you more information about what they’re conveying, but it allows you to approach the problem with a bit more of an academic handling, which can also disengage flight or fight. It also gives you an opportunity to chew on the information without figuring out next steps right away.

Write everything down. Try your best to write down explicitly what happened, not your feelings about what happened. Why? Because we’re going to do that thing we spoke about earlier: check in with the facts.

someone attacks you personally, stepping it back is incredibly hard. It’s completely okay to say that you’re not looking for feedback on your character. Express your boundaries around what feedback you are willing to listen to and what you are not. You are also within bounds to leave the conversation.

put the health and safety of people above all else. People do their best work when they don’t feel they are under personal attack. Try your best to cultivate an environment where this is not tolerated. And do not tolerate it for yourself either. Not all feedback is valuable.

Like it or not, meetings are essential for communication and nurturing a good working environment. Therefore it’s crucial that we managers make them as productive as possible.

There’s little chance that everyone will agree on what a perfect (or even great) meeting is. So half the journey is aligning on that.

Some features of a bad meeting are as follows: There’s no clear purpose or direction. It feels chaotic. The wrong people are there. People are generally disrespectful of one another. Everyone feels it’s a waste of time.

a good meeting is: The purpose of the meeting is clear. There’s an agenda (we dive into the complexity of this in a moment). The right people (and the right number of people) are in the room. Not too many people where communication is overly complicated, and not too few people where those you need to move forward aren’t there. There’s some order. People aren’t dropping in and out, talking over each other, or being generally inconsiderate. There’s a clear decision, outcome, and next steps at the end.

Ideally, the following points encapsulate information everyone needs: What is the shared purpose? What are we doing to get to that outcome? Who is owning what, and how? What are the timelines?

if you come to a meeting where an agenda is locked top to bottom with material, it can sometimes shut down the collaborative aspect of the meeting, which means it shouldn’t be a meeting at all; it should just be a shared doc, to be consumed async. Part of the purpose of the meeting is the discussion itself.

Again, louder: Part of the purpose of the meeting is the discussion itself.

have folks add whatever they like to our agenda, asking that they preface their contribution with their name and a small category. For instance, A for announcements, RD for rapid decision, D for discussion, and Q for questions. Here’s an example: [Sarah, RD] should we block off four hours to triage our iceboxed (items stored for later) issues?

In these meetings, we also talk about what was done or shipped in the previous week, so that we can celebrate a little, especially the tasks we know took the person a lot of time or effort.

twice-a-week check-ins were suitable: once on Monday to kick off the week, and again on Wednesday to keep us aligned and our momentum going.

If you’re inviting everyone to meetings out of fear of hurt feelings, it’s likely not a problem with your meetings, and more a sign that roles and responsibilities aren’t clear for everyone.

I’m a “walk toward the fire to put it out” kind of person, and will actually just acknowledge that it’s awkward because it doesn’t feel like we’re being transparent with one another. I’ll state what I know from my perspective and then ask if other folks are feeling the same. If you do this, you’ll usually have to wait a beat or two. People will likely be a bit shocked that you came right out and said it. It may take them a couple of seconds to adjust and consider what will happen if they tell the truth too. It’s crucial that you not speak to fill the silence in these moments. It may feel uncomfortable, but I promise, you have to let the silence hang for a bit before someone speaks up. From there, people will typically all start speaking, and you can actually dig into the problems.

It’s the job of a manager to disambiguate healthy conflict from attack, so that respectful discourse is encouraged.

If folks are putting out ad hominem attacks, it’s on you to reel that in, and move the conversation toward the work instead. Otherwise it really is hard for the conversation to stay productive.

A good meeting must have a DRI (directly responsible individual), and it is not necessarily the person who called the meeting. It might not be you. But you must designate who owns the project and ultimately makes decisions when there’s one to be made.

we use directly responsible individual because that’s also core to deciding who this person is. That is the person who is going to own the outcome.

When there is a conflict, be it on an individual or organizational level, it’s crucial to deal with it immediately.

You’re leading a team—they’re looking to you to model good behavior. You probably want a team that’s as open and collaborative as possible. As a manager, it’s important you try to imbue these qualities.

The key is to continue to provide clarity, and usher folks toward productive conflict that is devoid of personal attacks, and focused on the larger goals.

contributor covenant code of conduct

Saying “thank you” for the project before making an inquiry about a new feature or filing a bug is usually appreciated.

What you should know about OKRs is that they are separated by “objectives” and “key results.”

Objectives should be high-level goals that inspire a picture of the future and imagination.

Key Results are specific measurable pieces of data over time.

You can guard against “scope creep,” where people pile tons of other things on your team. For instance: Stakeholder: “Hey, can your team do X?” Me: “Maybe, but how does it fit in with the priorities we already set out to do?” (I show them the spreadsheet.) Me: “I’m happy for us to work on this if we deprioritize something else

You can’t generate a million OKRs and metrics and expect a positive outcome. Part of looking at the big picture and prioritizing means letting go of some projects and being aggressive about what is most important.

You have to be clear what your highest goals are and be willing to let go of the others.

I usually communicate with stakeholders by aligning them to what they want most, and make it clear that the risk is sacrificing those things if we don’t properly prioritize.

One of the most-valuable skills one can possess as a manager is to help your team scope down large, ambitious, abstract work into more manageable pieces, and often the smaller the units the better.

It’s easier on reviewers. It’s easier to test. It’s easier to iterate.

some things that you think will take two minutes turn into hours or days, or vice versa. So start with the end. What output do you expect to see from that ticket? Now we can walk backward. What parts of the codebase will be affected by this change? If you’re newer to the project, ask someone with more seniority on the team to help you track which areas will need to be updated.

Happy and productive teams seek out the best technical perspective over their own personal glory.

Assess whether the tech stack is serving their needs: Are they able to make changes without a ton of side effects and other pieces breaking? Is the stack new enough that they can use modern languages and libraries if they see fit? Do you have an appropriate language or style guide in place, as well as linting systems so that PR reviews aren’t getting stalled on stylistic details? Is there a part of the system that everyone complains about? If your tech stack had a map, does it have an area marked “thar be dragons?” Are there appropriate CI/CD systems or other tooling in place so that they’re not constantly yak-shaving and context-shifting to get their work done? Most importantly, can any single individual easily and accidentally bring down production or a shared local environment? (Surprise! This one impacts psychological safety too!)

Once you figure out what problem you want to tackle, it’s critical to write up a small one-sheeter that you can share with stakeholders. This will cover the nature of the work, the amount of time it’s going to take, and why it’s important.

I suggest building time for internal documentation into any feature process.

It’s crucial to celebrate the work of completing a migration just as you would a launch.

The team needs to know you value this work because it’s often thankless, but very impactful.

Your values have to be reflected in what you schedule. If you say you care most about your family, and make no time for them, then you’re not honoring your own value. If you say you care most about creating a supportive work environment and never take time to meet with your team, your values are misaligned.

Find a system that motivates you and allows you to be proud of the progress you’re making, despite the fact that new things are appearing all the time.