How To Lead Engineers Who Don’t Report To You

SubscribeSign in

How To Lead Engineers Who Don’t Report To You<br>This is about leading engineers, but the first sentence will piss a lot of people off.<br>Ryan Murphy<br>Aug 09, 2026

Share

This was 100% written by a human. Me. No AI ‘in my voice and tone’ was used. I wrote, researched and did the graphics. If I want you to take time to read this, you should expect me to actually write it. Fight against the slop.*(see end of post)<br>One of the most difficult tasks in Software Engineering isn’t technical. It’s leading engineers who don’t report to you.<br>This might be engineering managers having engineers from another team on a project; typically, the people who feel this the most are in non-management positions. The people who feel this the most are tech leads whose role has high expectations but low formal authority.<br>This is a MUCH harder problem to solve for ICs and Tech Leads who have no formal authority than engineering managers who do.<br>Say what you want, an EM, even the ‘servant leader’ archetypes who are there to only serve their team and tend to try to lean on the management aspects of their position the least, still have a, maybe subconscious but still significant, sway over the engineers they can bring PIP proceedings against if they really wanted to.

It’s much faster to reach compliance by leading with authority, but that’s where it will stay. Tech leads and ICs do not have that unspoken reality; they must lead with influence. And leading with influence is much harder than leading with authority.

Subscribe

The 5 bases of power

In 1959, social psychologists conducted a widely cited study on the bases of power. Ultimately, they found that power comes in 5 unique forms: reward, coercion, legitimate, referent and expert.<br>If I could put the outcome into one sentence:<br>When someone does something that you wanted them to, there’s a reason they did it. Why they did it is more important than the fact that they did it.<br>Let’s use an example, purposefully obtuse, to understand the difference between the 5 forms of power. Let’s imagine that you want the other people on your team to start writing more tests. Let’s also imagine that they did it. That’s amazing. But why? The 5 bases of power say it might have been because:<br>They got something out of it. Bonus? Good review? Promotion? (reward power base)

They know you can damage them? Bad review? Put them on trash projects? Pip? (coercion power base)

You’re the boss. You do what the boss says (within reason and safety, of course, but remember this is an obtuse example). (legitimate power base)

They look up to you. They really want recognition from you. (referent power base)

You’re just damn good. You never steered them wrong before. You are known to have good judgement. (expert power base)

Now, you go away for 2 weeks (I’m thinking Barbados), one of two things will happen:<br>If the reasons they did the extra tests were 1, 2 or 3, then they did it because of you. Without you, there is no reason to write the tests or go above and beyond.<br>If, however, the reasons they did the extra tests were 4 or 5, they did it for their own reasons. They were convinced the tests were worth writing.<br>A manager can use all 5; a tech lead or IC can’t.

The 5 bases of power are often portrayed as all or nothing; it’s one or the other. I view it as more of a radar where you can be stronger in some than others. I think the nature of people, leadership and management is so dynamic with modern understanding that it possibly can’t play out any other way.<br>We still haven’t discussed how to actually lead engineers who don’t report to you.<br>They better trust you

There are 3 parts to trust here.<br>They need to know that you will lead with empathy and be sympathetic to the daily trials and tribulations that we face not only as software engineers, but as humans. If they feel you are down their neck at the smallest situation, they won’t trust you; they will comply with you. If you instead fail publicly and show that it’s a safe place to do so without fear of escalation, then they will learn to trust you.<br>Be honest. A lot of people, I see this a lot in new engineering managers, think that giving something 2 more weeks to change, or sandwiching feedback, is kindness. It’s not. I remember Taha Hussain, when I was on a call with him one time, saying a true friend would be upfront with you because they actually care for you, whereas someone else would skirt around the issue to save their own face. Is something not right? Tell them. Got some news about a project someone has spent weeks working on? Tell them.<br>Do what you say. Everyone has been in a meeting with their manager or someone else that you view as a leader, and they say something along the lines of: ‘yeah, let me get back to you on that’ or ‘let me put that as an action for myself; I will let you know’. Everyone has then experienced it when they never got back to you, or they never actioned that takeaway....