> In "traditional" companies, developers get work items assigned to them - most often JIRA tickets. These tickets are vetted by the product - or project - manager, and they have most key details to do the work. And they're expected to do just that. There's little need for questions unless it's about clarifying a detail in the ticket.
> Join a "SV-like" company, and you'll see little of this. There are projects, and there are program managers and engineering managers. But for the most part, engineers are expected (and encouraged!) to figure out the "how" of the work, including making larger decisions. In some places, each project would have an engineer leading it, who facilitates breaking up the work. At other places, engineering managers or senior engineers could do this work. Regardless of how it's done, all engineers are incentivized to look at the big picture, to unblock themselves, and to solve any problem they see.
> Engineers taking initiative is something "SV-like" companies celebrate. It's common to see services and features built that engineers suggested or have teams spend dedicated time paying off tech debt that people on the team advocated for. And it is uncommon for managers to tell engineers what exactly to do, to break down their work into small chunks or to micromanage them. People self manage.
> The expectation from developers at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has. This is a huge difference. It impacts the day-to-day life of any engineer.
> Sounds like you're working at a more traditional company then:
Yes and I apparently always have, despite working for tech startups in several cases. Never thought that they would be considered "traditional", but they evidently are.
I've worked at both types of companies, and it's funny: People who have only worked in one style are surprised to learn the other style exists. I actually made a career switch out of engineering because I wanted to have more input into the product, rather than just sit at my desk getting showered with JIRA tickets. Of course, I switched out of engineering, and moved into a company with the other style--where the features were engineering-led. Just my luck.
Of course, there's always the definitional question of "what is traditional?" because you can obviously 'go back' to different time periods, and perhaps in one of them what you're suggesting was true. But in this case, we're talking about cutting-edge/high-prestige tech companies vs 'traditional' non-tech companies in a modern context.
Same here, I resigned recently from a company (nominally a startup) that behaves like a traditional company described here. After working in SV-like companies for 20 years, it was very difficult to be a leader in that environment, with heavy micromanagement and information filtering.
Yes, at a lot of companies (anecdotally 3/3 for me including a FANG) the developers are the main driver of the product development. Product managers help guide the process and directors set the cardinal direction, but the product innovation comes from the developers.
This has not been my experience. Everywhere I've worked (a bunch of different kinds of places now) has been hungry for people who can help out with the broader more ambiguous direction-setting and decision-making needs of the company, but most developers I've worked with are not very energized by this kind of work.
Someone else makes decisions and creates tickets for devs to work on.