[HN Gopher] Principles of Engineering Management
___________________________________________________________________
Principles of Engineering Management
Author : im_dario
Score : 328 points
Date : 2022-04-25 13:52 UTC (9 hours ago)
(HTM) web link (acjay.com)
(TXT) w3m dump (acjay.com)
| osigurdson wrote:
| "Distribute problems, not solutions" makes sense.
|
| Making sure that the problems are the right ones to work on is
| pretty important as well.
| [deleted]
| lifeisstillgood wrote:
| 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.
| travisgriggs wrote:
| 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.)
| gkop wrote:
| 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.
| travisgriggs wrote:
| 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.
| deeptote wrote:
| This is typical, MBA armchair psychology.
|
| 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.
| brimble wrote:
| Ah, software "engineering"--the fastest path to professional-
| tier wages coupled with blue-collar or service industry social
| standing.
| nealabq wrote:
| 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.
|
| Sorry if this is preachy.
| deeptote wrote:
| It's not preachy at all! You're more eloquent than I am and
| yes, I'm a tad bitter about some of my recent work
| experience.
|
| I'm grateful to report that I'm in an awesome situation now
| and my manager and I get along swimmingly.
| broast wrote:
| As an engineer, I have never worked under a manager who wasn't
| previously an engineer. YMMV
| higeorge13 wrote:
| 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.
| gkop wrote:
| If you have the energy and curiosity to be an EM, please do
| give it a try. The industry needs compassionate and highly
| technical EMs.
| onion2k wrote:
| _according to pretty much every middle manager, director, and
| vp I 've ever worked with_
|
| You might be right and every manager is terrible, but it's
| worth noting that the common denominator in all of these
| interactions is you.
| deeptote wrote:
| dboreham wrote:
| > Put engineers on-call instead of hiring support staff
|
| Note that in some jurisdictions (including the USA) this is
| problematic from a labor law perspective.
| wnolens wrote:
| I really wish. But it is the standard. 90% of jobs I see
| involve building some online service. On call is as part of
| the job as writing code is.
| lostcolony wrote:
| 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.
| brianhorakh wrote:
| 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.
| nolawi89 wrote:
| this seems basic to me
| [deleted]
| thecryptodiver wrote:
| This is such a great read! 100% agreed!
| havkom wrote:
| 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) ?
| chrsig wrote:
| 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.
| dominotw wrote:
| > 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.
| havkom wrote:
| I agree (with some reservations, see my other reply to my
| post)
| havkom wrote:
| 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.
| chrsig wrote:
| > 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.
| pkaye wrote:
| Maybe use your one-on-one to discuss those things.
| daok wrote:
| 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.
| mateo411 wrote:
| 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.
| Irishsteve wrote:
| 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).
| tschellenbach wrote:
| 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.
| malfist wrote:
| 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.
| bumby wrote:
| 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"?
| and-not-drew wrote:
| > 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.
| seadan83 wrote:
| 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.
| bumby wrote:
| 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.
| tchalla wrote:
| Many of these, could be principles for life.
| ttoinou wrote:
| Quite naive. 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).
| drewcoo wrote:
| Well it's not called Principles of Engineering Non-Management.
| xbar wrote:
| 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.
| PragmaticPulp wrote:
| 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.
| kqr wrote:
| > 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.
|
| What am I missing?
| jseban wrote:
| > 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?
| turdnagel wrote:
| It entirely depends on the dynamics of the team.
| willturman wrote:
| > 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.
|
| [1] https://www.shrm.org/resourcesandtools/hr-topics/talent-
| acqu...
| marcinzm wrote:
| >it seems that the basics of being a decent human being are
| often being overlooked by management.
|
| People working in tech companies may not realize how un-
| decent a lot of other companies and their management are.
| pkaye wrote:
| There are a lot of shitty employers and employees around and
| the rest are trying to avoid them by different means.
| kemiller wrote:
| 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.
| cjalmeida wrote:
| 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.
| vasco wrote:
| 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.
| jahbrewski wrote:
| Good feedback here. Do you have any example "smaller forums"
| that you have found particularly helpful?
| superzadeh wrote:
| teams at work is a good one: https://bunch.ai/slack-community
| hintymad wrote:
| 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.
| nickff wrote:
| 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.
| hintymad wrote:
| Yeah, the book also passes Taleb's Skin in the Game test:
| the author is also the practitioner of what he wrote about.
| ttoinou wrote:
| 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
| [deleted]
| TameAntelope wrote:
| 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.
| hitekker wrote:
| 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.
| TameAntelope wrote:
| I just don't see how you can read "facilitate wellbeing"
| and be this upset about it, especially given how you feel
| about "prioritize wellbeing".
| [deleted]
| [deleted]
| [deleted]
| [deleted]
| lbriner wrote:
| 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".
| tootie wrote:
| 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.
| photochemsyn wrote:
| 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?
| 0xbadcafebee wrote:
| - Choose and limit your battles
|
| - Provide data to make an argument
|
| - Put your concerns in writing
|
| - Challenge your manager to ask their bosses tough questions
|
| - Form coalitions with other managers to try to solve problems
| together
|
| - Ask for a skip level (IMHO once a quarter, not just to
| address business problems but to maintain good relationships)
|
| - If your employees are still at risk and upper management does
| nothing, threaten to quit
| joshbetz wrote:
| 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.
| queuebert wrote:
| 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.
| Ozzie_osman wrote:
| > 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.
| lostcolony wrote:
| 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).
| heisenbit wrote:
| 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.
| the_arun wrote:
| IMHO, we should add "Be Human first, everything else comes
| later".
| Taylor_OD wrote:
| 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.
| prmph wrote:
| 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.
| ttoinou wrote:
| 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
| [deleted]
| ttoinou wrote:
| Maybe it's not just about the managers but also how do
| employees treat the relationship with their managers. i.e.
| it's a two way street
| skeeter2020 wrote:
| 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.
| ttoinou wrote:
| 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.
| chrsig wrote:
| 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.
| skeeter2020 wrote:
| 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.
___________________________________________________________________
(page generated 2022-04-25 23:00 UTC)