71 comments

[ 2.8 ms ] story [ 101 ms ] thread
Sounds like perhaps just bad top down management at that place. My coworkers/teammates are not lazy, we work as a team, and if not they'll be gotten rid of.
Yep. It boils down to wanting to work at a place where it's OK to make mistakes, but unacceptable to not learn from mistakes. It's a culture thing, and it comes from the top.
I think you are the one who should be gotten rid of. Your blame-game attitude is toxic to your team. You should be teaching and showcases, not putting down and ignoring issues.
> January 9, 2012
We've added the year above.
Blame others for what happens when you choose to passively test your coworkers instead of using direct communication to raise and address an issue at your own risk.
I'd argue that instead, she should have emailed the rest of the team and asked what's going on. Raise the issue and let somebody take responsibility.

A potential side benefit is that you can teach more people the "right" way to do things.

Also, the comment about the docs was a really poor choice of words. A better comment might have been "Yah, they need work. Feel free to update them to make them better."

I agree with your comment, except the last part. This feel free to do X is just a covert agressive response, not unlike feel free to submit a patch.

When I get that from a project where I report a problem I immediately think "feel free to keep your buggy docs/code".

A straight but assertive answer is IMO much better: "we don't have time to do X, could you please help?" or "we have higher pririty bugs that we need to work on, but we could sure use your help if you have some time". Heck, even "let's take 1h and work on improving it together" would work for me.

Bottom line is that unless there's a clear responsibility involved, other people don't have to perform certain tasks, so they should be politely asked for help...

An even more helpful response about the docs would have been, "Could you tell me where in the docs this process is unclear so I can update it?" Everyone writes and reads and comprehends in their own way, and something that seems clear to one person can be completely obscure to another.
I'm not impressed --- she took an already not-great situation, where she had co-workers who weren't really pulling their weight, and made it confrontational and poisonous. This is pretty obviously not a good way to treat your co-workers, and it doesn't help build the sort of positive relations that will allow you to help them improve, so you have people who still aren't pulling their weight, but now have reason to dislike you.

My advice? Don't do that, no matter what your boss thinks of it.

EDIT: I can't type.

Mostly agreed, although it's hard to judge. I wouldn't want to be the one that always has to pick up after everyone else either.
Sounds like there was bad blood or a general cultural problem there already. I can't imagine a well gelled team of people who like each other ever being unable to solve this kind of problem.

An employee should be comfortable going to their manager and their manager's manager about problems like this, and a manager should "nip it in the bud" when an employee begin running such "little pseudo-managerial experiments" on their colleagues instead of voicing your frustrations directly. What even is a managerial experiment? Colleagues and subordinates are not experimental subjects.

That's a classical political problem. Sometimes it's good to be the problem solver that takes care of things but often you end up being the sucker to do things nobody else wants to do. And you get no credit.

I had this once with answering questions for a new dev. He asked a lot of stuff. I first answered happily but after a while I realized that he didn't even try to find out things himself but instead asked me immediately. So I stopped answering and promptly got a complaint from his manager for not helping with critical stuff. Thank God I got support from my team so it was no problem.

Lesson learned: Be selective in taking on things that are not directly your job or could be done by somebody else. Set some boundaries.

My approach to learned helplessness is to still assist the person but don't give them the final answers or do it for them. Instead, ask them leading questions. "Why do you think foo is failing? What happens when you add some debugging here? Have you read the foo section of the docs?"

That way you can't be accused of not helping, and the person is developing their critical thinking skills. Unfortunately our Western educational system is still based around rote learning, which can really hamstring some folks when converting facts into actions.

There is also a difference between learned helplessness and laziness. In my case it was plain laziness
This is very common mistake junior developers make. My approach is to ask them only ask questions after 10 minutes of research.

If they have spent 10 minutes trying to find an answer, they are allowed to ask that question.

If I encountered this situation, I would create an automated alarm to detect this condition, a run book to describe how to resolve it, and then have it page the oncall.

Bonus points for having a metric that showed improvement over time, and extra extra bonus points for creating automation to remove the human element completely.

At the end of it, you can demonstrate a clear result of how you improved reliability and increased knowledge across the team.

Sometimes having a human in the loop is a good idea. Taking down a master server probably one of those times, especially given that taking it down isn't time-sensitive.

Aside from removing the human completely though, agreed!

Manager's perspective: We have Rachel on the team, she thinks she's so smart. She tells others to just 'figure it out' in a condescending manner, bringing the team morale down. Nobody likes her but we keep it polite and cordial because we're professional.

She one day told me about some 'experiment' she's going to do, I don't know what she meant. We received a complaint 2 months later, it turns out it's because of Rachel. What is wrong with her?

---

It can take some time for idealistic, intelligent people to understand how other people may not be into system admin, or into programming, or managing, or whatever their job is. They stumbled into it, realized they don't really like it, but don't want to uproot their life, to 'find their passion'. They just want to work, and go home.

Those people are not to be hated, despised, or complained about. They are not happy. It would be like getting angry at someone in a wheelchair for taking up so much room on the bus. They are in a wheelchair, you're not. It is up to you to accommodate and help them if you can, because you actually have that ability in you, they're just getting by.

Empathy does not come natural to everyone, and usually comes with age. I hope Rachel has moved on to better things.

Thank you for writing this - there is so much empathy in this.
She told her manager precisely what was wrong, that it wasn't an issue, and that she was going to leave it to see if anyone else gave a rat's ass.

If the manager was going to object to this plan, the time was then. Having a whinge about it months later while taking no responsibility and trying to make it sound like she'd just skived off? Nah.

The entire point of my reply was to show that there is Rachel's side to the story, and then the manager's.

You can spend your entire life thinking other people should act a certain way and say things like 'the time was then'. I understand the smug satisfaction of thinking you know better than somebody else. I also know the loneliness and frustration of living in a world of perceiving other people as being wrong, less, or better etc. It's exhausting for you, it's at best exhausting for others to deal with you, so who is winning?

I know the ego-trip side of thinking you're right is feeling like it's a winner. Go see if your heart and gut agree - the gut will communicate by clenching or being relaxed, the heart by being closed or open.

I know there are plenty of people walking around with a clenched gut, a closed heart and a very busy mind that's gleefully judging everything in sight and gossiping about it with other minds, posting on HackerNews etc. I just don't know anyone who's happy, engaged in that lifestyle :)

I've taken some time to think about it and my gut says that manager was an asshole. I'm not a particularly judgemental person, but one thing that does incur my ire is managers not taking responsibility for things under their control.
> There was no division of duties on the team. Everyone was responsible for the system as a whole. [...] Basically, I asked why he didn't take care of it. His response floored me.

> "Oh, well, you always take care of it."

I've found that it's almost never the case that there is no division of duties. Sure, there may be no explicit division of duties, but there is almost always an implicit division of duties. If Person X is always the one that handles Task Y, then the team will come to view Task Y as a duty of Person X. Other team members may then just simply assume that Person X will take care of it, or they may even actively avoid it to avoid stepping on anyone's toes.

And that is the kind of low-touch crab pot[1] management practice that irks me.

I have to wonder if structure is actually evolving away, or if it's just a side-effect of the internet birthing so many businesses that management skills are rare in general so people just figure they might as well do without. I'm not nostalgic for the Mad Men era and rigid org charts, but there has to be a better way. If careers are just going to be one long Choose Your Own Adventure game, we all might as well go contract and freelance.

1. https://en.wikipedia.org/wiki/Crab_mentality

"Too many cooks spoil the broth."

If a particular person typically handles it, trying to do it for them without explicit instruction that you need to because they are out sick or something can actively cause problems.

That practice is ok in many circumstances. People tend to fall into different roles. Personally, when I was an SA I loved the scripting and troubleshooting aspects of the gig. Support, even Dev support wasn't my favorite thing. But my colleague was the opposite, and we matched well.

If that workload becomes an inequity, the solution is to raise the issue and work on resolution. Shaming people and blogging about it feels petty.

This is my nightmare. Implicit division of duties are natural, but they should definitely be combated. Otherwise, things fall apart when people go on vacation, or worse, leave the team.

The way to do that is to have a communal backlog of work that people pick up tasks from, and to have an on-call rotation. Both of those things are rudimentary software engineering best practices nowadays. No one should be quietly maintaining things in their own corner. Situations like the ones described in the original post should be made part of on-call duties, or, even better, automated away.

Warning sign 1) People aren't doing what they're supposed to, and rather than wanting to improve/rectify the situation, they don't care.

Warning sign 1.5) Manager didn't consider this a problem.

Warning sign 2) Manager burned you, the employee trying to do things right.

Given my experience, at this point I'd leave. The department, or the organization, if I believed the problem went higher or would continue to haunt me.

I've spent way too much time and energy making up for others willful deficiencies.

Move one. Let them put themselves out of business.

The term 'team' pops up about five times in the article, yet passive aggressively leaving an identified issue that is responsibility of the team unaddressed to prove something to yourself is the least team-like behavior I can imagine.
I know this is a piece from 2012, but I can share my experience from the one being on the receiving end of this. I had a very very similar colleague and I really repent my working experience with her. What people like Rachel post as acceptable behaviour is actually not conducive to the workplace at all.

In my case, I was just transferred to another position and I was required to maintain some production machines for clients. These machines are all hosted on the cloud running their own CRON. My job was just to ensure everything was smooth and no downtime happened. This person, SSH-ed into the instance, removed the CRON tasks on one of the machines and let the system on. I was still fairly new and I was only a few days into this new position. Eventually I found out based on login logs that this person did something and when confronted directly, she said she wanted to see if I would do the work diligently in the right situation. Almost like what Rachel did, except she didn't go out of her way to do something nasty. I think you don't have permission to do these things to your colleagues because you're exactly just their colleague and not their boss.

We had some heated arguments and my ex-boss sided with her because she played the minority woman in tech card (no kidding) and it affected my appraisal as well.

Just a note to any of you reading this really bad article. Just don't do this. There is no win win for anybody here. If you feel you have a problem with someone, directly confront with them. Don't do all these indirect things which may have serious consequences in your career in the long run (eg. Management's Perception of you). What Rachel did is exactly what you're not supposed to do at a professional work place. Don't do stuff like this and play the victim card. It's really uncalled for and annoying.

In the end, a lot of people left the company because of this one nasty colleague and management wouldn't take any action because of her gender as they kept her to maintain the gender ratio. About a week ago I learned that about 7 engineers quit this position over a span of a year for the very same reason.

These kinds of actions are the foundations of passive-aggressive behaviour and culture rot and are breeding ground for politics. Please don't do this.

Yeah, the best thing to do when you have a problem with a particular person is take time to calm down, and then:

Figure out what your problem is. Are they doing something you don't like? Are they not doing something and you really think they should? Why don't you like that? Why does it make you feel that way?

Figure out what needs to change so #1 doesn't affect you. Are you upset because you're doing a bunch of menial work with no end in sight? Ask the team to pitch in more. Is your coworker not writing enough documentation when they submit pull requests? Tell them that, and tell them that you're frustrated by it if you need to.

Talk to the people you are having trouble with. Tell them what your problem is, why it's a problem, and be really clear that you own your emotional response but that you're hoping they can change the things that are upsetting you.

Be willing to negotiate. Be open to alternative solutions. Take ownership of things that you have agreed to do, and don't be afraid to remind others to take ownership of the things they've agreed to do.

Also, don't be afraid to leave a place where people aren't paying attention to you and basically don't care about you. There are plenty of other companies in the world. They don't all pay the same, but it's possible to value more than just money. Sometimes the best way to signal that conditions are bad is to leave.

Well said. Appreciate the sound advice. Very actionable.
Didn't look that bad from the co-worker. He could grow up a little bit but that's all I see really.

Problem was your boss cause one could easily retort "oh okay, you accepted what I had mentioned I was going to do and you later go against it, saying it was the wrong decision"? (obviously he's your boss so you're stuck and saying that wouldn't have helped much)

> There was no division of duties on the team. Everyone was responsible for the system as a whole.

The authors point is valid: It is necessary to be aligned with your team leader. :(

I think that this author has had a key misconception about their team. Regardless of what the 'official policy', it turns out that that the team is happiest (excluding the auther) so long as this author is continuously monitoring certain issues. It's less efficient for multiple persons to be doing the same monitoring.

If I were in her position, I would attempt to divest myself of the menial task of checking/monitoring and write some code to do it instead.

(And automatically deal with this "extra master")

Next, I asked an honest question: even then, why was it automatically up to me to get these things to work? There was no division of duties on the team. Everyone was responsible for the system as a whole.

So, it was up to her because everyone was responsible for the system as a whole. That includes her. She is clearly in the wrong here.

What "experiment" did she think she was running? I see no experiment here. All she did was not address the issue until someone higher up complained. That's it.

She made zero effort to find out why this happened, who did it, etc. She assumes her coworkers are wrong and bad and lazy. Maybe they were busy doing other things and didn't notice this issue. If you are more competent than your coworkers and not getting paid extra or whatever, that can be aggravating. But management doesn't care about your petty BS. They care that the system runs properly, not which individual routinely has to catch and correct the anomaly while pouting about doing their job.

She even indicates it was incredibly trivial to resolve. So this post sounds like someone looking for BS reasons to be wrapped around the axle about something.

"Once, at work, I spent vastly more time conspiratorially complaining to my boss and then faux monitoring the system than it would have taken to just fix the problem that it was my job to fix because I had delusions of grandeur and wanted to indulge in some completely pointless witch hunt."

Wow, honey, get new hobbies. Fucking with coworkers for giggles and then blogging about it does nobody any good at all.

She obviously felt under appreciated by her team, and resented the workload that hand fallen into her lap, viewing her other coworkers as lazy. For their part, they saw she did it without complaint, and obviously didn't mind that. Sure they may have been lazy in this scenario, but the author certainly didn't communicate she viewed them that way.

So she conducted this passive aggressive "experiment" and then got mad when she was called out on it.

This is just an example of a communication breakdown resulting in bad team dynamics. Worst of all, IMO, the author concludes not to disengage in her anti-social behavior, opting to continue doing it but this time in secret.

She went on a completely pointless witch-hunt. The odds are good that had someone risen to the occasion to track down the anomaly and fix it, we would still have some poison pen piece about the incident. She just would have found some different catty angle.

"Let me tell you about that time I kindly stood idly by failing to do my job as an experiment to graciously let my bad and lazy coworkers grow and they completely botched it. Thousands of dollars in damage done and servers had to be replaced."

"Let me tell you about that time my male coworker decided to steal my thunder and get promoted over me by doing my job when I couldn't be arsed to because sexism is clearly alive and well!"

People who spend two months looking for some BS excuse to fingerpoint instead of spending 30 seconds fixing the problem are going to find something to complain about. She not only spent two months pursuing this at work, she then blogged about it. She invested all kinds of time and energy into this bizarre little scenario in her head.

She clearly has Big Feels about something. Why? I don't know. But that is the real issue here.

Politely, you don't know what you're talking about here.

If you read up on the author you get a much better picture of the orgs she's been a part of, the work she's done, and the problems she has done troubleshooting on, I think you might adjust your opinion a bit.

She suspected her team was underperforming and unfortunately the quietest way of verifying that is just not to be the one to step up. There was no "witch hunt" here.

Her stated goal of proving the badness of coworkers is clearly outlined in the title of the piece. The piece itself in no way supports the assumption she asserts concerning their badness.

Perhaps it is just bad writing that neither stands on its own nor indicates that there is additional material needed to fully appreciate it. I don't feel any personal obligation to do a lot of legwork here to bend over backwards to give her the benefit of the doubt, especially since I see no reason to doubt my conclusion.

> since I see no reason to doubt my conclusion.

That's because you clearly haven't worked in a technical role that involves babysitting, ma'am.

If you can't spare the effort of researching somebody before calling bullshit, please continue that trend and spare the effort of spouting off. :)

I thought I must have misunderstood the story, because after skimming it I had the same impression. The author came across as having superiority + victim complex, and I got the impression that yes, the team has problems, but the author was toxic.
Congratulations, you've labelled the author exactly as she did other people. (Labelled, pigeonholed, same thing.)

This is how these things get started, people label each other in a bad way then force them to stick to labels. (In a soft way or more explicitly.)

There is no good way out of such situation. If you point it out you're labelled as disruptive, because status quo is God. Even more so if you escalate. If you take initiative, get labelled toxic and evil. If you quit, you're a quitter or job hopper.

There are good ways out. The fact that she and you have no idea what they are notwithstanding.
Please name a few of them. specifically ones that will result in a good situation for all involved.

I'm actually interested and not being obtuse here.

You decline to fit the label. You decline to accuse the labeler. You treat it as a communication problem. You starve the drama of attention. You prove them wrong by failing to be guilty of the accusation. You assume the first several incidents are unfortunate happenstance.
"Starve the drama of attention". Love it.
DoreenMichele already indicated what she could have done, and what she shouldn't have. She did not take the high road. She demonstrated that she had a chip on her shoulder and chose to express that in her behavior. I'd have raised the issue with the manager in a non-confrontational, constructive way. If that proved impossible or ineffective, I'd have accepted it or quit. Even the author freely admits nothing good came of her approach, but she failed to realize that put her in the wrong, because she had a superiority complex.
It's all about intention. Her intention was to set up and take down others. Her intention was to hurt, not heal. When it gets to this point, you're not a team player anymore. You are a saboteur. I've seen people get like this when the stress is way too high (which is common in the tech field).

Arguably, there is a time to not forgive, e.g. 'Three Billboards'. But that level of line in the sand stuff should only be used rarely, not on a regular basis.

The part that struck me as particularly strange was:

> he just said "the documentation sucks". My response to that was "uh, well, I figured it out, so how bad could it be?".

Isn't common sense to update the documentation for how to do semi-obscure dev-opsy things and disseminate this information to the rest of the team?

There will always be some plumbing thing that you are the most familiar with; if you want the team to take shared responsibility, it's kinda up to you to bring it up and suggest rotation or whatever needs to be suggested to systematize the workload distribution.

I interpreted her response as "the documentation is adequate, so the problem lies elsewhere."
Same, her coworker also said they were aware of the issue but did nothing about it nor were they inclined to ask how to fix it.
Why is her standard for "adequate" superior? We're to assume it is, apparently, but it isn't clear that it actually is adequate.
Well she did figure it out from the documentation, so clearly it was adequate for her. Maybe she's just that much smarter and more competent than her colleagues, and what's adequate for her is not adequate for them, but if so then that somewhat justifies the frustration that caused her to run her little experiment in the first place.
It doesn't justify her frustration at all. There is no indication she tried to help (e.g. by teaching, explaining the superiority of her method, etc.), ever. Her frustration would be justified if she'd been acting like a senior, experienced person and constantly met with ambivalence or incompetence, but there's no indication of that in this blog post. Her frustration absolutely does not justify her actions anyway so I'm not sure it's relevant.
I don't know, it could be interpreted both ways. FWIW, in my current job, documentation is plumbing I tend to own, even though it really is supposed to be a collective effort to improve it. There are people in my team that will be quick to say documentation is "adequate", even if it's missing some implicit knowledge.

Rather than sulking and running sociopathic "experiments", I've found it to be more effective to keep advocating for more attentiveness to docs (by discussing it as a task prioritization item with the team, by setting examples, via code reviews, etc). If you continuously call it out when people drop the ball, and give constructive feedback when they attempt to take on the task in earnest, you gradually see better results.

The problem is that witch hunts tend to find people guilty, whether they are or not.

She wasn't asking an honest question. She was trying to do a gotcha.

My ex had some great expression along the lines of "It is a when did you stop beating your wife? question."

In other words, the assumption of guilt runs so very deep, even when nominally trying to give you credit, it is damning. The framing does not allow for the possibility that you never stopped beating your wife because you never were a wife beater to begin with.

She set out to prove her coworkers were bad. In other words, their badness was a foregone conclusion in her mind. She wasn't checking to see what they would do.

It's entirely possible she had crap coworkers. But if she isn't management, managing her coworkers is not her job.

I don't think it was a witch hunt, I think it was just "I'm sick of fixing this crap, let's see if anyone else will show an iota of initiative."
(comment deleted)
This is great, ty. I'm going to add this to my collection of 'words for when'. There are so many strange tricks that people pull on each other that are hard to concisely describe.
I mean her job is not specifically to make the team function well. The person whose job it specifically is, her boss, totally flubbed this one. An engineer came up who was clearly having issues with the team and his response was to just sit back and watch it happen.
There were, no doubt, genuine problems at her job. This was not a good way for her to handle it.

Setting out to prove you have bad coworkers is unprofessional and just not a good thing to do. I had a really lousy coworker at my corporate job. I hated being assigned his botched files when he took the day off. Management figured it out for themselves and eventually fired him.

If you have so little faith in management that you think they won't find the bad eggs themselves, you should be job hunting, not setting up little experiments to prove they are bad. If she was dissatisfied with always being the one doing this 30 second job, there are far better ways to try to address it. This is not it.

The post is several years old. Hopefully she now feels "Gosh, I was young and stupid and can't believe I did that."

I would not want to work with her and would not want her in my team.
> "Oh, well, you always take care of it."

That could have been a nice chance to say "Oh cool, I implicitly got this new responsibility? Let me solve this, get to the bottom of it, own the solution, present to the management. Maybe ask for a raise later?".

Part of the the road to success is taking situations like that and turning them into your favor.

> He took what I had set up as a little pseudo-managerial experiment to see just how lazy these people were and turned it against me. Meanwhile, nothing happened to the actual people who were lazy!

Now come to think on it, I wonder if she was the experimental subject after all. Notice how people expected her to handle it. I wonder if somehow the manager turned "the experiment" around into another experiment "I wonder how much time she'll waste running the experiment instead of fixing the problem?".

There are a number of problems with this person's behavior.

1) Letting an incorrect configuration persist without either notifying the team or manager is irresponsible (and, no, her "chat" wasn't informing the manager; if anything the writing indicates it was deliberately light on information as part of her "ruse").

2) Engaging in a passive-aggressive experiment to "prove" laziness is demoralizing and hostile.

3) Failing to address a co-worker's concerns (however poorly or inappropriately articulated) about documentation by helping him over his issue or updating the docs is itself lazy and irresponsible.

This person passed an opportunity to exercise leadership by setting an example and act as a member of a team and instead chose to be aggressive and hostile toward her co-workers. If I were her manager I'd have dinged her in the performance review, possibly worse than she was dinged.

I'll add that she probably had some bad experiences in the past which turned her cynical in regards to her team and made her take this passive agressive route.

The manager missed an opportunity to improve what's likely a problematic working environment.

We don't know that from her blog post. Maybe the manager had negative feedback for others on her team stemming from this, and she just isn't aware (or didn't include it).

I would agree that the manager has done a poor job of managing to let things get to the point where this person felt the need to act as she did. Even if he didn't miss an opportunity from this, he seems to have missed many previously.

I don't agree with the author, like most of the comments.

She's setting herself up for a win-win. Either somebody fixes it and nobody else notices and she gets to escalate the severity/subtleness of her testing of teammates, or else nobody fixes it and she can yell about something that she thinks should have happened. It just seems like she's setting other people up to fail.

I generally don't play those gotcha games. There is no winning path. If your coworkers play these games, LEAVE.

If you have a problem with someone's behavior, the moral and healthy thing to do is to address it with that person directly and to not leave that conversation until the situation is fully resolved to the mutual satisfaction of both parties. Conflict can make a relationship stronger if it is genuinely pursued with a positive sum intent. What this woman did was to try to make herself look good to her boss and to make her team mates look bad.

Finding fault in others seems to be a conscious strategy for this woman. She has even written a book called "The Bozo Loop".

Who in their right mind would choose to hire someone this toxic?

Ouch, ouch, ouch so much distaste for somebody with high standards and perhaps one who demands high standards from the people they work with.

One thing to consider is the environment in which these machines were running. If the group Rachel was working in is getting phone calls about mis-configured machines in one of the clusters they manage then perhaps there was a lot at stake - the description of the cluster setup would seem to indicate this was the case.