You can be directive without being a jerk

Originally posted Oct 26, 2021 • More resources on effective communication

This post originally appeared in my newsletter. Subscribe to receive it!

Last newsletter, I answered a manager’s question about helping their team break the cycle of going in circles, while still being as empowering as possible.

But sometimes, getting your team out of quicksand will require you to be much more directive than empowering.

Don’t worry: we can still approach this in a way that drives buy-in and helps your teammates feel heard, and know they have autonomy.

Employing a directive model doesn’t mean being a jerk or overly controlling. As you’ll see, sometimes, being directive is the most empowering thing you can do for your team.

Identify what you’re optimizing for

To recap our example from the last newsletter: this team has a clear roadmap with well-defined projects and deadlines. There are enough people to accomplish the work. But despite knowing what the work looks like, the team is still going in circles. We’re assuming that this manager has already identified and documented the project’s goal.

So now it’s time for my favorite coaching question. I’d love to ask this manager: When you think about how you want to lead your team in this moment, what are you optimizing for?

In the case of this letter-writer, I’d guess they’re optimizing for forward progress. So letter-writer, here are my tips for you; we’re going to plot out the route that will optimize for forward progress most effectively, using a directive approach.

Identify the who, what, when, and how

When we as managers are being directive on a project, we’re deciding on the who, what, when, and how, and then we’re communicating that information to the rest of the team. First we’ll start by identifying your role as manager, and then we’ll move on to the rest of the team.

Identify your role and responsibilities

In the original letter, you have already identified that you feel responsible to “keep everyone moving forward.” But what does that mean in practice?

Describe your role in outcomes, rather than describing how you’ll do your work. This way, the “how” can iterate over time, but your role’s success criteria remains the same.

Here are some examples of what your role on this project might entail:

• I’m responsible for ensuring that the team has internalized this project’s timeline: our target ship date, definition of “shipped,” and expected milestones between now and then.

• I’m responsible for ensuring that each team member has a clearly-defined individual role on this project: what they’re responsible for, and what they need to communicate and when.

• I’m responsible for ensuring that stakeholders know who to reach out to when they have questions about project progress. I’m also responsible for communicating to stakeholders when we’ve hit major milestones. If there are any leadership/higher-level meetings or email threads about this project, I’m responsible for presenting (or otherwise communicating about) this project to others around the company.

When surprises pop up, I’m responsible for ensuring that a new plan is drafted within 8 hours with clear requirements and success metrics. Stakeholders are informed within 24 hours of the surprise, plan changes, and any new requirements. The team has what they need to get to work on the new plan within 48 hours. (And if they can’t get what they need, a new plan is drafted, and the cycle begins again.)

You might have noticed that I try to avoid the word “accountable” when I’m listing responsibilities. I’ve found “accountable” can mean many different things to people: “will get fired if this doesn’t happen,” “is the comms person/liaison,” “is doing the work directly,” are all possible meanings of “accountable”. I recommend you use longer descriptors of what you actually mean, rather than use the catch-all term “accountable”.

If you start writing this list of responsibilities in your role and find you’re falling into the trap of describing the “how” instead of the outcome, ask yourself, “what’s going to happen, or be different, as a result of me doing this thing?” For example:

• Instead of “I facilitate standups on Mondays and Wednesdays,” it might be “I make sure that team members have a routine, frequent opportunity to raise blockers and ask for help, so that they’re not stuck or left floundering on any given piece of work.”

• Instead of “I present a project slide deck in biweekly Product meetings with red/yellow/green indicators for our progress,” try “I continually ensure Engineering leadership and our product partners have a rough sense of our project’s progress. They know I’m the person to reach out to with questions about our project’s timeline.”

This distinction is important because it allows for the “how” to evolve over time, based on what you learn, how the context and urgency changes, or what your teams discover they need. For example: you might decide that standups aren’t useful, or the team doesn’t do their best thinking (and communicating) in this medium. Describing your role in terms of outcomes will allow you to make informed “how” decisions that always tie back to the primary goal.

Hopefully by doing this exercise you’ll recognize that your job is not to micromanage. You don’t need to look over folks’ shoulders at every step. But you do have to get your team clear on what’s expected of each of them, and identify what they need to be successful given those expectations.

Identify your teammates’ roles and responsibilities

You’re going to need to carve out time for this work. This might take you a couple of days of complete focus time.

Identify one person who will be good at giving you gut-checks as you develop the plan. Ask them if you can check in with them at the end of each day for their feedback, and block out the time on both of your calendars. This doesn’t have to be someone on the team, but you will want to lean on someone who has some experience with similar projects, and is also familiar with the skill sets of your teammates.

Block out your calendar for all of this focus time, say “no” to other meetings, and tell your team that you’re developing a plan. Let them know when and how you’ll be sharing a project plan with them, so they’re not swimming in total uncertainty.

I find that teams stuck in this rut either have the who and what defined, OR the when and how defined, but not both. A team might have a cadence of sprints, retros, and standups, but they’re still stuck not knowing who is doing which part. Or each person has already picked up some work and is tackling it, but it’s still a black box of uncertainty: folks don’t know what progress is being made, and intra- or inter-team dependencies are lurking on the horizon.

No matter which aspect is fuzzy for your team, you’ve got options! Here are some examples of defining the who and what for your team:

• Create the same responsibilities Venn diagram, but to fill it in yourself rather than approaching it as a team exercise.
• Use a responsibility assignment matrix.
• Break down project epics into distinct chunks of work (each with an observable end goal) and assign a person to drive each one. (Be sure to describe and document what “drive” means!)

You’ve also got tons of options for nailing down the when and the how. For example:

• Pair people up on each chunk of work, so that everyone has an assigned partner for code reviews, gut-checks, help getting unblocked, feedback, etc.
• Decide how sprints work:
  • Establish a pattern of stand-ups and high-level project updates so that folks on and off the team know how the project is progressing.
  • Establish a cadence of retrospectives, in addition to identifying blockers during standups, to ensure the group as a whole has what it needs.
• Identify major milestones and estimate dates for them, so teammates can feel their own progress more concretely than measuring it against the far-future end goal.

Communicate the who, what, when, and how to your team

I doubt you’ll need something as thorough as a tick tock doc for communicating these updates to your team. But you might need to tell some folks earlier, or separately from others, to keep optimizing for that forward movement. I go into even greater detail about these tactics and tradeoffs in Chapter 4 of Resilient Management, but here are a few crucial takeaways:

If you need to communicate to particular individuals first

Prioritize communicating to different folks based on how much their reaction or input will affect your future messaging, how gracefully they can navigate confidentiality, and how much their reaction will affect the rest of the team.

If you’re expecting a big negative reaction from one individual, but you suspect informing them early will help you optimize for forward progress, use these open questions liberally when you meet with them.

I’ll go into more detail on responding to pushback in a minute, when I talk about communicating the plan in a group setting. But in short: stay in coaching mode, help this person feel heard, and be clear about what parts of the plan can be amended versus which parts are firm.

I like to keep an intentionally-directive conversation future-focused, meaning: we’re not going to litigate what’s happened in the past, and we’re not going to spend hours talking about what all the potential options are. We’re here to talk about what we’re doing from here on out, so that we can nail our most important objective: making forward progress.

Like I mentioned in the last newsletter: feel free to describe these new roles, responsibilities, meeting cadence, etc. as an experiment! When you share the plan with your team, you can say that you’ll be using these defined roles for this project, and you as a team will be iterating on it and updating it for future projects based on what everybody learns.

Share with the team

Before the meeting, clarify the #1 most important thing you want to communicate. Maybe it’s, “We’re optimizing for forward progress.” Or, “I know how eager everybody is to get this product into the world.” Or, “We as a team are stronger than the sum of our parts.” It could be anything that’s true for you! But make sure your “bottom line” thesis statement gets to the heart of why this plan is the one your team is moving forward with.

Keep this statement top of mind as you prepare. Repeat it throughout the meeting. Acknowledge the tradeoffs you’re making, in order to nail this #1 most important thing.

As you share the plan, stick to just the facts (who, what, when, and how!). Identify what’s changing about how the team is doing their work, and what’s staying the same. Leave plenty of time for questions.

And just like last time, spend time in this meeting identifying what the team needs to be successful with this new plan.

Respond to pushback

Naturally, when you choose the directive route to assigning roles and responsibilities, there will be folks who aren’t thrilled about your decisions. That’s okay. It can be hard to remember, but you’re not optimizing for avoiding grumpiness here. You’re optimizing for forward progress!

There will be times when folks’ reactions will get in the way of that forward progress, though. When people are frustrated with being told what to do, they might slow down/fight/check out (which are classic signs of amygdala hijacking; no judgment here!).

Before getting defensive, arguing, or shutting your teammate down (which will just cause you more problems!), try spending five minutes using open coaching questions to understand where they are coming from:

• What feels most important to you about this?
• What is your gut telling you?
• What one thing do you wish you could change about this?

Use affirming body language as they respond.

(By using a coaching approach here, you’re actually operating from the empowerment end of the spectrum. In a lot of directive settings, you will still have an opportunity to leverage empowering skills to help others feel seen and heard, and to help them grow. That’s why it’s important to continue adapting your approach as the context evolves!)

One outcome of this approach is that your teammate will have taken a moment to think more deeply about what’s at the root of this issue for them.

But the bigger win? Asking these open questions and reflecting on what you heard them say will make your teammate feel heard and seen, which speeds up their ability to recover from their amygdala hijack.

Empowerment vs direction

When your team faces any hurdle or stuck moment, you’ll need to decide how to jump in. You might choose to adopt an empowering approach, viewing your role more as a facilitator and support structure as the team plots the path forward. But there will still likely be moments where you need to be directive, making decisions and tackling aspects of the work yourself.

We all have a different default approach to this work, and that’s okay. If given a choice, I do not naturally choose a directive route! If you’re the same, you’re not alone, and it’s okay. But it’s important for every leader to learn how to adopt a directive approach when it’s the most effective option, while maintaining the trust and buy-in of their team.

Spend some time with these coaching questions to figure out what your default approach to leadership looks like, and when you might need to switch it up. As leaders, it’s our responsibility to choose the approach in each new scenario that will work best for the work, the team, and the organization. You’ve got this!