4 ms·

As a PM I would agree that some of these traits are really able to increase team effectiveness. For example, just in a recent project, we saved weeks of work af

by ridaj 7y ago

As a PM I would agree that some of these traits are really able to increase team effectiveness. For example, just in a recent project, we saved weeks of work after asking the developer to be more upfront about tradeoffs. However a big, big caveat on #1 "proactive with ideas/opinions" and #3 "curiosity and keen interest in 'why'". These are also traits of a different kind of engineer — the opinionated one with poor product insights and who isn't interested in feedback and constantly derails the team by sharing their thoughts on what we should and shouldn't do. Of course I prefer working with an engineer with product opinions and who asks why than one who doesn't, but if you're an engineer who's looking at this article and thinking "oh, this says I should start blurting my opinions out about the product more often and asking people why they are doing things the way they are", well that doesn't work well. To be really efficient I think you need to look at it more as "I should share and be curious about whether my insights on product and strategy are valuable to the team", then listen to the feedback about it.

tgtweak 7y ago
As a product manager you should not be asking anyone to build you anything without properly explaining the why. It starts with the why, and a good engineering team will offer how+when. If you get overly involved in the how you'll end up with ignoring that insight and the responsability that comes with it. Being on both the side of product and engineering, more often than not it's a lack of collaboration and trust between the two that leads to poor products and frustrated engineers. Your last paragraph hints at this. Poor product insights - some of the most competitive features I've seen make it into a product found themselves there because an engineer decided to build it to fix a pain point of their own (often after having that feature request ignored by product owner) Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out. "I should share and be curious about whether my insights on product and strategy are valuable to the team" Good advice for everyone in the team, wish it was followed unilaterally.
- ridaj 7y ago
  > "I should share and be curious about whether my insights on product and strategy are valuable to the team" > Good advice for everyone in the team, wish it was followed unilaterally. Indeed, and this is how I approach my responsibilities as well. I grew myself in service of the team rather than telling people what to do / not to do. > Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out. From firsthand experience, it works well sometimes, and when it works it's really magical. But it unfortunately doesn't work every time, because some folks really just want to be told what to code (don't want to engage), and other folks want to engage but don't have the skills (creativity, awareness of the pros and cons of various relevant UX patterns, user testing, etc). I give as much creative ownership as possible and really wish it could delegate it entirely though (does make my job easier).
james_s_tayler 7y ago
I think I can see your point. If you're the kind of engineer described in this article, you don't need to read this article. You have always naturally behaved this way and there is a natural trajectory that you're on because of it. You find this article just resonate deeply with you. If you're not the kind of engineer described in this article, you probably can't become one. You will try to follow advice and wind up falling flat. Thats because the kind of engineer described in this article isn't following advice, they are following instinct. And if you don't have instinct then you have nothing to follow.
- ridaj 7y ago
  That's one way of looking at it. The question of whether there is a path that someone who doesn't have good product insights can follow and learn to have some, or if it's all "instinct", is an interesting one. No one was born with those skills out of the womb, so it's obviously a learned skill, but it's one that we haven't quite broken down to a teachable course. I agree that following simple advice probably won't work, but I personally believe intentional practice can actually help people get better at this — only there has to be more than a desire to communicate out, there has to be a desire to put oneself on the line and evaluate oneself honestly based on result.
  - james_s_tayler 7y ago
    I sort of half agree half disagree. My mental model on this is that for a given skill/outcome everyone sits somewhere on a continuum of possibility with upper and lower bounds depending on intrinsic factors. So, in that sense I agree there are those people who could develop a certain aptitude through a clear pathway of study. My model assumes their highest level of aptitude they can attain is capped at that lower than those who are "naturals". Conversely if you are a natural and you never seem to develop your aptitude, you will bumble along likely doing OK or even accidentally doing well, but those who can reach the absolute top of the aptitude spectrum are those who a) realize they are a natural b) seek out a pathway to accelerate their progress and c) actively work really hard at it.
mobjack 7y ago
I fought off the urge to endlessly debate my product managers by encourage them to A/B test their "bad" ideas. The results were humbling for all everyone. Sometimes I was right but I often implemented features that I was sure would fail but turned out to be big successes. Although my ego was initially bruised, the tactic was a big win for the business as now the product is more data driven.

by ridaj 7y ago

tgtweak 7y ago

As a product manager you should not be asking anyone to build you anything without properly explaining the why. It starts with the why, and a good engineering team will offer how+when. If you get overly involved in the how you'll end up with ignoring that insight and the responsability that comes with it. Being on both the side of product and engineering, more often than not it's a lack of collaboration and trust between the two that leads to poor products and frustrated engineers. Your last paragraph hints at this. Poor product insights - some of the most competitive features I've seen make it into a product found themselves there because an engineer decided to build it to fix a pain point of their own (often after having that feature request ignored by product owner) Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out. "I should share and be curious about whether my insights on product and strategy are valuable to the team" Good advice for everyone in the team, wish it was followed unilaterally.

ridaj 7y ago
> "I should share and be curious about whether my insights on product and strategy are valuable to the team" > Good advice for everyone in the team, wish it was followed unilaterally. Indeed, and this is how I approach my responsibilities as well. I grew myself in service of the team rather than telling people what to do / not to do. > Humor your engineers and give them creative ownership over a feature (from suggestion to implementation)- you'll be surprised how effortlessly it comes out. From firsthand experience, it works well sometimes, and when it works it's really magical. But it unfortunately doesn't work every time, because some folks really just want to be told what to code (don't want to engage), and other folks want to engage but don't have the skills (creativity, awareness of the pros and cons of various relevant UX patterns, user testing, etc). I give as much creative ownership as possible and really wish it could delegate it entirely though (does make my job easier).

james_s_tayler 7y ago

I think I can see your point. If you're the kind of engineer described in this article, you don't need to read this article. You have always naturally behaved this way and there is a natural trajectory that you're on because of it. You find this article just resonate deeply with you. If you're not the kind of engineer described in this article, you probably can't become one. You will try to follow advice and wind up falling flat. Thats because the kind of engineer described in this article isn't following advice, they are following instinct. And if you don't have instinct then you have nothing to follow.

ridaj 7y ago
That's one way of looking at it. The question of whether there is a path that someone who doesn't have good product insights can follow and learn to have some, or if it's all "instinct", is an interesting one. No one was born with those skills out of the womb, so it's obviously a learned skill, but it's one that we haven't quite broken down to a teachable course. I agree that following simple advice probably won't work, but I personally believe intentional practice can actually help people get better at this — only there has to be more than a desire to communicate out, there has to be a desire to put oneself on the line and evaluate oneself honestly based on result.
- james_s_tayler 7y ago
  I sort of half agree half disagree. My mental model on this is that for a given skill/outcome everyone sits somewhere on a continuum of possibility with upper and lower bounds depending on intrinsic factors. So, in that sense I agree there are those people who could develop a certain aptitude through a clear pathway of study. My model assumes their highest level of aptitude they can attain is capped at that lower than those who are "naturals". Conversely if you are a natural and you never seem to develop your aptitude, you will bumble along likely doing OK or even accidentally doing well, but those who can reach the absolute top of the aptitude spectrum are those who a) realize they are a natural b) seek out a pathway to accelerate their progress and c) actively work really hard at it.

mobjack 7y ago

I fought off the urge to endlessly debate my product managers by encourage them to A/B test their "bad" ideas. The results were humbling for all everyone. Sometimes I was right but I often implemented features that I was sure would fail but turned out to be big successes. Although my ego was initially bruised, the tactic was a big win for the business as now the product is more data driven.