Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rachelbythebay.com

Post reply on HN
Print view View original

61–70 of 91 posts

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

#61

Post by physicles »

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 year, no plans to rewrite it.

Now let’s say another dev decided that they wanted to build another dashboard to monitor a service they just built. Obviously I’m gonna insist that they add on to the stuff I already built. I show them where to add the function (literally one function that makes an HTTP request and returns an error), it takes them 10 minutes instead of 2 days, and doesn’t add another entry point for attackers.

But now let’s say our company now has 100 devs. There’s now more status info than can fit on a single page. 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.

What the dashboard team in OP’s article should’ve done is to create a self-service solution for making a new dashboard: here’s a big template, fill in whatever health checks you need in one of N languages, and tell us when you’re done and we’ll spot check the code and deploy it for you. That way they maintain control of all the dashboards, and teams get their dashboards way faster.

(Am I missing a downside, other than that the dashboard team will need to downsize?)

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

#62

Post by Tempest1981 »

sokoloff wrote: post #46
alistairSH wrote: post #44

Earlier quoted context omitted.

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

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

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

#63

Post by treis »

tluyben2 wrote: post #56
treis wrote: post #53

Earlier quoted context omitted.

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.

These are often long term projects; consultancy firms, especially big ones, are very good at delivering over time and over budget and still remaining there 10+ years. They are trained to do this and do it well. Maybe it depends on the region but it's very normal in Europe anyway for the Cap Gemini's etc to do this. Sure they have an unending stream of work, but you rather still do far less work for far more money or…

Things go over time & budget for lots of reasons. The biggest one is that the lowest bid is likely to win so the incentive is to under-estimate. But it's rarely because the contractor is intentionally creating more work.

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

#64

Post by rdtwo »

agd wrote: post #38
siscia wrote: 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 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…

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

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

#65

Post by alistairSH »

sokoloff wrote: post #46
alistairSH wrote: post #44

Earlier quoted context omitted.

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

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.

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.

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

#66

Post by chockablocker »

My personal record is 2 years for a text box to be added to a form. To be fair, that's harder than it may sound. The textbox must be in the web version, the app, the api. It needs to be localized, and data stored must be compliant with GDPR etc. The list goes on. It doesn't help task velocity if the PMs switch, the thing gets de-prioretized, re-prioretized and there still being ongoing discussions that question the purpose of the textbox (maybe we should do videos instead of text). After 2 years I'm happy to report the textbox launched... :-/

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

#67

Post by TomDavey »

nicbou wrote: post #28
leroman wrote: post #23

Had very similar experiences at not even a "big company" it's more of a mentality of a "Big Co.". People hired to just not care, sit at meetings to make managers feel important and provide some pseudo progress to higer-ups to make things look like they are moving somewhere. In reality, I have not doubt a half decent motivated engineer can replace a group of these unmotivated developers, which I have seen done and did…

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

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

#68

Post by Zababa »

l0k3ndr wrote: post #13

This is too real. But not only big companies, even startups with good funding and mid-sized team can behave like this.

I can confirm this, I've seen this happen in a startup that has ~40 people. The cause seem to be that devs aren't sensitive to business needs, and product managers/owners don't fix this.

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

#69

Post by Zababa »

alistairSH wrote: post #65
sokoloff wrote: post #46

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.

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.

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

#70

Post by milesvp »

tester756 wrote: post #58

>"this is the only way we can maintain it". So, when you don't have XP with X tech, but you wrote your hacky solution and the person who has XP with X tech tells you that other_solution is more maintainble, then probably... He/She's right.

I have mixed feelings about this. I’ve seen stuff built by different departments that weren’t core developers. They definitely needed help making sure they had something that could be sustained by the company going forward. Similarly, I’ve been handed unmaintainable trash handed to me by teammates who should have had enough experience to know better.

On top of this, I’ve come to appreciate that maintainability is very much context sensitive. What’s unmaintable on an expensive team of engineers can be totally maintainable on a team of cheap interns. Is the solution maintainable by the engineers better? arguably. But the solution maintainable by the interns may well be good enough.

So, yeah. I try to be responsive to the needs and capabilities of teams when they request help from me in an organization.

Post reply on HN