Hacker News Reader

>I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with

I have to agree. I’ve always assumed that everyone else knows who this person is, and that she’s some sort of FAANG superstar, but each time I read these pieces, I see someone exhibiting entitlement and always looking for external blame.

I read this particular post thinking about the very first task I was given after switching from an advertising career (making Flash sites with ActionScript) to a software-service company, where I needed to construct industry-grade tools with Js.

My new tech boss gave me the task of building a dashboard that would hook into a secure database and display real-time stats using D3 to track things like number of online users and response latency. This was unlike anything I’d built before, and starting with zero knowledge I had a working dashboard about a month later.

In other words, not rocket-science, and not beyond the capabilities of anyone with even a small amount of frontend/backend experience to build themselves - or in this case spec properly so that another team could understand what was needed, and be able to build it quickly.

Stories (which is the medium used) about how things went right without effort are boring. Which leaves two stories - things that went right that had a lot of effort, and things that went wrong.

In the case of things going right with a lot of effort, there’s the case where things went right because of that effort. If you write stories about those, you can be accused of being self-aggrandizing - but they do give people practical options to consider in similar situations.

In the case of things going wrong, there’s the case where you tried to correct things, but were not successful. There’s value in exploring what you could do better - but that’s not a story. The story is the people and archetypes and systems and so forth. In that case, you can be accused of seeking to blame others.

The other stories could be where you did something wrong (but which at the time seemed like they were good and necessary), but despite that the outcome was successful, or because of that, the outcome was unsuccessful. If you’ve read enough of the back catalog, these do exist.

I like that these are presented as stories, and that they are representative of situations people will recognize and also find themselves in. If you’ve seen them, it’s validating that others perceive the challenges the same. If you haven’t, you’re forewarned about things that may come up.

I guess the hard part here was to split the work into these small independent chunks, that a single person can work on, and that in the end all chunks can then be joined or replaced. That is where companies rise or fall.

> For instance figure out the resources that was suppose to create the application, pass by its office, offer its a coffee and communicate clearly why the things is important and how important it is and what is the goal of the project and finally reassure the resources by putting in whatever work tracking system all the details.

You are assuming that just because the manager can swing by at author's desk, their team is also at the same location. Not necessarily true. They could be sitting across the world, in a another dysfunctional team, they have a bi-weekly dysfunctional meeting and nothing functional comes out of it. Even when engineers are in the same place, some of those can be very bureaucratic/defensive/lazy/CYA type because bigco allows such people to exist in the shadows. Based on past experience, I'm only slightly exaggerating.

> These kind of human work and relationships building is fundamental.

Having said that I said, I also agree with this in the current context - that personal connection, when established, speeds things up. But then again, this doesn't always work out/is possible due to reasons mentioned above.

Of course it was just an example!

But even a chat message or an introduction does wonders.

My point was that, from the tale, I don't think the author did enough to actually accomplish the task and that the complaints on the internet public square is hardly justified.

Said so, I find it a well written piece that may be useful to younger engineers approaching these kinds of dynamics.

I would find extremely interesting a similar article comparing when stuff goes well and when they move at high speed highlighting the differences of approaches and results.

> comparing when stuff goes well

I suppose that then the dashboard team would have replied that same afternoon: "Done, here: __", end of story. Without needing any coffee.

And if they (the dashboard team) didn't see how the dashboard was important, they'd kept asking for clarifications until they knew, and then clearly said if they'd do it or not

> [...] "please do this" and when naturally things takes too long to look reasonable complaining on the internet.

This is a story about broken parts of a large company and how something got done in spite of it, there are lots of these on HN.. They are cathartic for the author and readers who experience similar scenarios. Perhaps you were expecting some sort of moral to the story but some things are just broken and you have to do it yourself, still I'm not sure why you are picking on this author in particular.

> stuff that the author could have done differently [...] pass by its office, offer its a coffee and communicate clearly why the things is important and how important it is and what is the goal of the project [...] These kind of human work and relationships building is fundamental.

This cuts both ways - and I believe the recipient of a task (as the recipient of many) has a greater responsibility in understanding the requirements and keeping dialogue open when they do not understand something. But this is not the problem here, in this story the person tasked and the person originating the task are too far removed from each other due to corporate layers.

I take her articles as wakeup calls. She points out ridiculous behavior patterns in companies by telling stories from her hands on ops perspective.

As a industry we talk a lot about agility but stories like that are more the norm than the exception. It is good to see an outside perspective on what is expected. Typical customers swallow our behaviors due to the lack of understanding but an IT ops like her just knows what is possible.

> stories like that are more the norm than the exception

And most of the time, nobody learns from the experience when it happens to others, or even to themselves. "Learning from failure" is one of the most overused and most underutilized mottos in tech companies.

Her stories gain a sharper edge if you’ve worked in similar sorts of environments before.

If you aren’t aware of how there are teams trying to “own” turf, and prevent alternatives (even one-offs), and also how the entire company tries to funnel anything that matches a keyword to that team, even when it is the most tentative match, then you aren’t aware of the challenges faced to navigate them.

You see one path (going with the flow), but don’t see what happens when you don’t follow it.

Not going with the flow is definitely valuable - it’s something any good senior person should have in their tool belt. And if you read Rachel’s stories, there are many examples of not going with the flow (and comments in the HN posts about how she’d be more effective if she didn’t go against the flow).

The challenge is that you can’t always go against the flow either. It’s celebrated if you cut through some red tape - but at some point you’ll just get a reputation of being contrary. Even if you don’t, it’s tiring to have to be the one trying to course-correct the world. Either way, you have to choose your battles. And a button on a dashboard probably isn’t worth using your capital on…

There’s a degree to which you can just go out and talk to people and build relationships. You’d be mistaken if you think that developing these relationships (as well as a reputation for solving real problems, which puts you on the right foot with many strong engineers) is an avenue that wasn’t explored.

I agree with most of what you said, however:

> For instance figure out the resources that was suppose to create the application, pass by its office, offer its a coffee and communicate clearly why the things is important and how important it is and what is the goal of the project and finally reassure the resources by putting in whatever work tracking system all the details.

That's far not always possible. An example from my previous job was a situation where the upper management wanted to enforce some changes in order to try and shine in front of the CEO. Changes which no one further down, myself and my direct manager included, agreed with. We warned the upper management that this is a terrible idea and that a lot of people would quit - in a similar fashion - in the office over a coffee (actually over a zoom call, considering the pandemic had started). The response we got was "If they wanna quit, fine, f*ck them, we'll find new people". Needless to say we announced our departure the next morning with 0 room for discussion. And same happened to the rest of the team over the coming 6 months. What I'm saying is that you are right in principle but this does not always work.

While I agree completely that "human work and relationships building" in organizations is a more practical way to work with people than the author's strategy, if I were to call any of the people in the story "awful [...] to work with", it would have to be the people from the dashboards team, who apparently wanted to own the dashboard page but not have any of the responsibilities of actually building it. To be clear, it wasn't the author's preference to have another team build the page their team needed. The dashboard team insisted on doing things their way, then deprioritized the task, bungled the implementation, and finally delivered a trivial amount of work, six months after promising to do it.

And sure, everyone has different priorities, and may not understand the urgency of tasks in the same way. And it's only human to want to promise to do things for other people, and therefore make them happy. But promises by themselves aren't enough to get work done: when I'm in the workplace, I don't want wishes and happy thoughts, I want people to deliver. If someone tells me to hold off on doing a one-day project, because they're going to do it for me, and rest assured, it's on the roadmap, even though we won't tell you when we're going to do it, because quite probably, the answer will be something like "never, as long as we have more fun things to do" --- well then, at the very least I expect to be told as much, so I can avoid throwing my project into that particular black hole. If they can't, or won't, communicate realistic priorities and deadlines, then they might be great to eat lunch with, but I definitely don't want to work with them on a project.

Office jobs, in my opinion, tend to play host to microcultures which value politeness, sympathy, and relationship building so highly that these virtues start to displace and eclipse the honesty that is the cornerstone of serious, professional work. I come across this theme over and over in these kind of "story-rants", a theme that in the telling can come off as rudeness or abrasiveness on the author's behalf. Those who are keen to interpret it as such, should keep in mind that this says as much about them, and their own opinionated view of how the workplace should operate, as it does the authors of those stories.

I agree just went on to check couple of posts:

https://rachelbythebay.com/w/2020/03/03/emoji/

This one stands out as "you are all dumb and I am so smart".

Then also that person does not understand that one should keep hers "edgy" stuff for group of her besties. Or at least understand that other people might not be in the same context.

So for the original story posted - well I don't trust the narration. It just seems there was lack of communication.

Wow, that post is really something.

Yeah, we've probably all felt frustrated at work due to managers, coworkers, bureaucracy or something else, and sometimes we want to vent. You don't do that in the company slack, though. That's just juvenile and stupid.

This person really doesn't sound very pleasant to work with, and I don't feel inclined to believe the retelling in the OP. There are always two sides to a story.

I read the thing to the end and it seemed like the requirements that the author claims were undelivered weren't mentioned until, "oh and it didn't do this other thing that we asked for". The confirmation for example, mentioned in the second-last date entry:

> turns out, no, wait, the button is there, but it doesn't ask for confirmation (as we had asked)

This could have been a much better article if it had laid out the exact requirements in the beginning instead of saying "we just need a list and a button". And while it sounds like the dashboard team really dropped the ball with a lot of things, it also sounds like they may have just not have had good a good specification of what they needed to deliver. If you tell front-end devs to deliver a page that just does this thing (and glosses over the details) they're going to spend time interpreting it how they want. A CSS bulldozer sounds excessive, but why not.

I think the company velocity would have been greatly improved if they had handed off a formal spec, broken out the chunks of work, and put them in an issue tracker.

>but as an awful person to work with

I see what you mean but keep in mind this is where she(?) vents out, so that should make some things show more than others.

These things are written with the intent that people she works with read them. Some of the recent ones are about drama where some walking bridges on her works campus were closed and she wasn't happy about that, and a building was named after her and then not named after her but one that was named after one of the company founders in a different country stayed named after them, and she wasn't happy about that either to the effect of multiple posts on it.

Both specifically communicated to people still working there mentioning to look up and leak videos.

Certainly doesn't seem like someone I would want to work with either.

>about drama where some walking bridges on her works campus were closed and she wasn't happy about that

Oh noes! Should we cancel her for that?

I feel like you're making a storm in a glass of water.

>Certainly doesn't seem like someone I would want to work with either.

But you don't work with her ... so what's the real issue here?

I think you wrote your approach with the best intentions. In some scenarios it may work very well for everyone. In other scenarios it looks like a person circumventing rules and hierarchy, using social manipulation and pressure tactics, and interrupting workers who need uninterrupted focus time. People who use these tactics can come across as selfish and inconsiderate. Your approach may work great for organizational work priorities and helping build motivation, but for situations of overload you may be adding to the emotional stress of overworked developers.

> I keep reading from this author and it always struck me as a very capable technical person, but as an awful person to work with.

the author is a big favourite of HN. they're some early-100 or so employee of Google. many of their articles reach top-5 in HN

I have to agree that the author is somewhat responsible here. Reading it I don't get a strong sense of urgency or ownership.

If this work was important, then why wait on another team who give you a "no telling when" reponse? Get the team together, and assign someone to do it same week. Don't do half-assed follow ups then complain when the dashboard team (which has already shown you it's not their priority) doesn't do anything about it.

If it isn't important, then go focus on the important stuff.

Says someone who never worked in big co. You can easily spiral into weekly one hour leaderless meeting over really trivia items

I got the same feelings. From the article:

> January 29, early: there's this team that nominally owns dashboards, and they got wind of us wanting a dashboard. They want to be the ones to do it, so we meet with them to convey the request.

> January 29, late: asked "dashboard team" manager if they had been able to get the network stuff talking to our server yet via chat. No reply.

Am I the only one to think this is completely unreasoanble to message the other team later that day? I mean it's not as if I am sitting and dangling my legs waiting for a Karen to come, drop everything I do and do her dashboard. They might have had stuff planned for weeks/months in advance...

Yup. I pretty much stopped caring at that point. My backlog is 6+ months long. If you need me to drop something and pick up a new project, it’ll need the blessing of product management and, depending on size/LOE, also approval from my VP or SVP.

PM will adjust when appropriate; they do care. But, I can’t just build every little thing an internal customer wants because I have revenue-producing/cost-saving updates to build and deploy. Make your case that this lost+button saves more money than something else on my backlog, and we’ll probably squeeze it in.

This is a mid-sized enterprise software company and I manage one of our SRE teams.

If your backlog is six-plus months long, do you simultaneously go out and “want to be the ones to do it”?

I have no problem with another team being too busy to take on work in my area, provided they don’t actively try to take on work in my area and then pocket veto it.

This is the real core of the issue. There's always a chance that some software project, small or large, will progress massively slow for 1000 reasons. But the dysfunction with turf wars and actively blocking solutions is really serious, and common in large or growing companies.

Possibly fear that "asking team" builds the dashboard themselves, in a custom way, then asks the "dashboard team" to maintain it.

Although that might still be a time-saver for the backlogged "dashboard team".

I think they (the dashboard team) were worried that if other teams started building their own dashboard, that'd indicate that the dashboard team wasn't that useful. Which could mean they would get fewer promotions or raises, or might even get fired if bad days came. -- So they wanted ownership of all dashboards, whilst actually building them, was less important. (Is my interpretation.)

The new dashboard team manager, who appeared in the end, seemed to be a bit more "get something done" minded though

No of course not, but this person was complaining they didn’t start work the same day the request was made. That’s completely unreasonable.

In that case, shouldn't you reply with "my backlog is currently X weeks/month long, we'll probably get started around Y, I'll keep you updated" instead of saying nothing? Since the team wanted to do it and didn't mention that they had to do something before in the meeting, you can assume that they will get started on it right away. If not, at least tell it to the other team so they can explore their options.

If you go to another team and tell them to drop a project because you will do it for them then it is fair for them to assume that you will start working on it very soon. If you don't have the time to do a project then don't tell people they must let you do it.