Lil’ Wayne really captured something important in that line. It doesn’t just apply to gangsters. It also applies to senior engineers and managers. I was in a discussion a few weeks back about how directly technical we can expect managers to be. To be honest, it was quite a dramatic conversation (by the standards of smooth operating engineering management types). The drama hinged on the argument that management is a completely different skillset from engineering. I don’t buy this argument though. Instead, I think there’s huge overlap in the Venn diagram of senior engineering and management.

• 

The aspect of this diagram I want to focus on in this post is the “Don’t create drama within the team” bit right at the top. This huge differentiator between senior engineers and exceptional senior engineers is equal parts technical and management. Exceptional senior folks think a lot about team alignment and how to affect the right change in the smoothest way possible.

Imagine something is broken

You can differentiate an exceptional senior engineer by how she reacts when something is broken. For the purposes of this discussion, let’s say that our senior engineer sees that some important piece of the technical infrastructure is built in a clumsy, fragile way.

Junior engineers usually don’t have a clue when something is built badly, so they won’t factor into this discussion. As engineers trend more senior, they usually acquire a strong technical opinion. They start to see how things ought to be. Junior engineers are working hard just to catch up to where things even are.

The hallmark of a senior engineer is that they’ll catch wind of something that isn’t right and will have the instinct to fix it. You want these people in your team. They have the antibodies required to prevent bad things from happening. If you don’t have people at this calibre in your team, you’re gonna have a bad time.

Side note: It’s quite common for highly confident, rhetorically gifted junior engineers to masquerade as senior engineers. They are among the most dangerous people you’ll ever hire. They don’t know the difference between a real problem and something they just feel opinionated about. If you don’t have perceptive, interpersonally strong, technically senior people on your team, you’re at massive risk of hiring these kinds of engineers. Once you do, it’s basically game over.

When a senior engineer — a real senior engineer — spots a problem, the very next thing that they do will tell you loads about how senior they are.

The Heroic Senior Reaction

An average senior engineer will see a problem and decide to solve it themselves. They’re technically strong. They’re faster at coding than most people. They see the problem. They see the solution. They’re used to being rewarded for their technical contributions. To the first-degree senior contributor, a moment like this is one they can’t resist. This engineer dives in and solves the problem and then throws their solution into the broader team like a hand grenade.

The problem with this type of contribution is that it’s completely unaware of team issues at all. Why did this problem exist? Was it a known problem? Did the managers involved know about the problem already? Who was working on this problem? Were they already trying their best? Was the situation the result of everyone trying really hard and doing the best they could possibly do? Did this engineer absolutely have to intervene? Would the company fail if they didn’t intervene?

The sense of urgency in these cases is usually driven by the engineer’s own satisfaction at a problem well-solved. Sometimes there’s a cynical, self-serving edge to this approach. This senior engineer wants the glory and reward for solving the problem. Occasionally it’s completely naive productivity that just happens to create a pinch point for the team, but that’s much less common than the engineer gunning for recognition.

Often an engineer doing this kind of disruptive work is doing it because they’ve really enjoyed being bad ass. These folks are often the “rock star” juniors who became super strong technical contributors. It’s not uncommon for this person’s ego to get tied up with a sort of heroism. They like being the one to swoop in and rescue the situation. This is totally human, to be fair.

Heroic junior engineers can swoop in and exceed all expectations. As they progress from junior to mid-level, they begin to deliver well-scoped work better and faster than anyone expected. The problem comes when that person gets the technical prowess to do work that impacts the people around them. Big problems come when they continue to expect to be recognised for these heroic efforts despite their heroism causing disruption across the team.

Pretty much every newly-senior engineer will go through a period of this kind of behaviour. The Mighty Lobster on High knows I did my fair share of heroic doing-things. It was a hard habit to kick.

The Red Alert Senior Reaction

Better senior engineers will spot the same problem but they’ll pause to consider the people involved. These engineers generally trust that they’re in a team where people work hard, do the right thing, and generally don’t need heroic saviours to swoop in to rescue the situation. Often these folks will have done more mentorship work. They’ll have the vague idea that they should probably think about the “people” involved — whatever that means. They likely believe that the team has genuinely missed some key problem that only they have seen. They believe the team just needs to be told about it. Folks with this level of senior awareness will likely jump straight to talking to the whole team about the work. Often these are the folks raising red alerts in team meetings or writing long posts in Slack about the urgency of resolving the situation.

While this person has a better understanding of team dynamics than their Heroic counterparts, they can actually be more disruptive. A little bit of knowledge can be a very dangerous thing. At this level of team awareness, the senior engineer will see that they need to fix the problem by working with others. However, this level of senior engineer won’t have an instinct for how their over-communication and pushy direction-setting might interact negatively with other projects or management efforts that are already at play. These seniors have the awareness to think, “I need to let the team know this is a problem” but they usually don’t have the level of awareness to think, “I wonder if the senior people on the team already know this is a problem…”.

These sorts of grandiose “red alert” interventions cost the company in a deep way. Noisy senior engineers garner most of the attention from the team. They’re conspicuous and often imitated by junior and mid-level folks. One of the down sides of more senior people being so discreet is that it’s harder to see how they work. By contrast, the less effective senior engineers broadcast their methods loud and clear in ways that everyone can see — to everyone’s detriment.

Part of the reason people get stuck in this mode is that it can feel really thrilling to be the public agent of the change. Sometimes these are folks who enjoy the limelight of raising issues. It can feel really exciting to make a daring, team-wide post about an existential threat. When the person really enjoys this limelight, they can sometimes get stuck at this level of seniority and never progress beyond it.

The bigger your organisation and the more open your internal culture is, the more likely you are to see seniors doing this anti-pattern. I should put my hand up here, too. I’ve been this engineer. I’m not proud of it. Especially toward the end of my time at Facebook, I got a bit lost in the celebrity of being senior and lost my focus on doing impactful work. And it cost me a couple performance reviews.

The Backseat Driver Senior Reaction

When a senior engineer has acquired some significant mentorship experience, it’s not uncommon for that person to start to see their role as shaping the technical direction for others. These senior folks understand that they shouldn’t be diving in and solving the problem themselves. They may or may not cause thrash by making grandiose internal posts. The hallmark of this behaviour is that they take the problem to the root. They figure out the who of the situation and set about to make others be the change they want to see in the world.

I was once on the receiving end of a backseat driver trying to get me to change my priorities. I was a mid-level engineer at the time. He grabbed me and another mid-level engineer and took us into a conference room to talk about a project that needed to happen. It was urgent. He could not overstate the importance of the work to us. The problem with his approach was that he didn’t check in with us about what pressure we were already under. He didn’t ask what we were already working on. He didn’t check with our manager. He was directing us in a vacuum. Meanwhile, I was stressing about my own deliverables at the time. I had my own manager and teammates to worry about disappointing. It felt terrible.

Folks doing this kind of thrashy behaviour likely see that they need to be more team-aware, but they haven’t really let go of their individual-heroics mindset. They know they need to work with the team, but they don’t (and sometimes won’t let themselves) see how to do that productively. Being directive of others feels like technical achievement. It’s something they can tell their manager they did. It contains a healthy dose of the action bias.

It’s also sometimes the case that this person genuinely feels misunderstood by the people involved. They believe they’re the only one who really understands what must be done and they feel the ends justify their means. Sometimes this is layered in with a healthy dose of mistrust of the people around them, managers, and/or leadership.

What this person is still missing is that there’s likely a whole world of additional factors at play. They don’t yet see just how crucial it is to understand the situation fully before intervening. They’re tottering around the edge of real team awareness, but staying safely within the envelope of individual achievement while causing massive team drama.

The Manager Hounder Senior Reaction

When a senior engineer has finally started to put team alignment ahead of individual action, they’ll likely gravitate to talking with tech leads and managers. This style of reaction has a few subtypes, but it’s generally quite a milestone in the senior engineer’s growth.

The first degree of this interaction is still directive. When a backseat driver realises he or she is causing thrash by grabbing individuals and telling them to change what they’re doing, that person might start to push on the manager instead. This is strictly better for the health of the team. After all, it is the manager’s job to balance priorities, absorb intensity, and keep the team running smoothly doing the right stuff. Talking with them first removes the thrash from the team overall. Notice how this senior engineer doesn’t throw work over the wall or make grandiose internally posts. They also don’t grab individuals and thrash them. Those are three pieces of team thrash they avoid.

They do still thrash the leads and managers though. A highly motivated, unaligned tech lead can cause other tech leads and managers massive amounts of stress. I’ve watched managers leave exhausted from discussions with these kinds of engineers. The manager is often boiling inside as they tried to diffuse an ardent tech lead who is hellbent on thrashing their team.

The reason these senior folks still cause trauma in the org is that they’re still not considering the full picture. They see only what’s within their immediate purview. They only see their own priorities. Going back to the hypothetical problem, they only see the needed technical changes and it feels absolutely urgent to them. They tend to believe they’re advising the manager, but they’re actually not. Advising without full context is just varying shades of shouting an opinion.

What they don’t see is how much work that manager might have been doing to align that team already. Maybe there’s a performance problem on the team. Maybe the engineer responsible for that system is already on the brink of being fired. The manager legally cannot tell this senior engineer these things. It’s entirely likely that the manager and the manager’s manager (if there is one) and the leadership folks are already aware of the tradeoffs being made. Everyone up the chain knows and it’s just this one senior engineer who isn’t aligned. And he or she doesn’t know it. A hallmark of an engineer stuck in this level of seniority is that they will ask questions like, “How was I supposed to know that?” when they discover they’ve caused thrash on the team.

Often people get stuck at this level of seniority because they underestimate how much one person can understand about a team without being a manager. These engineers tend to wall off “technical stuff” from “people stuff.” When they see a “people stuff” problem, they treat it like someone else’s dirty laundry. From these sorts of engineers I hear things like, “Ugh, I expect my manager to unblock these kinds of problems for me” when they’re presented with tricky team dynamics. They’re not wrong about that being a huge part of a manager’s job. What they’re missing is that other engineers who are more senior than them probably don’t have that kind of attitude about team dynamics. More senior engineers than this have a much more nuanced perspective about when something becomes their manager’s problem, which we’ll talk about in the next two sections.

This level of engineer might also have an us-versus-them mentality towards management. Senior folks sometimes think of management as the bad guy. The people you shouldn’t trust. Honestly, fair enough. There exist some perfectly toxic managers in the industry. However, treating anything beyond the management veil as other or dangerous or disdainfully non-technhical only costs the senior engineer over time.

The Advising Senior Reaction

At this level of seniority, things change a lot. Senior engineers at this level of team awareness tend to invest a lot of energy in executing the Chesterton’s Fence thought experiment about the current situation. They step back from the problems they see overtly and think, ‘What might be behind this problem that isn’t obvious?’ This often leads them to their own manager first and then frequently to the manager of the problem area they’ve discovered. Importantly though, they go with questions, not direction. They hold in their mind the possibility that what they’re seeing is already as good as it’s going to get and that more input or direction or urgency wouldn’t improve things.

Better senior engineers know that when you work with the manager who is accountable for a given problem area, you give them a chance to inform you about the why and the how of the current situation. Good managers love to create clarity. They will eagerly share context. This level of seniority includes a huge shift in the degree of shared context between the engineer and the tech leads and managers they work with.

Most senior engineers understand that there are things the manager can’t tell them for legal/HR/privacy reasons. Bad senior engineers will take comfort in this, remaining wilfully ignorant of team dynamics. Better senior engineers understand that managers can say a lot without saying anything explicit. Discretion and the ability to extrapolate from incomplete interpersonal information are bread and butter management skills. Importantly, the most senior engineers tend to have exactly these same skills. They don’t need to be told that a given junior engineer is on a performance improvement plan and in danger of being fired. When a very senior engineer looks at the junior person’s overt performance (code written, tasks closed), looks at what they are or aren’t doing on the team, and hears their manager say a sentence like, “we’re working with <that person> to make sure they’re set up for success,” the senior person knows everything they need to know.

Engineers who reach this level of subtlety and discretion tend to win the trust of the managers and the other tech leads they work with. It’s counterintuitive, but by being better listeners, these engineers become the people that the managers seek input from. They are advisors because of how much they listen, not how much they talk.

Whether or not a given engineer moves beyond this level of seniority usually hinges on what they want their job to look like. Some very senior engineers just want to be technical, solving super hard problems, and don’t want to solve people problems. These folks will have the ability but not the interest to move beyond this level of interpersonal seniority. They also have the awareness required to stay at this level of broad team-wide impact without causing thrash. That’s totally fine. All tech companies are desperate to keep these kinds of self-aware, thoughtful tech leads in their ranks.

To level up beyond this level, it’s really helpful to switch to the management track for some amount of time and then switch back. Honing the skills of active listening and decoding interpersonal dynamics is crucial to advance from here. Likewise, understanding how the management apparatus at a given company actually works is crucial for being effective as a high level individual contributor.

The Team Elevating Senior Reaction

At this level, senior engineers have long ago embraced their role as someone who never creates drama. And they take it as their duty to know when they might be venturing into sensitive situations. Compared with folks earlier in this progression, you’ll never see a senior engineer of this level asking a question like, “How could I have known that?” This level of leadership has baked into it the expectation that you observe until you really understand what’s going on. You perceive and gather context richly before you do or say anything.

Engineers who reach this level of awareness look for opportunities to align and elevate the team. We often imagine very senior engineers as technical visionaries staring at terminal windows for hours on end doing “algorithms”. Sometimes that is it, but very often it’s not. Sometimes it’s purely technical mentorship. Other times it’s spotting cross-team dependencies and resolving them. Other times it’s just scoping different approaches to decide which direction to take. A lot of the time it’s delivering complex, multi-stage technical projects that touch many teams and layers of the stack.

In most tech companies, 90% of the problems are solvable by early senior or mid-level engineers. The very senior engineers know this and don’t seek to amass their own list of personal technical contributions. Instead, they look for opportunities to scope and delegate work for junior people to grow into. These senior engineers often make promotion opportunities for others.

For the small number of extremely difficult technical problems, this calibre of engineer will typically solve the core of the problem via lots of deep thinking, consultation across teams, hard-earned wisdom, and experience. Importantly though, they almost always follow this up by breaking the problem into smaller, coherent parts which — you guessed it — they delegate to more junior people.

A top-level senior reaction to a situation like what we’ve been discussing here would include all of these considerations (very likely in this exact order):

1. Hm… something is wrong here. This system seems really poorly built and it’s going to cause problems.
2. I could do the work to fix it, but I don’t need to do it. People more junior than me can do it and I could possibly support them. Maybe I can help a junior team member level up by delivering some technical improvements here.
3. Hm… there are people already working on this problem, I wonder why they haven’t solved this problem in a better way already.
4. I’ll go read through some commits and code reviews then I’ll decide if anything needs to happen at all, maybe I don’t see all the factors involved yet.
5. My manager (if it’s not the same person as the manager of the folks on the problem project) probably has some context here. I’ll bring it up in a private conversation. Maybe this is the end of the conversation because my manager shares enough context that I see the problem is owned and being handled. If not…
6. The manager supporting these folks definitely has more context, I’ll have a 1:1 with that manager and ask how it’s going. If that leads to more questions…
7. I’ll continue having one or more conversations — listening 90% of the time. I know not to be alarmist or leading here — I just want to understand first.
8. Across these casual chats, I’ll try to understand the team dynamics and technical issues in high resolution
   1. Is it a lack of technical leadership? If so, can this be fixed with a few conversations with the engineers working on the problem? Maybe the engineers working on it just inherited a broken system and are working hard to replace it already, but I haven’t seen that work yet.
   2. Is it a problem with the performance of the team? If so, is there anything productive to be done? When I talk with the manager, I’ll listen for the words between the words. Maybe this problem has to persist until the person causing it is removed from the situation.
   3. Is it an organisational problem where something isn’t well-owned? Is there some other complexity involved around cross-team dynamics? If so, is this already understood by senior managers upstream? If not, that might be another conversation to have.
   4. Is it something else entirely and if so, what/why/how?
9. Now that I understand the situation richly, I’ll convey this shared understanding back to the other folks involved with equal discretion to how they informed me.
10. Collectively, we’ll consider ways to engage with the situation that could be beneficial. We’ll all bias heavily toward only doing things that will definitely help. I’ll absolutely avoid just doing something to see what happens.
11. Very likely the answer is that there is nothing better to do at all. In this case, do nothing. Keep the problem on the radar, but move on to the next problem to solve for now.
12. If there is something to do, execute the manoeuvre in a way that conveys calm confidence and in a way that elevates the team. Maybe this is a few conversations with a struggling mid-level to get them onto the right path. Maybe this is connecting members of two different teams that didn’t know about each other’s efforts. Maybe this is helping a manager gather performance feedback to help a junior improve. In all cases, I’ll talk to the fewest people required to make it happen. This is about getting the right outcome, not about amassing personal glory.
13. Along the way, I’ll feed back to the folks involved what I did and how I did it.

This is the “real Gs move in silence” approach. There is silence because they’re discreet and calm and never create drama. There’s also silence because in many cases, the senior person will conclude that there’s actually nothing to be done.

A lot of the time, the team is already doing the best thing possible. When these senior folks do discover something that needs intervention, it’s very likely to be a completely new problem that no one else has discovered yet. Not because they’re galaxy-brained, undiscovered-problem-truffle-pigs who only ever strike gold. Rather, it’s because they patiently and thoughtfully discover and suss out problems constantly. Often they’re busy trying to achieve some other, higher-level technical goal and they stumble onto blockers along the way which they must address in order to deliver the bigger project. This is a huge point of distinction between the ‘Real Gs’ and the folks who make dramatic internal posts or publish manifestos.

This sort of thoughtful problem navigation is extremely valuable to the team’s and company’s success. Less senior people will be busy making dramatic posts about problems that have already been managed as effectively as possible. The more senior person will already have done their homework on the same issue and moved on without wasting any time on drama or thrash. By the time the dramatic engineer is responding to their long chain of replies (which shows the cost to the organisation of high-drama — other people getting drawn in), the more senior person is working on a problem no one else is even aware of yet. When the very senior engineer does engage, they do the least dramatic thing possible. They lift people up. They make opportunities for others. They create clarity and accountability. This steady hand makes them crucial and reliable members of the team.

Because they always bring value, their work tends to be regarded with a sense of reverence by others. Less senior engineers will try to finagle this sort of reverence in all the degenerate ways I listed above, but without seeing the real impact of the very senior folks. When there is a more subtle, less aggrandising way to solve a complex team problem, the most senior person finds it and executes it. Often the most senior folks’ work is understood fully only by managers and other very-senior people. Many times in my career I’ve seen early-senior folks question the impact of much-more-senior-than-them folks. It often takes the form, “I keep hearing how senior they are, I just don’t see any evidence of it.”

That’s because real Gs move in silence, like alignment.