1. 16
  1.  

  2. 25

    Let’s reframe this: maybe it’s more challenging to be an engineer (or a software manager) in a small company with a small customer base. Where building the wrong feature is a mistake that will cost you a year’s revenue. Where alienating your main client will lead to insolvency. Where you can’t just launch a new product and sunset it two years later.

    FAANG’s enormous scale and customer-lock in makes it very inconsequential for them make mistakes. I’m sure that’s very comfortable for the engineers working there. But I wouldn’t make the mistake of confusing the dividend of those companies’ enormous success with the source of it.

    1. 5

      This is an important point. The motivations of an individual engineer (learning, problem solving, building a CV) may not automatically align with the motivations of a company (sustainable operations). This is not to say that large slathers of management are needed to align the motivations, it’s just that this alignment is needed.

      1. 3

        I’m not sure size is the key factor here. I worked at Google and now I work at a series B startup (joined at 3, now at 50) and we do a lot more of “makers (engineers, designers, etc.) talking to customers” at the startup than at Google. In fact, one of my biggest complaints about Google was that the game of telephone between the person making something and the person using the thing that was made was so long that it was very difficult as a maker to get meaningful feedback on whether you were building the right thing (because feedback from customers got passed through various PMs, etc. and lost detail at each step).

        1. 1

          I’ve worked for a company that prided itself on its customer support. And to be fair, their people were really good at talking things over with customers, making them feel appreciated, maybe offer a little discount for the next month. Anything rather than admit there’s a bug and escalate it. I think that strategy worked well for the company, but it made product development rather frustrating.

      2. 7

        Not sure how valid my experience is as someone who never worked at a silicon-valley company… but my experience is that traditional companies probably do half of either side. There are exceptions to everything, but I’ve not seen some of these magical work places (as the author puts silicon valley companies), but startups and other companies where I worked did some of these things, but not the same ones.

        1. 6

          I second that. I’ve worked for Silicon Valley companies and various European companies, and I’ve seen a mix of these behaviors in all of them. I think agility and trust in engineering mostly depends on the size/age of the company, or the size of your department within the company (e.g. a “startup” team within a big org).

          1. 2

            I never worked for silicon-valley companies either, but my experience is quite similar to the one in this article. When you are free to find solutions. You find them and you are much more efficient when someone dictates what to do.

          2. 7

            I was expecting this to be a lot more special pleading about how software engineering is so different than other white collar work, and I wasn’t disappointed, but it’s well enough argued that it’s an open question as to whether it’s special pleading or actually just the way more white collar work should be done.

            1. 12

              Yeah, if you talk to people with experience in both, or people in management science, it’s pretty obvious that SEs aren’t different. Most companies just are bad at handling white collar workers.

            2. 4

              Having seen both the SV and traditional sides of the software engineering experience, an SV company can hire great SEs and still self-sabotage by egotistical young founders who think they know better than the experienced SEs they hired because famous-VC gave them an A round, validating their genius.

              1. 2

                Who doesn’t want more autonomy? Most of what he said could be applied to any kind of individual contributor. I think a lot of people like to think that software engineers are special in some way, but we’re really just humans like everyone else.

                1. 2

                  Now add Apple to this model, who work in none of those ways accused of being the “Silicon Valley” ways.

                  1. 2

                    They’re not really a software company though, software is a means to an end to them - just like with “traditional” companies.

                    Their main pillar is hardware and they try to shift to services, and the software they ship on their hardware isn’t great (basically living off the NeXT-inheritance from 20 years ago) and from what can be seen with their services, neither is it great there.

                    1. 3

                      The problem is that there are no true Scotsmen: no company is a software company. Facebook is an ad broker. Netflix is a media channel. Microsoft is a licensing company. Red Hat is a training company. It just happens that they each use software quite a bit in delivering their “true” business, just like Apple.

                      1. 4

                        Yeah, shipping the 2nd most popular desktop, mobile os and web browser is pretty trivial. Any “real” software companies could do it. All the tech has been there for 20 years after all.

                        1. 2

                          iCloud had a rough start (and even more so its predecessors .Mac, MobileMe, etc.) but it seems mostly rock-solid today and has an astronomical amount of traffic. A billion and a half active devices, I believe, with a large proportion using multiple iCloud services all day every day. I’m not saying Apple doesn’t have room for improvements in services, but “Apple is bad at services” is just a decade old meme at this point, IMO.