Load 'em up and throw 'em under the bus | Hacker News Reader

Load 'em up and throw 'em under the bus

rachelbythebay.com

662 pointspicture168 comments

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.

> 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).

I really love that example. Thanks for sharing it.

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.

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.

> 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!

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.

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.

> 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.

Where do the specialists come from? University? Or do certain types of environments tend to produce them? How does that happen?

> 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.

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).

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.

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.

Cloud services mainly replace networking specialist with IAM specialist, SRE specialist with VM specialist, systemd specialist with Kubernetes specialist, and so on.

So in the end you are at +/- 0 resources anyway. However, what you get out of these same resource count is potentially a lot more, because the cloud gives you a longer leverage arm and a lot of the underlying tech in the cloud is more best practice than what you would have cobbled together yourself. For example IAM is a higher abstraction level, that a manager can actually understand, whereas ssh keys is black magic tech talk.

> 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.

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

>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...

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.

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.

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.

> 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.

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.

> 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".

[…] Now draw the rest of the owl.

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.

>The company insisted that managers should manage/delegate and developers should develop with little to no overlap.

Did you ever find out why?

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.

I'll put a simpler, more likely explanation. It's dangerous to complain about being overworked. It puts hard barriers on your limits.

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.

Completely agree. If you never say that you are at capacity you become the dumping ground for work that other people should be doing.

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.

> 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.

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.

> 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

So you’re the one keeping me up at night…

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.)

Neither employees nor corporations have incentives to care about the quality or future of the industry, so they keep up the inflationary pressures.

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.

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.

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.

"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.

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.

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.

> 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.

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.

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.)

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.

True

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 :)

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.

> 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.

> 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.

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.

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.

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.

    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?

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.

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).

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?

That his expertise (and desired field) is a totally different layer?

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.

>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.

Well, in extraordinary circumstances it may be warranted… Help out a colleague, then both leave ASAP on good terms after victorious delivery.

> 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.

> ... a Dilbert-level hapless manager was assigning me and a coworker to a fullstack project.

Oh so it was actually halfstack project.

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.

Oh a half-half-stack project. My bad.

There's always Reddit for such stimulating intellectual discourse

Hardly qualifies as discourse.

My point precisely

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.

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".

Thanks for the additional context. In your initial post it came across like you sat and watched the project burn.

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.

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.

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.

No interest in learning backend dev stuff?

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?

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.

>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".

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.

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)

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.

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"...

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.

He could've learnt to mock the endpoints from the backend.

I literally said I mocked up the endpoints from the backend? To which my manager was angry?

Sorry. I wasn't able to see that on your comment.

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.

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.

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.

>>> 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

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.

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.

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.

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!

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.

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

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…!

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.

> 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).

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]

>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 :)

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.

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.

Absolutely a solid career move. Touching broken things is a mistake at dysfunctional companies. Much better move to chase the initiative of the year

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.

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.

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?

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?

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.

The anecdote would have had as much impact, for me, without the hints as to the which parties were involved.

If you are writing an anecdote about someone you know named Sandra Smith who worked on borg at Google then you should call them Charlie and say they worked on infra at a FAANG. Anonymising them by saying they worked on a certain Star Trek themed container tool at a didn’t-be-evil search engine wink wink isn’t meeting the bar for anonymity. Anyone doing that is kind of thumbing their nose at anonymity — I know I’m supposed to make this anonymous but here are some hints so we all know who I’m talking about.

The people closest to the subject of the post — the ones where the impact of having their story shared with thousands of others is going to hurt the most — will see straight through it. You might as well call them Xandra Xmith who worked on xorg at Xoogle.

Outing people in a way that means their closest associates know who it is, even if strangers don’t, feels tasteless. For me, that’s what makes this blog post feel like gossip. Again, I don’t know the details — everyone involved could be just fine with this story being public.

(Thank you so much for asking your question in the spirit of HN. It adds value to something I perhaps should not have said in the first place.)

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.

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.

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.

> 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.

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.

Or, you get replaced or fired. Don’t bet on most managers to actually help.

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.

That’s if you have coworkers capable enough.

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.

Leave, leave, leave. The universal solution to all problems in a market(like) economy.

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.

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.

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.

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.

Well they had a chance to and failed so I'm fucking off.

Atlas shrugged

That's an interesting perspective.

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

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?

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

> 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.

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?

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.

Often ICs stay for 2 years in a company, start a project, but aren't happy with org/management/career progression and move to the next company before having to deal with the problems they have created. Eventually other developers who weren't assigned on this project now also need to maintain this project, without having the detailed knowledge of existing mechanisms and prevalent tech debt. Those developers did work on their own project and now need to care about both or even more projects.

The developers are basically invisible to upper management. PMs are the point of contact which translate between higher managment and the devs. Higher management often operates on such a high level, that they are disconnected from reality and work on a abstract level, basically using the inputs of the PMs. The PMs often also were never that technical, instead they realized soon that career progression is only possible in mgmt. This leads to the incentive to spawn new projects a PM can lead.

Eventually there are too many (poorly defined) projects with too few (original) developers. New developers are unhappy since they have to work with legacy code and the devs who are spread over multiple projects and still have some original knowledge, don't have enough time/incentive to properly take care about project development (plus, spent a lot of time in "agile" meetings for each project). Adding no career paths for devs (since the company only focuses on mgmt), this leads again to the starting point, where the ICs leave the company.

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.

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.

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.

> 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.

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.

Because knowing something is important to the organization and to you and choosing to do it is not overworking. It is delivering the necessary effort at the right time to end up proud of your work. And with a reasonable boss, there's nothing stopping you from knocking off early the next Friday.

No, thanks.

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.

The Engineer can leave, the project can utterly fail, and only management will be left to take the blame and deal with the consequences.

How do you think the interview is going to go for that engineer for their next job?

It'll go great. Busy people interview well. They just explain the ten different things they did that day.

> 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?

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 ...

Seems like a problem of hierarchy

Maybe managers should be democratically elected

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.

Note management never took accountability and nothing really changed in the management situation.

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.

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.

I love companies like that. If you are a bit proactive, you can snatch the easiest parts, and get rewarded just for sending reports.

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?

>How can we fix this problem?

You're being called upon to fix "stupid".

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.

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).

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?

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!

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 :)

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.

Need to learn to say no and push back. Shouldn't need someone to come and tell you this is ok.

But you risk a shitty performance review which still almost happened.

Management should not be giving bad reviews for not meeting unrealistic goals.

Sometimes you have to manage your manager.

Duh!

Reply on news.ycombinator.com