[brownbat]

Ok, innocent question, having never worked in a giant tech company with a viable, popular product -- how do they deploy the massive amount of available engineering hours?

Do teams just work on random projects like the above while other people fix bugs? Is it like a million mini startups internally all pitching an idea to the CEO all the time?

Or do you need 90% of people focused on how to develop your product at first, then suddenly it flips and you need 90% of your engineers to balance enormous amounts of network traffic and data storage?

[0xbadcafebee]

A guess, from other companies: a manager is given some engineers, they ask themselves "What should we create?", they come up with an idea, make up a random business justification, POC it to upper management, get approval and headcount, and spend a year or two trying to prove it was worthwhile. Best case it works and gets used by other internal teams for 2-5 years, worst case the team gets broken apart and the project abandoned. (Mind you, nobody gets laid off, they just find other reasons to keep paying people who aren't making anything of value) If you have ever heard about it publicly, it was probably someone's pet project and they wanted their ego stroked, or to "get a win" and a promotion.

Many of the projects are just a response to some other internal problem, like "the teams aren't using a shared platform", so they build a platform for the platforms. Persistent problems get ignored because nobody wants to rock the boat. The joys of working in a large corporation...

[tootie]

I saw this at a decades-old retail company. New CTO brought a Silicon Valley perspectives to the company which involved hiring a load specialist engineers into newly created departments without any explicit business justification. Literally said that once they were hired they'd come up with useful projects. He also wanted to start exporting our in-house software as standalone products even when we were still running transactions through a mainframe. CEO bought it all hook, line and sinker.

[naravara]

> Literally said that once they were hired they'd come up with useful projects.

This is a great way to have engineers burn time on projects they think are interesting rather than projects that will actually have good ROI.

[iamasoftwaredev]

How do you balance avoiding this with wanting engineers who have ideas and agency?

[karthikb]

Bring engineers in to solve problems you know need to get solved. As they learn the system, its debt, the business, etc., listen to their ideas. For ones that sound good, give them the resources to develop a POC. For the POCs that work, give them the resources to take it all the way.

Larger companies with substantial profits can hire engineers explicitly to come up with POCs one after another.

[rockinghigh]

The idea and proof of concept often come before creating a new team.

[karthikb]

In general, initiatives tend to be top down while tasks tend to be bottom up. Politics between the "managers" and the "doers" happens at the interface of those two. What actually gets done and delivered ends up being some function of the top down, bottom up, modified by the political battle.

[sjg007]

All of those are plausible but typically you have core teams built around product lines, teams that build shared components. maybe have infrastructure dev and devops too. maybe a database or datawarehouse team and data analytics/ stats team etc.. a cyber security team. all of these will have some team charter for where they fit into the business and there may or may not be shared resources technical and otherwise. These are typical in post market fit companies that are now “giant”. But yes, first you need the product, everything comes from there.