3 ms·

>Although these topics are not related to coding at all, they make me a better engineer and engineering leader. This is fine for shallow problems in the busine

>Although these topics are not related to coding at all, they make me a better engineer and engineering leader. This is fine for shallow problems in the business space, but eventually you will get to harder problems and will need to collaborate with experts. Experts are experts because they spend many hours on those subjects. You are an expert at engineering because you spend many hours on that subject. Don't let your recently acquired domain knowledge make you overconfident enough to not reach out to experts. Everyone thinks they know how something works until someone more knowledgeable comes along. >instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy. Which is fine if the problems are obvious and there are easy wins to be had. Your solution's effectiveness is limited by your expertise in the domain. This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge. Additionally, while it's great to strive to be an expert in both engineering and the domain, you're naturally doing two jobs for the price of one. Many domain experts with a singular expertise might also make more than developers striving to be double-experts at the lesser price of a developer.

mooreds 4y ago
> This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge. I wrote about this years ago: https://www.mooreds.com/wordpress/archives/134 https://www.mooreds.com/wordpress/archives/134 Both things can be true: it's good to have some product mindset and you should also defer to the experts. In fact, they build on each other, otherwise how can you communicate with the experts? You have to have some common, shared language to do so. They might learn engineering, but it's more likely a dev will learn some of the domain.
- taylodl 4y ago
  Absolutely true - but at the end of the day some one has to be vested with making the final decision. That's what Product Managers are for, they're vested with making the final call. As you point out, good Product Managers won't be overbearing overlords just like good engineers aren't simple order takers.
  - ownagefool 4y ago
    Which decision? How a feature UX should work based on the PM having a fair bit of expertise in the field? Maybe. What task you work on next? Maybe not. You see the problem with letting someone who's not an expert in the work decided the work goes both ways. The PM is in charge? Good luck getting patching on the backlog. Don't consult the PM? Good luck getting the functionality right. My takeaway is the PMs often aren't the experts in writing, maintaining, or running a production system, thus they probably shouldn't actually run the backlog. But said production system is pretty useless without market fit, so you want to strongly align with whoever your version of a PM is.
    - taylodl 4y ago
      The Product Manager owns the what?, they don't own the how? or how long?. They're getting feedback and directing the sales team, the marketing team, the engineering team, the UI team, the QA team and the support team. It should be easy for a competent engineering team to get patching on the backlog - after all, that's table stakes. Organizations struggling with the mundane is the very definition of dysfunctional.
      - ownagefool 4y ago
        But very common. Which goes back to the point, maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate, but not direct the others groups, whom are the actual experts of their respective areas.
gedy 4y ago
> This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge. Maybe that's true, but almost all the Product managers I've worked with in multiple companies were not experienced in the the domain we were working in either. They were mostly generic "product people" from random other domains. So it wasn't a stretch to say the engineers who had worked there knew more about the domain than the product folks did.
- vsareto 4y ago
  Even in that situation, the PM should be striving for more domain knowledge than the devs. Devs shouldn't be expected to pick up that slack. If they are, they should be compensated for it.
  - ArnoVW 4y ago
    The funny thing is, developers will always have a more precise and detailed domain knowledge. Because unlike the PM, who can analyze the problem in the abstract and approximate, the developer must produce working code. However it is very difficult to have empathy with the user when you're trying to produce code. Also, you're generally judged on your ability to 'finish US' quickly. So generally you'll choose an approach 'that works'. Only to have the feedback 'great, but why did you not think about this?'
    - spookthesunset 4y ago
      > However it is very difficult to have empathy with the user when you're trying to produce code. Not only that, but as a dev you can get into a position where what you decide to work on is based more on ease of development or “fits cleanly with what we have now”. There should be a balance. The PM should push for the impossible and the engineers can tell the PM why that won’t work. Kind of… maybe not with that much hyperbole in my assertion.
    - peteradio 4y ago
      > the developer must produce working code. Bingo, I can't (well won't) build a contradiction even if its part of the spec. > Only to have the feedback 'great, but why did you not think about this?' Even worse IMO: "Great, no problems!" every time. Ok, I'm not that good, is anyone even running this shit?
encoderer 4y ago
I’ve served many roles in tech. Engineer, lead, manager, director and now founder. My experience is that when a product manager has true expertise, that product manager is respected easily by the whole team. Likewise, when a product manager without specific expertise proves adept at prioritizing and gains a reputation for quality work, they are easily respected by the whole team. But in many cases the product manager is a Stanford MBA with a couple former roles at other tech companies and has never accomplished anything very impressive. And these hires are corrosive for a product org. They get in and hire more just like themselves. The problem is not the Stanford mba it’s that all they have is a Stanford mba and confidence in their own skills. It’s not enough to demand the respect of engineers who have sometimes worked years in the domain.
- danielmarkbruce 4y ago
  Fwiw, it's not really their fault. Management who put this in place suck.

mooreds 4y ago

> This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge. I wrote about this years ago: https://www.mooreds.com/wordpress/archives/134 https://www.mooreds.com/wordpress/archives/134 Both things can be true: it's good to have some product mindset and you should also defer to the experts. In fact, they build on each other, otherwise how can you communicate with the experts? You have to have some common, shared language to do so. They might learn engineering, but it's more likely a dev will learn some of the domain.

taylodl 4y ago
Absolutely true - but at the end of the day some one has to be vested with making the final decision. That's what Product Managers are for, they're vested with making the final call. As you point out, good Product Managers won't be overbearing overlords just like good engineers aren't simple order takers.
- ownagefool 4y ago
  Which decision? How a feature UX should work based on the PM having a fair bit of expertise in the field? Maybe. What task you work on next? Maybe not. You see the problem with letting someone who's not an expert in the work decided the work goes both ways. The PM is in charge? Good luck getting patching on the backlog. Don't consult the PM? Good luck getting the functionality right. My takeaway is the PMs often aren't the experts in writing, maintaining, or running a production system, thus they probably shouldn't actually run the backlog. But said production system is pretty useless without market fit, so you want to strongly align with whoever your version of a PM is.
  - taylodl 4y ago
    The Product Manager owns the what?, they don't own the how? or how long?. They're getting feedback and directing the sales team, the marketing team, the engineering team, the UI team, the QA team and the support team. It should be easy for a competent engineering team to get patching on the backlog - after all, that's table stakes. Organizations struggling with the mundane is the very definition of dysfunctional.
    - ownagefool 4y ago
      But very common. Which goes back to the point, maybe Product aren't master of the universe directing all the teams, but just another group of folks with relevant skills that should advise and advocate, but not direct the others groups, whom are the actual experts of their respective areas.

gedy 4y ago

> This is a regular pattern I see, which is "developers pretending to be experts at everything because they're good at picking up knowledge and skills". There is a time component you can't skip when acquiring domain knowledge. Maybe that's true, but almost all the Product managers I've worked with in multiple companies were not experienced in the the domain we were working in either. They were mostly generic "product people" from random other domains. So it wasn't a stretch to say the engineers who had worked there knew more about the domain than the product folks did.

vsareto 4y ago
Even in that situation, the PM should be striving for more domain knowledge than the devs. Devs shouldn't be expected to pick up that slack. If they are, they should be compensated for it.
- ArnoVW 4y ago
  The funny thing is, developers will always have a more precise and detailed domain knowledge. Because unlike the PM, who can analyze the problem in the abstract and approximate, the developer must produce working code. However it is very difficult to have empathy with the user when you're trying to produce code. Also, you're generally judged on your ability to 'finish US' quickly. So generally you'll choose an approach 'that works'. Only to have the feedback 'great, but why did you not think about this?'
  - spookthesunset 4y ago
    > However it is very difficult to have empathy with the user when you're trying to produce code. Not only that, but as a dev you can get into a position where what you decide to work on is based more on ease of development or “fits cleanly with what we have now”. There should be a balance. The PM should push for the impossible and the engineers can tell the PM why that won’t work. Kind of… maybe not with that much hyperbole in my assertion.
  - peteradio 4y ago
    > the developer must produce working code. Bingo, I can't (well won't) build a contradiction even if its part of the spec. > Only to have the feedback 'great, but why did you not think about this?' Even worse IMO: "Great, no problems!" every time. Ok, I'm not that good, is anyone even running this shit?

encoderer 4y ago

I’ve served many roles in tech. Engineer, lead, manager, director and now founder. My experience is that when a product manager has true expertise, that product manager is respected easily by the whole team. Likewise, when a product manager without specific expertise proves adept at prioritizing and gains a reputation for quality work, they are easily respected by the whole team. But in many cases the product manager is a Stanford MBA with a couple former roles at other tech companies and has never accomplished anything very impressive. And these hires are corrosive for a product org. They get in and hire more just like themselves. The problem is not the Stanford mba it’s that all they have is a Stanford mba and confidence in their own skills. It’s not enough to demand the respect of engineers who have sometimes worked years in the domain.

danielmarkbruce 4y ago
Fwiw, it's not really their fault. Management who put this in place suck.