3 ms·

As a rule, the structures around product teams tend to discourage asking if it's better to not ship a thing. When you measure a team by what (and how many thing

by Kalium 7y ago

As a rule, the structures around product teams tend to discourage asking if it's better to not ship a thing. When you measure a team by what (and how many things) they ship, they are always going to default to shipping things.

kevas 7y ago
This is hitting too close to home. Currently on a team that does what’s on the task list without questioning anything—driving me up the wall.
- Aeolun 7y ago
  This is a function of the organization, not the team. If you hear ‘do it anyway’ after raising concerns one too many times, eventually you just do it.
  - JohnFen 7y ago
    Not necessarily. It depends on exactly what "it" is. I have quit jobs before because I was required to implement something that I considered an egregiously terrible idea.
overgard 7y ago
The structure thing is spot on. Decisions like this tend to get made when management has found a way to essentially silence any feedback (by making feedback pointless). This is why I cringe whenever I hear the phrase "leadership team". Whenever I hear that phrase deployed it's almost always to diffuse responsibility for a bad decision so no single person has to answer for it. Which amusingly is the opposite of real leadership: real leaders actually accept responsibility for the decisions they make.
LyndsySimon 7y ago
This is... insightful. It brings to mind a larger question of how we (as an industry) should be measuring developer and team productivity, though. “Story points” are largely designed to solve this issue, but in my experience they are quickly co-opted to mean something different to each stakeholder. At a past employer, I experienced their trying to measure productivity by “net lines of code”. That didn’t work well, either. I prefer refactoring and simplifying to pretty much any other type of task, and it isn’t at all uncommon for me to end a day - or a sprint - with a negative NLOC. I see at a positive, as each LOC carries with it an ongoing cognitive and maintenance burden. Thankfully, that scheme didn’t last long :)
hn_throwaway_99 7y ago
This is absolutely true. It's absolutely what killed Digg with Digg V4 IMO. I can't possibly believe anyone who ever used Digg could have taken a look at Digg V4 and thought "Oh yes, a feed full of spam, just exactly what I come to Digg for". But the team had already invested a ton of work, and organizationally it would have been next to impossible to say "Shit, we fucked up, lets hold off". So at least I give GitLab credit that they backed off (for now).

by Kalium 7y ago

kevas 7y ago

This is hitting too close to home. Currently on a team that does what’s on the task list without questioning anything—driving me up the wall.

Aeolun 7y ago
This is a function of the organization, not the team. If you hear ‘do it anyway’ after raising concerns one too many times, eventually you just do it.
- JohnFen 7y ago
  Not necessarily. It depends on exactly what "it" is. I have quit jobs before because I was required to implement something that I considered an egregiously terrible idea.

overgard 7y ago

The structure thing is spot on. Decisions like this tend to get made when management has found a way to essentially silence any feedback (by making feedback pointless). This is why I cringe whenever I hear the phrase "leadership team". Whenever I hear that phrase deployed it's almost always to diffuse responsibility for a bad decision so no single person has to answer for it. Which amusingly is the opposite of real leadership: real leaders actually accept responsibility for the decisions they make.

LyndsySimon 7y ago

This is... insightful. It brings to mind a larger question of how we (as an industry) should be measuring developer and team productivity, though. “Story points” are largely designed to solve this issue, but in my experience they are quickly co-opted to mean something different to each stakeholder. At a past employer, I experienced their trying to measure productivity by “net lines of code”. That didn’t work well, either. I prefer refactoring and simplifying to pretty much any other type of task, and it isn’t at all uncommon for me to end a day - or a sprint - with a negative NLOC. I see at a positive, as each LOC carries with it an ongoing cognitive and maintenance burden. Thankfully, that scheme didn’t last long :)

hn_throwaway_99 7y ago

This is absolutely true. It's absolutely what killed Digg with Digg V4 IMO. I can't possibly believe anyone who ever used Digg could have taken a look at Digg V4 and thought "Oh yes, a feed full of spam, just exactly what I come to Digg for". But the team had already invested a ton of work, and organizationally it would have been next to impossible to say "Shit, we fucked up, lets hold off". So at least I give GitLab credit that they backed off (for now).