The dangers of pulling rank as a Staff+ engineer

Throughout your engineering career, you’ll never stop getting into disagreements about code, architecture, and technologies.

What does change is how those disagreements get resolved and by whom.

Early in your career, it’s common for managers to resolve disputes among peers. Senior developers will tell junior developers what technologies to use and how to design the code. Hopefully, they’ll teach and explain their thinking, but often they simply pull rank and issue edicts under the power vested in them by managers.

As you cross over from a senior engineer into a senior individual contributor role like staff engineer, you implicitly lose the ability to pull rank. You no longer have power vested in you by managers. Managers don’t want to resolve who is right; they want you to be effective.

Most importantly, even in situations where you can pull rank as a staff engineer, you shouldn’t. Influence as a staff engineer comes from building trust and camaraderie. Forcing teams to do something your way, because of your seniority, destroys everything you’re working towards. When the rare situation where you can pull rank arises, resist the temptation!

Resisting the temptation to pull rank

As a staff engineer, I know it can be tempting to pull rank. An example that sticks in my mind is when my team was working on the number one priority on the company’s roadmap, and I felt we were being blocked by another team.

Our website wasn’t scaling well, and the main page loaded slower as clients got bigger. It could take 90 seconds to render for our biggest clients. Even the median time of six seconds had people rightly complaining.

To ensure our clients had a quality experience, leadership set a goal: get the load time under three seconds for everyone, including our largest clients!

First, we fixed the scale issues so that the page loaded in the same amount of time for everyone, then we worked to get the median down from around six seconds to three and a half seconds. That’s a 42% improvement for most clients, and 96% for our biggest clients.  But that last half-second remained and needed ‘just a little more optimization’.

Looking at the existing code, I found it was making a REST call on every page load to a service to check if a client had a feature enabled and if the current user had permission. Doing the call added 50 milliseconds to every page load, with occasional spikes up to 90 seconds. ‘Ah-ha!’ I thought. Here’s 10% of the optimization I need, wrapped up in some intermittent bug that we need to fix anyway. Simply add more servers and client-side caching and a week later we’ll only need to find another 450 milliseconds!

I approached the other team, and the nos began:

Can we add client-side caching?
No, we can’t cache the data on the client side. What if the permissions change between clicks? We can’t have the user waiting for the cache to expire.
Could we add more servers to address the latency?
There shouldn’t be that much load on the servers.
I agree, but the load exists.
We’ll have to look into it, but it’s not on our road map.
Could we cache the answer for one minute? That would reduce load by about 80% and hopefully get rid of the latency spikes.
But then changes wouldn’t be instantaneous. We would need the product owners to sign off, and they’re too busy to look into the issue.

This is what’s known as ‘being blown off’. The manager had decided that the answer was ‘no’, regardless of the client impact or the scope of the proposed solutions.

I could have asked the VP of Engineering, or even the CTO to step in. As a staff engineer, I outranked every dev on the other team. By org chart, I was a peer of the manager. My team had priority – the number one priority! The issue was a bad design, bordering on being a straight-up bug, and the latency spikes were a production issue regardless of design!

By golly, I was right, they were wrong, and we should do it my way!

I’m confident that if I had reached out and pulled rank I would have gotten the feature removed.  I would have my 50 milliseconds.

But I would have lost, because that’s not how a staff engineer works.

Pulling rank wins today at the cost of tomorrow

If I’d pulled rank, I would have lost influence with the VP for making him settle an argument – especially because it was a low-stakes argument. Architectural decisions with subtle implications for our business model, sure, bring it to the VP to settle. A team about to do something illegal out of ignorance? Bring it up! Caching a single REST call? Never.

I would have lost influence with the manager, and the managers in general, for going around them. Blowing off a peer is rude. Go over your peers’ heads, and they won’t see you as a peer for long.

Most unforgivable, I would have lost with the developers on that team. Overriding them with managerial dictations instead of developer solutions would have made me a manager, pushing from the top down, instead of leading from the bottom up.

By pulling rank I would have lost more than I gained. I wouldn’t even have achieved the company goal of three-second load times. Page load time is a journey, not a destination; performance is a constant battle of new features, tweaks, and scale. 50 milliseconds was nothing more than a stepping stone.

Instead, I settled for fixing latency spikes. Hundreds of users were saved from 90-second page load times. The client experience improved even if it didn’t move the needle on the average page load times.

A better approach

Don’t think I gave up on those 50 milliseconds though. I also continued to push; instead of asking the VP to settle who was right, I asked for help on how to engage with the other manager and team.

Asking for guidance works in three ways:

• it engages the VP to help find a solution instead of demanding that he solve the problem for me;
• I’m likely to learn new ways of working with my new managerial peers;
• it lets the VP know there’s a problem without putting him on the hook.

Five months later, I found a solution that made an even bigger impact on the same root issue. Because I was on good terms with the lead developer, I was able to hop on a call with them and outline the issue. During the call, we noticed a simple 2-line change that would eliminate over 99% of the problem.

I made the change, he approved it, and it went into production the next week. That’s an interaction that never would have happened if I had pulled rank.

Why staff engineers should never pull rank

To summarize, pulling rank burns you:

• with leadership because you make them solve the problem;
• with managers because you aren’t negotiating priorities. You’re playing zero-sum games instead of going for win-win;
• with developers by dismissing their decisions and priorities in favor of yours.

On the other hand, not pulling rank helps you:

• engage with leadership by asking for guidance instead of solutions;
• maintain your relationships with your peers in management. The manager who rejected your idea is probably a lost cause but you won’t make an enemy or make it personal, and other managers will keep seeing you as a peer and not as a difficult developer. This difference is critical if you want to remain their peer;
• engage the other devs with some outside-the-box thinking. Maybe it goes nowhere this time, but over the long term, showing up and asking for help leads to more help than showing up and demanding your solution.

Reflections

As staff engineers, it really doesn’t matter if we’re right about a feature being unnecessary or badly designed. It really doesn’t matter if we get the performance metrics to a certain number by a specific date. That’s all transitory. Sometimes we’ll be right, sometimes wrong. Sometimes the pages will be faster, sometimes slower. The most important thing we’re building is trust and comradery, and we can’t do that by pulling rank.