How To Lead Engineers Who Don’t Report To You
This is about leading engineers, but the first sentence will piss a lot of people off.
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)
One of the most difficult tasks in Software Engineering isn’t technical. It’s leading engineers who don’t report to you.
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.
This is a MUCH harder problem to solve for ICs and Tech Leads who have no formal authority than engineering managers who do.
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.
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.
If I could put the outcome into one sentence:
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.
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:
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:
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.
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.
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.
We still haven’t discussed how to actually lead engineers who don’t report to you.
They better trust you
There are 3 parts to trust here.
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.
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.
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. It doesn’t seem like a big deal at first, but it compounds, and when you speak to them in the future you just secretly roll your eyes and know it’s their way of fobbing you off to get the conversation done quicker. You aren’t their priority, and it slowly becomes more and more obvious.
All of these behaviours are continued behaviours. They need to be demonstrated over again, and some of the value can be lost during lapses. They go up and down, which is why everyone always says how important it is to be consistent.
They better know your value
At Yelp, I was one of the weakest technically on my teams. I’m not too proud to admit that. That’s not an admission of weak technical ability, but it’s an understanding that I was surrounded by people who were eventually hired at places like OpenAI, Anthropic, Meta, Uber and more. They were brilliant.
These people still highly believed in me because they knew my value, and I didn’t shy away from it; I embraced it. I know that because for 3 years running I got a 100% manager satisfaction score (much above the average) and all of the engineers messaged me to tell me I was the best manager they ever had when I left. That’s not to brag (ok, it felt good writing that), but it’s to demonstrate that when someone says ‘what value do you bring’ in a technical setting, it doesn’t always have to be so conventional.
For example, I am one of the best coaches you will ever come across. I am one of the best people at fighting your corner when you’re not in the room you will ever meet. I am one of the best people at giving context you will ever meet. But there are areas that I am definitely not (notice how I am not too quick to list them out with such passion?).
I encourage you to understand what value it is that you bring, because if you don’t know that, then how are others supposed to? Lean into those strengths and be upfront about the areas you will likely excel in and others where you might lean on others more.
We work in an industry surrounded by incredibly smart people who will see straight through anything else.
They better think you amplify
Just as I was writing this article, this post from Steven Syrek, a long-time internet friend of mine and Senior EM at DeepL, appeared on my feed, and it was too perfect not to include.
I went back and forth a bit with Steven; ultimately, this especially applies to people in a leadership position - read ‘leadership’ not ‘management’; anyone can be a manager, not everyone can be a leader. In leadership positions, we really need people to switch from being a doer to an enabler. That can be uncomfortable for some people as a lot of their gratification from work has always been fairly instant; now it’s earned through other people.
Final Thoughts
People often confuse leadership with management. How many people on LinkedIn have seen, as soon as they move into the role of ‘Engineering Manager’, change their headline to ‘Engineering Leader @ x’?
Who says? You? Or are you just confusing being a manager with being a leader? It’s probably the latter.
I personally think being a tech lead is one of the hardest jobs in tech. You have high expectations and low formal authority, which, in my experience, is difficult to get right.
It requires skills that will feel alien to the skills that got you here. Going from a doer to an enabler, when you have been getting stuff done for so long, feels like a natural battle to pick.
I made an accompanying video for this article, you can find it on YouTube here.
—----
If you like this article, please give it a like and/or a comment. It takes a long time to write stuff like this, and if you got anything from it, please help me out; a like is the best way you can help me.
You can find me here:
LinkedIn, X, Instagram, Threads, YouTube.
—----
Sponsored by:
EM Accelerator is the membership for Engineering Managers in their first 2 years or ICs/Tech Leads looking to step up into engineering management. It looks to help you become a confident people leader so the team don’t bear the brunt of your on-the-job learning. Included:
Community.
Flagship courses from a top-rated Dometrain instructor.
AI management simulator.
Expert Interviews with leaders at places such as Google, Meta and Salesforce.
Scenarios such as ‘survive your first 90 days’ to practice how you would handle your first 90 days on a new job.
Custom-built platform for its needs, none of this Thinkific/Kajabi/Teachable logins with a few videos.
You can do a free trial which doesn’t require a card, and you get a 14-day money ‘no-quibble’ money back guarantee.
Sign up for the free trial here
All paid subscribers of my newsletter get 25% off for life (that’s a ridiculous discount btw). Just message me for the code.
—--
*I am joining the fight for human-written content and against AI slop that people so often say, ‘but it’s my tone and voice, I trained it’. I am guilty of this; I have articles on this site and content on LinkedIn from when I first started writing earlier this year that I would regard as AI slop. Not anymore. This post took a significant amount longer to write (took me ages), but I believe the results are beyond worth it.
*For full transparency: https://www.pangram.com/history/ca69d218-fd9d-435a-8d73-33b54ffd8a90
