24 ms·

What Silicon Valley gets about engineers that traditional companies do not

• chmaynard 6y ago
  I have worked in this field since 1980. The first time I was given the title "Software Engineer" was at Apple in 2001. Was I really a trained, licensed engineer in the traditional sense? Of course not. But it sure made me feel flattered and empowered. Silicon Valley HR execs use strategies like this to manipulate their employees, particularly the youngest ones.
  • shrimp_emoji 6y ago
    C'mon, you're too cool for higher pay and worker's rights. :D
    • MattGaiser 6y ago
      Software developers enjoy great pay, great perks, and have plenty of job opportunities if anyone abuses them, in North America at least.
    • esoterica 6y ago
      Why do people keep pretending like Silicon Valley engineers aren’t one of the single highest paid demographics in the entire country?
      • glitchc 6y ago
        Initially this was true, certainly SV would use higher salaries to draw developers and engineers to the valley. But cost of living has exploded since then. A modern developer living in SV does not command a higher standard of living as food and housing costs are significantly higher than most of the rest of the country. A similar trend plays out on the east coast so it’s not just SV. It’s balanced by the CoL adjustment. In short, SV engineers are not better off, and haven’t been for the past decade. This is apparent by the observed exodus in the light of Covid forcing a shift to primarily remote work. Engineers are trying to reclaim their wage advantage by moving to cheaper locations, and companies are fighting back by reducing compensation accordingly.
        • markalexander 6y ago
          Sort of. Often a big chunk of your CoL is going into a massively appreciating asset. People always seem to ignore this when talking about the top n most expensive cities in the world. You can literally sell your apartment and go live in a mansion most other places on the planet when you feel like it.
          • codesnik 6y ago
            hm. do many people in silicon valley buy their apartment or house there these days? Is it even accessible?
            • markalexander 6y ago
              People in general or people in tech? Well what’s the typical mortgage multiple, 6 or 7 times salary? So for the latter, it seems pretty attainable to get an apartment at the lower end of the market to start out on. Correct me if I’m wrong, though.
            • sidibe 6y ago
              Well if you're just renting the CoL difference is nowhere near the salary difference you'd get in other locations/careers.
      • mlthoughts2018 6y ago
        Pay is nowhere remotely close to being proportional to impact on revenue though. Many engineers are much more offended by unmeritocratic pay than by absolute value of pay being low - hence why you can convince amazing engineers to work for peanuts at start-ups. I want the greatest share of the returns of my own labor I can get. If that results in very high salary, great, it’s earned. If I take a risk at a place where that translates to much lower salary, that’s fine too - as long as it’s very objectively meritocratic. If I am making $200k per year as a top, top performer, while my employer is paying far more mediocre performers $175k (perhaps based of geolocation), or where both of us are bringing in ~ millions of revenue, that’s super unacceptable. As time goes on, the surplus of my labor productivity that a big corporate employer can capture beyond my total compensation should be decreasing heavily - and expert software labor is one class that has the negotiation power to actually push that issue. So I’d flip your question on its head. Why do we pretend that rent-seeking executives deserve the surplus revenue generated by rare talented engineers? Why (with complete sincerity) aren’t many, many, many more software engineers paid on the order of what Hollywood actors are making, while executive salaries simply have to come way, way down in these lines of business?
        • courtf 6y ago
          Exactly. The funny thing is the same people making the counter to your argument no doubt don't bat an eye at 8 figure annual salaries for the best sports players. The argument is the same in either case.
        • dilyevsky 6y ago
          Depending on your budget the min SAG rate can be anywhere from ~100-1000/day so many sw engineers in fact make much more than most actors
          • mlthoughts2018 6y ago
            I’m exclusively drawing the comparison with high demand actors / athletes. Perhaps athletes has the better clarity - many NBA players are paid more than their head coach, and even those paid less are still paid much more competitively to their revenue contribution than engineers by comparison.
      • walshemj 6y ago
        Compared to other professions? maybe SV is just treating "Engineers" more like other older professions and has less of the class distinctions you see in the UK for example.
• deleted 6y ago
  [deleted]
• dilyevsky 6y ago
  Is pay scale on this chart logarithmic?
  • lawrenceyan 6y ago
    Good eye.
• draw_down 6y ago
  I think the first two are complicated by the eventual (even if slow) inclusion of layers of process, sign offs, and approvals required for a given piece of functionality to go live. You start off with engineers having autonomy then something bad happens one day, so you introduce an approval process to make sure that doesn’t happen again. Then one day someone notices visual/UX inconsistencies between products so a process is introduced to ensure consistency. Then someone notices the tone of the copy is not what they think it should be so it is decreed that all copy should go through the writing team. Etc. Eventually shipping becomes as much about fighting through these thickets of bureaucracy as about improving things for users or, you know, writing code. You end up with a situation where someone who has never heard of you or your stupid project asking you fundamental questions about its existence which have already been answered at the outset of the project... but why should they care? You answer to them. Their job is not to help you make users’ lives better. Their job is to stop peons like you from screwing up.
• Smaug123 6y ago
  A nontrivial part of this blog post is essentially saying "Silicon Valley practices leader-leader management more than most industries", in the sense of David Marquet's "Turn The Ship Around!". Points 1, 2, and 5 are precisely aspects of leader-leader management.
• opportune 6y ago
  I have noticed that as SV companies get larger they tend to adopt the more "old school" approach. Not that it's a binary - it's a spectrum, and depending on management chain/how an org runs, people can have different experiences. I think it's caused by 1. When you have very deep management chains you start to have lots of people with opinions on what you should do, how you should do it, who you should do it with. Even if on average most of them aren't micromanagers, it only takes a few. 2. As you grow you start pulling in more people with experience outside of SV who bring in culture with them. Note that "SV" is also not monolithic here. Companies like Microsoft (ok, technically not SV) are farther to the "traditional" side of the spectrum. 3. "Horizontals"
  • erikerikson 6y ago
    Perhaps: as size increases, relationships don't scale and mechanisms of control and coordination become more shallow.
  • Smaug123 6y ago
    Related: the "Moral Maze" of Robert Jackall fame, recently "popularised" (if Less Wrong can be considered "popular") by Zvi Mowshowitz (https://thezvi.wordpress.com/2020/05/23/mazes-sequence-summary/ https://thezvi.wordpress.com/2020/05/23/mazes-sequence-summa...).
  • plorkyeran 6y ago
    The "SV style" runs into scaling problems. Engineers making product decisions requires that they have a solid grasp on everything the business cares about, which gets harder as the business gets bigger. Direct engineer -> engineer communication between teams is O(N^2) to organize things between N engineers. As you grow I think reducing engineer autonomy is unavoidable, and the goal is merely to stick to reducing it and not eliminating it.
    • chris11 6y ago
      It's not the only solution for building products. But you can still maintain dev autonomy. Instead of having senior team-members break apart work into story-sized pieces a system can be broken apart into smaller pieces. Devs can still be working towards a specific business goal, but they can own a larger portion of their work, and they can work with longer deadlines. Also, I think dealing with those large scale issues is what separates a staff/principal dev from a senior dev.
• libraryofbabel 6y ago
  I agree with a lot of this article and it reflects the culture at the kind of places I like to work. But - I'm curious what costs folks have seen in making this switch to giving engineers more autonomy and expecting them to be problem solvers for the wider business rather than code-factory workers. My hunch is that it's usually worth it - but what are the risks? It's easy to mention a couple of anecdotes about some engineer who made an improvement or feature that represented millions of dollars for the company bottom line. But what about people going down strange rabbit holes, engaging in resume-driven development or following the allure of cool tech that isn't really needed for the use case (e.g. "let's use Cassandra for this!"), Not Invented Here syndrome, premature optimization, spinning up unnecessary microservices because that's the way to get promoted, building a fancy internal system that internal stakeholders don't actually need or want, etc. It's really really hard to simultaneously see the business big picture and also be down in the technical details, and very easy for engineers to fall victim to the Dunning-Kruger effect and go off in the wrong direction. Perhaps the few people who are able to do this well are able to compensate for all the waste, but I don't think we can assume that it leads to good results for the business in every case.
  • coderintherye 6y ago
    What you noted of engineers going down rabbit holes of cool tech for cool tech sake is certainly an issue, which is why management must help keep in mind that the autonomy is given with a goal of "solve business problems." It requires a bit of careful management but it usually becomes clear over time who enjoys playing with new tech for the sake of new tech and who does it to try to find a solution to a problem. The former group can be put into a research team if the company is large enough otherwise they are likely not a good fit. As for risks, the biggest problem I've seen from this cultural change in a company is the disharmony it creates between the people who enjoy task-driven work and just working their 9-5 vs. the people who enjoy creative problem solving. It usually works better to have that culture from the start and also why it is so hard to change a company's culture to this way of working because it disrupts a way being that almost everyone in the company is used to.
• quicklime 6y ago
  I've worked at both SV and traditional companies, and I feel like this very closely matches my experience. One of the things I worry about is that even at companies that are doing "Agile transformations" and adopting methodologies like Scrum, in practice have "Product Owners" who are there to give instructions via Jira tickets. Other roles like "Business Analysts" are there to ensure that lowly developers never have to worry about things like understanding the business themselves. So I get funny looks when I suggest that engineers should go talk to people in the business, and write design docs. Silicon Valley engineering practices can look very non-Agile to a lot people from traditional companies that are doing Agile.
  • opportune 6y ago
    Yes! The proliferation and role of "business people" in traditional companies is IMO their defining characteristic. It shows how much or how little a business trusts engineers (and also engineer's "status" within the company, e.g. are they respected and valued or treated as a disposable resource) to run the business as general problem solvers. The ironic thing about Agile is that it has a cottage industry of "scrum consultants", "scrum masters", project owners, etc. which advocate ostensibly for letting developers self-organize but which also has a vested interest for career and self-preservation reasons in inserting itself above software engineers in the decision making process.
    • courtf 6y ago
      I've long imagined a position just above the scrum masters: the scrum lord. I see this position as a critical component of any agile strategy that seeks to maximize scrum master productivity, while still allowing scrum masters all the autonomy they need for their day-to-day duties.
      • loosetypes 6y ago
        I appreciate your sense of humor
      • klipt 6y ago
• itronitron 6y ago
  Interesting, what the author describes has been the norm at every company I have worked at, and I've never worked for an SV company.
  • astura 6y ago
    Same.
• bdcravens 6y ago
  In extremely small companies that are very technology driven (yet often pretty traditional in terms of the problem they are solving) you can find much of the same. (I work for such a company)
• peter_d_sherman 6y ago
  >""SV-like" companies think of software engineers as the people best suited to solve the problems that the organization has. They hire not only for technical skills but communication and problem-solving ability. Their thinking is a bit more like this: Software engineers are among the highest-paid people in our company. This is because they can bring some of the highest leverage through coding and problem solving. We want to expose them to the business, so while they are doing their "normal" work, they can also find more impactful opportunities for the business."
• jedberg 6y ago
  The best way to tell if a company values engineers is to ask which cost center they are in. Is it IT? Then they will treat you like a cog and consider you just a cost to the company. Is it Product? Then they will consider you valuable and critical to the company's success.
  • mycall 6y ago
    I'm lucky enough to make products for our company while being in IT, so it is a hybrid. With data driven decisions becoming more important to businesses these days, I see IT's transitional role as the cost side (vs. profit side) starting to change.
  • qppo 6y ago
    A question I like for non-tech businesses is: "do you see this as a software business or transitioning to become one?" Because these days every business has to be investing into software products, and the ones that don't recognize that the software is key to all their products are the ones that are dead folks walking. They're also great targets for SaaS consultant vultures.
    • arexxbifs 6y ago
      I dearly hope my cast iron skillet will never require a firmware upgrade.
      • jedberg 6y ago
        A company that makes cast iron skillets can still have software as a core part of their business. Logistics, monitoring the manufacturing process, forecasting demand. All of these things can be software that is core to business. Or even more important, having a useful website for selling their products.
        • bigiain 6y ago
          Sure, but Le Creuset will never describe themselves as "a software business"... (And if they did, I'd immediately be looking for a different cookware supplier.)
• Animats 6y ago
  One could have said that about electricians a century ago. "Men and Volts", a history of the first 50 years of the General Electric Company, makes that clear.
• lukashrb 6y ago
  Are there any German companies that work like this?
  • ju-st 6y ago
    I'm working in a kind of internal startup of a big German company and we operate "SV-like" as described in the article. My job title is Software Developer but most of the time I'm convincing other developer teams to share code to speed up development, inventing simple solutions to complicated sounding wishes of product management, helping project management to prioritize low effort features and trying to find out what the customers really need. The only problem is that there is no leverage or scale because the software is coupled to physical goods, which means no big profits to pay above average salary and no career progression. And that is the point where I don't agree with the article. I don't see the correlation between salary and autonomy.
  • MauranKilom 6y ago
    Yes, there are. By density you'll probably find most of them in Munich or Berlin. Some fields are of course more amenable to one or the other style (e.g. automotive middleware is not going to be done SV-like), and I wouldn't have high hopes with large, old, traditionally non-software companies. I would look at startups/small/medium companies where the founder(s) come from an engineering background.
• mindtricks 6y ago
  From personal experience on the product side, if you want to be more involved with the business, I'd recommend you work on two things from this article. First, curiosity is an absolutely must have. Without it, you'll not be able to truly learn what a customer is looking for. Second, demonstrate you can "talk with another engineer" without manager facilitation. It's a signal of ownership that I guarantee people will notice.
  • courtf 6y ago
    I've done both of these my entire career and no one ever cared, mostly because it's not remarkable. Do you work somewhere that has a large management apparatus? These behaviors are sort of bare minimum expectation in smaller companies. It sounds like you perceived developers as a group to be mostly anti-social curmudgeons.
    • mindtricks 6y ago
      I've worked in large and small, with good and bad cultures. And to be clear, that is not my view of developers. I point it out because I agree with the author of the article that there are differences in companies. I'm sorry that those traits did not get you where you wanted, but they are not bare minimum in a lot of companies. I've walked engineers from their seats over to the counterpart's seat and have had others who do not go outside of their area due to an inaccurate belief that it's not what their manager wanted.
• hummel 6y ago
  Money
• realjohng 6y ago
  This is probably because Silicon valley companies have tech cofounders and first early hires are also engineers who become involved in important decision making beyond engineering, like product and even strategy. This creates a culture of empowering engineers. On the contrary, companies where tech is an afterthought-- well why would you empower your engineers to make business critical decisions if you're running a hospital or a sports team.
• mlinksva 6y ago
  These things (1. autonomy for software engineers; 2. curious problem solvers, not mindless resources; 3. internal data, code, and documentation transparency; 4. exposure to the business and to business metrics; 5. engineer-to-engineer comms over triangle-communication; 6. investing in a less frustrating developer experience; 7. higher leverage --> higher {autonomy, pay}; the "biggest" is a repeat of 2) seem like plausible differences between "SV" and "traditional" companies. I wonder if there's data (survey? perhaps correlated with compensation?) to back up and establish magnitude and trend/diffusion or refute any or all? Also would be interesting to look at those characteristics for non-employer open source projects and government. There would surely be lots of variation across projects and departments/governments, as there would be across companies, though I'd guess for non-employer open source 1, 2, 3, 5 would be very high, 4, 6, 7 unclear or lacking, and for government possibly even lower than traditional companies across the board? Just speculating, again, curious about data, or more speculation. :)
• mettamage 6y ago
  What European companies are like this? I've been trying to apply for ages at US companies, for the reasons such as this. Reading HN for 6 years and being US-centered in general (thanks to tech) made me want to work like this. I've noticed that at European organizations people indeed try to pin me in a box, and then I can't thrive when I'm working there.
  • flibble 6y ago
    Flipdish (HQ in Ireland with a distributed tech team) is one. Full disclosure - I’m the technical co-founder.
  • igeligel_dev 6y ago
    FAANG can be found in Europe. And I believe companies like Spotify, Klarna, Skyscanner, Uber (Amsterdam), takeaway.com are also working like this.
  • kabes 6y ago
    For what it's worth. I worked at multiple European tech companies and moved to SF a couple of years back to work at a SV startup, and later a FAANG and this post heavily romanticizes silicon valley companies. Except for the bigger pay, I found them to be not that different. I'm now working back in europe and really don't miss SF/SV
  • dkdbejwi383 6y ago
    Another comment mentioned that a good indicator is whether or not software is a company's raison d'être or not. Compared with trad companies like old-school banks, B&M retailers, etc. If the entire value of the company is and always has been their software, it's likely they value engineers more.
• KaiserPro 6y ago
  The article uses JIRA is a touchstone that seems to equate to no autonomy. I think this is wrong. I have worked at a good number of places, including a FAAMG. The freedom that was given to me directly correlates to company size & seniority. When I was younger, I didn't get much autonomy, why? because I was a naive arrogant prick. I would dream up solutions to problems that didn't exist. I would make existing problems worse by trying out new things. When a company gets larger, it will bump into problems, missed features, deadlines or massive bugs. New procedures will get be implemented to make sure that those don't happen again. Ticketing is a good thing, so long as its developer lead. It allows delegation of tasks, and simple tracking of state. Its an artform that should be taught. I was at a start up for two years that was bought out by a FAAMG. We were working on cutting edge computer vision research. We had a tight process, tracked with ticketing. We had complete autonomy. We were chucked into SV "culture" only to find that is somehow managed to make cutting edge research both more chaotic and boring. Ironically I have much less freedom than I did when I worked at a large financial newspaper.
  • throwawaybbqed 6y ago
    Can you please describe how you had a Jira/ticket system that you felt gave you autonomy? Very curious how it could be implemented in a research setting.
    • q845712 6y ago
      not the GP, but I've had multiple times in my career when I and the team I was on were given pretty high-level problems to solve and left alone to solve them. The request to use JIRA was basically our managers and the product people wanting some vague reassurance that progress was being made, but nobody was concerned with the details of the tickets, etc. This included early-phase 'R&D' work on a medical device. Of course in that setting once the device was on a release cadence, if we were contributing to the 1.x line of the release we had a lot more overhead :). However even then you could always file yourself a more R&D flavor ticket, as long as it was going to the long-term branch and not to the release branch... What it came down to, per the article, was that everyone in the co. respected that the engineering team was capable of delivering results and solving problems. But i think per your question about JIRA, it gives you autonomy if: - anyone on the team can add a ticket - the team is trusted to make small changes in scope or spec to tickets in response to things they encounter as they work - there is little to no ceremony around accepting tickets as done - the team is trusted to check their own work first, and then collaborate with QA / stakeholders / etc. on releases
• dhenneberger 6y ago
  SV-like companies try to hire the best of the best so it makes sense to that they would give them more greater autonomy and more responsibilities. These observations may not help a 'traditional' company become better.
• abalashov 6y ago
  It all depends on who you're hiring and what you're building. Definitely applicable to startups and innovators coming up from the bottom. But, there are absolutely companies maintaining low-growth Clunky Java Accounting Application for Insurance Companies #574 for whom this approach is contraindicated. Those companies can hire relatively entry-level, average graduates, at commensurate salaries, and assign them highly structured JIRA tickets. Would they get better talent if their fronds tended more toward the SV model of compensation and autonomy described in the article? Absolutely. But in terms of marginal productivity or ROI, it's far from clear that it makes much of a difference to the financial performance of Cluky Java Accounting Application for Insurance Companies #574. That means massively overpaying for skills, or skill levels, that aren't really needed, or aren't needed enough to matter. No, it's not the kind of software development any of us want to do, and I think the audience for this post are for the most part in no danger of having to. But I think it's important to be honest about the fact that this sort of dimly-lit, cubicle-dwelling sweatshop software work _is_ a high percentage of software development occurring on the planet. For that type of company, following the "SV" philosophy would arguably constitute a dereliction of fiduciary duty. My view may be somewhat coloured by my exposure to medium to enterprise-sized companies in the telecom world, where a lot of the work is tedious, unimaginative and formulaic, using unexciting but established technology stacks, and so forth. But it still needs to be done, and there are companies who darken the skies with people to do it. Lastly, I incorporate by reference everything that has been said elsewhere in this thread about the nature of large organisations and the poor scalability of engineering-led company process. Most software work, by volume, doesn't consist of skunkworks innovation or the development of something new. Most software work is incremental, in many cases strictly maintenance mode, and caters to many stakeholders. Large organisations and big capital serve an entirely different purpose that is realised at points further along the technology and product lifecycle. In this comment, I merely chose to focus on (1) the problems of empowering "average" talent this way and (2) the poor prospectus for doing so.
  • jtdev 6y ago
    Those companies will die...
    • 6y ago
• ng12 6y ago
  Interestingly enough most of this applies to one of the SF tech darlings I worked for when it was growing between 200-1,000 people. Every day I'd get either a pile of Jira tickets or a PDF full of mocks to build. Several projects I worked on were canned at the last minute by the "product" clique. I don't think it's about SV companies against traditional companies, but more about companies that intrinsically value technology versus those that do not.
• deleted 6y ago
  [deleted]
• lxe 6y ago
  Software engineers can't always be the best or effective at solving problems that require specialized non-software engineering knowledge. In an SV-style company that develops a SaaS product, engineers can make all sorts of decisions, since they are solving a problem they are intimately familiar with. What about other industries that require specialized knowledge or regulatory bureaucracy, like finances or healthcare?
  • tester756 6y ago
    this, I work with mid-size ERPs that deal with some law, some tax, invoices and all this shit that ERPs deal with and I wouldnt trust myself to commit any "business logic" decision in that environment there's so much stuff happening
    • jtdev 6y ago
      In such an environment engineers should be working closely with these subject matter experts... you don’t just put fear in the engineering culture and throw layers of bureaucracy at the engineers.
  • BigJono 6y ago
    You just have other technical roles to handle those areas that are treated the same as the software engineers. Or "technical" roles in the case of bureaucracy (once it gets complicated enough to need entire people to manage it).
• 6510 6y ago
  Nice article, short and to the point. I hear a more general version a bit like it: There are 2 types of employees Saint Bernard's and Hyenas. The Saint Bernard needs to be told what to do all the time. Everything needs to be planned and organized for him. If he doesn't have a pen he cant write. If there is one pen in the building all the hyenas can write. If you chose the Saint Bernard's, as a manager your job is to make sure all the Saint Bernard's stay productive. If you chose the hyena your job is watching them like a hawk because they might run away and take your company (or chunks of it) with them. Early on you should work with nothing but hyenas but at some point they should all be replaced with Saint Bernard's. During the transition you have to elaborately compensate the hyenas to keep them in line.
  • 6510 6y ago
    Clearly old-world type of reasoning.
• u678u 6y ago
  meh I feel like SV companies are great to work at the last 10-15 years because they're making loads of money in a growing area. Oil, Pharma, Banking have all had great times when employees there had lots of autonomy and made bank. True with SV Engineers are the main type of employee so probably do better than at firms where engineers are helping other divisions make money.
• deleted 6y ago
  [deleted]
• 11thEarlOfMar 6y ago
  From my experience, the triangle communication is great within the engineering department. It can cause big problems if persons from outside engineering wander in and communicate with an engineer. Typically, this is a problem when the engineer happens to want to be helpful and winds up spending time on a matter unrelated to the task they have committed to delivering. We've seen hours, days and even weeks of time consumed by such side-tracking. We've had to smack it down pretty hard in a couple of cases, and pretty strictly enforce the triangle when communicating with non-engineering departments.
  • ramzyo 6y ago
    We've run into the same problem. What's made this a particularly hard problem for us to address is that the intentions of involved parties are usually aligned with the best interests of the business in the short term despite being misaligned (and detrimental) over the medium and long term. In discussion it's clear that both parties are doing what they believe is right for the company, but their level and responsibilities might inadvertently encourage them to optimize for the short term. The ensuing conversation is usually a tight rope walk between trying to get both parties to understand short term vs long term outcomes and consequences while encouraging them to continue to execute on what they believe is right for the company. What's worked for us is to not restrict communication, but to hold our engineers accountable to what they say they'll get done and when. If something slips and it's not for a technical or personal reason (i.e. some risk materializing or needing to take unplanned time off), but rather because someone floated in and asked for something that wasn't scoped in, that comes up in a review and reflects poorly on the engineer and the asking party. On the other hand, if the engineer is able to get all of their scoped work done and also get the unplanned work done, that reflects well on the engineer and potentially the asking party. In our experience, approaching these situations in this way also has the benefit of preserving and encouraging individual autonomy.
• _antix 6y ago
  This article hit me hard. I work in a non Silicon Valley-like company. I became a developer because I thought I love coding. But I found out that, in fact, I love problem solving. Tightly defined Scrum tasks make me sad and I would love to have more autonomy.
  • MauranKilom 6y ago
    I strongly encourage you to go out and find such a job then! You certainly don't have to move to SV to find one, and we spend too much of our lives at work to forego the opportunity of having work we're passionate about.
  • Osiris 6y ago
    I'm the same way. I spend a good amount of my time being pulled into production issues or debugging a particularly difficult issue with the product. In both of those cases, the "code" changes often take only a few minutes, the problem solving can take hours. I get a lot of satisfaction from that. Of course that means that as a team lead/manager, I have to have a lot of self discipline to allow my team members to do the same and not try to solve every problem.
• sidlls 6y ago
  This article...exaggerates...the difference between SV and 'not SV' companies. A lot, actually. I've worked at a few places in SV, and several outside of SV, too. For the most part it's similar: use the existing infrastructure and implement a service, front-end, whatever, within that, to solve a business need. Very little in the way of novel or new solutions to genuinely new problems is required. The difference is mainly in pay and, to a much lesser degree, respect. Regarding autonomy--usually a high degree of autonomy is found in two places: 1) at larger companies, a very senior, trusted individual who has proven himself to be competent and capable of making big decisions; 2) at startups, a very junior individual scratching an itch and loading up on technical debt. For the most part solutions are prescribed or narrowly constrained--99.999% of engineers are going to use the same services architecture, libraries, and compute infra every other engineer is using. Regarding curiosity and problem solving: I guess I have a different definition of "curiosity" and "problem solving." What I've seen in this industry ain't either, generally: it's mainly driven by personalities at the individual or corporate level, e.g., "everyone" doing what Google does or following Fowler, and empirically unsupported anecdotes/fads (e.g. TDD, agile, etc.). The vast majority of engineering work in any established company is to use an existing tool or infra to implement a generally well-defined need. Most of the interesting details are already solved, and the implementation work, while also interesting, isn't really solving the problem, per se.
• juancn 6y ago
  The engineering job (regardless of specific engineering discipline) is essentially solving business problems using applied science. That's it. If you don't let your engineers understand the business problem they're supposed to solve, you're wasting valuable resources.
• avivo 6y ago
  This mostly matches my experience...but I wonder if it ignores significant costs. In particular, how this impact long term maintenance vs. the desire to build new interesting things? (e.g., see https://themaintainers.org/ https://themaintainers.org/). And what about people who just enjoy the act of coding — of wizzing through tickets and gathering points? For another potential cost, take the example given of the Like button in the piece. I'd be curious what Justin Rosenstein now thinks of the example of the Like button. The author says "The business impact of this button is well in the billions: allowing Facebook to (re-) target ads, and "track" users outside of the Facebook site. [...] Everyone is better off for it: the people with the idea and the business." Does everyone here include the users and world? Perhaps if we had better metrics, this SV would work for everything. But in the current world, with profit, data, and growth metrics being incentivized, it may have real societal costs.
  • pietrovismara 6y ago
    > And what about people who just enjoy the act of coding — of wizzing through tickets and gathering points? That's not coding. Those people enjoy closing tickets and gathering points. That's fine, but they should try videogames, it's a similar experience but 100x more entertaining. Shame it generally doesn't pay.
• gwbas1c 6y ago
  I once had a rather prestigious developer position in a Silicon Valley company. The "approachability" was a double edged sword. One problem I fought was that a lot of people expected handholding from me, or wanted me in their meeting to "feel important." There really is value to having your manager act as a gatekeeper. Another problem I had was that less ambitious people in other departments (support, qa,) would throw their work over the wall to me. I eventually had to get involved with triage to train the other managers to push back on this.
  • sudeepj 6y ago
    > would throw their work over the wall to me I can relate to this. One way to look at this is that dev-team is where majority of IP is created and not in teams like support/qa/docs/PMs. Over the period of time, they are also the reservoir of domain knowledge. This often results into nuisances like: 1. Instead of reading product docs people will ask questions directly over slack (e.g Do we support Windows 2008? Do we have feature X?) 2. Adding dev team in a slack channels in which sales can directly ask questions which ideally should be answered by Product Managers.
  • shaneofalltrad 6y ago
    > would throw their work over the wall to me For myself as QA, I would see the throwing the opposite direction. Devs started having me close out unit tests, giving incomplete work hoping I find their issues, gathering requirements to know what to test etc.
    • wolco5 6y ago
      The requirements should be coming from elsewhere and hopefully you are involved at the start of the project. Hopefully you should be catching all issues regardless and the increase catches look good to your matrix.
  • mepiethree 6y ago
    yes! I'm more junior than you are, but once I got a rep as a gung ho problem solver, I started getting approached by random sales associates asking me to implement features. I would usually do it out of love for the business, even if it meant I was staying up until 2am hacking shit together. But then I burned out. My quality of life improved significantly when I started being strict about people communicating with me only through my manager or product manager.
• lifeisstillgood 6y ago
  I have occsssionally espoused "metric-driven-development" where a metric is defined and measured and then a release is tagged with that metric - and over a period the release is seen as a success or fail if it moves the metric. This keeps everything focused on the important usually externally facing issues.
• WhitneyLand 6y ago
  So then what... Yes it’s been true and knowable for many years now but, not many orgs change to a highly leveraged style. So then how to succeed at it? Hard to address in a comment, easier to check for some big red flags. What percentage of people involved have lived it before? If 0%, then I’m not sure it’s even possible. Similar to trying copy Disneyland. You could read a novel describing it but if no one‘s actually been there it’ll be a rough ride. What’s the plan for anyone leading people? Some people freak out when people are newly crossing the triangle below them, more so if they don’t know why it’s important or how to adapt to it. What are the checks to make sure your org is not just choosing a fancy name (I.e. digital transformation) and merely mapping old processes back onto it but with more overhead? It seems like maybe that’s the mistake is to think about this as a process difference when really it’s a systemic and cultural difference. Take the example of a stakeholder talking to a new hire. If stakeholders do it to ‘do the new process’ it’s not there yet. If they do it reflexively because they expect they may get useful feedback, then that’s a good sign.
• Osiris 6y ago
  The big take away for me here is: does the company see engineers as a "cost center" or a "profit center"? You can almost directly correlate the "traditional" approach to seeing engineering as a cost center, while startups/S.V. style companies see engineering as a profit center, and they treat their employees accordingly.
  • bumby 6y ago
    I think part of this is because in SV a software engineer is closer to the value creation of the end product. In a traditional company, the software developers are more of an enabling function than a primary one
• a-dub 6y ago
  it's funny, as the faang interview process, as i know it, does not select for the hybrid dev/product skillset the OP describes. in fact, it shies away from it about as far as you can get, instead focusing on beloved algorithmic problem solving, which i guess is a good fit for standardized testing and leveling, but will tell you nothing about broad skills in both software development and product design/management as described here.
  • pm90 6y ago
    For senior engineering roles, faangs do have design related interview component. Usually, there will be 4 hour long interviews. With new grads, all of them will be algorithmic problem solving while for senior engineers there will be 3 algorithmic and one design session.
  • somurzakov 6y ago
    algorithmic problem solving is very close to IOI/ACM ICPC type problems, which test on combination of knowledge of data structures+algorithms and creative ability to combine both to create own algorithms while being under interview anxiety+time limti stress. Quite essential in everything internet-scale and filters top percentile candidates pretty well. THis process is not required for your average company where IT is a cost center and CRUD-type apps generator.
    • a-dub 6y ago
      yeah, yeah. programming contest problems make better programmers, sure. OP is arguing that developers should be more involved in product design though. although in a large enough shop that will likely cap out with a single service...
• syntaxing 6y ago
  I think one of the most interesting thing about working for a tech company is how transparent everything is and how much more power engineers have in the decision process as mentioned in the article. There’s a higher tendency that transition companies are purely revenue focused (for reasonable reasons). When that happens, the engineers’ customer is sales. When a company is focused on the idea (which makes money too), the engineers’ customer is the product.
• hikerclimb 6y ago
  Then why need a manager?
• hikerclimb 6y ago
  Then what’s the point of a manager?
• antipaul 6y ago
  Sounds very true to me. I'd summarize the problem as lack of real engineering leaders. It's as if programming/engineering is looked down on or not taken seriously enough. - Biotech (in Silicon Valley to boot!)
• netc 6y ago
  Recently I had a discussion about an SV company with a friend in Texas. I mentioned to him, the company X is going to do great as they hire very good engineers. His question was - "what does that have to do good engineers?" Go figure ...
• jiveturkey 6y ago
  > As a software engineer, pleasant places to work at is where you are a problem solver, not a factory worker. It’s not so cut and dried as that, now is it. The pressure from the expectation and need to bring leveraged value can be detrimental. sometimes, and highly dependent on the person, this is life destroying. factory work is fine for most people, i believe. even engineers.
• austincheney 6y ago
  I read the article and the comparison is improper. It is a narrow slice of a larger problem that is impossible to see if your processional experience is limited to writing software. What the article compares: SVC-like vs traditional can be more accurately described as non-software employment versus software employment. It isn't that silicon valley has some magical solution that nobody else has, but instead is incentivized to leverage expectations common to all other industries. Again, this is impossible to see if your experience is limited to writing/managing software, but is clear as day otherwise. The key reason why this is different for other industries is that the expectations are higher for employees where the investment per employee is higher. This is even true of lower paid and lower educated professions like truck driver or construction equipment operator compared to software engineer. In all other industries there exists some form of licensing or certification followed by some form of formal training such as a broker/agent relationship and then there is continuing education or periodic re-certification. These processes exist because of regulation. They take time and money away from the profession, which is an investment into each employee. With that level of expense more is expected in return by the employer. The software profession has none of that. There is no investment in a software employee aside from keeping them happy enough to retain them. As a result its hard to think anything more of them than as a tool, like a janitor. This where you get the churn the article accurately describes as death by JIRA. SVC-like companies invest more in employees with higher salaries and thus expect more in return, which is not entirely the same as a formal professional process, but is a step in solving for this gap. As for plain as day examples look at the common expectations for engineers at engineering firms, lawyers at law firms, and even truck drivers and police officers. There are all kinds of administrative and documentation expectations that are impossible to find in most software developers. Comparatively most software developers at the traditional companies seem largely illiterate. As an example most of these guys are scared to death of writing original software without a billion packages from NPM or Maven and are almost utterly incapable of writing formal documentation.
• achow 6y ago
  No focus on a structured product definition and leaving it to engineers to 'figure it out' does not bode well for the end user or business itself. This is a real experience in a FAANG company - we were developing a new product in enterprise space targeted to small enterprise IT admins who may not be highly trained or experienced. One of tiny feature was the ability to download and self manage security certificates (upload again if any issue with security), it took literally weeks to define this feature by the engg and UX team. From tiny things like how to name the downloaded security files.. should we have the app name in the file or not - otherwise how would IT admin locate the file when they search, should file have time stamp because later we discovered that these d**n things expire, is there a 'standard' to begin with that defines the naming convention of these things, and so on.. All this because? The detailed level of spec is never written by product managers. Which I think is a very foolish culture, particularly in enterprise space.
  • ramzyo 6y ago
    This is an informative counter-example to those presented in the article. Thank you for sharing.
  • billllll 6y ago
    I think there is certainly a middle ground between "engineers do all the decision making" and "engineers do none of the decision making." I'm not sure the author was advocating the former. Rather, I think the author was saying that the possibility to influence the decision making at a fundamental level is what makes the SV-like companies great. This follows my experience. Even at a FAANG, product managers aren't going to get every detail and edge cases are going to pop-up, so requirements are going to come from a back-and-forth between product and eng throughout the process. That back-and-forth is the key, not expecting engineers to figure out all the requirements, nor from product managers either.
  • jayd16 6y ago
    This actually just sounds like a successful example of agile design... A subtlety complex feature took a couple sprints to iterate on stakeholder feedback and fully define the business need. The story doesn't seem that bad to me.
• poof_he_is_gone 6y ago
  I think this completely leaves out how user research and interface design influence the prioritization, process, and delivery of work done by the development team.
  • rtlfe 6y ago
    I think it's pretty similar. Like are UX and Eng working together to solve problems? Or is some VP telling UX what to design then telling Eng to implement the design.
• blago 6y ago
  I wonder how much of this is actually determined by the organization size and business complexity rather than the company pedigree. In my experience, things like autonomy, decision making, understanding the business, and communication style seem to evolve towards the more "traditional" model as the business grows.
• deleted 6y ago
  [deleted]
• ojbyrne 6y ago
  In my experience in the traditional companies none of this applies to “engineers,” it only applies to “software engineers,” mostly because they’re called “programmers” and are basically not considered “professionals.”
• qPM9l3XJrF 6y ago
  I suspect another important part of the story here is that SV companies are more selective in their hiring. Part of the reason SV engineers use their extra freedom well is because they're better at what they do.
  • deleted 6y ago
    [deleted]
• noipv4 6y ago
  Europe is horrible. Idiots at a biology lab that I had the misfortune of working for a while categorized Bioinformatics devs and analysts at the same level as technicians.
• dependsontheq 6y ago
  This is a good article but there is a causality problem. I know a lot of pure software companies in the EU that work like that. If software is your core business, developers are in the loop at every decision, if your core business is building power plants...they are not. Now the Marc Andressen argument might be that software eats the world and everybody should run their business like this, and that might actually be true or not. Beside this product/core relationship problem, I see one other issue and that are margins, many SV companies are comparatively young and are in new markets with high margins (or ridiculously high funding) these high margins change their way of doing business.
  • bennyelv 6y ago
    I think funding and margins are the thing that are actually causal here: when you're swimming in funds, can afford to hire whoever you like to do whatever you like and you don't need to be turning a profit for at least 5 years, the organisation can be run very differently to one in which quarter to quarter cashflow really matters and there are margins to think about. Funnily enough I work at a software company which is bootstrapped and where cashflow matters, I'd love to run things like a fully funded SV startup but I can't. We just can't afford it.
  • koushikn 6y ago
    Good point on having developers in loop in a software business. Tesla might be a counter example, where it is often touted to be run like a "tech" company. Are developers in loop in the design of non-software stuff? (is chassis design an example? or maybe not?) The other point on triangular communication with middle managers I think is known problem that Musk has publicly spoken about..
  • tsss 6y ago
    My problem with non-software companies is that they don't treat programmers as equals. To them they will always be "code monkeys" and below the mechanical or electrical engineers. These companies are led by people who think all programmers are stereotypical "nerds" and try to create software departments according to the script of The Big Bang Theory. Just look at this crap I was sent by a recruiter: https://www.mercedes-benz.io/ https://www.mercedes-benz.io/ It's chock full of buzz words and infantilizing language. I don't want to "impact", "move the world" or whatever bullshit the marketing department can pull out its ass. I want good pay, good work-life balance and I want to be treated as a professional.
• phendrenad2 6y ago
  Having work at both styles of companies, in my opinion you really want a mix of both. Top-down decision-making is great! It allows your engineers to be engineers, cranking out good code and not "thinking up the stack" and worrying about the business logic. On the other hand, when engineers see a problem area, or see a feature that could be implemented in another way, you absolutely must stop everything and listen to them. This is a rare occurrence and they usually know what they're talking about.
  • koonsolo 6y ago
    If your engineers are not involved on the business side, they basically have no clue about who the customer is, how the user use the software, what problems they bump into etc. In the bigger companies I worked, engineers never even seen a customer or user. A vision needs to flow top-down, but if you want your engineers to make helpful suggestions, they need to be involved on the business and customer side from day 1.
• red_admiral 6y ago
  There is a second kind of leverage that startups in particular can get out of their developers: expecting them to live for the job. The choice between a company where (a) you work on assigned tickets, but standard business hours and weekends off and X days of guaranteed holiday per year versus (b) a high autonomy, high pay but if the company needs you to pull a 90-hour week then you do it without asking - it's a tradeoff. Whether you get to write your own JIRA tickets is just one of many dimensions here. One of those two options is not compatible, for example, with having responsibilities outside of work such as childcare.
• zuhayeer 6y ago
  Autonomy is certainly a huge factor. Providing engineers with the tools and compensation they deserve is how you set them up for success. If they have to think about being underpaid or potentially having higher outcomes elsewhere, that’s mindshare / allegiance you’re losing out on as a company. Part of the reason why comp packages for senior level roles are so high especially in stock, see https://levels.fyi https://levels.fyi
• jrcplus 6y ago
  I was at Apple during the golden SJ era and it was like this. I remember asking my manager (in my first year or so, fresh out of school) about something and he replied "That's what we're paying you for!" I was at Skype during the eBay years and it was similar. Lots of autonomy. Then Skype got sold, Silverlake instituted Scrum training for everyone, and well, look what happened. Product owners took over; the engineers became Jira-ticket minions. That said, I do understand the problem with giving engineers too much freedom, if there's not enough maturity on the business side. I've been at places like that, too. Engineers gone wild. Just burning money. I see too many startups adopting Agile/Scrum for lack of a better clue on how to run software development. These days I refer people to Basecamp's Shape Up for "just enough" structure.
  • rorykoehler 6y ago
    We have product and tech roles in our company. Product always goes to tech for design and implementation advice. This is taken care of during sprint planning. I see product getting a lot of hate from engineering types recently. It just smacks of myopia. Engineers are being well paid because the company makes good money from the whole solution not just the technical implementation. What an engineer thinks is important may not be that important from the business perspective which is where product comes in. If product wants to do something that will cause technical problems that's where engineering comes in. It's a team effort. As an analogy no soccer team fields only goalkeepers or only strikers etc.
• ChrisRR 6y ago
  I don't know if this is just an american thing, because this sounds like any company I've worked at in the UK
• gcatalfamo 6y ago
  The article forgets one detail though: while attributing much of the fault in the traditional managers saying their engineers "Here's a ticket. Do this. Don't think.", there is also a class of engineers that actually seek this "state", less rewarding but also much less challenging altogether. If you try the SV model with them you will fail.
• cody3222 6y ago
  This feels similar to the "MBA cofounder" profile of someone who has the mindset: if I just had an engineer to build my idea then this would be big. Every engineer knows it doesn't work that way (but many who charge by the hour w/ consulting may be happy to take the job for a while).
• brailsafe 6y ago
  Having no influence on decision making and being given tasks by an opaque task mill that also decides on arbitrarily tight and uninformed deadlines is a great way to burn out, because you learn that what you do doesn't matter.
• supergeek133 6y ago
  Reading a bit deeper into this... the real big difference to me is "context". If you want someone to critically think, they have to have business context and in many cases a vested interest in what they're building. This crops up quite a bit when your engineering is primarily outsourced/overseas and your work involves an issue that might be a primarily US based problem. How can you expect people to critically think when they don't have context around the issue?
• troelsSteegin 6y ago
  I think that in an ideal organization, staff autonomy is conditioned on the risks and rewards of staff-initiated contributions to the business. High autonomy is higher variance. Some of that may be good - innovation. Some of that may be bad - customer or market failures. The outcomes are money consequences to a business, and given business has some to downside tolerance to that. In some businesses tech innovations have huge realizable upside. Maybe a way to see the autonmy tradeofff is in terms of manufacturing complexity. A business whose products reach customers via endpoints on hosted service is different than one whose products are tractors off an assembly line. Maybe that's understood as how capital-intensive it is to bring a marginal capability to market. I'll say further than in an ideal organization, with respect to autonomy, the job of management is allocating attention and distributing context, and that management and staff alike are serving a well articulated mission through the vehicle of the business organization. In a given instance, we all can take a compass reading on "true north" for business. A non ideal business, for starters, has a self serving and self interested control structure that views autonomy in relation to power. Both SV and traditional companies can be ideal or not. I think the difference comes down a culture of thinking about risk - reward, and the collective, cultural engagement with mission.
• jskrn 6y ago
  As someone who has been on both sides, it amuses me to see programmers (many who could not be called engineers), reduce non-programming roles to sending emails and having meetings. There are absolutely some people who frustratingly cannot do any work on their own without a meeting - they are mostly good at guiding a group and making sure communication and progress is happening. However, there are SO MANY skills and functions outside of programming that go into building the right thing the right way at the right time. Costco doesn't beat Sams with more engineering, they did it with strategy.
• rmk 6y ago
  What this article is saying in a very roundabout way is that companies whose primary products are software, hardware or hardware/software artifacts will 'get' engineers better than companies whose primary products are not these things. If you have worked for a few years in this industry, you would know this.
• tabtab 6y ago
  This kind of reminds me of Paul Graham's article on how "suit culture" ruined Yahoo, a company poised to be bigger than Google but squandered it by being engineer-unfriendly. http://www.paulgraham.com/yahoo.html http://www.paulgraham.com/yahoo.html A quote: Hacker culture often seems kind of irresponsible. That's why people proposing to destroy it use phrases like "adult supervision." That was the phrase they used at Yahoo. But there are worse things than seeming irresponsible. Losing, for example.