I consumed a lot of blog posts like this before becoming a manager. It feels satisfying to read vague principles like this:
> Facilitate wellbeing
> Personal safety, dignity, and wellbeing of every team member are paramount. Team success is only success if team members feel good about it.
But then you become an actual manager and realize that these are largely just feel-good aphorisms that don't really help navigate the hard work of being a manager.
Don't get me wrong: I think "facilitate wellbeing" and similar tidbits are valid advice. Likewise, a manager who chooses to not facilitate wellbeing would clearly be in the wrong. But when you get into management you realize that the hard work isn't waking up and deciding to facilitate wellbeing. The hard work often involves making unpopular decisions, or telling someone "no" when their pet request wouldn't be in the best interests of the team, or defusing interpersonal conflict among two team members who have been feuding for months.
These feel-good blog posts seem rather vacuous after being in the trenches of management for several years. Again, not because the advice is bad or wrong, but because it's just a lot of text around the basics of being a decent human being. Learning how to do the hard things about management or how to make unpopular but necessary decisions is something that you won't learn from the average blog post or LinkedIn post, largely because these function more as personal branding pieces than actual advice.
In my experience, the best management advice comes from talking to the best managers you know personally. Online, the most practical management advice comes on smaller forums where people are either anonymous (and therefore less interested in personal brand building) or older and accomplished (and therefore not worried about blowback impacting their career). The type of feel-good blog posts or LinkedIn blurbs that people associate with their personal brand don't really add much value after you've read 5-10 articles saying the exact same aphorisms.
Similar feeling. These principles somehow do not help me make decisions or build mechanisms for my teams. On the other hand, the principles in the book Turn the Ship Around, the book No Rules Rule, and Amazon's 14 leadership principles helped me a lot because they give clear guidelines on how to make trade-offs. In particular, Turn the Ship Around advocates pursuing excellence instead of minimizing errors. Netflix advocates Freedom and Responsibility. Amazon advocates working backwards (customer obsession) and making two-way door decisions. More importantly, they prescribe a system to balance trade-offs especially when there's conflicting choices. For instance, Turn the Ship Around explores how to make sure everyone delivers yet the leader can fully delegate responsibilities -- it's not surprising that it requires a system.
I was a bit skeptical of "Turn the Ship Around" because of its title, and despite all the positive reviews, but it's one of the best management books I've ever read. It's definitely worth a read, even if you're not a manager, as it applies to any team-related activity, and provides a useful toolkit for improving your team, whether you're the leader or not.
Jim Keller (helped design the spec for x86-64, was in management during Apple, AMD and Tesla's ultra successful periods) said when he was interested in management he just read like 100's of books on it, and turned out there was lots of really useful information that he applied and got great results from.
Hm. That's a generous take. Marquet lived the experience once. Now he goes around and lectures people in it instead.
I have all respect for Marquet and I agree with most of the things he says about leadership, as well as try to apply it daily myself. But my best reading of Taleb is that the sort of thing Marquet does (potentially get lucky, extract oneself from the situation, and then live off of the one experience), that's the opposite of skin in the game.
Sure it is. But, and this is a subtle point, he does not go around telling people specifically how they ought to invest, or how they ought to insure against tail risk.
He tells people how he invests, and some theoretical consequences of tail risk depending on input parameters.
It's a small difference, but, from what I understand, a meaningful one to Taleb.
> Again, not because the advice is bad or wrong, but because it's just a lot of text around the basics of being a decent human being.
Judging by the trends observed in the Great Resignation [1] and the popularity of forums like /r/antiwork, it seems that the basics of being a decent human being are often being overlooked by management.
I took a very different interpretation of what facilitating wellbeing looks like than you - interpreting facilitating wellbeing as being flexible when team members need some time to navigate their personal lives, scheduling project timelines and scoping work to necessitate productive work while alleviating burn-out, providing space for people to discuss ideas or provide feedback in a team setting, allowing for growth or transition into roles they may find more interesting or rewarding. Facilitating wellbeing doesn't conflict with making necessary but perhaps unpopular decisions, or de-prioritizing a pet project or whatever - it's much more basic than that.
Tech is hardly a paragon of good management. I can count on two fingers the amount of skilled managers I’ve had in my 15 year career. Both got promoted out of line management very quickly because they were too good.
Some have been truly terrible and abusive towards their team.
This right here is the juice. Generic management advice is like relationship advice. Be honest, care about the other person, respect the other person and so on. But anyone that's been in a relationship knows it's way more about breathing deep twice when you see the dishes not clean or whatever annoys you than the rest of it. Obviously you need to try and be honest, but good outcomes are created first and foremost from adequately dealing with daily situations in a balanced manner.
There's no playbook for being a good manager the same way there's no playbook for being a good partner or a good parent. The playbook would have to be too generic or too specific and end up being mostly useless.
Best you can get is someone who genuinely tries to improve and listens to you because they seem to care about you. If that takes the form of "how was your weekend" in the beginning of a 1-1 or having your back in a compensation review, that all depends on the situations.
I think "facilitate wellbeing" is more than just a feel-good aphorism, because it really does help when there's a difficult decision on your desk, at least for me.
My instinct is to push hard, let "the most correct" idea win, and not really give a shit about how it impacts others. All, as you know, awful, very bad, no good ways of managing. Being reminded that one of my primary jobs is to "facilitate wellbeing" helps keep me grounded.
Let someone take the day off even if there's a deadline looming, be cool with a later start date than would be perfect, take that vacation week and really don't plug in, a) for yourself and b) to show that as acceptable behavior for your team to do as well.
None of this is how I, naturally, would behave, and I need to be reminded and continually work at doing things like that, for the sake of the health of my team. None of this is theoretical in my view, I see it as specific and practical advice.
What you're speaking of is "Prioritize Wellbeing" which is a worthy belief to hold and to remind ourselves as engineering managers.
However, the specific word used by the OP is "Facilitate" which gives managers the leeway to be weak and lazy. A manager can say "I let my team take PTO a few days each quarter, I facilitated their well-being!" while they passively allow their stakeholders to dictate the workload of their engineers, with zero pushback. In practice, "Prioritize" basically means conflict and action, "facilitate" means whatever the manager wants it to mean.
Going further: most "principles" like the kind the OP wrote are designed for a manager's self-therapy. Beliefs that justify decisions the manager has already taken, dressed up in nice-looking words, the kind of drivel that influencers peddle on LinkedIn. Whereas real principles that the GP refers to are meant for self-discipline. Beliefs that call into question decisions, and force the manager to really think their next steps through carefully.
FWIW, what you wrote here is very similar to the situation I had and the mistakes I made that led to the lesson learned and that sentence being in the piece.
You would be amazed at the number of managers that largely ignore the "feel-good" part of the job, or even contribute to the workplace being a crappy place to work.
Like the author said, actively improving the working environment when possible earns you "currency" and trust into making unpopular decisions easier to swallow.
I think the lack of specificity is a fair criticism of what I wrote in the piece, but this is also something I was very aware of when I wrote it, which is why this caveat is included:
> The management principles below reflect lessons I have learned the hard way. These are things I wish I would have known and internalized when I first became a manager. By keeping this brief, I hope that it will be easily consumed, perhaps at the cost of people being able to fully understand each point.
Maybe at some point, this expands into multiple pieces or a short book, but for now, this is what I've produced. It won't be specific enough to be useful to everyone, but hopefully some folks find it helpful.
There is no manual to being a good manager. Only ideas you can project into your own approach.
I'm sad to see parent post at the top of the page. It nitpicks the one most abstract bullet and calls the whole thing unactionable. I think that's silly. I enjoyed your article and agree with many points.
I rate your article (ie up to a dozen headings with a paragraph of text each) higher than having to wade through a book of padding to get not much more actual information.
Thanks Owein! I've been around HN long enough to know that nothing pleases everyone, but getting enough upvotes to hit the top of the front page feels great. On a day without Elon buying Twitter, I might have hit #1 :)
I could have phrased it better, but my point is that no single book on management can reliably make people into good managers, any more than a single book on engineering can make people into good engineers.
Some people may say some points are common sense, but when you condense your personal perspective it adds the depth of your experience without having to write a book.
When managers of unrelated industries come up with some similar preferred practices, that can show fair agreement that it's more likely to be worthwhile.
People need to realize there are lots of companies that fail on almost all of the eleven points you have here, and if the right key person were to just take your page to heart and follow it with action it would be like a breath of fresh air across the entire project environment.
It also seems like 99% of management advice is about how to manage down. Not topics like how to set expectations with stakeholders, how to fight for budget, how to get your team positioned for highly visible work.
And office politics can be brutal, especially in large organizations - watching out for other teams trying to trap you into unrealistic deadlines, pushing their work on to you, deflecting blame - You want to be a team player and help the company achieve its goals, but there are can be a lot of pitfalls to look out for when others teams depend on you and your team's work.
You are right but there is something that has to underpin all of this advice and that is openness, honesty and balance.
Openness because you should be able to communicate why something might not be possible in unambiguous terms; honesty so people know they can trust you and that you will tell people the truth and not try and avoid it; and balance because you will be prepared to go some distance for an employee for the benefit of the business but this is not unlimited.
It can be hard to tell someone they are not performing well but it is much easier with those principles in mind, "I think these are areas that you are not performing well in, if I can help you achieve those then please let me know how, otherwise I need someone who can do this job that you were employed to do".
I think this is a result of the persistent flawed way most companies look at management. The author points at it when he says that most managers are strong in execution, and that's true — it's viewed as the baseline trait for any manager. But execution and maintaining well-being are fundamentally in tension, and most of the time, execution wins if a choice is forced. I think we need to be splitting the role into ones focused on each of these competencies. This sometimes happens informally as it is, but making it formal would change the hiring patterns and maybe lead to better outcomes for everyone.
True. Recently one of the sales directors at my company threatens the CEO to make him a "co-founder" (which basically means granting him a lot of option), or he will quit. He is responsible for half of our revenue, and he has been empire-building in his org for a while, so that his team answers to him, not the company. If we cut him off, very likely he (and a few key leaders) would deflect to our main competitor with our sales pipeline, and do some real damage. Very brutal situation for the CEO. I can not imagine learning how to handle this in any water-downed advice.
Thank you for bringing a different opinion. I feel like the "Thats the spirit!" crowd liking this kind of blog posts are employees who don't know what their manager are going through dealing with them
> The hard work often involves making unpopular decisions, or telling someone "no" when their pet request wouldn't be in the best interests of the team
I realise I'm just plucking a small point out of a large comment here, but I'd like to drill down into this one a little.
My very limited experience is that teams can generally self-manage this sort of thing. You tell them what you're trying to optimise, under what constraints, and lay down some ground rules for equal and fair participation, and then the team can make their own tough decisions and tell each other when they're not acting in the best interest of the team.
> My very limited experience is that teams can generally self-manage this sort of thing.
My experience is that they can absolutely not self-manage these things, it leads to literally living out lord of the flies in chaotic and dysfunctional teams, that are full of infected conflicts and stalled progress.
On the other hand, what exactly is it that gives you the impression that decision making is suddenly not needed? And what makes you believe that a group of people with different goals and interests, should spontaneously just "get along", especially when there's money involved?
I think what you're missing is that most humans are not what Netflix calls "fully-formed adults."
If your team consists of mature, kind, focused, skilled, honest, emotionally well-regulated people, then yes, the team can self-organize well.
That's very, very unusual, though. I don't think I've personally ever been on a team that consisted solely of such people (and, to be clear, though I strive for those things, I wouldn't say I've got them all nailed down perfectly).
Lot of misconceptions here that cause teams to underperform.
1. Managing comes first. (Nope, as a manager your are primarily responsible for ensuring a good outcome. As your title goes from manager, senior, higher to VP etc this becomes more important. Lower job titles you get paid to "do the work", higher titles are about "achieve outcome".) In the current market you'll often run into team members that don't perform. I see this so often where leads think that they have to "manage" and not do the work and the result is them and their team failing
2. Facilitate wellbeing. That's nice. But your primary responsibility is to A. Achieve the goal. B. hold people accountable to an acceptable level of performance
Give credit, take blame: That's a good one.
This post is just full of vague language that doesn't hold anyone accountable. Sucks to be an IC on that team, thinking everything is going well and eventually end up having whole teams being fired since your manager didn't set the right pace.
If you supplant your team and do the work yourself, you're not helping the team perform. Nobody is learning lessons and everyone, including yourself will just be more stressed and less satisfied with the job.
If you can't trust your team to do the work, then you shouldn't be managing those people. Management is about being a force multiplier, and not the force.
At the moment I have flexibility in how many people I hire underneath me and would like the team to remain small enough where I can be both a force multiplier and part of the force. The goal is to be an elite small squad.
The other option is to hire a larger number of people, handle more of the project scope, and cease being an IC. However I'm new to being a formal manager and am guessing this would probably be bad for my sanity.
You can't do that at any team size. The role you was looking for is generally called a "lead" role, which has different responsibility than manager role.
It's mostly because of conflicting mindset and commitment. As manager, meeting is your tool to get work done (source: High output management by Andrew Groove, I didn't make this up, and I didn't understand it until after I had to become a manager either). As an IC, meeting is a big giant distraction to you. You basically can't get the two type of works to mix together. You will always be blocking other members of your team in your IC task. And this doesn't get started with the different mindset yet (For example, you have to watch/ teach people fixing ugly code, as opposed to doing it yourself. And there will be some point you have to give up asking polishing certain piece of code, due to the members not interested, incapable or other reasons).
Being a manager and part of the force should only be a transitional period.
I've seen teams that got very little done for a long time because their manager didn't hold them to finishing tasks. So the team was perpetually in a state of polishing just a few more edges and never finally shipping things.
I don't know what sort of company would respond by firing the whole team, though. If a manager fails, the manager should be out, and a new manager should try to turn the team around.
I suspect you're right and the article conflates the means (managing) to the end (achieving an outcome). It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare.
But in fairness, "achieving outcome" is equally vague and it seems most leaders know they want Outcome X, but falter because they don't know how to get from their current state to that end state.
Can you elaborate on how you'd fill those gaps of "achieve outcome"?
> It's not unlike the military priority of 1) mission accomplishment and 2) troop welfare.
I hear what you're saying, but I would be careful taking a military type model and applying it to a team of software US engineers mainly because I think the power balance is so different.
If I'm in the military and I tell one of my subordinates that they need to dig trenches in the rain all weekend for the next 6 weeks, they may bitch and moan, but they've signed a contract so they're just kind of stuck. If I tell one of the engineers on my team that they need to work weekends for the next 6 weeks, they can probably have 3 interviews with other companies lined up by Monday.
I agree that achieving results is still priority #1, but the distance between that and #2 is very different.
The power balance aspect to me is extremely interesting. On the one hand, there is a lot of power a manager has:
- do you get the good assignments?
- will your performance review cherry-pick out-of-context a worst sampling of 'goals' that were created in the last few weeks, or will it be a glowing report of what you did?
I think those managers that ask their software engineers to pound sand are generally going to be bad managers. Notably, who should you ask advice from, someone that has designed 10% of the system specs, or the person that designed 90%? (Guess what, software engineers design about 90% of system specs!) Citation needed, but the amount of specifications that engineers have to fill in is quite mind boggling (what happens to this web page if DB is slow? What happens when a user clicks this button while this other thing is still loading, etc..). So while the 90/10 split is an exaggeration, the point remains, software development is a highly collaborative activity, particularly with the engineers. Some have said that a software's engineer main job is to figure out how to achieve 80% of the benefit, with 20% of the work. This aspect is missing from the typical unit-level command and control example, notably the "commanders" in software really don't know what the hell they are talking about unless they engage in actual conversations with the developers and users.
This is a perspective that is bandied about quite a bit, but I don't think it's exactly true (or at least not true to the extent presumed). Personally, I've only heard it come from people who have little actual military experience.
Leadership capital is a perishable resource in the military. Junior troops are not dumb and if you treat them like crap and just use the justification that they signed the contract, you won't be a very effective leader. If I leader has to use that type of tactic (or use their rank, or whatever), it's an indicator they've messed up somewhere along the way. The power dynamic isn't as cut-and-dry as most outside the military think. It's not unheard of for junior troops to get a bad leader fired, and in the absolute worst cases junior troops can put a poor leader's lives in danger. The idea that good military leaders would tell their subordinates to pound sand because they signed a contract is more of a trope than reality.
There's a surprising amount of times when the incentives align for a military subordinate to NOT listen to orders and leaders have to actually rely on the social capital they've accumulated by building trusting relationships with their subordinates.
> Optimize work distribution
> Managers have a portfolio of work that the business needs and people with work preferences. Optimize the dual objectives of delivering value to the organization and giving individuals problems that build their skillset, impact, satisfaction, and/or advancement. Performance is contextual; set people up to shine.
I find this so important. A good manager has a good mental map of the business's short-term and long-term goals, and a corresponding map of each person on the team's short-term and long-term goals (and strengths/weaknesses) . This map requires constant updating and refining. The magic happens in finding the right fit between all of that.
I'll comment that this is also something that you can partially delegate to the team.
A healthy team has a good understanding of one another's strengths and weaknesses just from working with each other. A manager should be trying to collect that feedback, as well as use their own, then work with each member of the team to determine what opportunities they need, to either demonstrate a strength, or work on a weakness, and then create space to socialize those needs. With the team aware of what one another needs, they're able to all be on the lookout to identify and highlight those opportunities.
Once the items the team definitively owns are being optimally allocated by the team, the manager can look for opportunities outside of the team's domain. They don't even need to be for specific individuals, but things that the team would be able to reasonably help with; then pitching them to the team, the team can self-organize to determine who it's an opportunity for (and then further break it down; maybe person A needs the opportunity to lead a cross team initiative, but person B needs the opportunity to dive deep into a technical implementation, style of thing).
The key job of a manager is to say no. It is not to optimize the work distribution but to control the scope of the work that is done. A critical distinction between manager and leader is the former has more focus managing shape of the playing field and the rules while the latter is more concerned about pushing towards results.
Last but not least management is about gaining, using and maintaining power. Without it saying no is not possible.
This sounds pretty good, all these are qualities anyone would want in their manager if they had a job doing 'the critical path of execution'. There's few things more frustrating than continually having to halt in the middle of one task to jump over to another task because someone's pants are on fire. Sure it happens, but it should be the exception not the norm.
However, there's another side to the manager's job that doesn't seem to be addressed - interfacing upwards with whatever layers link to owners, founders, the board, shareholders, etc. How does that exactly work out in practice? Let's say leadership makes what you think are really stupid decisions with disastrous longterm consequences (ex: Boeing 737 MAX design process, Google signing up with China to build Dragonfly, etc.). What do you do? Pour gasoline on yourself and set yourself on fire in protest, or roll your eyes in despair and proceed to assign your team to the task?
Be honest with the people who report to you about your feelings. You don't have to go out of your way to stir up trouble, but if people come to you with concerns that you share, it can be very helpful to know that you're not alone and your manager is on your side.
As an engineering manager myself I concur with all the points.
Some of them are difficult though, for example:
“optimize the dual objectives of delivering value to the organization and giving individuals problems that build their skillset, impact, satisfaction, …”
and
“ Managers with excellent execution skills and deep domain knowledge must resist the urge to present solutions to their reports.”
To what extent should one allow suboptimal solutions, failure or allow employees to do things inefficiently with their “favorite tech stack” (in cases where it does not add business value) ?
My approach so far is to be very very allowing —- until any failure becomes apparent and it can “naturally be discussed” (or it causes problems with colleagues in the group).
This can be quite stressful though — I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible.
> I do not think the people reporting to me understands how much energy is spent as a manager negotiating with others in order to give the team and team members the most space/maneuverability that is possible
Speaking from experience as an IC -- managers do an absolutely terrible job of surfacing what they're working on.
What are you doing to broadcast your efforts? If you don't tell them what you're doing, you can't expect them to know if you don't tell them.
I don't think 1-1 is the right time. If you have a team of 15 people, you would need to repeat the same thing 15 times. Better to give an update of what you are working on (as a manager) for the whole team once.
That's a large team. I don't think it makes sense to have 15 direct reports. You probably want to split that into 2 teams so you can feed your team with two pizza boxes.
If you do have a team that large, then you need to have a weekly or biweekly meeting with an agenda set beforehand. You can make announcements and possibly have a rotating presentation by somebody from the team about what they've been working on.
If you are managing this many people, you are managing people, projects and comms.
> To what extent should one allow suboptimal solutions
100% of the time. After all you can't count yourself being there to 'save the day' every single time, so whats the point of interfering here and there randomly.
An underrated approach here is to ask questions if you think someone is making a mistake, and then see how they answer. "Oh, cool - why do you think X is going to be better than what we've been using?" etc.
There's a huge difference between asking questions about an approach and prescribing an approach or saying "Nope that's not the right way" and there's a ton of room there to avoid the really suboptimal stuff.
As a non-manager, I find that having a company wide policy for what tech stacks are supported really helps with that particular concern. It should be a pretty easy "tap the sign" sort of thing. And engineers should be able to understand that technology spread has a very real cost that's hard to quantify. It also has that cost over time as long as the software they produce needs to be maintained.
For things that are much more personal -- allowing suboptimal solutions for example -- those are teaching moments. You don't dictate the solution, you educate on the problems that the chosen solution exhibits and provide resources. Make requirements clear. There's a decent chance that if they're presenting a solution that you find suboptimal, then you haven't communicated the requirements properly. Surface them and re-scope the project as needed. Be sure to double check that the things you're finding as suboptimal are actually important as well. That is, don't be arrogant -- there's plenty of room for the error to be on you, and that you're assuming something may be suboptimal. Also consider that the person in the weeds may have more context than you, and there may be factors you're not considering.
Rely on concrete things like tests and metrics to guide those discussions, so you're not evaluating on subjective matters. Don't put value judgements on solutions, frame things as decisions with trade offs. Those trade offs have ramifications that you can discuss, and together you can navigate to a workable solution.
Ultimately remember that even though you could give into the urge to present solutions, it is not your job. Focus on your job, and help your reports do theirs. If you don't like that, get a different job.
It depends. Part of the job is being the leader is being able to foresee risks and consequences, and also to evaluate your constraints. Sometimes, you can let something be a teachable moment. Sometimes, you need to prevent a decision from creating problems or risks. Sometimes, your reports will do things better than you would have, and you're the one who learns a good lesson.
> To what extent should one allow suboptimal solutions, failure or allow employees to do things inefficiently with their “favorite tech stack” (in cases where it does not add business value) ?
All solutions should be put out on the table as business tradeoffs. "It will cost X; we will get Y; we might run into unexpected problem Z". We all need to agree that we want to choose the best solution for the company, we lay out the solutions naked and vulnerable, we pick them apart, and then we make a decision. If we still can't make a decision, we let someone take the sword - potentially making a bad decision in the process - because we agree that forward progress is more important than total consensus. Will we always pick the best solution? No, but hopefully we've come to agreement as to what the pros and cons of each solution. We likely had to make a decision on several shades of grey. Still, we should be held accountable for our decisions regardless of how difficult they were
100%. I've worked for a lot of bad managers and 2 good ones. 1 of the good ones wasnt a great human but an incredible teacher. The other was an okay teacher but an incredible human. The later I'm still in contact with and we've stayed in touch for 5 plus years.
A lot of what I'm looking for in a boss is just someone who kind and understanding. It's shocking how low that is on most managers agendas.
Well, as an engineering team lead for years, and recently founder of a small gig, increasingly I've been shocked at how many people (employees, contractors, prospective business partners or co-founders) just want to take the easy way out, instead of putting in honest, conscientious, reflective work and effort, or are just plain incompetent at what they claim to be good at.
Every once on a while you come across someone that is enthusiastic, actually competent, and wants to do things to the best of their ability (or a reasonable approximation thereof), but those are few IMHO.
I mean, I know not all people can be interested in all things, but if you say you're up for something, be it a job, project, or partnership, you've got to give it your reasonable best.
I think the need to be kind and nice all too often is abused by their targets. The key is to find a way to be kind and flexible, but not allowing that to paper over rank incompetence or a bad attitude.
I guess I'm not really sure what your point is but it seems like you're saying being nice and delivering are not compatible.
You can have high standards and expectations and still be nice. In reality no one is going to be operating at 100% all of the time. They will have good days and bad days. I assume that others are doing their best. If their best is not enough for the role they were hired for than I made a bad hire. If I cant find a way to communicate expectations and standards without remaining nice than I'm the one taking the easy way out.
It's easy to be an ass and use emotion to make strong employees feel like they need to do better or deliver more. But at the end of the day your employees will leave once they have had enough.
I've left jobs I was highly effective at because my manager was constantly pushing for more and more. I would have stayed much longer if they would have had the EQ to recognize that I was operating at a high level and praise and kindness would be more effective in the long run. Who cares if someone delivers more of X when they leave in 6-12 months? Every gain will be canceled out by the amount of time you will spend finding their replacement and training them.
So to end my ramblings... If your point is that kindness can be abused... Sure. I agree. But is choosing to be kind and understanding, even if you feel like you are being abused at times, going to lead to you having significantly greater employee retention? Will choosing to act some other way cause your employees to leave which will drop their production from whatever % to 0% for an extended period of time?
It's even worse than what you say sometimes : some people are actually competent in engineering, but when it comes to simply remembering basic stuff or communicating about what they do -- total blackout. Meaning, they just want someone else to manage every little thing they have to do, remember the small details. And then they'd complain they don't like to be micro managed
It is, but I think it's the manager's job to be the first to take the emotional risks, and continue to do so even when they're not immediately reciprocated.
If the other doesn't know you moved forward, why would he/she change his behavior ? It looks like the relationship will continue as it began forever - one sided.
Well, if you're doing a good job of treating the person...y'know, as a person, then you can ask them to change their behavior. And generally they'll be amenable to reciprocate.
Also: Why doesn't the other person know you've "moved forward"? Try communicating that you have.
Agree! As an EM I've felt that the simple act of genuinely caring about your people can get you a long way. So much of the day-to-day execution falls into place when you follow your prime directive, and when you need to do unpleasant things you've earned the legitimacy and trust handle them.
We are putting too much into the word "management"
- supervision (did you turn up on time, are you capable of doing the basic functions needed)
- coaching (this team needs someone to do X, but I have two Ys. One goes or one changes)
- administration (budgets, projects, scheduling etc). Certainly the part most at threat from software - looking at you Project Manahers
- strategic decision making (yeah that's the part everyone wants to do because it's the big bucks with years before anyone can judge you. It is also oddly under threat - not from software but from voting - my guess is most strategy is going to be voted for in twenty years. don't like the strategy - binding vote at the AGM for new Board. would save Elon the effort of buying twitter)
All four of these (and I am sure MBA text books have better selections) are wildly different, at different levels of an org and need different skill sets and people. just thinking we could ever ask one person to get on with it all is crazy.
This resonates with a basic "anti management" feeling I have. I don't hate managers as people. I often really like them. But I hate what the title "manager" does to people. Like "domestic engineers" and "waste engineers" of the past, it's basically become a title grab for "get paid more money." In particular for managers, it usually establishes a "the principal said I can climb higher than you on the jungle gym, and from this point, I'm to wield authority over how you play on said gym." They may even protest "how bad it is up here" and "how I'm suffering for you."
What I really wish would happen, is that we'd abolish the title "manager" as overly vague and oft abused, and instead just call it what it is.
- Public Relations (go to meetings)
- Clerk (push papers, manage minutia)
- Meeting Caller/Planner
- etc
Anecdotally, an off the cuff euphemism from my Advanced Fluid Dynamics Professor in the early 90's still holds too true all to oft in my experience. He had great rapport with our class of ~100 students. After one test, the class was collectively whining about grading to a curve. After humoring us for a bit, he said something like "Look, you A students, you're going to go out in industry for a bit, but the lack of idealism is going to frustrate you, and you'll be back here soon with me. You B students know what compromise is. When it's good enough. That's why you're going to make great engineers." And then he turned to begin his lecture like that was it. And someone yelled out "wait, what about us C students." "Management" was his terse reply.
(Apologies to the venn intersection of managers <-> HN readers <-> "A" students.)
What does engineering leadership mean to you? What factors make it easier or harder to practice engineering leadership?
For me, I like having a budget and a staff - it’s way easier to influence my organization with a budget and a staff, than without.
I’m saying this only to encourage engineering leaders not to be afraid of formal management roles. You can make them your own. You might find what I found.
I think the difference here is in "corporate structure". I mean Bezos and Musk are both extraordinary people - but say Bezos employees about 1 million people and is worth about 150bn - why is the world structured so that each employee "gives" Bezos 150 grand?
There are other ways to structure our corporations, our tax and investment incentives. The Early Victoria British style of corporate structure worked so it got copied naturally. And I am not saying there are easy fixes. But co-operative movements were born at similar times. One day we will see VCs funding co-op unicorns and the world will look differently
Simplicity, speed, responsibility, authority. A lot of reasons why having a clear hierarchy makes sense. How do you assign blame in a co-op that makes bad decisions?
If a group of people performs/delivers poorly, how effective is it to assign blame to one select member? It may be efficient, but I’m not sure it’s effective.
I have worked in the classical management structure a good chunk of my career. And a couple of times (including mostly right now), I have worked in something that feels more like a basketball team with zero or little management. Competent engineers play the court together and get the job done. I prefer (greatly) this second model.
The job of being a manager is to understand the leadership roles that need to be fulfilled within the team and to figure out how to make sure they're all performed. You don't have to embody them all yourself. You are accountable for anything you delegate, however.
Quite naïve. Nothing has been said about what employees need to follow. It is like, everything they can do is perfect, the manager is always the one who needs to work on the relationship, and there are no criteria to select / stop working with employees (i.e. those rules will work with any team).
It says none of that. At worst, it is incomplete as an instruction manual, but it's a fine list of starting principles for thinking about humans doing work.
This seems like a reasonable goal, but it is not actionable advice. "Prefer one on one meetings" is actionable, and it tends to enable you, as a manager, to facilitate wellbeing.
Forgive me for quoting my book, but this example is worth thinking about:
-------
Great news! You just raised a round of investment! You are flush with cash! Now you can hit those ambitious goals that you excitedly promised to your investors. In six months, you can go back and tell them that you totally crushed the numbers — not only did you make your milestones, you blew past them. The investors will be so pleased! Now we just need to tell your head of marketing to ramp up the customer acquisition! Luckily she has a genius for this kind of thing. Oh, wait, here she is now, walking over to you, about to say …
… oh damn. She just quit? That was unexpected.
One-on-one meetings are useful for many things, one of which is that you aren’t likely to be ambushed by a surprise resignation. There are many personal issues that might cause someone to quit, and these will never, ever be mentioned in a group meeting. Burnout? A divorce? A spouse with a job in a different city? A child failing in school? A parent who is dying? Interest in other kinds of work? No one shouts that stuff in a group meeting, but they might tell you when you are one-on-one.
As an introverted high iq nominal eq person with an execution bias I routinely find companies that are keen to move me into senior leadership roles.
This post reinforces why I want to work for a good manager but also how I have zero desire to become one.
I’ve been managing a while and a striking difference between profitable established companies versus quasi profitable growth companies is the culture of delivering value. It goes without saying that you want your reports to thrive at work, and as a manager you want to build a great atmosphere and culture.
But what I often miss from posts like this is focusing on the value the group of individuals is meant to create (maybe it’s implied).
I like how modern society has created a special caste for sociopaths and then secondarily created an entire industry around teaching the sociopaths how to act normal.
Here's the real Principals of Engineering Management, according to pretty much every middle manager, director, and vp I've ever worked with:
1. Be caviling and pedantic, so you can reinforce your position of petty power.
2. Contribute exactly zero code, infrastructure, etc. Basically, anything that actually provides value to the engineers or the customers, you don't touch.
3. Put at least a couple meetings on the calendar every day of every engineer that they don't need to be at to remind them you rule over their time.
4. Push nebulous "goals", then have very set goals when it comes time to promote/give a pay raise an engineer and then insist they aren't quite there.
5. Put engineers on-call instead of hiring support staff, again to remind the engineer that you own their time, even when they're not at work.
6. Constantly seek updates from engineers, so many in fact that they can't complete the work on time, then promptly blame the engineers for not delivering.
"Managers" are people with business degrees who failed out of anything technical. Real managers are architects and PMs who actually understand the product and the technical lift it takes to actually make things happen. They don't concern themselves with your comings-and-goings, but whether you can get things done or not.
For some reason they downvote you, but your post has some truth.
I really wish EM wasn’t only about people management, hiring and goals but actual technical leadership. I want my manager to care for my wellbeing, be empathetic etc. as the post and common sense suggest, but i prefer he could provide some technical direction to the team (not let the team leads figure it out themselves), collaborate closely with product and leadership, make time for engineering to solve hard problems and tech debt and not just deliver d2d features and so on. I would expect EMs coming from IC roles to have this mindset, but most of the time they are stuck to non technical responsibilities and i really cannot understand why this role has become like this.
I was a data engineering em for a while, but it’s super tough to find open roles on the field. I just don’t understand how most em roles demand zero technical contribution.
I think it's helpful to consider these points, and try not to be put off by the bitter tone.
As an employee you have to consider the workplace culture, and your manager's attitude towards his/her "resources" (employees). This is a list of danger signs. You want to be watch for dysfunctional behaviors like this creeping into your work environment, and either combat them if you can, or find a new position. Or, you can accommodate/enable and try to insulate yourself, which is OK in the short-term, as you work towards a longer-term solution.
The culture of the organization and the management chain above you greatly affects your satisfaction and mental well-being. I assure you that, although no workplace is perfect, a few are pretty darn good. And sometimes it's possible to exert influence. Try not to sink too far into cynicism because there is a lot of incompetence and selfish self-interest out there. Use your skills of observation and writing to make things better, or find a place where that's possible.
As much as I disagree with the article, this is just the engineer's version of it.
I think you would find it really interesting to try running a company or even a team. I think it would help you see your prior managers in a different light.
Everywhere I've worked has had on call rotations. Literally everywhere. Nowhere have devs been the first line of support (i.e., not "instead of" per the parent post, but "as well as"), but they've been in the mix.
Quite frankly, I wouldn't want to work somewhere that didn't. I have a huge problem with the idea of "my team wrote the code, and now isn't responsible for it". I intentionally optimize against "avoid 2 AM pages", and that ensures I push for enough testing and such to avoid them. If it was "someone else's problem", the only pressure I'd be under is to deliver ASAP, and that's unhealthy.
Well...I also have not worked anywhere that you personally got paged more than maybe once or twice a year, and that any after hour pages led to the expectation you'd take twice that amount of time off the next day, and if it was more than a couple hours, or interrupted your sleep, you'd take the full day off.
And those were not FAANG. So I think it's also the culture and expectations, and it's not ludicrously impossible to get. It just requires, getting back to the topic, a reasonable manager who understands the negative effects of getting paged.
I didn't say you can't put engineers on-call. But if you do that there are labor laws you need to comply with regarding overtime and suchlike. You can't just pay someone a salary then say "oh yeah you need to wear this pager at the weekend".
I also acknowledge that failure to comply with labor laws and other regulations is widespread in the US, whether knowingly or though ignorance.
> You can't just pay someone a salary then say "oh yeah you need to wear this pager at the weekend".
It seems to be the case in every job I've had. Maybe they ARE adhering to some laws but at the end of the day I get paid a salary, and I have on-call evenings+weekends which I don't select. I can swap shifts, but it's my responsibility to find a substitute. I average 4-5 shifts/months.
As far as I know, all of FANGetc is like this. It may be the case that labor laws permit this. Still miserable.
> Facilitate wellbeing
> Personal safety, dignity, and wellbeing of every team member are paramount. Team success is only success if team members feel good about it.
But then you become an actual manager and realize that these are largely just feel-good aphorisms that don't really help navigate the hard work of being a manager.
Don't get me wrong: I think "facilitate wellbeing" and similar tidbits are valid advice. Likewise, a manager who chooses to not facilitate wellbeing would clearly be in the wrong. But when you get into management you realize that the hard work isn't waking up and deciding to facilitate wellbeing. The hard work often involves making unpopular decisions, or telling someone "no" when their pet request wouldn't be in the best interests of the team, or defusing interpersonal conflict among two team members who have been feuding for months.
These feel-good blog posts seem rather vacuous after being in the trenches of management for several years. Again, not because the advice is bad or wrong, but because it's just a lot of text around the basics of being a decent human being. Learning how to do the hard things about management or how to make unpopular but necessary decisions is something that you won't learn from the average blog post or LinkedIn post, largely because these function more as personal branding pieces than actual advice.
In my experience, the best management advice comes from talking to the best managers you know personally. Online, the most practical management advice comes on smaller forums where people are either anonymous (and therefore less interested in personal brand building) or older and accomplished (and therefore not worried about blowback impacting their career). The type of feel-good blog posts or LinkedIn blurbs that people associate with their personal brand don't really add much value after you've read 5-10 articles saying the exact same aphorisms.