rw-book-cover

Metadata

Highlights

  • I felt more and more that engineers are being faded out from the picture. It seems that PMs now has taken over a big portion of “fun part of the job”: figuring out what to build, iterating on the spec. We’re basically converging to a model where, PM + design figures out what to build, write a doc/spec, hand it over to engineer to build it (and then iterate by going back to step 2). (View Highlight)
  • it’s kind of like being a minority in a not-inclusive-by-default environment: You can voice up, it may improve and people are open-minded , but if the system is setup this way, engineers just need to keep forcing-their-way-through. (View Highlight)
  • the PM is the one ultimately tasked with having the full product context. It’s not efficient to have every engineer be reviewing research documents, reviewing user survey details, dicing data in Looker, (View Highlight)
  • The issue may be that you’ve got a ton of boring CRUD work so there aren’t any interesting technical problems so this is the next best things. (View Highlight)
    • Note: What happens in many places, where the tech side is not challenging at all?
  • It’d probably be helpful to as a team define a set of norms and processes for how you function. You can use something like a RACI chart or other approach. (View Highlight)
  • not socializing the people that are going to be actually making the feature is always a mistake, albeit a common one (View Highlight)
  • As a developer, if you only have to focus on building whatever you’re told, then you don’t really have to care about the success of the product. (View Highlight)
  • That said, it is a mistake to not include the engineering side in discussing architecture and how things are built. It’s alienating and causes resentment. Humans need a sense of agency to stay motivated. (View Highlight) rw-book-cover