Being Visible to the People You Lead

There’s a lot of discussion about how as an individual contributor it’s important to “make your work visible” to higher ups to get the appropriate resources, opportunities for advancement, etc. But there is relatively little discussion going the other direction about being a leader and making your work visible to the people whom you lead. I think there's just as much value to thinking about and framing your work for the people lower in level as there is to higher ups.

In my last post, I aggressively (and somewhat sarcastically) referenced Staff+ engineering being “:bullshit”. But, I don't want to imply that leadership is bs. Rather, I want to point out that as a leader, especially from the view of the people you lead, you get to both make up the rules and then evaluate yourself based on those rules you made up. From an external perspective it can make it all seem a bit... arbitrary, and designed to post-facto argue why you are doing a good job, regardless of the "truth on the ground".

And it's true, in other roles it was easier for my collaborators to evaluate the job I'm doing. But in the Staff+, and other leadership, roles that moment-to-moment determination is solely up to me, depending on how I feel about the situation and what, I think, would be best. And the line between doing something that’s incredibly self-serving, and something that’s beneficial for your team can be nebulous and is often the result of a personal judgment call.

This is the power and risk of the role. As always, the easiest person to fool is yourself. But we often talk about the risk of the role from an upward looking perspective, i.e. aligning yourself appropriately with the goals of business leaders and managers. But what about looking the opposite direction? How, given all of that uncertainty, do you maintain the trust of the people who follow you?

The DALL-E prompt for this was a cartoon hippo in the middle of tall grass with onlookers from a 3/4 bird's eye view.

What is Being Visible?

There’s some popularity in tech writing that talks about the book Seeing Like a State. The general concept here is that control structures will ask for behaviors that are observable and understandable. In doing so, reducing positive development by pruning things they don’t understand. This broadly applies to tech orgs with things like OKRs and metrics.

When I talk about “making yourself visible” as an IC, it means framing your behavior in terms of phrases and logic that fits with the goals and priorities of your management.

When we mention upward visibility, the career benefits are obvious, better opportunities for advancement and more interesting problems to solve. The value of downward visibility isn’t clear because the consequences aren’t obvious. If the people who you lead don’t know what you’re doing for them, there is no career cost to you. There might be an efficiency cost to the team, but it’s unlikely to immediately have an impact one way or another.

I’ve had a decent number of conversations with coworkers from past tech jobs who ask questions like “What does X director even do”. These discussions have made me notice how as we move up the leadership chain, we lose sight of making our behavior visible to a different set of concerns, the other ICs who live within the system.

A Hypothetical Situation

Let’s say I, as a staff engineer, work on a team struggling to deliver a particular project. I have a few options. I can:

1. Note that there’s an issue, but stay out of resolution determination with the team
2. Communicate resolution steps to the team, but not take part in resolving the failures
3. Communicate with the team and take an active role in making the project a success

In various points each of these outcomes could be the exactly right thing to do for the team, it’s also possible that #1 could be a complete copout that sells the team short for my failings. It’s also possible that #3 could mean I end up overshadowing the team. Maybe we feel great that we launched, but there’s resentment that now people outside the team see the project as mine instead of the team’s or the other project leads.

From my perspective, good leadership requires a constant sort of vigilance in terms of reflection and understanding of my behavior. Even asking for feedback from the people impacted won’t necessarily be a good barometer. People could be happy I jumped in and fail to see the negative externality I just caused on their career. Or, people could be unhappy I didn’t jump in, but fail to see the way the career growth and positive feedback they got for their response to the challenge improved their careers.

Note: This isn’t to say that you shouldn’t ask for feedback. It’s to say that the feedback is non-determinative in a way that it’s not in other roles.

This is the exciting and terrifying thing about staff+ roles. You are fully in charge, and can exceed or fall back to the level you feel comfortable. The constraints can be less about practical outcomes so much as they are about your ability to tell a good story and your desire to see impact.

It’s hard to manage this visibility, and this challenge as a thoughtful tech leader (which I aspire to be, though I suspect I fail at quite regularly). We value the contributions of our team members, we view them as our equals, and we don’t want to put ourselves above them. The difference between being open and transparent and flaying your emotions out at the people whose careers you impact can feel awfully thin.

Being Visible to the People You Lead

It’s easy to create this picture where everyone is focused on the same set of concerns and metrics that are set and driven by leadership. And it’s true, we all want to do well for the company, but the things we all value have niches and twists. Some people might care most about doing well for their users via accessibility, some might be driven by learning the latest technology, and others might be driven by things like optimization. Each of us is going to interpret company goals, and the best way to achieve them, in unique ways.

It would follow, then, that making yourself visible “downwards” would firstly be about framing your impact in a way that’s most interesting and valuable for those goals, not just the company ones. Most importantly, especially in an IC leader role, you can attempt to reframe the concerns of the company in terms of the concerns that your team has. But doing so requires thoughtfulness not just about how to hit goals, but also listening to what the team values and how they can achieve those values within the framework the company provides.

Being “Visible” is Easy as an IC

As an IC slash leader, it’s easy to default back to shipping code, so you feel valued, and so that you can “show value” to the rest of your team. You can always pick up tickets! But as Will Larson makes clear, that’s much more akin to snacking than providing actual value. Actual value might look more like doing the hard work of explaining to your team (and encouraging them to challenge you) on the 3+ month vision doc you’re building out. It’s certainly possible that working that ticket is the most important thing you could be working on, but even so, I think you should have an answer beyond “I’m a developer, and I’m shipping code”.

What Does Being Visible Look Like

Let’s go back to those three outcomes for a flailing project. How can we make this visible:

Firstly, you should be transparent with both your manager and the people involved in the decision what tact you’re taking. There isn’t a situation where you should feel like if you clearly communicate what’s happening, your team members won’t “get the learning” so some silliness. You should also talk to the team and understand how they’re feeling about the project, what concerns they have.

In each situation, it’s worth concretely calling out the following:

1. The concerns of the broader organization
2. The goals of the team
3. How you’ve come to the conclusion about integrating the two, and where you’ve picked one over the other, and why

**If you don’t think you should be involved in problem-solving the issue: ** You should explain that you have concerns as an external participant, but it’s not your place to get involved with how to solve it. Also make yourself available for feedback, but refrain from being an active participant in the discussion. Be clear that you either don’t have the bandwidth or think it’s valuable to not be involved in the solution because the right people are already involved, and you have high confidence in what they’re doing.

If you don’t think you should be involved in the execution, but you have real thoughts about what the key next steps are I would start by listening to hear what the rest of the team has to say, and then finding ways to piggyback and reinforce their ideas. If there are any big misses jump in and say, “hey have you thought about X, Y, Z, I have some concerns”. But then be clear that you either don’t have the bandwidth or think it’s valuable to not be involved in the solution because the right people are already involved, and you have high confidence in what they’re doing.

If you think it’s important, think you need to get involved, and are going to do so, I think this is a place where signaling intent is crucial. You likely have a lot of knowledge about the rest of the org that your team doesn’t. Be clear about why you’re getting involved, acknowledge the potential costs but signal why you think the tradeoff is worthwhile based on your knowledge of the organization’s vision, and your team’s values. And listen to any feedback your teammates might have about why they might disagree.

Rebuttals

Outcome focus and our discomfort with talking about ourselves

One counterpoint to all of this is the concept that, no, in fact, as a leader, your focus should be on outcomes. If the team has good outcomes, it doesn’t matter if they see your hand in them all the better, it means you’re making a quiet impact. And furthermore, to call out all the great stuff you’ve done is just self-serving, you’re basically asking other people to appreciate you for the work you’re responsible for!!

Here’s my response:

No one is ever 100% in agreement about what outcomes are good/bad and in between. Making them present makes it more possible for your team to nudge or redirect you in positive ways.

Invisible improvements don’t help create a good sense of team culture or reinforce the fact that you’re making efforts to improve the team, as you see it. Sharing what types of outcomes you’re concerned about makes you less of a “shit catcher” that blocks your team from the rest of the org and less of a values oasis: and more of someone who helps your team members have access to the rest of the org as they see fit. Maybe they’ll see something in an outcome you’re focused on and offer to step in and help out.

Sharing your map and your work also helps other people orient themselves more in beneficial ways for their careers. If they know what you care about, they can frame their contributions in the same way.

In the above example, maybe let’s take the “hero leader” path: You do what’s best for the team’s growth and tell them you trust them, it’ll take how long it takes, and you support them 100%. However, you don’t tell them there’s broader concern among the org and this is actually a critical release. In that case, you’re denying them crucial information about the constraints of the project, and the costs you are exposing yourself (and potentially them) to as a result.

Or maybe, let’s go the opposite direction: let’s say it’s your view as a leader to always fall in line with the company position, even if the team disagrees with it. Not acknowledging the conflict doesn’t make it go away, and might make the team lose trust in the decision process. Obviously, as a leader, you have to ultimately see that the organization’s goals are carried out. But, you have an opportunity to honestly talk about how you recognize the potential conflict in values, and how you can see a productive path forward.

But the spotlight already is on me

The other rebuttal to this sort of “leaders aren’t visible” argument is the concept that, as a leader, everything you say and do is already under a microscope. People look at you for stuff like behaviors, what to do, and what the priorities for the team are.

For me, that’s more “leader as a pane of glass” than a leader whose work is visible. The difference is between saying something like “We’re focusing on X this quarter” and “Here are the key viewpoints, insights, and feedback that led me to have the team focus on X this quarter”. If we flip this on its head, it would sound equally ridiculous as a tech leader to tell them that you’re going to only focus on tech debt because “it’s important”. The goal of making things visible is framing, reframing, and integrating one set of value systems to another, and listening to feedback to improve and manage that process.

Hippos in the Grass

In high school, I remember learning about how in the wild, the grass is tall enough for hippos to hide in it. The lesson was that just because you can’t see the grass move doesn’t mean that a hippo isn’t there ready to charge. I think, especially for thoughtful tech leaders, there’s some reticence around recognizing our own hippo-ness. We value the contributions of our team members, we view them as our equals, and we don’t want to put ourselves above them. But often we do this by talking less, by decentering ourselves too much. This can make us like the hippos in the grass, where we are still there, still dangerous, but hidden. It is safer for us to have our behaviors out in the open, visible to the people around us. This way our teams can see and respond to them, with the availability (and encouragement) to critique and shift our thinking, letting them take advantage of the influence we have within our orgs for their and our betterment.