Stop overcomplicating it: A simple guidebook to upping your management game
review.firstround.com
review.firstround.com
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.
Also, manager that has not have sufficient power over decisions is just secretary.
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.
> 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.
Done by product owner
> negotiating with customers
Done by sales
> negotiating with other teams or upper management
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
> deciding what will be promised and what wont.
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.
> final decision on whether to hire or fire people.
This is the manager indeed
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.
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)
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.
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.
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.
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.
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.
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.
>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.
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.
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.
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?
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."
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.
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.
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.
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.
Lack of coaching, culture building, career planning are something that would also lead to failures.
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.
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.
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.
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.
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.
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.
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.
I'm figuring out a way to change this: https://larsen.ai
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.
edit: typos
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.
It would be someone experienced, who is still responsible for technical contribution (writing code, planing architecture, etc.)
1. What is their philosophy on team development? (Ask for examples)
2. What is the career ladder look like? When was the last person promoted to a Sr role?
In addition, you should lay out growth areas you'd like to focus on. A good manager should be able to work with you and chart a path forward.
On a side note: There are other online communities to help you level up while you are in your current role. DM me for recs.
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
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.
My theory is founders are leading with a crystal clear, easy to communicate vision. That is the kind of management that scales.
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.
Simple. Failing leadership (further up the stream). Full stop.
> ... 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.
Love this, very well said.