[HN Gopher] Managers, stop distracting employees
___________________________________________________________________
Managers, stop distracting employees
Author : rustoo
Score : 237 points
Date : 2023-04-01 14:53 UTC (1 days ago)
(HTM) web link (hbr.org)
(TXT) w3m dump (hbr.org)
| kevinventullo wrote:
| I think this advice is subsumed by the more general heuristic
| that managers should basically understand and be able to do their
| direct reports' jobs. If they understand the importance of focus
| and flow state, they will also understand the cost of
| interruptions.
| lfciv wrote:
| One thing I love about the company I'm currently at is that
| pretty much every eng manager does some level of IC work.
| Meaning they all have some pulse on the codebase beyond higher
| level planning.
| [deleted]
| roflyear wrote:
| I used to run Teams reports on our employees to figure out how
| much $$$ was going into meetings.
|
| I found that some of the least productive employees spent 60-80%
| of their time in meetings (high Teams usage), and I suspect it
| wasn't because of the meetings that they were not productive, but
| that they had a lot of meetings because they were not able to be
| productive: it made them feel good.
| vegetablepotpie wrote:
| After being in a large company for ten years, I'm convinced that
| managers and companies don't want productivity from their
| employees, what they want is alignment and legibility.
|
| Alignment being: we both agree on what you should be working on,
| and legibility being: are we on track, or do we need management
| intervention to ensure completion? Emails, status meetings, stand
| ups, pop ins, IMs, while detrimental to achieving objectives,
| satisfies management desires.
| crazygringo wrote:
| But alignment and legibility _are_ productivity.
|
| 10 employees working fully aligned will achieve much more of
| what is valuable to the company than 10 employees working just
| as hard but on things that don't sync up right.
|
| And legibility is needed in order to _achieve_ alignment. A
| manager needs to make sure all the parts of a project come
| together by the deadline, and so tracking progress allows them
| to quickly say OK let 's drop that feature or I need to unblock
| you on this so I'll reach out to the other team's manager.
|
| Productivity isn't a scalar quantity produced by employees that
| simply adds together. Think of it as something more
| multiplicative, where a "zero" from a key employee tanks a
| project altogether. (E.g. your team of nine back-end engineers
| and one front-end engineer achieves zero productive output if
| the front-end engineer doesn't deliver anything workable. Or
| the back-end database engineer fails at their tasks.)
|
| So alignment and legibility aren't detrimental to achieving
| objectives -- they're critical.
| throwaway689236 wrote:
| The bigger the company, the less effective it is.
| zmmmmm wrote:
| Absolutely ... for large organisations the key is scale. When
| it comes to staff in strategic roles (engineering, software,
| etc etc) that build capability, there's a point where the
| challenge of growing past a certain scale completely depends on
| substituting individual action (aka productivity) with
| organisational ability to deliver results using any number of
| employees, where that number doesn't really matter any more.
| And that depends far more on the things you mention - clarity,
| alignment, procedural coherence, etc than getting even 2x more
| from the individuals involved.
|
| It's funny because software engineers will be the first to tell
| you that "premature optimisation is the root of all evil" and
| other similar mantras but then be perplexed that their own
| individual productivity isn't the first item on their manager's
| agenda. The manager is probably busy optimising something else.
| vlovich123 wrote:
| I would argue that your innovation center should be staffed
| primarily focusing on productivity rather than scale. You can
| always add scale as needed but you can't add productivity
| once you're at scale
| Hermitian909 wrote:
| Maybe? Definitely not always.
|
| My team is the heart of my company's innovation center and
| we've very intentionally sacrificed a lot of productivity
| for alignment and it's been _really_ good for the business.
| It 's an internal platform with probably another ~20 eng
| years of work left, turns out the bits of work our team
| thought would be most impactful weren't. By focusing on
| alignment we've been able to sequence the work so that more
| of company gets onboard early and the company as a whole
| delivers more value, faster, with less long term debt.
| tremon wrote:
| How would you define productivity and scale here? Because I
| would say the exact opposite: you can always add
| productivity by employing more people to do the same job,
| but to really grow you need to innovate so that the
| processes/tools you use become productivity multipliers. So
| in my mind, the innovation center is where the scaling
| happens, and operations departments is where linear
| increases in productivity happen.
| Tyrek wrote:
| There are productivity decisions at the micro-level that
| actively hurt scaling. The easy business example here is
| the choice to manage data in Excel as opposed to a formal
| database. (Very common in financial orgs). Excel gives the
| team today much more flexibility, at the trade-off of risk
| (anyone can edit numbers) and scaling (other teams probably
| can't find your excel file).
| zmmmmm wrote:
| > There are productivity decisions at the micro-level
| that actively hurt scaling
|
| Probably the most obvious one that HN readers will be
| familiar with is the 10x developer who trail blazes out
| amazing software but even if they do document it well, it
| generates an unsustainable technical foundation because
| it can't be supported after they move on (whether
| internally or externally). In a startup, this person is
| invaluable. In a large organisation you may even screen
| them out at interview stage in certain contexts.
| alexashka wrote:
| 'Productivity' is just a term higher management tells lower
| management to make them believe they can get promoted.
|
| Not unlike organized religions telling folks about heaven.
|
| The best lies are always audacious - people can't help but want
| to believe them :)
|
| That this results in holy crusades, witch hunts, daily stand
| ups and open offices - that's just part of being a homo sapiens
| sapiens.
| LanceH wrote:
| There are a lot of people who prefer proof of work over work.
| Spivak wrote:
| I feel like everyone acts so surprised at this like it's some
| contradiction when it's exactly purposefully right.
|
| At the end of the day delivering results isn't the end all be
| all. It's delivering the right results on a known and
| predictable time scale without any surprises. Above a baseline
| of speed it doesn't really matter because you're only as fast
| as the slowest business unit involved in your release and it's
| not usually engineering.
|
| Realistically my team could push out features that could fill a
| newsletter every single week but the parts of the business that
| figure out what features customers actually want, how we can
| market and sell them, how we tell users about them, getting
| them through qa, gathering incremental user feedback for the
| next iterations all work on human time and so we directly (or
| indirectly through management) get pulled into those concerns.
|
| I think lots of devs feel weird about coding for 20 or less
| hours a week because it's the part we associate with work when
| in reality we're delivering real business value in those stupid
| meetings, it just manifests outside our view.
|
| Dumb Hack: Treat meetings even ad hoc ones like card work,
| groom them, assign them point values, define ACs and retro
| them. You'll discover really quickly the meetings that aren't
| serving you and the value you're providing to the rest of the
| business.
| opmelogy wrote:
| > ...delivering results isn't the end all be all. It's
| delivering the right results on a known and predictable time
| scale without any surprises.
|
| Well said. I've had a hard time articulating this but you
| nailed it.
| jack_riminton wrote:
| -deleted-
| tester457 wrote:
| > "I want to see people and I want to see people jump through
| hoops for me".
|
| Nauseating.
| bytehowl wrote:
| I thought execs had to do all the cunty things they do
| because "it's their legal duty to maximize profits for the
| shareholders"? But suddenly it's OK to sacrifice productivity
| for the sake of power-tripping? Shouldn't he have been fired
| on the spot?
| markus_zhang wrote:
| I actually think both are important and pretty much define what
| real productivity is. Since the company pays me dough surely it
| has a say in what I should work on.
|
| And a bonus if manager can pull his weight to make things
| happen, i.e. management intervention.
|
| My current manager works like that and I'm perfectly fine with
| it. The only issue that I can see is that said manager might
| drastically misunderstand the scope of things at hand. But so
| far I haven't met anyone like that.
| marcus_holmes wrote:
| This is why I hate working for large companies. It's all about
| the politics not the craftsmanship.
| greatpostman wrote:
| When I was younger I always assumed all the tracking had value.
| After a decade of working, it's all a facade. And all these
| people are constantly trying to be managers which explodes the
| amount of documentation
| A4ET8a8uTh0 wrote:
| Some tracking has value. Last year I did some testing. Its
| results were recorded for posterity. A year later, for god
| only knows what reason, production environment differed
| slightly from testing environment a tiny little bit. Records
| allowed for a relatively quick follow up with vendor and
| resolution.
|
| But it goes back.. how do you know something will be
| important?
| Kamq wrote:
| Can I ask how people found it a year later?
|
| Everything always ends up on a confluence dumping ground,
| and I have trouble finding pages I wrote after any sort of
| significant period of time, much less finding things other
| people wrote.
| A4ET8a8uTh0 wrote:
| To be honest, I think it is my history with the vendor. I
| know them to be flaky so I keep anal documentation of
| minute changes one version to the next. It is genuinely
| just an excel spreadsheet, but there is a focus on
| changes they introduce along with dates since I was
| burned before.
|
| The issue was fairly unique and actually tested for and
| the list of implemented defect fixes in testing env. was
| listed on our end ( and maybe for once the fact we don't
| use confluence helped ), which helped to narrow it down
| on the vendor's side ( I am not sure what they use
| internally ) and it certainly helped that there were only
| two related projects for that specific move for the date
| the issue occurred.
|
| FWIW, it is possible that I am just still relatively new
| to this ( 3 years for the testing part ) so all the
| issues we experience don't all blend together yet.
|
| edit: Apologies, as I re-read it, my response feels
| fairly generic, but I am not sure I can discuss more
| details.
| nostrademons wrote:
| That's literally a manager's job. If you don't have managers,
| by definition, you have individual contractors. The _point_ of
| being a manager is to line up the work of all the ICs so they
| are more or less pointing in the same direction and can tackle
| problems that no one person could handle on their own.
|
| There is always a productivity cost to this, and it takes many
| forms. One is simply the manager's salary: they aren't doing
| useful IC work, they're spending all their time aligning their
| reports' work with the goals of the organization. Another is
| that the ICs will typically be working on projects that align
| with their organization's goals rather than their own goals,
| and most people are less excited by a faceless megacorp's goals
| than their own personal projects. A third is that all the
| communication overhead and status reports come out of time that
| could be spend actually working. A fourth is that you're often
| forced to adapt less productive methods, programming languages,
| frameworks, etc. simply so that what you're doing can be
| communicated with other employees.
|
| But this is all intentional, and savvy businesses know it's
| going on. It's the cost of being a big business, and you
| usually can't become a big business unless you can solve
| problems that smaller businesses cannot.
|
| A corollary is that a good manager usually doesn't care much
| about _how_ productive you are, only that you have positive
| productivity and demand little of their time & energy. If they
| manage a team of 10, your productivity could be 1/10th theirs
| at the same task, and yet be a net win for them (and the
| organization), because the _team 's_ output is more than they
| could achieve on their own. However, if your productivity is
| half theirs and you take up half of their time with your
| questions, it's easier for them to just do your job, and now
| you're a performance problem. And conversely, if your
| productivity is double theirs but you're a jerk that
| demotivates the other 9 employees, they're better off letting
| you go even though you're a superstar, because their team
| productivity is 1/5 what it would with the other 10 people on
| it.
|
| This is why there's often a lot of counterintuitive behavior in
| large organizations. Your manager _knows_ that you 're reading
| HN on company time, or taking personal calls, or arranging
| doctors appointments. _They don 't care_; you'll make it up
| later, and it's usually a net productivity gain to make sure
| employees are rested, happy, and healthy rather than squeak out
| every working hour from them. Same if you want to take off an
| hour early for childcare. But conversely, if you're putting in
| long hours and cranking out tons of code _but_ you 're a jerk
| that makes the rest of the team stressed and anxious whenever
| they come into work, you are a net productivity sink and will
| probably get let go. It's even worse if you're putting the
| company at risk through HR violations, negative PR, stealing
| trade secrets, etc - which is why even prominent high-
| performers can get fired for that.
|
| The bigger the company the higher the downside, and hence the
| greater the tendency toward mediocrity. In a startup your bad
| attitude, loose mouth, or penchant for lechery might be
| tolerated because the potential upside outweighs the risk to a
| company that's probably going to fail anyway. In a megacorp
| there are 200,000 other employees that can do your job, so a.)
| your productivity has to be pretty bad before you're a net
| negative to the organization and b.) your potential _negative_
| productivity caps out at 200,000x your salary, which means it
| doesn 't take much of an infraction against the company before
| you're terminated.
| AdamJacobMuller wrote:
| But what's the point of productivity if you aren't working on
| things which align with larger goals of the organization?
|
| You can be the busiest person in the company, but, if your
| doing work which doesn't align with the goals of the company
| your contribution is either useless or in many cases is
| actively harmful.
| Cardinal7167 wrote:
| I think what OP means (and I would be inclined to agree) is
| that companies will take significant cuts to productivity in
| order to feel more secure and informed of the progress, even
| if that feeling is not grounded in data.
| serial_dev wrote:
| The word you are looking for is micromanagement.
| lifeisstillgood wrote:
| Goals at what level? I mean the goals for the CEO are so
| broad almost anything that is not going to land the board in
| court is a likely candidate. But for most middle management
| goals are highly restrictive.
|
| I suspect that the guy who invented gmail (or rather linked
| ads to the text), had he asked his manager would have been
| told "hell no, fix the javascript bug that's assigned this
| week - that is putting us behind target for the month"
|
| I generally think one should measure new or increased
| _capability_ as opposed to most other metrics.
|
| How is an interesting question
| bick_nyers wrote:
| Yes but there are diminishing returns to alignment. The
| difference between 90% and 99% alignment is minimal, and
| cutting productivity in half to achieve it is not worth it.
|
| I also hypothesize that when you have systematically low
| productivity, the business/product no longer becomes aligned
| with the market. In that situation you actually don't want
| your employees to be 100% aligned with the business.
| YokoZar wrote:
| Sounds like the company's problem. Maybe they should change
| their incentives so that managers actually want the right
| things.
| sigstoat wrote:
| > Maybe they should change their incentives so that
| managers actually want the right things
|
| what's the incentive structure for mid-level managers that
| maximizes productivity, but doesn't have the managers
| whipping the staff to work harder?
| lolinder wrote:
| Why are you so sure that legibility and alignment are the
| wrong things to look for in a large organization?
|
| Most of the work in a large software project is
| coordination between all the minds involved. The more
| minds, the harder this task is. Large companies don't need
| people who can work super productively but might work on
| the wrong thing for weeks before surfacing again.
| Kamq wrote:
| > But what's the point of productivity if you aren't working
| on things which align with larger goals of the organization?
|
| Assuming larger goals on the level of "profit", sure. There's
| no point.
|
| But alignment that people harp on about tends to be on
| specific business initiatives, or possibly KPI targets
| (generally tied to executive bonuses). This sort of alignment
| is how you get an alignment trap (where teams that are more
| aligned actually cost the business more and deliver less
| value than teams that are less aligned).
| JeffeFawkes wrote:
| I'm a relatively new team lead (this is my second year with the
| title officially, though I did TL responsibilities prior) and my
| entire goal is to be the antithesis of the type of manager
| mentioned in the article. My best managers were ones that let me
| focus and removed roadblocks, so I try to do the same. Ideally,
| my team has zero to one meetings per day (stand-up inclusive);
| I'd rather them focus on development than get caught up in
| unnecessary meetings. As a result, I'm often in meetings instead
| (which is fine) and then can give my appropriate teammates the
| outcomes of those chats. Everything else should be offline /
| async where possible, and I try to prefix those slack messages
| with a priority level so they can tell at a glance whether a
| given message can be safely ignored until a break between work
| items.
|
| So far my team seems to love this arrangement, but I'm curious if
| anyone has advice on the long term effects of this approach.
| scarface74 wrote:
| My first job out of college was working at the backup site of a
| state lottery as a computer operator. Nothing ever happened all
| three years i was there to need it.
|
| But we were told by our manager at the time that while shit is
| hitting the fan and you may have all sorts of people breathing
| down your neck, focus on the people you need to coordinate with
| and politely tell other people that you are following the
| checklist and you will give them updates at the appropriate time.
|
| This was in the mid 90s. I have followed the same m.o. through
| out my career. I have been on all sides as a psuedo-manager,
| software architect, hybrid developer/sysadmin, consultant, etc.
| mkolodny wrote:
| When a remote, international company gets very large, it can be
| just about impossible to find a time where everyone can meet.
|
| Even in time-sensitive situations, I prefer asynchronous
| communication methods like email and voice memos. That way
| everyone can catch up as soon as they get a chance, no matter
| what time-zone they're in.
| flashgordon wrote:
| Ok so just to be clear is there a reason these guys aren't
| writing articles where s/manager/leader? Yet another manager
| bashing article while leadership is sublime! How about "leaders,
| give your managers space to do their effing jobs without having
| to constantlu sell your Kool aid?"
| wuliwong wrote:
| This article seems so obvious to me that I'm surprised it got
| traction on HN. Are there managers here that felt there was some
| new/interesting content in this article? Maybe the scarier notion
| is that this was upvoted by the reports of managers that are not
| heeding this advice?
| opmelogy wrote:
| I consider this like drinking water. It's a no brainer that you
| should drink water, but some people need reminders because
| mentally they are getting caught up in other stuff.
| omginternets wrote:
| Every time I read an article from HBR, I find myself wondering
| (a) how the content isn't obvious to anyone with a working
| nervous system, and (b) what value its core readership can
| possibly bring to a company.
|
| But this one really takes the cake. My respect for the "academic"
| field of business has somehow managed to fall below rock-bottom.
| lordnacho wrote:
| If you're a brand like HBR, you need people to mindlessly link
| to uncontroversial articles. Particularly from LinkedIn where
| this kind of thing lives. Nobody will pick a fight about this,
| but thousands of people will like it and re-post it.
| omginternets wrote:
| This is a good articulation of the problem. It's effectively
| business-class shovelware.
|
| But my concern is less about the people writing or publishing
| this drivel than about the people who consume every drop of
| it, hoping for some "insight" into "strategic thinking".
| Before anyone accuses me of attacking a straw man, I have
| personally met dozens of such people.
|
| What pains me the most is that there is something out there
| that can give them what they want; a classic liberal-arts
| education would actually teach them to think with some rigor.
| But they're stuck. They can't think well enough to dig
| themselves out of this hole of mediocrity, and it's an
| unsettling mix of tragic and repulsive.
|
| So in true HBR form, if you find yourself reading "thought
| leaders" or looking to improve your "strategic thinking",
| please -- for all our sakes - read a book. (NYT bestseller
| doesn't count.)
| dylan604 wrote:
| >than about the people who consume every drop of it
|
| but but but, how can you become a thought leader if you
| don't slurp up this kind of content to regurgitate on your
| own blog as if it was your original thought and then
| relentlessly post about it on $theSocials?
| itronitron wrote:
| While I mostly agree with you, I can offer a more
| optimistic view that you may choose to consider. Think
| about all the hobbies that people pursue in which there is
| some new gear they can read about and aspire to having that
| will take their pursuit of said hobby to the next level.
| There are entire magazines devoted to reviews of new gear.
|
| If HBR is such a magazine for managerial oriented people
| then at least it shows that some people are aspiring to
| improve their ability as managers, or at least the
| functioning of their organization.
| omginternets wrote:
| I see your point, but this is akin to witnessing someone
| go to a psychic for help. There is little cause for
| optimism when people seek help from vacuous people or
| publications.
| wpietri wrote:
| The content isn't obvious to them because they operate in a
| different context than you.
|
| Managerialist culture is founded on the notion that workers
| must be supervised and controlled. That the important thinking
| should be done by people in the managerial class. In that
| context, the experiences of non-managers is always secondary,
| because workers must be coerced via carrots and sticks to do
| things they are not smart/wise/good enough to see on their own.
|
| A great example here is the ubiquitous status meeting.
| Everybody troops into a conference room for an hour and takes
| turns saying things to the boss while everybody else's eyes
| glaze over. This lets the boss feel powerful and important, but
| it's a giant waste of time. The POSIWID conclusion is that
| organizational effectiveness is very much secondary to
| reinforcing the dominance hierarchy.
|
| For somebody adapted to that world, treating the time of
| minions as truly important -- by which I mean more important
| than the passing feelings of the powerful -- is radical. Even
| though that's something blatantly obvious to makers and others
| who do direct work.
| incone123 wrote:
| Almost every meeting I ever attended had an agenda and the
| others were on single, specific topics. So is that normal and
| hbr is inventing a problem, or am I very fortunate?
| mattnewton wrote:
| I think you are exceedingly fortunate to the point where
| you must know how to pick companies/roles better than
| average.
| incone123 wrote:
| Well someone has to be the lucky outlier. And these
| meetings do have digressions plus heavy use of Any Other
| Business!
| CPLX wrote:
| Why do you think a regular status meeting is definitionally a
| giant waste of time in all business contexts? Is informing
| others of status and next steps not a business goal?
| sethhochberg wrote:
| Many tech-forward schools of thought would probably suggest
| that status of work is something that should be
| discoverable - ie, we shouldn't need a status update
| meeting because the status is obvious from looking at tasks
| on a Kanban board or some other tool that is used for
| tracking work. I'd guess the person you're replying to
| believes more that meetings are a poor way to accomplish
| this than that a pulse on work isn't important to business.
| [deleted]
| ethanwillis wrote:
| Human memory is bad. It's also synchronous. It's also not
| easily referenceable. Why aren't status reports more common
| than status meetings?
| jdlshore wrote:
| > Managerialist culture is founded on the notion that workers
| must be supervised and controlled.
|
| That's a shallow view of the situation. What you're
| describing is "Taylorist" management, or "Theory X"
| management.
|
| Modern management theory also discusses "Theory Y"
| management, in which providing context and trust is more
| important than supervision and control.
|
| Many managers are unaware of this concept, even though it's
| Management 101. If that's the case in your company, it's not
| a problem with "managerialist culture"... it's a problem with
| _your company 's_ culture.
| omginternets wrote:
| I don't disagree with any of what you've said, but you
| haven't addressed the issue.
|
| The issue is that anyone unable to _intuit_ what has been
| said in this HBR rag has no business directing the work of
| another human being.
|
| No amount of difference in "mindset" or "context" can account
| for the sheer obviousness or what is being said, nor can it
| justify passing this off for expert analysis.
| mentalpiracy wrote:
| is-ought problem though; unfortunately many/most of the
| individuals managing work are not able to intuit this on
| their own.
| omginternets wrote:
| And so I rest my case: I fail to see what value HBR's
| core readership can possibly bring to a company.
| [deleted]
| jldugger wrote:
| > Every time I read an article from HBR, I find myself
| wondering (a) how the content isn't obvious to anyone with a
| working nervous system (b) what value its core readership can
| possibly bring to a company.
|
| Pretend for a moment you are responsible for the quality of
| management at a large tech company. You think this article's
| guidance is obvious but what percentage of managers do you
| think already practice it? How do you make that number go up?
|
| Also: what makes this article so much worse than
| http://www.paulgraham.com/makersschedule.html?
| omginternets wrote:
| >"What about PG"
|
| What about him? That's drivel too.
|
| As to your actual point, it's horrifying that people need to
| be told "don't be distracting", and that this passes for
| best-in-class analysis on the subject of business
| organizations.
|
| P.S. as a sibling comment points out, this drivel isn't even
| meant to be helpful. It's meant to be uncontroversial.
| civilized wrote:
| It's for the bullet point class. The type of person who, if
| you can get their attention for 10 seconds and stuff 3
| bullet points in their head, they will make a crude,
| flawed, but genuine movement in the direction you pointed.
|
| If this person were rare, the world wouldn't be nearly as
| saturated with slogans as it is.
|
| And to be honest, I think we are all this person from time
| to time, when we are stretched thin.
| izacus wrote:
| It's kind of incredible how naive you are, did you ever
| actually work at a larger organization? :)
| omginternets wrote:
| Naivety is being surprised by this, which I am not.
|
| What I'm experiencing is closer to despair (and maybe a
| hint of misanthropy).
| [deleted]
| thenerdhead wrote:
| Many managers fail to bring out the energy in the people they
| "lead". Some people are energized by autonomy in their job, some
| relatedness to others or the work itself, and some competency in
| their skills or career progression.
|
| Work is getting more personalized every year and modern
| management cannot be a one sized fits all approach anymore.
| nuancebydefault wrote:
| So, suppose a manager profiles an employee using metrics
| software, and subjectively concludes from the outcome that the
| employee is not performing well. What are they going to do
| subsequently? Admit the deed of profiling and ask the employee to
| level up? How will the employee feel, motivated?
| lifeisstillgood wrote:
| Pretty much each piece of advice here can easily be replaced with
| software. I think "manager as supervisor" is frankly dead. It
| just hasnt stopped moving yet.
|
| For me a great thing to learn from software development is daily
| integration builds - whatever work is being done, build it as the
| complete sellable product every day. This way you will get good
| at making the saleable product
| volkk wrote:
| > I think "manager as supervisor" is frankly dead.
|
| sorta. as someone who is an EM, so i guess take the bias with a
| grain of salt, the difference between a really good EM, and
| someone who warms a seat is astounding. the really good ones
| have strong opinions, can coach well on a variety of topics
| (e.g effective communication, organizational thinking), and
| understand the technicals at least from a level of where you
| can see how your direct reports are doing. they also understand
| the economics/business of a company and can foresee which teams
| are dead-ends so they can offer good advice to direct reports
| to grow careers.
|
| the ones who warm seats are glorified project managers. no real
| advice beyond "should we do standups, when are retros" and
| basics like running a board, or taking notes during meetings.
| usually pretty disconnected from the day to day, no strong
| opinions on the actual hard stuff, just topical high level
| advice. plenty of those in the field, and its unfortunate
| because its not a hard science, so they tend to BS their ways
| into these positions and make a lot of money.
|
| either way, managers aren't going anywhere and no amount of
| code will automate them away.
| dalyons wrote:
| I agree and further - After ~20 or so years in tech
| (including being a manger myself for awhile) I would guess
| about 70% of EMs industry wide are your "seat warmers".
| They're not necessarily harmful or bad people, just kind of
| useless. These days I have learned to pretty much ignore what
| they say and chart my own path to making things happen.
| SamuelAdams wrote:
| Unfortunately in corporate America there are many people
| who are simply coasting towards retirement. It's quite
| difficult to motivate someone when they only have three
| years left.
| nine_zeros wrote:
| Supervisory management actively impedes work. Managers should
| be planners, resource allocators and stakeholder communicators.
| They should work to bring their team into alignment with their
| org's goals and their company's goals. By attempting to be a
| supervisor, it sets the wrong incentives within the team.
|
| This is also the reason why penalizing performance reviews
| don't work. It causes lower morale within the time and nobody
| really feels aligned with the company. Everyone is out there
| looking out for themselves.
| lifeisstillgood wrote:
| >>> Managers should be planners, resource allocators and
| stakeholder communicators. They should work to bring their
| team into alignment with their org's goals and their
| company's goals.
|
| But there are either better ways to do these things, or they
| still require coercive (supervisory) activity.
|
| So planning. yeah it's important. Have a clear goal and work
| out what you need to achieve it. Frankly the new intern can
| achieve most of that in one day, and all the senior team can
| easily do it. And prioritise it. The hard part is where you
| have multiple parts in parallel. Sometimes people think they
| are some Moriarty style genius who can direct each part to
| develop and land with precision six months in the future.
| Total bill ox. If you aren't doing daily integrations you
| aren't co-ordinating and so you aren't "planning".
|
| Yeah there is a function of logistics - but that's
| spreadsheets and gaming out scenarios - not a "management
| task" but certainly a "management input" - and if instead of
| giving it solely to managers you just published it to the
| whole org such logistics would be available to increase
| discussion and awareness (ie the workers would understand the
| plan better and not need managers)
|
| Resource allocators - pretty much as above - plans, resource
| budget all different sides of same coin.
|
| Aligning goals ... that's incentives. That's easy - pay me.
| Otherwise ... looks a lot like coercion.
| mhss wrote:
| > But there are either better ways to do these things, or
| they still require coercive (supervisory) activity.
|
| I wish there were a consistent answer to this, but part of
| the reason management is hard (and I won't deny there's
| plenty of useless managers) is that people is very variable
| and you need to adjust your approach depending on the
| organization composition.
|
| > So planning. yeah it's important. Have a clear goal and
| work out what you need to achieve it. Frankly the new
| intern can achieve most of that in one day, and all the
| senior team can easily do it. And prioritise it.
|
| There are plenty of teams and situation where this is
| hardly "easy", particularly at very large companies.
| Relative priorities are not always clear, many teams
| demanding your team's attention and understanding what is
| "best" for the company and company goals, the team and
| individuals is non-trivial. You need to align all of those.
| It requires constant communication (hence why managers
| spend time on meetings, reading presentations, reading
| roadmaps from other teams, 1:1s with their team to
| understand their personal goals, etc);
|
| > and if instead of giving it solely to managers you just
| published it to the whole org such logistics would be
| available to increase discussion and awareness (ie the
| workers would understand the plan better and not need
| managers)
|
| Even in organizations where the information is open and all
| documentation, meeting notes, spreadsheets, etc; are open
| people struggle to understand and some just want the
| summary (I'd say most); they don't want to know how the
| sausage is made outside maybe have an understanding of the
| process (and some not even that).
|
| > Aligning goals ... that's incentives. That's easy - pay
| me. Otherwise ... looks a lot like coercion.
|
| Maybe is that easy for you. A lot of people want something
| else from their careers and as a manager you have to align
| what the organization wants with what the individual(s) and
| teams want as much as is reasonable to maximize their
| satisfaction (retention, performance, etc; is better if you
| achieve this).
| Eumenes wrote:
| HBR is unsufferable. Whether you like it or not, remote work has
| led to reduced productivity. No, I don't need to see some HBR or
| NPR article. I literally see it everyday. Some people need to be
| micromanaged or axed. I say this as someone whose worked remotely
| for over 10 years. Most just aren't cut out for it and need adult
| day care.
| _448 wrote:
| I once worked for a startup co-founded by people who created
| DirectX at Microsoft. There is a book written on how DirectX was
| created and what went on inside the team during those initial
| days of DirectX. Hence this book was available in the library of
| the startup where I worked. These is a very interesting statement
| in that book on the topic of what a manager's responsibility
| should be in a team. And this is what it said:
|
| "A manager's responsibility is to remove any roadblocks from the
| path of an engineer. If an engineer is coming down a hallway and
| there is a chair in the path blocking that engineer, then it is
| the manager's responsibility to remove the chair from the path so
| that the engineer is not troubled." :)
| myself248 wrote:
| This is exactly right.
|
| Years ago, very early in my career, I rotated among a few teams
| at the company, and even then, one manager stood out as
| different from the others. I straight-up asked him if he had a
| philosophy or something, and this is what he said:
|
| "Yeah, my job as a manager has three parts. First, get the
| right people for the job. Second, get them the resources they
| need. Third, get everything else out of their way."
|
| Decades later, this still rings true. That team was the most
| productive I've ever seen.
| sigstoat wrote:
| > There is a book written on how DirectX was created and what
| went on inside the team during those initial days of DirectX.
|
| what's the title? the number of books on programming with
| directx sort of drowns out the search results.
| rqtwteye wrote:
| Reminds me of my first startup in the US. When things got
| difficult, we had daily 30 minute status meetings. Then things
| still didn't go fast enough so everybody had to attend 2 30
| minute status meetings every day. It was just nuts. I tried to
| tell upper management that probably nothing important will change
| every day and even less likely in half a day but no luck.
| Waterluvian wrote:
| I remember an experience many moons ago where there was some _"
| emergency"_ situation and our manager was just insufferable.
| Every 40-60 mins wanting to check with the ~3 engineers working
| on the issue for an update or to offer futile advice. I could
| palpably feel their anxiety and helplessness. I remember it
| reminding me of the trope of a parent in an ER on a hospital TV
| show. Obviously there was a lot of pressure put on them from
| above. I am sympathetic.
|
| Years later, a very similar experience happened with a different
| manager. But they handled it very differently. They called a
| meeting, led us through understanding the situation and us
| working out what the solution should be. They got our feedback on
| how long we thought it would take and then said they'd come by
| for an update in half that time. And that was it. I was so
| impressed.
| jrockway wrote:
| I like to practice incident response on a regular basis, so
| people, including managers, know what to expect out of the
| process. If you do a practice incident every week, a real
| emergency will feel routine and people will be less anxious. If
| people are really distracting on the incident response call,
| you can always kick them off and elect someone to keep them
| updated, of course. I've never had to kick anyone off a call,
| though.
|
| I was introduced to Pagerduty's incident response guide and
| like it a lot: https://response.pagerduty.com/
| awinter-py wrote:
| Crisis communication is an specific sub problem of team
| communication. Good takes on this often come from experienced
| disaster responders, like a fire chief or FEMA.
|
| Their version of this is very real: 1) the annoying manager
| bugging for updates is the mayor's office or other powerful
| executive branch, 2) the emergency from which people are being
| distracted is life or death, 3) a jumpy executive can give
| wrong messages to the public which increase the workload or
| danger level.
|
| Saw a lecture about this once, takeaways were 'clear lines of
| communication' and 'clear chain of command'. Wherever possible,
| put a person or a process between non-operational managers and
| front-line responders.
| lnxg33k1 wrote:
| I had a manager at my last job who tried to do the "what's the
| update" during a crisis and I just decided to make fun of her
| saying "I solved it but decided it would be funnier if didn't
| tell anyone" and she stopped
| onion2k wrote:
| Something to note is that there are _two_ important variables
| in the second story. The first, as you say, is that you had a
| different manager. The second is that _you_ had more
| experience. In every situation a manager is only ever as
| effective as the information they have, and that comes from how
| good their team is at communicating with them. I 'd hazard a
| guess that you were better at telling your manager what they
| needed by the time the second event happened.
|
| If the team has good comms, and experience of both working and
| communicating updates to their manager regularly, and the
| skills to explain things in ways people understand, generally
| speaking you find the manager needs to check in less often.
| They can trust you to raise things promptly, to ask for them to
| do things for you, and that when you're quiet it's because
| you're busy rather than stuck. I find that teams who complain
| about their manager very often don't trust their manager and
| vice versa. Building up that trust by getting both sides to
| work on improving comms fixes a ton of problems.
| Waterluvian wrote:
| My knee-jerk reaction is to offer a riposte of additional
| data demonstrating it really was about the managers. But I
| think you've got a valuable and generalizable point here. I'm
| going to reflect a bit on that.
|
| You know what's difficult? Looking back at a younger self and
| being truly critical. Gosh, it's so easy to just say, "yeah
| well his employment future at that company proves my point."
| But then I learn nothing else that I can grow from.
| rhommel wrote:
| > In every situation a manager is only ever as effective as
| the information they have, and that comes from how good their
| team is at communicating with them.
|
| So much true in these words
| serial_dev wrote:
| > > Every 40-60 mins wanting to check with the ~3 engineers
| working on the issue for an update
|
| > I find that teams who complain about their manager very
| often don't trust their manager and vice versa.
|
| I get that sometimes it's not (only) the manager's fault if
| there is no trust, but if as a manager you need a status
| update every 40 minutes while the people are fire fighting
| and working on an incident, I feel like you failed as a
| manager.
| viraptor wrote:
| I feel like there's a good and bad way to do this at the
| same interval. Of course it depends on the situation as
| well and what you say, but when I'm dealing with an actual
| emergency, I can't imagine not posting an update every hour
| or so. Usually much more as a way of documenting what's
| happening for a later PIR.
|
| If a manager doesn't get the required details to know
| what's happening (I'm situations where they do and still
| ignore it), then the whole process could use an
| improvement.
|
| From my SRE perspective, if an incident takes longer than
| 30min, I want my manager/coordinator to be constantly
| updated and handle communication with the rest of the
| company/customers.
| sokoloff wrote:
| I've been that SRE senior manager in some longer-than-
| ideal outages.
|
| One of my biggest roles was chasing off the lookie-loos
| and fending off the VPs and CIO (usually by telling them
| to GTFO of the war room but then going to give them an
| update away from the team with what we knew and what I
| thought).
| 8ytecoder wrote:
| Usually there's a primary and a secondary. One person
| handles the actual debugging and the other handles the
| communication and coordinating. While I agree it's poor
| management to ask for an update every few minutes, it's
| not because asking for an update is bad, rather because
| they themselves failed to communicate and train their
| employees to properly handle communication. Looking back,
| this was something we did in our team when I was just <2
| years out of college. I was the secondary and posted
| updated to the tickets and emailed the team every 30
| minutes. I was also the one calling in people to help
| when primary needed help. My manager didn't bother us
| because he had already clearly laid out how we handle
| issues of each severity and who does what. It was also
| clear what the chain of escalation was and who and how to
| reach out. Incidentally, it was also my job to close the
| issue by identifying the cause and fixing the issue from
| recurring - because the secondary was only observing and
| communicating they get to see the bigger picture and also
| a welcome break for the person working hard to fix the
| issue.
|
| Learnt a lot by working with a team that knew how to
| handle themselves. And we weren't SRE - just regular
| devs. This manager - my very first one - has also been
| the best one I've ever had. I wasn't surprised at all
| when he quickly scaled the ladder and is doing really
| well for himself now.
| idopmstuff wrote:
| While I do think the manager bears the vast majority of the
| responsibility in situations like these, the reality is that
| you're right, and oftentimes managers do a bad job because
| they're getting pressured from above to communicate and don't
| know what to do.
|
| You can often get them on your side by giving them a plan
| that makes them feel like they're in control (again, totally
| not your responsibility! But better than dealing with them
| being obnoxious constantly). If they ask for an update and
| you say, "I don't know what's wrong, but we're looking into
| it" then they don't know what to do. If you tell them "I
| don't know what's wrong, but right now we're investigating x
| because we suspect that's the source of the issue. I'm
| checking the logs and other engineer is trying to recreate
| the issue in a clean environment. Unfortunately I don't have
| a good answer as to how long it'll take, but we'll update you
| either when we've learned something useful or in two hours,
| whichever is sooner," then they have something to say to the
| people above them and they understand when they'll get an
| update, so they don't need to bother you.
|
| A helpless manager is like a child - if left alone, they'll
| just shout and cause problems. What they really need is
| direction and structure.
| candiddevmike wrote:
| > A helpless manager is like a child - if left alone,
| they'll just shout and cause problems. What they really
| need is direction and structure.
|
| What they really need is to find a different job. Needing
| to "manage up" is the ultimate waste of resources IMO and
| puts a lot of stress on the employees, why even have a
| manager at that point.
| TheSpiceIsLife wrote:
| While I tend to agree with you, this doesn't look like
| anything actionable.
|
| I've even tried it by saying something like: "I get the
| impression you don't really enjoy your job" and getting a
| response something like "no, I hate it, I hate trying to
| manage _people_ ", and then suggesting the look at job
| ads.
|
| Nothing has changed since.
| candiddevmike wrote:
| I agree, and to make matters worse, IME managers of
| managers tend to be very apathetic of their reports and
| don't have the same kind of scrutiny of the folks under
| them that they expect those same people to have of their
| reports. So the people that shouldn't be managing others
| don't really have a "check" above them to confirm it,
| especially if they're good at deflecting
| blame/sacrificing their reports.
|
| I'm a big advocate for no confidence votes from reports
| to signal to someone that this person needs to go.
| 8ytecoder wrote:
| Right, circular logic. If I have to manage my manager,
| can I just manage myself?
| tremon wrote:
| _that comes from how good their team is at communicating with
| them_
|
| Communication is a two-way street. Proactively calling a
| meeting with all those involved to understand the situation
| and then letting the team get on with their work is 100% a
| managerial skill, not a function of the seniority of the
| engineers.
| Godel_unicode wrote:
| When I interview for a job I always ask my prospective manager
| about the is. "What's your process for getting status updates
| during a crisis". This question is graded pass/fail.
| ahepp wrote:
| Examples of passing and failing responses?
| iamcreasy wrote:
| Can you share some of the good/bad responses and was your
| inference correct?
| givemeethekeys wrote:
| Not having a process = fail.
| davnicwil wrote:
| I am sure you know this, but be careful with this strategy.
| The worst managers of all will tend to give you the answers
| you most want to hear in these situations.
|
| The best will tell you the truth. This _might_ be the same in
| the best case but is often less than perfect in reality
| (though, per being a good manager, can at least improve).
| sigstoat wrote:
| > The worst managers of all will tend to give you the
| answers you most want to hear
|
| i don't think the worst managers even know what the right
| answer is.
| eastbound wrote:
| You gained seniority. I have employees who don't take a support
| case with a customer waiting with the straightest path, instead
| they take the opportunity to refactor code, so I check on them
| all the time; Others who refactor the code after delivering the
| bugfix, and those I leave them alone.
| telman17 wrote:
| How do you coach the former to behave more like the latter?
| slgurtman wrote:
| This is a result of always having the refactoring put on hold
| for feature development. Eventually engineers realize the
| only way to address tech debt is to refactor as part of a
| feature or bug fix.
|
| This doesn't happen when developers have trust they'll be
| allowed to refactor although sometimes it's a case of learned
| behavior from previous employment.
| mk89 wrote:
| > This doesn't happen when developers have trust they'll be
| allowed to refactor although sometimes it's a case of
| learned behavior from previous employment.
|
| To my surprise, this is not always true. Some engineers do
| things because they have fun, even senior ones, and they
| will keep on refactoring things until there is a hard stop.
|
| Best is to never generalize. It may depend from team to
| team, etc.
| evilduck wrote:
| Yeah, everything is situational. Someone can be a very
| competent developer, even an congenial coworker, and
| still be a terrible employee.
| candiddevmike wrote:
| If you don't let them do this from time to time they will
| quit eventually, IME as a manager. Whether that's
| beneficial to the org or not is debatable. You can kind
| of "release the pressure" in a planned manner via
| hackathons, but those almost always never have the
| appropriate frequency.
| vgatherps wrote:
| The prioritization of refactoring is strongly context
| dependent. A small startup with a fast moving product
| trying to acquire and retain customers cares much more
| about serving said customer _right now_ than an established
| business who has more freedom and engineers available to
| dedicate time to forward thinking projects like
| refactoring.
| jrockway wrote:
| I've worked at both large companies and small startups,
| and I've never seen taking on tech debt pay off. Features
| never get delivered as quickly as anyone wants, but
| sometimes tech debt completely prevents even thinking
| about features, and not being able to even imagine
| implementing something is a much worse problem than being
| 2 extra weeks late to the newest pivot. If I were
| starting a software company today, I'd want to keep my
| POC code about as clean as I'd keep production code at a
| large company. Well, cleaner. It's going to be alive as
| long as you are, and there will never ever be a good time
| to rewrite it.
|
| Having said that, I am very skeptical about what some
| people identify as tech debt. Things like "we're using X
| logger instead of Y logger, this codebase is unmaintable"
| I tend to not prioritize, but things like "this system
| looks weird and we don't understand if the code is wrong
| or the documentation is wrong" is something that should
| be addressed with high urgency. It's very easy to spend a
| lot of time maintaining misbehavior that should just be
| fixed, and the first step is understanding whether or not
| something is wrong.
| Waterluvian wrote:
| I think this is an interesting comment because it seems to
| try to re-locate agency back onto the manager. Ie. It's not
| that the other manager was better, it's that I somehow earned
| the better management. Correct me if I'm misinterpreting you.
| vgatherps wrote:
| It seems like a pretty standard (and simplified for HN)
| classification of employees who are and aren't able to
| prioritize well.
|
| Employees who can prioritize well will naturally be given
| more independence to make choices than those who don't.
|
| This of course assumes the management is able to make good
| decisions about prioritizing but I think the commenter
| should be given benefit of the doubt here.
| NikolaNovak wrote:
| This is an interesting point and may be part of the factor.
| I.e. There are two variables, and chances are that playing
| with either affects the outcome - experience and self
| sufficiency of the hands on person, and experience and self
| sufficiency of the manager (plus, I'll argue, other variables
| like maturity of processes, and client relationship /
| management state, etc). There is an inclination to focus on
| one variable only.
|
| Fwiw. I've been a hands on techie for 20 years, then ops
| manager for 5. I've certainly been an Inexperienced/been a
| bad manager at times (especially as for a while, highly
| functional specialized vols reported to me as well), and I'd
| like think I'm becoming a decent or even good manager. But
| even still, there are definitely teams and individuals that I
| will feel the need to manage and focus ; vs others that I
| feel I can let prioritize and self manage.
|
| (In the ops, of course, establishing formal urgency levels
| and resulting comms expectations and paths, can reduce stress
| on EVERYbody)
| [deleted]
| 908B64B197 wrote:
| I've seen this distinction and it always boils down to two
| factors: is the manager technical and what's the caliber of the
| engineers.
|
| Technical managers typically have a pretty good idea of what
| the rough requirements for a given situation will be. They
| might not be familiar with the exact details but should have
| some clue, so they just want to make sure everyone has a plan
| and it's sound. Non-technical managers don't understand what's
| going on so need to micro-manage because they perceive
| everything as high risk and complicated.
|
| Caliber of engineers is pretty self-explanatory, but maybe
| that's selection bias; a 10x engineer won't stay long where
| he's micro-managed.
| zmmmmm wrote:
| definitely this ....
|
| non-technical managers have literally no tools at their
| disposal other than to bug other people to do things. in a
| crisis, therefore, all they can do is dial up how often and
| how much they bug everyone else to do the actual work. At
| best they act as communication hub, gathering crucial
| information and coordinating to ensure it gets to the right
| people as fast as possible and they act on it in the right
| way. But even in that role they are limited because they
| don't have enough insight to really know who needs to know
| what and what they can do with the information.
| Pxtl wrote:
| Hah, when an emergency is happening only one person asking for
| hourly status updates would be a goddamned reprieve.
|
| When stuff hits the fan I expect to be getting constant
| questions from the business analyst, the helpdesk, _and_
| manager, as well as having to explain to every other person who
| hasn 't heard that I'm busy that no I can't help them with that
| today.
| Jenk wrote:
| I've worked in >1 companies where the SLA requires hourly
| updates for incidents, and they have to have substance beyond
| "still fixing."
|
| This is in large scale finance and/or investment sectors where
| it is immeasurably important to keep clients (both "those
| paying us" but also the "those integrating with us" types) well
| informed of progress so as not to cause market panic.
|
| Sometimes communicating is worth it for interrupting the team.
| emeraldd wrote:
| There's communication by interruption and there's
| observation. If you have a situation where there need to be
| hourly updates, there should be a person explicitly tasked
| with observing and noting what's going on to be able to
| provide those updates with minimal impact to the group that's
| actually working the problem.
|
| Unfortunately, that means the observer has to be able to
| understand and follow what the engineers are doing while
| staying out of the way as much as possible. Tricky, but
| something you really need if for no other reason than to
| communicate and look for any holes that the team/person
| working the problem may not have thought of in the interim.
| bluGill wrote:
| If that is the case you should pair program, where one of the
| pair's only job is to sit behind the engineer doing the job
| and listen in, then take the meetings. This needs to be a
| full engineer who is fully capable of doing the work, but
| instead is just understanding the work, but not doing any.
|
| If the main engineer has a 'family emergency' your
| communication engineer has enough context to take over, while
| another engineer is assigned to communication.
| antod wrote:
| Agreed. That was how I've seen it run well. eg we'd create
| 2 channels for the incident - the first was for the
| technical team trying to fix it and would have quite a bit
| of noise as debugging went on. The second was for more
| senior managers and the client/account people to coordinate
| comms with customers. The only manager in the first group
| was the teams direct technical manager or their eg Tech
| Lead type of role. Their job was to not work on the fix but
| to communicate what they were observing to the 2nd group
| who would deal with the customers.
|
| Smaller companies though are a bit less structured, and
| have to wing it a bit more depending on circumstances.
| jeffparsons wrote:
| Assigning a "communications officer" at the start of an
| incident seems to work well. They are a person with the same
| technical skills as the people actively working on the
| problem, but their job is primarily to observe and
| filter/transform communications to and from the team. A nice
| side benefit is that having someone who isn't actually
| responsible for fixing things seems to free up their mind to
| notice things that their hands-on-keyboards colleagues
| missed.
| tremon wrote:
| _Sometimes communicating is worth it for interrupting the
| team_
|
| Perhaps, but the first thing any emergency responder will
| tell you is that there should be one incident commander, and
| that all communication and allocation of resources should go
| through that one person. And that the person with the
| incident commander role should _not_ carry out any
| operational duties besides coordinate and control, because
| those other tasks require the same mental faculties, but use
| them in a different way, making them less effective in
| either.
|
| If there is a requirement to update customers affected by an
| incident, the company should have processes in place to
| streamline the flow of information _without interrupting the
| team_. And the team responsible for updating customers should
| only communicate with the incident commander, and absolutely
| steer clear of the operational responders. If specific
| details are required, it falls to the incident commander to
| gather those details from the team, not to outside people
| running interference.
| Consultant32452 wrote:
| The key component in this system that understands human
| psychology is to set reasonable expectations. Most places
| don't have that kind of SLA, but when an event occurs you can
| set an expectation of when the next communication will be and
| as long as it's not crazy, people will go along with it. But
| if you just leave people hanging, not knowing when/if an
| update is coming, they have nothing to do but panic about the
| lack of new information.
| PragmaticPulp wrote:
| > Sometimes communicating is worth it for interrupting the
| team.
|
| If you need constant updates from someone who knows the
| subject material, you need to nominate a single person who
| knows the material to take point on communication. They can
| help in between communication updates, but they can't be
| tasked with leading or owning the work.
|
| The worst way to do it is to have a manager who can't
| understand the subject material themselves, then let them
| interrupt _the entire team_ over and over again. Then the
| team has to stop and educate the manager about what needs to
| be communicated so they can relay it to someone else.
|
| Having non-technical managers relaying information back and
| forth from the entire team is always a mistake.
| dilyevsky wrote:
| Clearly you need non-technical manager to communicate status
| to the customers. You know, because they have people skills
| treeman79 wrote:
| Had something similar. Deadline to go live was Monday at noon.
| We didn't even have a working proof of concept on Friday.
|
| Has multiple managers at my desk every 30 minutes on Monday.
|
| At 11:58 they announced they were calling client to go live
| with them. Product was not working.
|
| Manager. Hey they say it's not working.
|
| Me a few final key stokes and a save. (On prod server) Try now!
|
| Client says it's working now!
|
| Went to the ER. Thought I was having a heart attack.
|
| Never again.
| bitL wrote:
| As a VP I had some conflicts with subordinate managers who were
| super anxious and transferred their anxiety on their own teams.
| Basically they had no clue how to solve problems due to not
| being technical and as a consequence made their whole teams
| neurotic like they were. I typically had to take over for a
| while to cool down the team and shield them from their managers
| whereas managers were supposed to shield the team from me.
| abvdasker wrote:
| Not only should managers not distract their reports, I view a
| primary responsibility of any engineering manager as proactively
| shielding their reports from as many unnecessary meetings --
| particularly with external teams -- as possible so that engineers
| can focus on what they're paid to do: building stuff. The best
| managers I've ever had spent a significant amount of their time
| just interfacing with product managers and designers to cut down
| on bullshit that distracts engineers from doing their jobs.
| icedchai wrote:
| This only works if the EM is both somewhat technical and
| actually communicates well with their reports. "Shielding" and
| leaving out key, important details will eventually result in
| pissing off your reports even more than useless meetings.
| serial_dev wrote:
| It's a hard balance.
|
| One of my managers had the goal of "shielding" the engineers,
| which in practice meant that everything went through him (at
| each step losing nuance), we never knew why something was
| important (we didn't know what we wanted to solve and why it
| was valuable for the company), why something was the most
| important task at a time (why not work on something else), we
| didn't know who to ask about it (felt like learned
| helplessness), we didn't know how deadlines came to be (where
| they just made up or was there a really good reason).
| punnerud wrote:
| Leadership = A leader standing in front of a ship guiding
|
| In Norwegian: Lederskap = "Leder" is the same as leader + "skap"
| that translate to closet, the more right place for a leader?
| 29athrowaway wrote:
| Who is more important? An efficient manager that has 5 reports,
| or an inefficient manager with 10 reports?
|
| How about a very inefficient manager with 30 reports who now
| needs 2 levels of management to manage that team?
|
| Distracted employees are inefficient, create the perception of
| busyness and the opportunity to require more headcount, making
| bad managers more important.
|
| Many large organizations are just bad managers trying to look
| bigger.
|
| Those managers do not want efficiency, because they need
| inefficiency to justify their organization size and their role.
___________________________________________________________________
(page generated 2023-04-02 23:00 UTC)