I hate it when people mix terminology together. For me: a leader is the one that sets the direction. A manager is the one that supports the team so they can do their job. Those are 2 different responsibilities. Sure, they can be combined into 1 person, but don't have to. So for me it's always weird to read articles where they interchangeably use "manager" and "leader", as if it's the same thing. No it's not! And there the problem starts where companies think that a "manager" == "boss". NO! A manager is at the service of their team!
For what it’s worth, the book this article is based on explicitly talks about these two different responsibilities and why a manager (by title) will always have to do both in some capacity.
And the amount of each responsibility a manager holds varies depending on level, like a “Director of Engineering” will be more on the “leadership” side setting direction but they still need “management” of their direct reports (other engineering managers or managers of managers), whereas an “Engineering Manager” will likely spend more time in “management” at the service of their team of IC engineers.
I hope you also do a performance review of your work environment and wage. If your "boss" doesn't qualify, just go work somewhere else.
I always look at it like this: If I get fired, they need to hire someone, train them, and only after months they will come close to the productivity that I'm currently providing. In other words, it will cost them loads of time and money.
When I leave, I get paid >=100% at another place, from day 1 when I start.
You are in a much stronger position than you think. Of course your manager doesn't want to make this too obvious ;).
You have an easier time firing your "boss" than the other way around, don't forget that.
That's all fine - but if somebody has the power to fire you then they are your boss. Yes, a manager's job contains many responsibilities. But they are not just a coach and people should internalize that. If you want somebody who is just a coach or a mentor, find somebody outside of your reporting chain to do that.
I'm a freelancer. It basically means I do exactly the same job as an employee, and can be "fired" for the exact same reasons as an employee. But I never consider my customers as a "boss". If they don't want to work with me anymore, I just find another customer.
And in the end, the difference between freelance and employee is just a legal one.
I never understand why some people willingly put themselves as a "servant" of "the boss". It's a very limiting view on the world. Why not view it as a win-win relationship, where if either party doesn't have any benefit, you can just leave. They pay you, you do the job. They are literally buying your service. If you want to put yourself in a position where "you have to do what they tell you", that's all fine by me. But I will never put myself mentally in that position, because it really is not like that. I don't have to do anything, I'm selling my service under very strict conditions.
Agreed. I suspect in this case it's his military background. That is, your immediate superior is your leader. Afaik, in that scenario you don't have much room for push back, etc.
Regardless, confusing leader and manager is going lead to both failing (or at least coming up very short). That is, if a manager is failing sonewhere there's a failing leader.
Put another way (as I already left in a free-standing comment): If management is failing...it's because leadership is failing. Whether that's culture that's lacking, or training and development given a back seat, failures - with rare exception - should be by definition owned by leadership.
A good manager can to some extent shield a team from subpar leadership. But not always, not forever. Eventually, poor leadership will tilt the game. That's not managers' fault.
The distinction you make is correct and important.
However, when we do break it down that way you start realizing that nearly everybody has to be a leader, but at different levels.
Your CEO has to be the leader for the company setting the vision and direction for the entire company. Your department head has to be the leader for the department setting the vision and direction for the department that best allows the department to fulfill the CEO’s overall vision. The manager has to do the same for the team. And every IC has to do that for themselves individually.
Every good manager will also necessarily also need to be a good leader.
Leader and manager being different person is quite rare. Mostly because it is unstable setup - the leader will be out of touch, the manager will dethrone the leader. Unless the leader has some additional power.
Also, manager that has not have sufficient power over decisions is just secretary.
In a software development context, the functionality should be specified by analysts, not by the manager. The technical architecture should be specified by an architect, not by a manager. The development process should be steered by the conclusions of retrospectives, not by some management vision.
To be honest, the best places I worked at was where the manager was at the service of the team, relying on all the experts. Never the manager that thought he knew better than everyone else.
Analysts are not leaders by literally any reasonable definition. sometimes they don't even add own vision into the mix, but instead have to fill in somebody elses initial vision with details. Specifying technical architecture is being leader to some limited extend. But it is leading one aspect of the development, that all.
> The development process should be steered by the conclusions of retrospectives, not by some management vision.
Retrospectives are actually run by managers and whether they are useful or not depends primary on the person that is running them.
Then there are things like: setting priorities, negotiating with customers, negotiating with other teams or upper management, deciding what will be promised and what wont. How much of the testing will be done, what is the target quality, final decision on whether to hire or fire people.
Final contract is definitely not done by sales. That would be ridiculous as they have literally zero knowledge over how much the thing should cost and when it could be done. Maybe if you have packed done software where you are selling it without making contracts about future features.
The negotiating is done by manager.
> This is indeed done by a manager, but I don't really see how the "leader" fits into this. It's more of a management function
If you cant do this, you cant lead. Because these negotiations are key to both what resources team will get and to what will be expected from the team. Everyone else then need to fit their visions into whatever was agreed on here and in discussions with customes.
> I hope the manager discusses this with the team, and that it's actually the team telling the manager, and not the other way around.
Discussing with others before making decision does not make you not not lead. But, the idea that discussing with others somehow excludes you from leadership position explains why there is tendency to attribute leadership to less powerful positions that indeed discuss with others less.
Not sure where you worked, but in my last 18 years of experience over some 7 companies, if the team is big enough, there is always dedicated PM and dev lead (and test lead etc.).
Sure its doesn't apply to some 2-man projects but anything sufficiently large requires this division. I've seen control freaks trying to hold many seats on their projects but it never ends well (either heading to burnout or just not being able to tackle it all)
> if the team is big enough, there is always dedicated PM and dev lead
The PM there is leader and manager. The dev/test lead are managers of smaller sub-teams or aspects. But, the actual project leadership belongs to the PM, not to test lead.
> “We tend to select managers either based on their tenure or because they were the best individual contributor on the team,” he says
I wish that were true. But in my experience, the people who seem to be promoted are the 'climbers' - the ones who are looking for opportunities to get ahead, and are less interested in actually performing well at their jobs.
Promoting the highest performers would be actually a great idea - imo, one of the key properties of a good hierarchy is buyin from subordinates - seeing someone get promoted who is more experienced or a better coder than me signals to me that I should give that person's opinion more consideration, and if I improve my craft, I'll be eligible for promotion as well.
Instead usually the people who get promoted are the ones who suck up to their (likewise incompetent) bosses, say yes to every harebrained scheme coming from up above, rather than pointing out the flaws, and demonstrate 'leadership skills' by posting '5 ways to supercharge your code'-style articles in the group chat.
Once these climbing yes men start getting promoted, they show a preferential treatment to their own kind, and the organization's days are numbered.
That's why 'non-technical manager' is a contradiction in my humble opinion.
> Promoting the highest performers would be actually a great idea
If they are genuinely interested in the management career, I fully agree, otherwise I'd be more cautious since engineering management is a very different job.
A top performer may be a better fit for a technical specialist role, keep producing high quality apps/systems/code, mentoring colleagues and shaping the technology within the company.
Generally the problem is, in many (most) companies, management track is the only track.
I'm not sure how many companies have the maturity of recognizing that management stuff is just one of the things one must do, which some people have a knack/passion for, like devops or talking to customers.
Most companies have an org chart, and the level of success/pay correlated to how high you are on said chart (in no small part due to your pay being determined by the person above you).
This is an unfortunate reality, but truth is, programmers can avoid this BS to some degree, because can jump ship any time/start contracting, but this is even more the rule in other industries, that some paper pusher out-earns the movers and shakers.
> the people who seem to be promoted are the 'climbers' - the ones who are looking for opportunities to get ahead,
That makes sense to me. They want to actually be the manager. I'm above average developer and could make a decent manager but fundamentally I dont want to do it.
If you become a manager you still don't get to veto who becomes your manager - and I assume there is no difference is the level of misery inflictable upon a report just because they themselves have reports.
I don't think it's a reasonable counter. Enjoy the work you do, otherwise what's the point in being lucky enough to be selective?
Yeah, in my experience, there is a BIG difference. Having a manager who is a bad fit for me has been far more difficult when I've been in management roles than when I've been in IC roles. And it was even worse for me when I was managing managers. Many of the problems (and many of the good things) created by my manager scaled up with the number of people reporting up into me. As an IC, I could minimally comply with any BS requirements and use the rest of my time to create actual value. As a manager, performance is much less directly attributable - it's easy to claim that anything less than full compliance is hurting performance, even if that's the opposite of the truth. Paraphrasing an actual feedback conversation...
VP: "I've heard for years that you're an incredible manager that gets great results. But now that you report to me, I'm confused. You can't even get your engineers to fill out the daily status reports I told everyone to do. I think your engineers stay at the company longer because you coddle them."
Me: "I think I get results because my management approach, among other things, doesn't involve engineers filling out such reports on a daily basis. I told them they don't have to as long as they surface problems to me right away so that I can keep stakeholders informed. I've found that this allows them to stay focused, leading to better project outcomes and happier engineers."
VP: (literally laughs out loud) "No, seriously, they need to be filling those out daily. You're holding them back."
The leetcode grind is playing a game in some respects, and I don't see this as any different. Management was doing this before leetcode was a thing though.
>Once these climbing yes men start getting promoted, they show a preferential treatment to their own kind, and the organization's days are numbered.
I don't think so. If there were actually company-ending consequences, you'd see this stuff around a lot less.
I see a lot of preferential treatment for stuyding/passing leetcode interviews as well. There's also a counter-culture to it which has preferential treatment for people who don't like leetcode.
To me this just seems like company culture in America and instead of ending the company, it keeps it going.
I didn't mean leetcode-ability when I was talking about technical competence.
Why I think leetcode has its place (in interviewing), I think there are far better measures to determine ones technical contributions inside the company, like if someone writes a tool or script to automate a major hurdle saving tons of hours, or is capable of consistently providing high quality insight or elegant solutions, that is a very good benchmark for technical ability.
>Promoting the highest performers would be actually a great idea
That's actually a terrible idea. You lose a major contributor to your output and nothing in that person's skillset is necessarily related to good management practices. There's a reason Jeff Dean isn't CEO of Alphabet.
This is so generic as to be useless. A great manager can read this and nod along to most of the ideas. A terrible manager can cargo cult everything here and claim to be doing a great job.
Broadly speaking, there are two reasons managers fail: either A) they don't do a good job representing the work of their team sideways or upwards or B) they don't do a good job representing and cascading the strategic direction from leadership.
While there are many specific modes of failure, they all essentially boil down to one (or both!) of those gaps. The article talks about the Peter Principle where ICs are promoted without management skills, but the flip side of managers who only studied management with no practical expertise is a greater peril. It's obvious when the former is failing, whereas the latter can spin a web of bullshit long enough to continuously fail upwards.
I don't disagree with your observations of common failure modes, but I actually found this article quite concrete and actionable compared to much of the "productivity porn" that gets posted here.
C) They don't do a good job in shielding the team sideways or upwards from external pressures that are not aligned with the strategic direction from leadership
Your two points are important but the best experiences I had _always_ had a manager who effectively filtered out the noise/nervousness from external sources (including from leadership). That means the manager is likely taking all sorts of blunt force trauma along the way but the team is allowed to focus and be clutch.
I think about this sometimes. What about being a somewhat transparent shit umbrella? Like you don't let the team get hit by the shit, but they know that it's raining shit out there. I think it helps put some trade-offs in context.
This is most of my approach. I let the team know what nonsense is coming from up above, what my strategy is to avoid it, and offer options for suggestions on how else we can deflect the bullshit.
Often, we come up with really good solutions which get sent back upstairs for them to digest and shit back out on us in some other, stupid way.
But at least the team feels valued, understands how they fit into the organization, and understands that if an idea dies, it's because of institutional inertia that is out of their hands. It at least helps with the frustration.
This is just managing down. You gotta communicate with your team about what's going on and why.
Being a good umbrella isn't about hiding the rain, it's about keeping it off of them. In fact, hiding the rain is a bad idea, because eventually, people think they don't need the umbrella.
I acknowledge the reductiveness of what I'm saying, but it's absolutely not transactional. To the contrary, understanding and distilling broad contexts from which you have only partial visibility is incredibly difficult work and easy to get wrong. Influencing without direct control requires sustained learning, relationship building and self-reflection.
My point is that all the nuance and subtlety of management is easy to get lost in (especially if you go straight into management without strong baseline work experience). Coaching, Culture Building, and Career Planning are all important components, but you will not do a good job at them if you don't understand A) the work and B) the business context and strategic direction.
One big reason I see why managers are failing is because nobody really helps them to become good managers.
When you move from a developer to EM position, very often all the support you get is "good luck!" and a pat on the back. I've worked at a 1,000-people software development company where there was 0 training or even proper onboarding for managers, there was no community for EMs so that they can help each other, there was absolutely no effort to help managers improve.
As a developer it was much easier for me to improve my skills - I worked with other programmers, saw their code, they reviewed my code, we programmed together. When I was a mid-level dev a single pairing session with a principal developer opened my eyes to so many things. As a manager I lack such opportunities, and employers ignore it.
Managing people is a specialized skill. Both employees and employers should require that those in management positions have the necessary training and credentials to perform the task. This means either taking a specialized management curriculum at university or being put through a comprehensive management training course.
It takes four or five years of education at a University to get an engineering degree, yet businesses somehow find it acceptable to make anyone a manager regardless of whether they have been trained.
The funnel for promotions has started to get thin at this level, and leadership positions select strongly for people who like being promoted.
Individuals might perceive the situation more collaboratively. As a body though this is a group where every individual is competing and unlikely to spend time educating others who are, effectively, rivals.
I completely agree with this. I've always been curious as to why so many other roles get proper training but not the role of manager, which arguably has an even larger impact.
I have been an engineering leader for over 10 years and in all this time I received almost no training or coaching. I was pulled up from my role as an engineer.
For the past 6 months I have been working with a remote leadership coach and it has been incredible! My coach is extremely experienced and alternates between prompting me to solve my own challenges and sometimes just telling me what to do in a given situation.
I highly recommend it to anyone in a leadership or management role.
1. I have had a string of bad managers at both good and bad companies.
2. I want to set direction and work with people but I do not want to be a line manager.
Now I need to figure out how to find somewhere with good leadership that will invest in me growing the way I am interested in growing building teams instead of tech or I need to build my own company the way I want it to be where people are first and the tech is second. No smart jerks, etc etc.
Exactly this. I'm TL for a large team. I get to set strategic and technical direction for our entire org and manage no one. It's fantastic. If I had more time to write code, it would be my dream job.
If you are interested in building teams, line manager is the way to get there.
And if you think building your own company somehow lets you get around being a line manager... Unless you have a trust fund, I don't think that'll work. Pretty much no startup can afford to outsource people leadership until you've grown a good bit.
If you go the "tech lead" route in FAANG, you have some input into the building of the team, but you should be aware that's limited. Ultimately, the person doing the day-to-day leadership (the line manager) is the person who has the strongest voice in how the team is shaped.
What kind of growth areas do people look for anyway?
I'm like 15 years into my career, and I've grown, but none of it was necessarily intentional on my part. I've mostly grown when I was faced with an insurmountable challenge and my team/org/company would be screwed if I didn't surmount it, so I figured it out. I think it's safe to say that it was "the hard way" though
A great tech founder can scale a business to a few hundred employees while still contributing on an individual level. The typical middle manager, on the other hand, seemingly requires 100% time to manage < 10 people. Why is this the case?
My theory is founders are leading with a crystal clear, easy to communicate vision. That is the kind of management that scales.
Founders are also incentivized to invest much more time energy into their businesses than a middle manager.
Founders also shape their org structure to something that suits them, while a middle manager has to work within the constraints of their organization, which are often stifling with significant overhead.
Even basic things take inordinate amounts of time for middle managers. You could ignore them, but that often has secondary impacts like not taking care of your team (promotions, good reviews, training, etc.) or not getting your team the visibility it needs.
Visibility to whom? It seems like an anti-pattern that a team should have to fight for visibility in an organization. I believe this must be related to overly centralized control structures.
Yes, exactly. Large organizations are full of anti-patterns that middle managers must navigate. The gist of my comment was that middle managers have to wrestle with inefficiencies that founders don't. Said another way, founders define structure and middle managers inherit it.
I agree that such anti-patterns exist but they ideally should not. If shareholders and customers are not interested in these anti-patterns and inefficiencies then we should work to eliminate them.
And curiously, when they go on a vacation, their absence is rarely felt, except when encountering some administrative stuff that needs to be rubber-stamped.
I read a bit of this, and it struck me as some more generic fast food consumption, so I got bored. I've consulted for 5 F500's now, and by far the biggest issue with managers at these companies is that they still focus on managing people and not managing the flow of value.
In some ways, I think that's what the article is saying. I think the article takes the position that people are valuable and that investing in their success therefore creates value.
This is a great tl;dr - I'd still recommend reading the article though:
>
... a list of three specific management behaviors most closely aligned with employee engagement.
* Direction: Good managers ensure that every member of their team understands exactly what is expected and when it is expected.
* Coaching: Good managers coach their people towards both short and long-term success, helping them understand what they should continue to do and how they can improve.
* Career: Good managers invest in their people’s careers in a way that considers their long-term goals and aspirations beyond the four walls of the current company, and certainly beyond their next promotion.
