10 ms·

This hardly comes as a surprise. How many companies, especially startups, really need to tackle tough technical challenges? On the other hand, how many companie

• someguydave 8y ago
  Why should engineers agree to work for a regular salary from you? Why wouldn't they hold out for ownership in your product venture?
  • g9yuayon 8y ago
    Supply and demand? My assumption is the less challenging a technical project becomes, the more supply of engineering talents can work on the project. There should be more generalists after all. And dynamics of supply and demand will determine if engineers will be able to "hold out for ownership".
    • someguydave 8y ago
      What, precisely, limits the supply of people who have "product talents to figure out what is valuable to produce"? Why are are people with such skills apparently more rare than people with technical skills?
      • jordache 8y ago
        I think as a mathematical comparison. Given a successful product, there are likely way more engineers than product people.
        • kingraoul3 8y ago
          That's assuming the consequent though.
          • jonex 8y ago
            It leads to the supply for any given experience level >0 being smaller for the product people. Also, even in the 0 experience group, the selection will be tougher. This is independent of the measurable or existing differences in skill. The person that is best at convincing the employer of hiring them as a solo product manager is in a better position to negotiate than the person who managed to be among the five seemingly best developers.
      • g9yuayon 8y ago
        That beats me. If I have to guess, I'd venture to say dealing with ambiguity is truly hard. As a production manager, you need to have unique insights on the market you're interested; you need to capture future trend; you need to understand human psyche, you need to convince your company to take risks and invest into something that does not necessarily have a future, you need to build trust with both the engineering team and the management, and you should be analytical enough produce supporting numbers. Many of such activities are ambiguous in nature, and getting clarity and buy-in out of such ambiguity is in high demand in the current market. On a side node, engineers do sometimes need to function as PMs to build great product.
        • deleted 8y ago
          [deleted]
        • ecnahc515 8y ago
          In my (limited) experience; a lot of our best PMs were once engineers, and they usually transitioned to PM roles because it let them actually execute on their visions, in addition to potentially more career growth potential.
  • deleted 8y ago
    [deleted]
• riazrizvi 8y ago
  Waves hand, "We can always throw some more engineers at that part of the problem, what's really hard is figuring out what to do", said the project manager, and the product manager, and the QA manager, and the manager-manager. Meanwhile, talking heads in also ran companies in Silicon Valley continued to sell off stock in the mantra, "Innovation is 1% inspiration and 99% perspiration".
  • someguydave 8y ago
    Pournelle's Iron Law of Bureaucracy states that in any bureaucratic organization there will be two kinds of people": First, there will be those who are devoted to the goals of the organization. Examples are dedicated classroom teachers in an educational bureaucracy, many of the engineers and launch technicians and scientists at NASA, even some agricultural scientists and advisors in the former Soviet Union collective farming administration. Secondly, there will be those dedicated to the organization itself. Examples are many of the administrators in the education system, many professors of education, many teachers union officials, much of the NASA headquarters staff, etc. The Iron Law states that in every case the second group will gain and keep control of the organization. It will write the rules, and control promotions within the organization. https://www.jerrypournelle.com/reports/jerryp/iron.html https://www.jerrypournelle.com/reports/jerryp/iron.html
    • riazrizvi 8y ago
      Personally, I wouldn't go that far, I've found a decent number of managers to be value-adding. I think it is more about the sloppy mindset that tends to underplay the contribution of other producers on a team, to instead heavily over-value their own contributions. Engineers can go too far in this way too, of course. Managers can produce strategy, operational efficiency, organizational support for ill-understood projects, elevate performers, eliminate underperformers etc.
      • Fomite 8y ago
        This. A good manager is a force multiplier.
• stuartaxelowen 8y ago
  Most companies still have a very hard time building a good machine learning pipeline.
  • codingdave 8y ago
    And most product managers would confirm that most companies do not need a good machine learning pipeline.
    • FridgeSeal 8y ago
      Really? Because most product managers I meet are the ones going “how can we put AI and Machine Learning into <some task that doesn’t need it>?” I 100% agree that most companies don’t need nearly as much ML as think though.
      • gretch 8y ago
        full disclosure: I'm a PM in FANG I think that's what the bad PMs do. Good PMs think 'what is the smallest possible thing we could do to start truly adding value against our problem space?' A good heuristic is that good pms are problem oriented - bad pms are often focused on solutions first
    • Stryder 8y ago
      As an older engineer currently having fun digging into ML: yep, a well thought-out set of good-ol business rules can do a lot of what teams are applying ML to these days. Nothing wrong with learning new things, though. I can get behind that. It's important to stay intellectually honest, however. On the other hand, research efforts on vision, language and autonomous systems are genuinely pushing boundaries.
      • ghaff 8y ago
        Supervised learning using a variety of different neural network pipelines is doing some genuinely impressive things from a business perspective. But not much beyond that at this point (again, from a business perspective).
• rm999 8y ago
  Yep exactly. Especially for smaller, faster growing companies: what you choose to not work on is usually more important than what you choose to work on (once you remove the core work to support the company's current state). Without someone with product experience - usually either a PM or an experienced software leader - adding additional engineers often paradoxically hurts total productivity.
• jahaja 8y ago
  What's up with this usage of the word "talent"? Tech is in such acute need of humble pie I don't even know where to begin. I'm becoming disillusioned. Why is a programmer etc. a "talent", but a carpenter just an employee, hire or whatever? But maybe it's actually an appropriate term, now when our interview processes so clearly have ceased to be job interviews, and have become auditions - because nothing less satisfies our own grandiose self-importance. > "On the other hand, how many companies desperately need product talents to figure out what is valuable to produce?" These middle-management positions are so unmeasurable that I think they may be greatest source of bullshit jobs in tech. So if it's true that their success is largely unmeasureable, I wonder how you've come to that conclusion?
  • fredgrott 8y ago
    mainly because while we all go through the same basic CS-math foundations in HS...most never learn how to apply them...
  • payne92 8y ago
    ...because the skill gap between “ok”, “good”, and “great” is so much bigger for some jobs (software development) than it is for other jobs (carpentry).
    • padthai 8y ago
      You would be surprised how hard is and how many years takes to be a good cabinetmaker.
    • enjo 8y ago
      It's not tho. It's really not. Most of the software you use every day was developed by very average software developers. The vast majority of the work software developers do isn't terribly novel or particularly difficult. And you know what? They do just fine. Things work well. Systems stay on line. Companies make money. I've seen too many "bad" teams produce perfectly functional software over the years to think that this gap exists anywhere but in Joel Spolsky essays. I think comparing carpenters to software engineers does a disservice to carpenters. Software developers to me are more like dry-wallers. A really good one can do it faster, but the end result mostly always looks the same. The difference between an average and a great carpenter, however, is immediately obvious. There is real craftsmanship there, and you can clearly see the difference. It isn't until you get to the edges of software development that those same differences become clear. When you're dealing with very high scale, very aggressive performance metrics, or very difficult mathematical concepts you see the difference between average and great developers. But those are less than a fraction of 1% of software projects I'd wager. * I should note: I'm a software developer.
• Stryder 8y ago
  We are quite literally running out of productive things to do so we (the collective group) are all currently micro-optimizing everything we can lay our hands on. It's like a pond that's shrinking with all the fish gasping for air. A paradigm shift is necessary before we end up strangling ourselves.
  • aggie 8y ago
    "The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end." -Henry Ellsworth, US Patent Office Commissioner, 1843
• anon_0bviously 8y ago
  Totally disagree. In my experience across three tech firms, Product Managers spend a lot of time selling themselves. They are talking to customers (read: networking for their next job), going to conferences (read: shmoozing with their next potential boss), researching competitors (read: figuring out where to apply) researching products (read: learning on the job) Is it any surprise they tend to make more than people stuck in the office coding?
  • zhte415 8y ago
    talking to customers -> Listening to what the customer's pain points are, what the customer needs, what to address going to conferences -> Because face-to-face contact is far faster and richer than sending emails researching competitors -> What aren't we doing that others are doing better / what are we doing that's winning / what to change? researching products -> well, yes, constantly learning Is it any surprise they tend to make more than people stuck in the office coding? Listening to customer needs, staying ahead, constantly learning. Sounds like good general career advice.
    • consp 8y ago
      I do not see any activity here which would indicate a higher pay from any other ordinary worker.
      • shard 8y ago
        That's very astute. You are right, there's nothing in those activities that command a higher pay. For product managers, it's the work that comes after doing all the above which commands the higher pay: Synthesizing all the information that was gathered to present a strategy which satisfy consumer needs and exploit competitor weak points. Creating a long term roadmap which gives direction to the work that the engineering department will do. And doing both convincingly enough that upper management buy into the strategy you are proposing. This is the no-right-answer, risky work that product managers are paid for.
• walrus1066 8y ago
  Think the key factor is, talented engineers write software that's maintainable, and easier to change, extend & adapt. This could make the difference between having to do a complete rewrite at great expense, vs a small tweak. For startup with no customers it's probably fine to cowboy up a solution, then throw away and start again, to find market fit. But if you've got lots of customers, and you're forced to rewrite because the previous engineers left an unmaintainable mess, it's going to be hugely complex, risky, long & expensive undertaking.