Live data from Hacker News

Big company tale: six months for a list and a button

rachelbythebay.com

71–80 of 91 posts

Re: Big company tale: six months for a list and a button

#71
> April 8: it seems there's now a mock-up of sorts from the team. Inside the group, we start talking about that situation where if you mail the $open_source_project mailing list asking for help with a legitimate problem, nothing happens, but if you make up a shitty version of something and fire it off, then suddenly 50 million people show up and go OI! DO IT THIS WAY! But, three months earlier when you politely asked for help, zip, nothing, nada, zilch.

This seems quite interesting to me. I haven't really got chances to interact with mailing lists, is this really the case?

Re: Big company tale: six months for a list and a button

#72
post #17

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. There was a piece few days ago about picking co-founder using the army way. Beside being a well written piece, it made clear one thing. The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need…

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.

Re: Big company tale: six months for a list and a button

#73
post #28

Earlier quoted context omitted.

The last line is accurate. You either give up and leave, or stay and become part of them. It's really hard to stay and effect change.

You just described the thesis of one of the wisest books I've ever read, Albert O. Hirschman's 1970 classic "Exit, Voice, and Loyalty." https://en.wikipedia.org/wiki/Exit%2C_Voice%2C_and_Loyalty

Thanks! I read the whole Wikipedia page and a bit more (this far), started thinking about the book.

Re: Big company tale: six months for a list and a button

#74
post #17

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. There was a piece few days ago about picking co-founder using the army way. Beside being a well written piece, it made clear one thing. The role of leaders in an organisation is to get stuff done, despite rules, regulations, hierarchy and all the whistle and bells that an organisation need…

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

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.

Re: Big company tale: six months for a list and a button

#75

You can also use this essay to examine opportunities and pitfalls of horizontal coordination across organizations. I used to work at a big tech company, but now I’m one of a few cloud devs at a startup. One day we realized we needed a dashboard, so I spun up a server and put a single binary on it that saves data to SQLite and renders HTML server-side. Dumb stuff. Took 2 days, problem solved, been humming along for a…

> dashboard team ... create a self-service solution for making a new dashboard

> Am I missing a downside

I don't think so, I'm just wondering, what to do if the dashboard team creates a buggy & hard to use, worse than nothing, dashboard self service, and everyone is supposed/required to use it

> 100 devs. ... If you don’t do this right, the dashboard communication/management overhead at some point grows larger than the cost to develop a new dashboard.

That's an interesting point!

Re: Big company tale: six months for a list and a button

#76
post #71

> April 8: it seems there's now a mock-up of sorts from the team. Inside the group, we start talking about that situation where if you mail the $open_source_project mailing list asking for help with a legitimate problem, nothing happens, but if you make up a shitty version of something and fire it off, then suddenly 50 million people show up and go OI! DO IT THIS WAY! But, three months earlier when you politely asked…

Yes I would say this is a case when someone wants to contribute something to an open source project.

Often these initial questions are very unspecific and often as a maintainer you only get the question, answer it and then never see this person again. Time wasted.

When someone already wrote code and want to contribute it you know that the person already invested some time and is seriously about implementing some stuff. Here the likelihood that your time is wasted is much less.

Re: Big company tale: six months for a list and a button

#77
post #16

Ha I once tried to write a dashboard for our fledgling ecommerce platform at a relatively small company and hit a solid brick wall trying to get it deployed for all sorts of internal politics reasons . After months of back and forth I gave up. After about a year an entire new team was spun up with back end and front end devs to build something like the dashboard but… better… it took months of course. This isn’t just…

What can be ways to change the culture into pro innovation and cooperation

Re: Big company tale: six months for a list and a button

#78

Earlier quoted context omitted.

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.

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

Re: Big company tale: six months for a list and a button

#79

Earlier quoted context omitted.

You just described the thesis of one of the wisest books I've ever read, Albert O. Hirschman's 1970 classic "Exit, Voice, and Loyalty." https://en.wikipedia.org/wiki/Exit%2C_Voice%2C_and_Loyalty

Thanks! I read the whole Wikipedia page and a bit more (this far), started thinking about the book.

Btw that book explains why sometimes a police force or the military in a country can be recklessly violent, and consist largely of men who happily do all sorts of atrocities

Re: Big company tale: six months for a list and a button

#80
post #53
post #9

Earlier quoted context omitted.

> their PM told them to disagree with me to pump up the final bill This explains a lot of my experiences now

IMHO that would a rare to almost non-existant thing. Any sort of Mega Corp has an unending stream of IT work. There's no real need or desire to pump up the final bill. You'll make way more money in the long run coming in on time and under budget.

although the problem is there's no incentive to perform when delivering late and over budget rarely has any consequences
Post reply on HN