[HN Gopher] Load 'em up and throw 'em under the bus
___________________________________________________________________
Load 'em up and throw 'em under the bus
Author : picture
Score : 575 points
Date : 2023-03-09 23:42 UTC (23 hours ago)
(HTM) web link (rachelbythebay.com)
(TXT) w3m dump (rachelbythebay.com)
| busthrowaway844 wrote:
| Throwaway for raw honesty.
|
| I've worked under an engineering leader for a few years now that
| I think must get a bonus to meet every quarterly goal. Others
| must also, based on their behavior around these events. I've felt
| the weight of the team being so understaffed for the workload for
| so long that I've pendulum swung from high morale (i.e this is
| important good work) to such an abyss of low morale. I'm having a
| hard time shaking it and I could really stand to be more
| productive on things I find interesting and important about the
| work. I guess this article resonated with me enough to post about
| it. Makes you weary after awhile.
| a_c wrote:
| Management problem is an engineering problem. Management is how
| you engineer your organization.
|
| I don't know how big the organization the author is working at,
| too big in my opinion, too big in complexity.
|
| What I observe, could be wrong
|
| - the team "writing" the service is different from the team
| "fixing" the service. It is like letting one guy write code, the
| other guy compile code, but on a team level. Feedback of quality
| is lost.
|
| - "Then I got lucky and intercepted a few of the zanier ideas".
| It is common in tech companies nowadays, but I think is really
| not ideal, one party for ideation, one part for implementation.
| This is not making full use of engineers in my opinion. Give me a
| recipe, I cook for you. Engineer can be both chef and a cook, but
| people seem to be happy being a cook. Feedback between ideas and
| implementation is lost.
|
| - "The surprise came later, when the biannual review cycle ". If
| it is performance review. It is too sparse. Engineers might
| already be gone and good luck keeping the service up
|
| - "They wanted to give this person some bullshit sub-par rating".
| Lacking objective measurement. Maybe that's why they run the
| review biannually. Subjective rating is time consuming. I imagine
| it having to compile "evidence" from various source, and give
| "justification".
|
| You always want the feedback be quick and whole. Code compilation
| fast, test run fast, CI/CD fast, HTTP return fast, usage
| gathering fast, the feedback about whether your piece of code is
| useful fast, the feedback about team's performance fast. In
| engineering, we take for granted that things can happen almost in
| real-time. But in management, somehow feedback (reports,
| performance) need to be "compile" X times per Y period. In
| engineering, we somehow have the thinking that abstract only when
| the code is repeated the 3rd time. Hence we avoid abstracting the
| wrong thing. In management, we often form an abstraction (team)
| based on some vague notion on how things are compartmentalize. Oh
| yeah let's have 2 frontend and 2 backend on the completely new
| recommendation feature. That's the team formation. Engineering
| and management have a lot in common
| jeremyjh wrote:
| There was not another team fixing the bugs. I understood her
| original team to be some kind of SWAT team that works across
| the org to triage and pin root cause of high impact issues and
| outages. That kind of team deals with incidents, but they don't
| fix software bugs. How could they possibly do that across many
| different teams and codebases?
| a_c wrote:
| I did't mean they fix bug. They are to notify "compilation
| error". They are to triage and tell service team to fix it,
| rollback the service to a previous version, keep system up.
| They don't pin root cause, there is always rooter cause. The
| root to them is probably figuring out which service is down,
| which is not the root. This all come from SRE. From micro
| service. From practice most company ain't going to need but
| adopted. Which is my original intention: not sure how large
| the organisation is, but felt overly complex
| languagehacker wrote:
| Anyone else get the impression that this blames managers without
| thinking about making sure the members of the team made cross-
| training a priority?
|
| There's really not enough context to have a good opinion on this
| anecdote. Rachel has a very specific perspective, as always, and
| I often think she interprets her observations to fit that
| perspective. Don't we all.
| dizhn wrote:
| I don't know why, maybe because I came across them around the
| same time, but whenever I read rachelbytheway I am hearing Paula
| Poundstone's voice in my head.
| tristor wrote:
| I have been that guy, unfortunately nobody stepped in to prevent
| me from being thrown under the bus, and it ended up with me
| departing a company where I otherwise loved the people I worked
| with. It ultimately ended up being one of the driving factors of
| some burn out, that in working through made me leave engineering
| altogether for a different role. This can happen especially in
| startups, because you're always resource constrained, growing
| faster than you can handle (you hope), and everyone wears
| multiple hats. That is all fine, generally, it only becomes a
| problem when you never (after several cycles of hiring) get help
| to remove some hats and/or you end up being held responsible for
| failures outside your control due to that situation.
|
| Now in a different role, I make it a point to try to identify
| teams that are overloaded, shield them from unfair expectations,
| and advocate for additional resourcing. If you bother looking,
| it's generally pretty obvious, but most managers are focused on
| managing up, not managing down, so ICs at the bottom are ignored
| unless they're a source of waves that come back through
| management onto their chain.
| somsak2 wrote:
| interesting story but wrong conclusion. this isn't about a
| management problem but rather a case of an IC taking on too much
| themselves. had they never attempted to do the work of 3-4
| people, this general problem would have become apparent much
| sooner. instead they overworked themselves and put their own role
| at risk for a sub par rating.
|
| do not allow yourself to be overworked for more than a few days
| at most. it never ends well.
| ahtihn wrote:
| > rather a case of an IC taking on too much themselves
|
| Which is a management problem. If management can't see that
| this is happening and fix it, what are they even doing?
| devwastaken wrote:
| Management does not understand what a "3-4" workload looks
| like. By their estimate they have the number of devs required,
| therefore to them it must be the devs that are the problem, not
| the number of them.
|
| It's not as simple as getting more devs, it's justifying
| another half mil a year in wage costs for that team. The people
| at the top with the pocket books really don't like that. Is
| your manager going to risk their neck, bonus, review? No. If
| the dev doing all the work burns out thats not seen as a fault
| of management by other management.
|
| That dev likely did that work because they don't understand the
| politics and had a mortgage and a kid in school to pay for.
| They want to be able to claim their work for the next job
| interview/resume. "I did less work while the project failed
| because bad management." is not a selling point.
| flerchin wrote:
| The Engineer can leave, the project can utterly fail, and
| only management will be left to take the blame and deal with
| the consequences.
| devwastaken wrote:
| How do you think the interview is going to go for that
| engineer for their next job?
| GianFabien wrote:
| Have been in a similar position. I simply pushed back. Did what
| I reasonably could and well. It wasn't good enough for the
| managers so they demoted me and hired 3 "yes-men" who as a
| group accomplished less than I did whilst pushing back. It
| didn't end well. But no managers were fired.
|
| While there are less-competent yes-men out there, the managers
| will continue to hire those who don't tell them to ...
| anentropic wrote:
| Seems like a problem of hierarchy
|
| Maybe managers should be democratically elected
| jeffrallen wrote:
| > for more than a few days
|
| Yes! But do occasionally fall on a grenade for your team. Pull
| one 12 hour day to get a deployment plan just right, to check
| that one last rollback scenario, etc. Plan 8 hours for a bug
| and then follow it for 24, if the rabbit hole it takes you into
| is important. Develop the discernment to be able to say "this
| is where I'm going to overwork one time this quarter". And say
| it, literally out loud if you need to.
|
| You need to be able to look yourself in the mirror and say, "my
| boss counts on me" before you can go and tell him the same
| thing.
| H8crilA wrote:
| Why though? I don't want to overwork a single day per
| week/quarter/year. And I have absolutely no fairness problems
| with that.
|
| If it can't be done this week it will be done next week. It's
| your problem to deal with it, and my problem to make the tech
| work.
| whitemary wrote:
| No, thanks.
| clnq wrote:
| An important cautionary tale to the "I'll take on the world to
| save the project" types.
|
| Do you want working the job of 3-4 people while being paid a
| salary of one to become your baseline, not meeting which would
| make you an under-performer in the eyes of the management? If
| not, stop and delegate. If yes, good luck burning out while
| blocking your own career progression.
|
| I've seen this in so many tech companies and with so many well-
| intentioned engineers. And it always ends sadly. Either in a burn
| out resignation (worse if the break-up is messy because the
| company is desperate to keep the "high performer"), or a dead
| career (even if the engineer can sustain the pace, management
| won't want to promote them out of the situation). Or worse, if
| the engineer becomes stuck in this situation, they will ruin
| their health through stress, and then the consequences of
| returning to 1x workload and being an "under-performer" will
| follow anyway. It can go poorly in so many ways, but only poorly.
| PartiallyTyped wrote:
| > If yes, good luck burning out while blocking your own career
| progression.
|
| Is there a career blockage if you don't stick around? The more
| you do, the more you learn, the more you learn the faster you
| do, the faster you do, the more you do.
|
| > management won't want to promote them out of the situation
|
| Management can pay a higher salary to retain them. A vertical
| career into management is not for everyone.
|
| > they will ruin their health through stress, and then the
| consequences of returning to 1x workload and being an "under-
| performer" will follow anyway.
|
| Doesn't look like that if you leave a paper trail of everything
| you do.
| clnq wrote:
| > A vertical career into management is not for everyone.
|
| That's a different question which is even more polarizing -
| should good engineers become managers. But to be clear, I
| brought up promotion because that's why many people make the
| decision to take on these responsibilities to save the
| project. It could be a pay raise or a promotion to a higher
| engineering level.
|
| > Doesn't look like that if you leave a paper trail of
| everything you do.
|
| It works this way from what I've seen, I'm sorry to say. But
| I've seen a lot. The paper trail is good evidence in a
| grievance situation but it's hard to restore one's reputation
| through the grievance process - formal or informal.
|
| > Is there a career blockage if you don't stick around?
|
| No, and leaving, to my mind, is the easiest healthy choice if
| an engineer finds themselves in this situation. However, it
| is still an undesirable situation to put oneself in if one
| wants career growth. If leaving is the way they wish to
| achieve that, it's better to just leave than to suffer for a
| while and then leave. If they wish to achieve career growth
| in the company, this will block them. In any case, it's
| wasted time from a career advancement perspective.
|
| You could say that working in a high-pressure situation would
| teach the engineer something, and maybe it's true. But mostly
| it will make the engineer make many mistakes and be
| overwhelmed. Which is why most people argue that learning in
| a relaxed environment is much more practical.
|
| Even people who study extreme medicine (battlefield medicine,
| mountain rescues, and similar topics) study it in a safe
| environment. They do real life simulations but in a
| supervised way. Throwing an engineer into the fire to teach
| them handling a pressure-cooker situation would be much like
| asking an extreme medicine doctor to learn on the
| battlefield. You could say they would learn, but probably a
| lot of what they would learn is to make mistakes.
| oosk wrote:
| It doesn't always end sadly -- it really depends on the
| individual and the company.
|
| In my case, I ended up doing the job of maybe 5-10 developers
| for a year and a half leading up to the launch of a product at
| a large tech company. It was tough, but I believed in the
| product and wanted it to succeed, so I didn't mind putting in
| the extra time. I was also fairly young at the time, so I could
| handle marathon coding sessions without burning out.
|
| After it launched (successfully), I developed a reputation
| within the company that let me basically have my pick of
| projects for the remainder of my time there. Additionally, I
| was awarded a 7-figure stock grant that ended up being worth 8
| figures by the time it fully vested, so it worked out well
| financially too.
|
| I view that project as sort of a career-defining moment, and
| I'm extremely glad I did it.
| franciscop wrote:
| Since my top-comment is #1 and it's a bad example, I'll give a
| positive example here.
|
| In this company I joined I worked really hard. It was very
| exciting work, an innovative startup, pretty good pay (for my
| locale), great coworkers and manager. I still worked around
| ~8h/day, but those were VERY intense 8-hours and after few
| weeks it was clear that our office/team was shipping A LOT
| faster than other teams in HQ. It was a really nice combination
| IMHO:
|
| - Our manager was amazing at getting the work requests and
| converting them into technical tasks/projects, while shielding
| us of the BS that was literally raining from HQ. No one lasted
| too long when he eventually left, and they even closed the
| office a bit after.
|
| - Because of the timezone difference, we had meetings for 1-2h
| in the morning and then calm for the rest of the day to execute
| on those tasks. Our manager had more, but that was a really
| good balance for IC.
|
| - While we had different levels of seniority (and all hired as
| the same "mid-level"), we worked well together and all were
| reasonably knowledgeable, no one needed handholding.
|
| So yeah, after few months/1 year we got some major projects
| finished. One of which I made the major technical part, for
| which I struggled and fought like never before, and
| successfully delivered it. Our CEO used this project even for
| presentations to our investors and clients (was supposed to be
| an internal tool). So my manager got me from mid-level
| ("Software Engineer") to Staff Engineer, a whole 2-level bump
| and 40%-50% salary increase approx.
|
| So sometimes working hard does pay off :)
| Glawen wrote:
| you were just leveling with your teammates which were also
| hard workers. I experienced this in my last job and I'm
| trying to reproduce it, but I find it difficult to recreate
| in another environment.
|
| It is different than being a super hero and hand hold a
| project while your teammates watch you from the side.
| crabbone wrote:
| This is a very simplistic view of the situation. It doesn't
| usually work like that in the real world.
|
| In the company I left few years ago I was a lead developer in a
| department which started with me alone, then at times grew up
| to four developers and shrank to just two.
|
| Here's what it looked like: we were almost always advertising a
| position in my department, and about once a week I had to meet
| another Python developer with X years of experience in infra,
| who was barely literate... No, really, it was that bad.
|
| After each such interview, I had to go back to my boss and
| decide whether we should give this guy / girl a chance, or
| should we spend more time and money looking for more
| candidates. I tried both strategies. I tried to hold out until
| we find a better candidate, and we were simply wasting time
| running in circles. I tried to advocate hiring someone simply
| on a basis that they looked promising. I had to promise my boss
| to bring them up to speed, and that was a year of misery of
| dealing with someone who made such a painstakingly slow
| progress, being such a huge time sink that in the end I had to
| abandon that person to have at least something done.
|
| Infra projects, especially in large-scale products tend to be
| this way. Outside, theres' a huge pool of "Python programmers",
| but most of them are really "Django programmers", they have no
| idea how computers work, and will require years of mentorship
| to obtain that knowledge. Few will see that as valuable as it's
| not a common enough requirement. Few will have the
| determination or passion to get to the point where they are
| confident and independent that they may continue their
| education on their own.
|
| On the other hand, those who gained such experience don't like
| infra jobs for the very reason that they end up recruiting
| novice programmers and leave for more system-like jobs. And
| this dynamic affects every department both at a macro and at a
| micro level: people either learn how to be good and leave, or
| they never do and get replaced by the next batch.
|
| In the end, it's fairly typical that infra department will be
| "carried" by a single employee who's spend ages working there +
| a number of younglings who come and go never contributing
| anything of note. I wouldn't say it's a management problem.
| Infra isn't the only department which sees that kind of
| dynamics. QA is pretty much the same way. Front-end used to be
| more like that, but I don't know what the situation is today.
| It's caused by the pathological relationship which reinforces
| itself with time that prevents expertise from growing both
| locally in an org and generally in the field.
| jjtheblunt wrote:
| Every way you just mentioned seems to depend on a layer of
| managers assessing things?
|
| I ask that because I've observed in both deeply hierarchical
| (and dysfunctional as all hell) Amazon, and super flat (at
| least for a long time) Apple, and your characterizations only
| fit the bureaucracies. (I've observed the same at other places
| as well.)
| clnq wrote:
| You bring up an interesting point. I have not seen this in
| flat or small companies as I have not worked in many. But I
| imagine that those surrounding the engineer will still feel
| that their expectations are no longer met if the engineer
| tries to return to normality from their superhero role.
| Though perhaps the colleagues might understand the full
| circumstances of the situation better in a tighter or less
| hierarchical team.
|
| Ultimately, if someone has the engineer's back when they need
| to stop being the proverbial "Atlas who holds up the world",
| then maybe things could end better. But there are few
| managers that have the insight to notice it and grace to do
| something about it. The kind manager (or colleague) described
| in the article we are discussing is not common.
|
| So whatever the circumstances, generally it does end badly if
| the engineer significantly over-commits to save the project.
| jjtheblunt wrote:
| True
| treis wrote:
| I don't think the engineer in the OP did a good job. They were
| the last link in the knowledge chain. It's on them to pass the
| knowledge along and onboard the newbies.
|
| Is it possible that they got saddled with a bunch of
| incompetent and lazy new hires? Sure. But by simple numbers
| it's more likely that the hero was the problem than it is that
| 4 other people are incompetent beyond help.
| _corvo_ wrote:
| I don't think the engineer in the OP did a good job. They
| were the last link in the knowledge chain. It's on them to
| pass the knowledge along and onboard the newbies.
|
| I find it weird that you're blaming the Engineer and not the
| managers or culture. Isn't it on them to make sure that
| knowledge is passed as well?
| treis wrote:
| That's forcing the engineer to do what they should be
| doing. You can blame them for not doing that but that
| doesn't absolve the engineer of not doing what they should
| be doing.
| lacker wrote:
| It's a tough situation to handle, because if someone is simply
| struggling at their job, it can have the same symptoms. They
| claim they have too much work to do, and important projects
| always end up delayed, with their tasks being the ones that are
| delaying everyone. As a manager you need to make a judgment call
| about how much work they are actually taking on, but that can be
| tricky when you're less familiar with the codebase than the
| individual is.
|
| Either way, you still want to move critical tasks off their
| plate.
| gorgoiler wrote:
| Anyone who follows this blog -- it is frequently linked to from
| this place -- would be able to understand the code words and time
| frame to figure out which company this refers to. It's a small
| world and it's not difficult to guess which piece of tech, which
| team, and which engineers and managers were involved as well.
|
| The story is a good one but, like all gossip, it's a guilty
| pleasure. When someone spreads gossip about a third party then
| you can assume they do it about you as well. It is toxic and the
| opposite of _building trust_.
|
| If the engineers referred to in the story were asked for comment
| or OK'd the post (not that they have to) then I'm completely off
| base with everything I just said.
| draw_down wrote:
| [dead]
| doitLP wrote:
| Please enlighten us. I figure the company is likely Amazon, and
| it's some core service like EC2 given that underpins basically
| everything and has different agents running on each box that
| are handled by different teams like CloudWatch?
| philjohn wrote:
| Not Amazon - the clue is "You know, Cat Pics" - what's a
| service where you can share photos of things, like your life,
| your pets etc?
| weeeeelp wrote:
| I've read about a hundred of Rachel's posts and never thought
| "but who/what company was this actually, specifically, by
| name", just enjoyed the stories. I mean yeah something
| something facebook, big places needing big troubleshooting, but
| in the end I think it's irrelevant to most people, as most
| people don't work in SV.
| ornornor wrote:
| I for one have no clue whatsoever about which company this
| might be, and even less who the individual people (other than
| the author) might be.
|
| The world is bigger than SV, most of us have never set foot
| there or know anybody there.
| walleeee wrote:
| Is there not an enormous difference between spreading gossip
| (in my mind, always _about_ someone in particular, which this
| is absolutely not, or at least not to anyone not neck deep in
| bay area software circles) and relating instructive, anonymized
| anecdotes? I 'm not sure how you're reading this as gossip.
| [deleted]
| dcchambers wrote:
| Beautifully written and I'm happy there was a positive outcome in
| this instance.
|
| I feel like most of us have a similar story. I don't know if it's
| unique to tech, but every team I've been a part of has had a
| "well everyone who originally built this product left and we
| don't really know how to manage it so it's just sort of hobbling
| along but management won't prioritize decommissioning or
| supporting it so it keeps all of us up at night." Do other
| industries have this issue? How can we fix this problem?
| bragadiru_mafia wrote:
| Probable network behaviour. The other team members are part of a
| "network" and their goal is to 1) get non network members to do
| the work and then 2) get rid of them and 3) take over more
| projects, expand hold on the org.
|
| Crafty!
| ok_dad wrote:
| > I got to know him, and found out that he wasn't batshit or even
| malicious. He was just under WAY too much load, and was shipping
| insanity as a result.
|
| I felt like this at my last job but they fired me instead when I
| asked for time off without pay for a few months.
| flybrand wrote:
| It's straight out of Goldratt and Theory of Constraints,
| ultimately the constraint becomes leadership. How many issues can
| leaders address in a day? How do they prioritize the personnel
| needs of their team?
| marcus_holmes wrote:
| Looking forward to hearing the similar stories that will be
| coming from Twitter in a year or two. Egotistical shouty bosses
| are a great source of tech war stories :)
| babbledabbler wrote:
| This is a common pitfall for software engineers and one that is
| easy to fall into especially if you haven't gone through it
| before.
|
| Dysfunctional technical systems are symptoms of dysfunctional
| political systems.
|
| If the political system is not rehabilitated, the technical
| system will continually evolve dysfunctional traits no matter how
| much development effort is spent. It falls to management to
| ensure the political system is functioning properly but software
| engineers should keep this in mind to avoid getting caught up in
| the gears of such systems.
| wpietri wrote:
| As Gerry Weinberg wrote in _Secrets of Consulting_ , "No matter
| how it looks at first, it's always a people problem."
|
| It's situations like this that keep getting me sucked into
| management issues. I join something just wanting to build good
| stuff. But the problems are so rarely technical ones.
|
| I remember once when a friend of mine had joined a company with
| terrible bug problems. They brought me in to solve a particularly
| nasty one where a key client's key users were having regular web
| app failures that presented as network issues. And also to give
| them my take on the devs. After a week of late nights, I
| discovered that certain versions of IE had weird Keep-Alive
| behaviors, which then had a bad interaction with their load
| balancers and their web servers. I changed some configurations so
| the older IE versions had each HTTP collection closed
| immediately, which was slightly slower but always worked. Victory
| achieved, thorn pulled from paw, etc, etc.
|
| That sounded like as technical a problem as they come. But the
| root causes were really people problems. The key client was a
| large company with an IT department that was overloaded and
| underfunded, so lots of users were stuck on ancient Windows
| versions. And my friend's company had a salesperson as a CEO, one
| who would promise new features to close deals without ever
| checking with the development team. They were massively
| overloaded. They had to ship and ship and ship, leaving no time
| for testing or debugging or polishing. They were just drowning in
| bugs, so the CEO thought they were bad developers. But given time
| and room, they could have figured it out just as well.
|
| So I told my friend the developers were great; it was the
| dysfunctional relationship between the CEO and the overstuffed
| backlog that was the problem. I never heard how it turned out,
| but I have my suspicions.
| op00to wrote:
| Note management never took accountability and nothing really
| changed in the management situation.
| kart23 wrote:
| > Then I got lucky and intercepted a few of the zanier ideas
| while he was still under the stupid-high load, and we got some
| other people to step up and start spreading the load around.
|
| it's also up to that IC to recognize they are being overworked,
| and spread that load themselves. And if they're having trouble
| doing so, surface that to the manager and get help.
| vianneychevalie wrote:
| That's the core of the issue: when you're so overworked that
| you (a) don't have the time to reflect upon it and thus (b)
| don't realize that the situation is terrible.
|
| It's a not a new trope, Jack London's Martin Eden addresses the
| inability of physical workers to gain culture and reflect on
| their situation simply through the exhaustion they're subject
| to.
| ok_dad wrote:
| Or, you get replaced or fired. Don't bet on most managers to
| actually help.
| midoridensha wrote:
| Even if your direct manager wants to help, he may be
| overruled by his manager or the upper management. Your direct
| manager frequently doesn't have any ability to do much except
| pass information up.
| wiseowise wrote:
| That's if you have coworkers capable enough.
| draw_down wrote:
| [dead]
| hdhddhshhshd wrote:
| [dead]
| t344344 wrote:
| I love companies like that. If you are a bit proactive, you can
| snatch the easiest parts, and get rewarded just for sending
| reports.
| [deleted]
| hakunin wrote:
| One mismatch I often see between engineers and management.
| Engineers: "I must not be doing the best I can, because I'm not
| keeping up with work. Gotta work faster, gotta do better."
| Managers: "engineers are professionals with strong opinions who
| will always tell me when/if they need anything to help them get
| their work done. Right? If they aren't saying anything, it's
| their own fault, right? They're adults, right?"
|
| Unfortunately many engineers (and humans generally) can't easily
| recognize and articulate what they need. One theory of mine is
| that we assign senior-sounding roles in this industry too
| readily. "Senior engineer" sounds like they would know how to
| handle this, but while they might be great at programming, they
| often have little experience recognizing their own limitations,
| asking for help/resources, and understanding that this level of
| self-awareness and focus on outcomes would make them look better,
| not worse.
|
| If I was to give one piece of advice to an engineer in a similar
| position: you will always look more mature and professional if
| you evaluate your situation and explain what sort of help you
| need, than if you silently keep burning yourself out while the
| quality keeps slipping.
|
| If you're management and you actually reprimand them for asking
| for help, you will have trouble retaining engineers. It would be
| justifiable for them to look for work elsewhere on these grounds.
| JustSomeNobody wrote:
| > Managers: "engineers are professionals with strong opinions
| who will always tell me when/if they need anything to help them
| get their work done. Right? If they aren't saying anything,
| it's their own fault, right? They're adults, right?"
|
| Managers manage and bosses react.
|
| Some (management) people are great managers. The rest are
| bosses.
| nitwit005 wrote:
| If the story is accurate, all they had to do to figure things
| out was to ask an engineer. Two people independently gave the
| same feedback.
|
| Probably the reason the team had everyone quit was because
| management was dysfunctional.
| SkyPuncher wrote:
| I'll put a simpler, more likely explanation. It's dangerous to
| complain about being overworked. It puts hard barriers on your
| limits.
| hakunin wrote:
| I assume you're explaining the fear, because the opposite is
| true. You'd be lifting a barrier. The barrier is you doing
| all the legwork while having all the institutional knowledge.
| Business cannot afford you doing the legwork, you need to be
| mentoring and delegating.
| imilk wrote:
| Completely agree. If you never say that you are at capacity
| you become the dumping ground for work that other people
| should be doing.
| jim-jim-jim wrote:
| It doesn't have to be a complaint. Just put a higher
| fibonacci on your work or whatever. Don't see how it's a
| problem if you're honest from the get go.
| quickthrower2 wrote:
| More like: Managers: according to this metric he isn't working
| hard enough let's pull him into a room, ply some pressure, see
| if we can get him to shape up.
|
| Engineer: my boss has explicitly been pulling me up for how
| long it takes to do task so I need to start cutting corners,
| stop helping others and work longer hours to keep paying my
| bills.
| Mc91 wrote:
| > One theory of mine is that we assign senior-sounding roles in
| this industry too readily.
|
| Some large companies, particularly non-technical companies have
| to pay a certain amount of money to get people of a certain
| skill level, say a level below senior. However the company
| management does not want to pay market rates for that level,
| that salary only goes to "senior" people. So people with a
| skill level below senior are put on work that fits for a level
| below senior, but are given the senior title, because within
| the company, that is the title that matches up with the market
| rate for those people.
| whstl wrote:
| Not only that, but seniority is also often used as a
| bargaining chip.
|
| Having the title in your CV means something for future
| employers, so employees want it and companies give it willy-
| nilly as a very cheap perk.
|
| No need to say that this causes more problems than it solves.
| ghaff wrote:
| It's funny that, more often that not, in tech roles (but
| not a developer) I've mostly never used a title that was my
| actual HR title (which more than once shifted without me
| even knowing about it until I logged into the system for
| some reason or other). Yet some areas of tech, which prides
| itself on lack of gatekeeping, seems almost bank-like in
| its obsession with job levels.
|
| (To be clear, I'm not talking making up "Senior Vice
| President" but just something less HR-like than my actual
| title.)
| realjhol wrote:
| > No need to say that this causes more problems than it
| solves.
|
| As Senior executive vice principle king of engineering in
| charge of ensuring our product has enough blue LEDs in it,
| I don't know what you're talking about
| germinalphrase wrote:
| So you're the one keeping me up at night...
| BeFlatXIII wrote:
| Neither employees nor corporations have incentives to care
| about the quality or future of the industry, so they keep
| up the inflationary pressures.
| brianmcc wrote:
| This rings very true. I wonder if a quick nudge in the right
| direction could be a standing 1-to-1 agenda, to provide a low
| bar opportunity for such requests.
|
| E.g. - what's going well - what's not going so well - how would
| you rate the current pace, where 1 is too slow/boring, and 5 is
| red-lining and we should review things?
|
| Forgive the clumsy/rushed example, but point #3 is about an
| opportunity to say "actually we're about 4 or 4.5 and it might
| be worth looking at what's happening".
|
| All the above assumes a good manager that can be trusted and
| can make a difference, of course.
| germinalphrase wrote:
| "engineers are professionals with strong opinions who will
| always tell me when/if they need anything to help them get
| their work done. Right? If they aren't saying anything, it's
| their own fault, right? They're adults, right?"
|
| There can a cultural block here based on popular conceptions of
| "leadership" vs "caregiving" which maps against "strong"/"soft"
| & "male"/"female" in clearly counterproductive ways.
|
| Edit: I am interested in counter arguments here from
| downvoters. I am a pretty typical typical Midwestern guy with
| traditionally 'macho' interests/hobbies, but I've seen the
| above pattern play out repeatedly.
| DiggyJohnson wrote:
| This seems like quite a stretch. I don't think we should
| eschew these aspects of a competent engineer just because it
| may be possible to relate them to the current gender
| discourse.
| germinalphrase wrote:
| Fair enough. My comment was directed toward the manager
| rather than the engineer - though I could have left out
| "male"/"female" without impacting my point.
| mdekkers wrote:
| I'm in this story and I don't like it.
|
| I'm currently in a similar situation, and am desperately looking
| to move on. The market is not kind right now.
|
| We have a properly dilbert-esque management layer of PHBs with
| meaningless titles running around demanding that all technical
| aspects of the project are explained to them in detail, several
| times, blame their frustration of not understanding on our
| inability to explain properly, and then overrule every
| recommendation and design decision.
|
| Most of my emails are more disclaimers then content and
| everything is BCCed to my private email, because disasters are
| waiting to happen and this is an industry where "disaster" is
| weeks in the global news cycles.
|
| It's incredibly exhausting.
| ChuckMcM wrote:
| This is a good tale, and one that folks really should take to
| heart. I have observed when good engineers get an over developed
| sense of ownership they will move "heaven and earth" to get
| things done. If you're managing one of these heroes it is your
| job to spread the load of what they do across the team so that no
| individual is so overloaded everything suffers.
|
| New managers who had been engineers before management and care
| about the work always tell me "I feel like I'm not doing
| anything, I should be helping or something." And I tell them,
| your job is to look. Look at your team, who is working late
| nights, who isn't. Who is meeting their commitments, who isn't.
| Let their actions guide you getting them what they need to be the
| best they can be, things that you, and only you, as the manager
| can get for them. That often means blocking incoming requests for
| more "stuff" (features what not), carving out time for your
| "doers" to help bring the new people up to speed. As part of an
| IBM manager training video there was a discussion about how the
| US Navy trains every person on a submarine to do every job
| because you never know when the person whose job it is won't be
| available to do it. That really resonated with me and I tried in
| future groups to try to overlap skills and cross train folks so
| that everyone could both appreciate what their peers were doing,
| but could also help out in a crunch if one part of the work
| needed more effort briefly.
| jdwithit wrote:
| The cross training point is absolutely crucial. I've managed or
| worked on multiple Ops teams where one person was the "network
| expert" or the "kubernetes expert" or whatever. If that person
| left the company for any reason, or even went on vacation, it
| was a _disaster_. People on a team can and should have their
| specialties but you absolutely must document and cross train so
| that someone can fill in when the expert is unavailable.
| Anything else is a horrible failure by management.
| mschuster91 wrote:
| > I've managed or worked on multiple Ops teams where one
| person was the "network expert" or the "kubernetes expert" or
| whatever. If that person left the company for any reason, or
| even went on vacation, it was a disaster.
|
| The problem is in almost all of these cases the workload
| doesn't match the financial capacity.
|
| Basically, there is an absurd lot of stuff you have to know
| for each of these fields, which is why domain experts develop
| in the first place - it's just too much to handle for a
| generalist unless you happen to run into a person on the
| autism spectrum with eidetic memory (these are rare and worth
| their weight in gold). So, assuming at least basic levels of
| redundancy, you'll need at least _two_ people of each
| specialty (at least network, storage, virtualization /cloud,
| Linux, k8s, AD, macOS, Windows) in a company that has IT
| needs beyond "they're shuffling papers and emails". That's 16
| people, but many organizations don't have enough work to
| justify employing that many people.
|
| Most end up with going the "hire a generalist or two and have
| them do everything", which can work for an incredibly long
| time but then it collapses in a dumpsterfire (the generalist
| calls it quits and no sane potential new hire wants that
| workload for that paycheck, the company gets hacked because
| the generalist only has rough concepts about client-side IT
| security, ...).
|
| Some end up with outsourcing their IT, either to some local
| company or to body farms from India. That usually has better
| capacity to account for vacations, sick days and whatnot, but
| comes at the price that you don't have someone you can call
| for a quick firewall change but have to wait days or weeks
| for the ticket to make its way around, leading to frustration
| and eventually attrition from the non-IT staff.
|
| And a very select few end up hiring a bunch of specialists,
| which produce very good quality and high amounts of internal
| satisfaction... but as these few companies usually do that
| because the CIO pushes for it, some day when the CEO wants to
| count beans and the CIO can't defend the effort
| ("preparedness paradoxon"), the department gets slashed, and
| they end up like the first sort.
| ghaff wrote:
| There are other options to outsource these days. With the
| Kubernetes example, you can use a managed service whether
| cloud vendor specific or something that can run on multiple
| clouds. This doesn't completely let you off the hook for
| knowing what you're doing, but does effectively outsource a
| lot of the SRE-related types of activities. In general,
| managed services are a pretty decent middle-of-the-road
| option for companies that need a relatively complicated
| infrastructure for whatever reason but can't justify a
| large (expensive) team.
|
| Of course, it's also reasonable to ask if they really need
| that complicated infrastructure.
| whitemary wrote:
| Where do the specialists come from? University? Or do
| certain types of environments tend to produce them? How
| does that happen?
| mschuster91 wrote:
| That depends. Some come from universities or various
| types of schools (coding bootcamps, certification program
| trainings like AWS Certified XYZ, MySQL/Oracle/... DBA,
| Cisco Certified, Microsoft Partner, you name it). Some
| drift into specialist roles from generalist jobs (with or
| without the employer paying for additional training)
| because they prove to be good enough at a topic no one
| else cares much about. Some get ordered into it,
| especially in public service/military where your choice
| is to obey or get the boot.
|
| Of these:
|
| - the first group tends to have the greater holistic view
| about their certification topic and know a ton about best
| practices, but lack detailed knowledge about
| dependencies, prerequisites and other experience you only
| gain during real world experimentation and work.
|
| - the second group, the ones I like most, may lack best
| practices, but their experience makes more than up for
| that
|
| - the third are one hell of an explosive mixture. Either
| you get a combination of the first two groups (basically,
| someone with tons of certificates because you're not
| worth anything in public service without a paper proving
| your worth, and a lot of experience working in
| constrained and otherwise troubled environments) which is
| the best you can get, or you get a serial bullshitter
| whose best experience is in kissing leadership arses (as
| said, all that matters in public service is the papers,
| not knowledge or performance).
| cratermoon wrote:
| I'm a specialist in identity and access management -
| oauth, SAML, SCIM, that sort of thing. How did I get
| there? In my first job I was tasked with bringing up an
| organizational directory using x.500 and LDAP. Next job I
| was asked to help implement what we'd now call a paywall
| for newspaper's website, where subscribers to the paper
| got access to additional features. Over the years, more
| or less every job moved me through stages of knowing more
| and more about the field.
| tristor wrote:
| > Where do the specialists come from?
|
| They come from all different walks of life. That's part
| of what makes hiring specialists difficult. Specialists
| don't start out that way, they become that way, mostly
| due to intense focus on a particular area for a long
| period of time. Some people get that way quickly because
| they are pre-disposed with passion for a particular area,
| other people get that way due to their environment
| needing them to be there and sticking to it.
|
| There's consistent way, that I know of, to "create" a
| specialist. Probably the closest is by rote memorization
| and drilling from detailed and intensive instruction,
| which is the method militaries use to staff specialty
| roles, but quality and capability vary greatly. I don't
| necessarily classify these folks as "specialists" in the
| same way as someone who naturally gravitates towards a
| subfield.
| scrapheap wrote:
| > who is working late nights, who isn't
|
| Add to this who starts work early and who doesn't - just
| tracking when someone finishes working doesn't give you any
| information without knowing how long they've actually been
| working for when they leave.
| ajmurmann wrote:
| This! I've had to step up for folks in the past who were
| perceived by someone as "phoning it in" by calling out that
| the person frequently shows up before 6am
| jeffrallen wrote:
| > Your job is to look
|
| A really dramatic way of learning this is to be a volunteer
| firefighter. After a couple of years of experience where you
| know all the roles, they have you try out incident commander in
| an exercise. Now your job is to keep your head up, your eyes
| open, your hands off the equipment and manage your team. And
| you fail and fail again until you finally understand the role
| of a tactical commander (line manager).
| bluGill wrote:
| The problem is you can do any single job better than the
| people under you, but by doing any job you can't keep track
| of anything else and so all the other jobs you are not
| touching get worse by more than the one you do.gets better.
| ChuckMcM wrote:
| I really love that example. Thanks for sharing it.
| PragmaticPulp wrote:
| > New managers who had been engineers before management and
| care about the work always tell me "I feel like I'm not doing
| anything, I should be helping or something."
|
| Your points about managing (interfacing with the company,
| translating company's demands into a reasonable, steady stream
| of work) are spot on, but I would also note that the
| expectations for engineering managers are all over the place
| right now.
|
| In my first engineering management job I was severely chastised
| for writing too much code, even though I had the time and was
| choosing non-critical tickets for myself. The company insisted
| that managers should manage/delegate and developers should
| develop with little to no overlap. I internalized this as the
| way management was meant to be.
|
| Later in my career I took another management role and followed
| the pure delegation strategy. I was later chastised for _not_
| writing enough code. They believed managers should only need to
| spend about half their time managing and the rest should be
| spent doing IC work. They never communicated this, but assumed
| it was just how managers _knew_ they were supposed to operate.
|
| Even later in my career I took a "director" role, which was
| appropriate for my career progression to that point. I was
| stunned when the VP I reported to informed me that I needed to
| be spending "at least 2/3" of my time writing code, and that
| managing shouldn't take more than an hour or two per day. They
| then proceeded to book me into 20-25 hours of recurring
| meetings every week. That company had major problems for other
| reasons and it didn't work out, but after that I always made a
| point to explicitly ask about manager expectations multiple
| times during an interview.
|
| Different companies have wildly different ideas about what
| engineering managers should do.
| andai wrote:
| >The company insisted that managers should manage/delegate
| and developers should develop with little to no overlap.
|
| Did you ever find out why?
| P_I_Staker wrote:
| Wow, that's an insane request for a director. Even at the
| management level, unless you have a specific, obvious "dual
| role", this borders on inappropriate.
|
| The company in the first case was the closest to correct. If
| you really weren't sacrificing your commitments, then they're
| being unreasonable, but I can say I understand their
| perspective.
|
| So many engineers move to management, yet want to remain
| "hands on", and won't let go. It's obnoxious and frustrating,
| when they inevitably have their heads spinning from meeting
| after meeting, and no time remaining, but still insist on
| trying to help.
|
| Simply looking at code output and calling it a problem to
| produce too much is hilariously shortsighted, but I can see
| how someone with some bad experiences could trend in that
| direction.
| trashface wrote:
| Some go into management for pay and promotions, not because
| they want to. Long term, IC is often a dead end. Especially
| at mismanaged companies, which are, (see this post) not
| exactly uncommon.
| pastaguy1 wrote:
| > So many engineers move to management, yet want to remain
| "hands on", and won't let go. It's obnoxious and
| frustrating, when they inevitably have their heads spinning
| from meeting after meeting, and no time remaining, but
| still insist on trying to help.
|
| Oh god, I hate this. The thing that happens most often in
| my experience is they have time to do the "fun parts" of
| something, and then leave others with all the testing,
| paperwork, bug fixing, etc, to make their update into
| something "real".
| bch wrote:
| [...] Now draw the rest of the owl.
| coldtea wrote:
| > _And I tell them, your job is to look. Look at your team, who
| is working late nights, who isn 't._
|
| Sounds like a toxic environment...
| ianmcgowan wrote:
| From context (and a charitable reading), it seems obvious
| that the advice is to identify who is working nights in order
| to get them some help and spread the load.
| kevin_nisbet wrote:
| I learned a similar lesson outside of tech... with low wage
| employees. Often people would have problems dealing with our
| employee's and complain, but if we dug a bit deeper, it was
| very often an issue with training, manuals, high turnover, or
| managers not being good at setting expectations.
| scruple wrote:
| > managers not being good at setting expectations
|
| Expectation setting (and all of the things that fall out of
| it) is such a huge problem in my experience. I'm always
| trying to get clear expectations out of management. I had a
| ~decade gap in my career where the expectations were vague,
| ambiguous, bullshit... And worst of all misaligned. First-
| time engineering managers, specifically, were _all_ so bad at
| this. I 've walked from jobs where this was the root problem.
|
| Recently, I've landed in a company and on a team where the
| expectations are _crystal clear_ and, as a result, and
| closing in on 20 years in this industry, I feel like I am
| able to do some of my best, most impactful work. Work that
| will likely outlive my tenure with this organization, and it
| _feels fucking amazing_!
| steveBK123 wrote:
| New managers (or bad ones) have a hard time serving the
| basic functions of - filtering incoming noise, making
| priority decisions, and allowing some room for ICs to
| breathe.
|
| The last one - allowing ICs to breathe is extremely
| important. Most of my best / most impactful / bragged-by-
| others work was completely unplanned/unscoped/side project
| kind of stuff where I saw a recurring problem that could be
| addressed. Most of these were really like 1-2 days of
| focused work to get to 80%, then when management saw what
| it got them.. periodic planned/scoped/in-sprint tasks for
| improvements.
|
| New/bad managers often have a hard time not planning their
| ICs time down to the minute.
| ghaff wrote:
| And, of course, there are people working for that manager who
| don't think they are doing anything and that middle managers
| are a waste of oxygen--even though, in fact, they're shielding
| their team from a lot of crap and, as you suggest, they're
| doing a lot of coordination of a situation that would otherwise
| end up with a lot of wasted motion.
| steveBK123 wrote:
| I think the challenge is that ICs get "outed" pretty quickly
| if they underperform.
|
| Managers can be more at the whim of whether they have a good
| team or bad. A bad manager with a good team can take a long
| time to get "outed" while a good manager with a bad team
| might get whacked anyway.
|
| Upper Management doesn't really know how to measure the
| effectiveness of line managers.
|
| So it can make tech senior ICs pretty cynical about their
| management, especially if you are in a role as I often am
| where I am directly engaged by clients (directly receiving
| new requests), planning sprints, sizing tasks, planning
| roadmpaps, in hours of meetings per day, etc. At some point
| you wonder if your line manager is just an empty suit.
| D-Coder wrote:
| Sometimes you have to manage your manager.
| throwawaaarrgh wrote:
| Blaming management seems like a symptom of a larger problem:
| people continuing to work for unethical companies. If you're not
| willing to quit due to bad management, they'll just keep having
| bad management.
|
| I've never heard of a company that cared more about the welfare
| of employees than the company's bottom line. The natural result
| is employees are expendable assets, like machinery.
| danjac wrote:
| I've been in that position once early on in my career - single
| developer bearing the load of a project that should have been the
| work of 3-4 people. It didn't end well - I got the thing done but
| performance, quality etc were way below par and I got away from
| the project and company as fast as I could. Nowadays with more
| experience (not just technical) I would have seen the shit show
| coming a mile off.
|
| The key factor here was that management dictated a timetable then
| pulled a fast one and decided to pre-release with a "soft launch"
| three-quarters of the way through. It was insanity, and older-me
| would have quit on the spot and told them where to stick it where
| the sun didn't shine. As it was I got something out the door more
| or less on time, but it was absolutely nothing else to be proud
| of.
|
| My advice to younger-me and junior developers in general is that
| management are generally clueless about software development,
| even if they did it once in the past (hello Elon Musk) and part
| of your job is to push back against unrealistic deadlines and
| features and if you don't do that, you are doing yourself and
| your company a disservice. Don't let hubris and fear get the
| better of you.
| jimjonescoolaid wrote:
| Duh!
| franciscop wrote:
| This is very common? The most extreme example I've seen by a
| Dilbert-level hapless manager was assigning me and a coworker to
| a fullstack project. I was doing front-end, and he was doing
| backend, and by the nature of the project AND some bad tech
| decisions the backend was an order of magnitude more complex than
| the front-end. I did pick up React to learn then so at least I
| also had some of a challenge.
|
| That's on the technical side, on the project side it was even
| worse, I had an earlier MVP to base my designs on while he
| (backend guy) had to deal with multiple basically hostile 3rd
| party vendors.
|
| The predictable happened, after just 1 month it was 100% clear to
| me that it was impossible to work at the same pace, so I mocked
| up all the endpoints I expected, built most of the front-end and
| was done in 5-6 months, after multiple iterations with the
| previous business person who made the MVP. The backend (remember,
| 1 guy) had just gotten the Auth right basically, and almost
| nothing else in working conditions yet.
|
| My manager reaction? He was pissed that I had done it against a
| mock API instead of the inexisting real one, told me to wait
| until the end-points were ready and integrate them and wouldn't
| give me any other work otherwise despite of my best arguments.
| What happened is during the next 3 months I was basically writing
| and rewriting the app, becoming very proficient in React. Then
| the manager started to hear heat from above, and he started to
| complain about my coworker in a very similar situation of this
| article, so I started to look for a new job. That backend
| coworker left few days after me and never came back (I was
| probably the only non-hostile one, even friendly, to him at work
| by that point).
| justinclift wrote:
| No interest in learning backend dev stuff?
| coldtea wrote:
| Why should they be? If they were a doctor, would you ask them
| "no interest in learning x-rays" in a similar situation, if
| they were doing anesthesiology?
| luckylion wrote:
| Yes. "Our patients are dying left and right, I was able to
| pick up a new field of anesthesiology, I could've picked up
| doing x-rays" => "why didn't you?"
|
| Totally understandable if he says "because I don't like
| backend", but if you're essentially doing busy work just to
| keep yourself from going insane while someone else is
| struggling managing their work, you might as well help
| them. You'll learn something new, they'll struggle less,
| and the project will be better off.
| coldtea wrote:
| And the company would get away with using people as they
| like, and under-stuffing roles because "everybody free
| can do anything else we lack"...
| luckylion wrote:
| Maybe, but it's not like they'll learn from a project
| failing and a developer leaving on bad terms that they
| should staff projects appropriately. They'll shrug and go
| on while some guy suffered for months and another guy was
| bored out of his mind.
| justinclift wrote:
| Because there was a clear mismatch in available dev time vs
| what was needed, in the front-end vs backend err... teams.
| Thus asking the question.
|
| As per the answer, although interest was there the
| situation itself didn't allow it.
| is_true wrote:
| He could've learnt to mock the endpoints from the backend.
| franciscop wrote:
| I literally said I mocked up the endpoints from the
| backend? To which my manager was angry?
| is_true wrote:
| Sorry. I wasn't able to see that on your comment.
| malborodog wrote:
| But what we do is not the same as medicine, which is highly
| regulated and has implications for life and death. Nothing
| stops us from learning any new technical thing we care to.
| coldtea wrote:
| > _But what we do is not the same as medicine_
|
| Doesn't mean it's "whatever need there is and whatever I
| ask you to do, and forget the role you applied for, to
| and was hired to do".
|
| > _Nothing stops us from learning any new technical thing
| we care to._
|
| Nothing should stop us from focusing on the kind of
| programming layer/expertise we want to do, either, be it
| systems, backend, front-end, data science,
|
| If people WANT to change layer/role, they can do it
| themselves. And hopefully at a better company, where they
| can focus on their desired role, and aren't asked to also
| write front-end code when they were hired as systems
| engineers, or perhaps mop the floor because "you surely
| can learn that too, it's not like moping the floor is
| like medicine".
| VBprogrammer wrote:
| I'm not the cleaner in my office but I still take my cup
| to the dishwasher and put my litter in the bin when I
| leave. I'm not sure what I'd have done in the OPs
| situation but it wouldn't have been going round and round
| in circles slowly improving my own work in isolation.
| tomrod wrote:
| My thoughts:
|
| > But what we do is not the same as medicine
|
| It is extraordinarily similar from a systems aspect
|
| > which is highly regulated
|
| Some areas of software development are highly regulated,
| and this is an environmental constraint instead of a work
| methods outcome
|
| > has implications for life and death.
|
| Much of software has implications for life and death,
| especially at firmware level or medical device & AI/ML.
| If your experience is only with FAANG or web front ends,
| then sure, this statement has teeth. But software
| automates processes, and a lot of processes can end in
| death, either by intent (military) or accident (health,
| law enforcement, manufacturing)
| franciscop wrote:
| I knew some backend dev stuff (Node.js) and am very much
| interested. This was Go, and while I wasn't particularly
| interested (I'd prefer to continue with Node) I would
| compromise and learn Go to help him and the project. I
| suggested it but again our manager was strongly against it.
|
| Something I didn't mention which adds an extra of why I was
| unable to help, this was in Japan, and the
| backend-{everything} was performed in Japanese while I didn't
| speak the language, so talk about "not knowing the language"
| they were using.
| Accacin wrote:
| For some people, it's not just about learning it's also about
| extra stress and worry that they might take on work they
| can't complete. I completely understand that.
|
| I'm the type of person who will mostly say yes to anything,
| given some allowance on estimates and time.
| fasteo wrote:
| >>> I was probably the only non-hostile one, even friendly, to
| him at work by that point
|
| If you did not help him, this is highly subjective
| karamanolev wrote:
| Not to me. If they wanted to be a frontend dev, billed
| themselves as such and didn't want to take on backend duties,
| then they did their fair share by speccing the API and
| providing that. They have no direct obligation to work on the
| backend.
| franciscop wrote:
| I did try to help him in any way I could, but didn't know the
| language he was using so I was not able to actually code for
| him. Couple of examples: I made a Node.js program to help him
| debug why a 3rd-party endpoint he had to call wasn't working,
| documented the endpoints he was doing (learned Swagger for
| that), and acted as intermediary between him and our manager
| to try to reduce the scope of the work or to at least ship in
| two parts.
| clnq wrote:
| It sounds fair to me that a developer hired to do front-end
| work does not want to do back-end. I can't blame him for
| setting boundaries, especially in a dysfunctional management
| workplace.
|
| I've been in the back-end developer's situation and I still
| didn't think it is fair for others to re-specialize and help
| me in a large company. It's neither mine nor their fault the
| management is incompetent.
|
| If this was a small company with a close-knit team covering
| for each other's blind spots, then it could be different. But
| what was described was at least a medium-sized company where
| in all likelihood the manager was paid a good amount of money
| to be competent at their job.
|
| And instead the manager played games, saw the results of
| their actions, tried to slide the blame onto the person they
| made fail, and lost good engineers. The situation was
| completely in the manager's hands and so are the results. If
| we start expecting people to manage themselves under the
| managers, then what is the manager doing? Are they just a
| liability to the company with no upside? The role doesn't
| make sense then.
| scary-size wrote:
| What prevented you from helping him?
|
| edit: This comes off as a rhetorical question. I'm really just
| interested what happened here. The project was assigned to both
| of you. I imagine that implies some responsibility for the
| whole of the project. You spent your "free" time learning
| React. Was there an organisational blocker that prevented you
| from helping him out, in any capacity?
| coldtea wrote:
| That his expertise (and desired field) is a totally different
| layer?
| anileated wrote:
| Their expertise was not in React either, yet somehow it
| didn't prevent them from using it on this project. Turns
| out in this field we can learn quickly and don't have to be
| razor sharp focused in what we are able to do.
|
| A somewhat charitable explanation could be some internal
| politics which in large organizations are always baffling
| to me.
| coldtea wrote:
| > _Their expertise was not in React either, yet somehow
| it didn't prevent them from using it on this project._
|
| Yes, because React is still front-end. He expanded his
| front-end skills with a new front-end skill.
|
| Sounds like job functon, role, and area of experise don't
| matter, and everybody should do anything in your mind
| ("they're programmers, so whether they do front-end,
| server side, or program embedded software for artificial
| hearts, they should just jump to it and like it too").
|
| > _Turns out in this field we can learn quickly and don't
| have to be razor sharp focused in what we are able to
| do._
|
| Turns out people have specific preferences for the areas
| they like to work at, and have specific job functions
| they were hired for (say, "front-end engineer" or "data
| scientist") and whether they can learn another kind of
| role is moot.
|
| They might if they want to, or if they have to because
| they need the money. But it's a totally disfunctional
| organization one that has them do something they weren't
| hired too, just because "it's all programming, surely you
| can learn it".
|
| If you hire a systems programmer you shouldn't expect
| them to do UI or data science, just because your company
| didn't bother to have someone else for that. If you do
| have that need, ask for a "fullstack" engineer, or be
| upfront that you want people to wear many hats.
|
| Programmers are not just "do whatever/replacable cogs"
| they have specific preferences, skills and expertise, and
| career goals. Actually that's true for any profession,
| not just programmers.
| anileated wrote:
| Well, in extraordinary circumstances it may be
| warranted... Help out a colleague, then both leave ASAP
| on good terms after victorious delivery.
| lowercased wrote:
| > Turns out in this field we can learn quickly and don't
| have to be razor sharp focused in what we are able to do.
|
| Turns out this is how many orgs end up with mountains of
| half-baked copy/paste that sorta works-because-it-
| didn't-break-yesterday, written by people that have
| jumped ship to the next shiny-tech-of-the-month company
| and never have to suffer the consequences of their
| "quickly-learned non-razor-sharp-focused" actions.
| theteapot wrote:
| > ... a Dilbert-level hapless manager was assigning me and
| a coworker to a fullstack project.
|
| Oh so it was actually halfstack project.
| coldtea wrote:
| It was a fullstack project with someone doing the front-
| end and someone doing the backend.
|
| It wasn't a project given to two "fullstack engineers"
| which is a different thing than a "fullstack project"
| (which just means project involving all stack layers).
|
| So the sarcasm falls flat.
| theteapot wrote:
| Oh a half-half-stack project. My bad.
| coldtea wrote:
| There's always Reddit for such stimulating intellectual
| discourse
| theteapot wrote:
| Hardly qualifies as discourse.
| [deleted]
| bbarnett wrote:
| _What prevented you from helping him?_
|
| Guy already said, manager wouldn't assign other work.
|
| I have worked in similar. Some workplaces are highly
| political.
|
| In one case I was on contract, 3 months ahead, suggested to
| help in other areas, and even offered to "pause billing" and
| take personal time off. Yes, the contract allowed for it.
|
| Nope. Needed me there every day, doing nothing. Otherwise,
| upper management would know the project was slipping?!
|
| Some workplaces are highly broken.
| franciscop wrote:
| The backend was in Go, a language that I have no idea about.
| Also this was in Japan and backend discussions and 3rd party
| vendors all happened in Japanese, which I also didn't speak.
| I suggested learning Go myself and try to help, but my
| manager was also against it.
|
| I was dubious I'd be of much help when I suggested but at
| least I'd learn the language we were using and might be able
| to help long-term. But as things kept getting delayed I'm
| sure I'd have been able to learn enough to be of help even
| within that project. But again, had a hard ban to either join
| a different project or learn/help with Go, "just keep
| improving the front-end and integrate it with the backend and
| don't do anything else until that's done".
| scary-size wrote:
| Thanks for the additional context. In your initial post it
| came across like you sat and watched the project burn.
| franciscop wrote:
| Sorry for my bad explanation/coming off as that, since
| it's definitely the opposite. I actually left the company
| because of the stress of wanting to help and not being
| able to help. Going everyday seeing how the project was
| going into the ground and being told I couldn't help and
| to just sit there destroyed my soul.
| Aloha wrote:
| Working with Japanese engineers without either speaking
| Japanese or being sufficiently acultured to Japanese
| cultural norms was an interesting experience for me.
|
| Brilliant fellows, with a very different way of thinking
| about issues. Often however the solution was dictated by
| things outside of the engineering problem at hand.
| IshKebab wrote:
| Your manager sounds like a complete tool. Go is easier to
| learn than React IMO.
|
| Japanese not so much, but it sounds like you could have at
| least helped with the implementation without speaking it.
| drunkpotato wrote:
| In a thread about dysfunctional and mismanaged projects, you
| describe a very dysfunctional and mismanaged project in a way
| that brings out the hilarity, frustrations, contradictions, and
| impossibilities of the situation. Good job! And then the
| majority of the replies completely miss the entire point and
| ask some variation of why didn't you just superhero up and solo
| run the project? Providing extra entertainment by
| unintentionally highlighting exactly the manager galaxy brain
| that leads to such incompetently run projects. I love it!
| gniv wrote:
| This is an interesting management-training problem. When you're
| left with a single veteran developer in a team, what to do? The
| instinct would be to give them extra support/leeway etc. But I
| wonder if the better solution is to simply remove that person
| from the team and replace them with a junior. Short-term pain but
| long-term gain, maybe?
| dtech wrote:
| That's only a good idea if the veteran actively prevents the
| situation from getting better, e.g. by being possesive and
| contrarian, trives on being the hero etc. This does tend to
| happen a lot in these situations. The team will also need to
| have the skill to actually do better.
|
| If the veteran is not sabotaging things firing only throws away
| the most valuable source of knowledge the team has.
| hd95489 wrote:
| I'm surprised they didn't house this person. The key to a
| dysfunctional company is to completely screw over your key
| workers and drive them out while promoting poor preforming people
| tjpnz wrote:
| It wouldn't surprise me if the rest of the team were
| consistently exceeding expectations, proposing bullshit
| initiatives while refusing to touch the parts which were on
| fire.
| hd95489 wrote:
| Absolutely a solid career move. Touching broken things is a
| mistake at dysfunctional companies. Much better move to chase
| the initiative of the year
| ryandrake wrote:
| I was expecting that kind of twist too because I've seen it in
| so many companies: Heroic old timer doing the job of 4
| engineers because the poor performers were not carrying their
| own weight. One of the poor performers, instead of doing his
| work, spends his time schmoozing, boasting, and bullshitting
| his managers, who then reward him with promotion and fire the
| old timer. The team falls apart because they fired the only
| person doing anything, and the brown-noser successfully blames
| the ex-old-timer.
|
| Take as old as time...!
| klabb3 wrote:
| Absolutely. The majority of old timers are heroes who don't
| need to stay and tend to their understaffed garden.
|
| However. There are also old timers who refuse to delegate,
| only ever giving mindless tasks and not training the new
| folks to be self-sufficient. "They would just screw it up,
| it's better if I do just do it, it's both faster and better."
|
| You could argue that's a leadership problem as well, of
| course, but my response would be that if you're the only one
| who understands a system, you _are_ a leader, and leaders
| have a responsibility even if they aren't managers by title.
| samatman wrote:
| That's a great argument!
|
| The hypothetical person in question gets a leader's salary,
| title, and responsibility, right?
|
| We're not expecting them to hold up the sky for free?
|
| [waits for audience laughter]
| jterrys wrote:
| >However. There are also old timers who refuse to delegate,
| only ever giving mindless tasks and not training the new
| folks to be self-sufficient. "They would just screw it up,
| it's better if I do just do it, it's both faster and
| better."
|
| Hah, just observed something similar in a different team.
| They brought a teammate from overseas for training for a
| month and during that time none of the old timers
| interacted with this guy at all. Once this teammate
| returned they were all mumbling how he doesn't know shit.
| The same old timers are constantly ranting about being the
| only ones doing weekend maintenance :)
| scruple wrote:
| > You could argue that's a leadership problem as well, of
| course, but my response would be that if you're the only
| one who understands a system, you are a leader, and leaders
| have a responsibility even if they aren't managers by
| title.
|
| Hear, hear! Anyone who has on-boarded to some legacy system
| has probably experienced this from one end or the other.
| The trouble seems to be in getting the heroes, as it were,
| to recognize that they have a responsibility to properly
| on-board and train, _while simultaneously_ getting their
| managers to give them the space to do this work and
| properly prioritizing it (while also helping to keep the
| fires at bay... Easily 50% of the on-boarding challenges I
| have faced in my career were because the person who was
| responsible for on-boarding me was constantly fire-fighting
| by themselves).
| gedy wrote:
| Yes, it's usually a management issue, because unless that
| hero person is given a team or put in a team lead type
| position, it's frequently impossible to "train others",
| especially other devs who are uninterested or have other
| tasks to do.
| megablast wrote:
| Need to learn to say no and push back. Shouldn't need someone to
| come and tell you this is ok.
| MonkeyMalarky wrote:
| But you risk a shitty performance review which still almost
| happened.
|
| Management should not be giving bad reviews for not meeting
| unrealistic goals.
| chiefalchemist wrote:
| This sounds much like The Phoenix Project.
|
| https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
|
| It's a solid read for anyone in engineering or close (e.g.,
| project manager).
| physicsguy wrote:
| I think I'm this person in my current role, and it's 100%
| management related. I interviewed for a team and hand picked some
| very skilled people to try and relieve my load... and then the
| company decided to move them off of that project and onto another
| big contract they've signed. At the same time I'm just completely
| frazzled. Very hard to get yourself out of this situation when
| there is no buy in from the organisation that there is an issue.
| H8crilA wrote:
| Leave, leave, leave. The universal solution to all problems in
| a market(like) economy.
| physicsguy wrote:
| Right now it's not an option as I will be going off on an
| extended period of paid paternity leave in a few weeks, but
| I'll be looking after that.
| scruple wrote:
| Sure, but you can look _during_. You don 't owe them
| anything. You've earned paternity leave and they haven't
| earned your tenure beyond it.
| unxdfa wrote:
| Am in this situation. The 3-4 load isn't caused by me but is the
| minimum work necessary to keep the company from crashing and
| burning. The cause was a cargo cult restructuring that caused
| enough ceremony, overhead and friction that ingrained expertise
| left. The company made no effort to retain people either and
| won't pay enough to attract new talent.
|
| The solution is simple and will be applied within the next
| quarter.
| kozinc wrote:
| If you're the one with the 3-4 load, can you rely on the
| company to hire more people?
|
| For the worker, the solution is to find a job with a smaller
| load. For the company, it's to either to find more people to
| join or to convince the person who manages the high load to
| stay on as long as possible.
| unxdfa wrote:
| Well they had a chance to and failed so I'm fucking off.
| anthlax wrote:
| Atlas shrugged
| unxdfa wrote:
| That's an interesting perspective.
___________________________________________________________________
(page generated 2023-03-10 23:01 UTC)