Why Don't They Trust Us? | Hacker News Reader

Why Don't They Trust Us?

hackernoon.com

34 pointspierreneter14 comments

Hooray, more "equations" using arithmetic to compare things that not only aren't using the same units, but don't have clear units or aren't clearly quantifiable in the first place.

Outside of a very limited set of circumstances (sushi bars, or close longtime friends of the serving/kitchen staff), you're just annoying the staff when you ask to be surprised. It's a dick move to walk into a situation where the other party knows nothing about you, but they're still expected to impress you.

this isn't the point of the article which is, in my opinion, a very good narrative of what its like to try to practice agile development in an organization with not very agile tendencies.

it was just a way to demonstrate that this kind of request at least _can_ be made to a restaurant staff and you don't think "wow they're totally gonna blow it" but you'd rarely, if ever, see a product team make a similar request to a development team.

great job to the author of this post for capturing this.

I have on occasion seen top notch dev teams start delivering demos of unasked for, but mind-blowingly good new features, such that Marketing and Sales were downright salivating.

Those dev teams get trusted! They eventually come to be seen as wizards and get amazing amounts of autonomy.

It requires an uncommon mix of exceptional technical talent and exceptional product vision.

I'd say that it requires good design sense: a designer should be able to avoid the trap of typical workflows and see which features and procedures would actually help the user to get the result―all the way to scrapping the original requirements and proposing a completely different solution.

Hmm,

The article conjures up an idea of blind "trust" that I would claim you only have when you're making a decision of fairly small consequence to yourself. Sure, I'd guess a wealthy person is OK just sending their car, that probably doesn't many miles on it or problems to it, to a high priced mechanic and assuming everything will be OK. It probably will be and in the off-chance it isn't, the extra money you've been feeding the mechanic gives them an incentive to make things up to you.

Personally, I have one mechanic I trust to repair my car at the lowest price and another mechanic I trust to know all of the weird problems of this vehicle (and to charge a higher price as well as to have a multi-week wait time). But that's because auto repairs are a big part of my budget (sure, you can buy a car for $20K and spend nothing for a while or you spend $2K on your car and $1K/year for some period, TCO isn't clear).

Even more, if you are getting improvements on your house, you only dole out money to someone you "trust completely" if your income stream is secure enough you don't mind the risk of a significant amount being tacked by a contractor who's gotten up to the level of "best reputation". If you're trying to improve your house on the cheap, you look carefully at all the options, not "trusting" anyone explicitly.

And that's why it's unlike a software team is likely to get this sort of trust. Nearly everyone paying to have a significant piece of software built is making the kind of decision you have to supervise. Supervise doesn't mean micro-manage but it is significant and quite different from any "pay and forget" type relationship.

I can dig this.

That said, if a mechanic says “if you don’t get this repair your tailpipe is gonna fall off” and you say “nah let’s risk it”, you’re not gonna go back to him when it falls off and say “wow I can’t believe you let me drive my car until the tailpipe fell off, you should’ve done better!”

If, however, a dev team says “hey guys, if we don’t fix this tech debt we’re gonna run into some perf issues and the site may crash” it’s a lot more likely they’ll come back and still find a way to blame the dev team when the product inevitably does crash or really struggle to deliver results.

Again, like my other comments say, this could be completely anecdotal on my part and totally greener grass thinking on my part, but it definitely does feel like this is the way the product teams I’ve worked with behave toward development teams.

Maybe I'm misreading the article but isn't the author conflating product development and software development? Who is the "Us" in the title?

The article suggests multiple times that it's "software product development"... so product development. The author has tagged himself as "product development nut".

I don't understand who "they" and "us" are referring to.

Confusing article...

"us" = development team "them" = stakeholders/product owner/project managers/managers/ux designers/etc.

the problem (as I said in my other comment) is that "development" is incredibly vague, software development or product development are hugely different fields, almost always those roles won't be covered by the same person, unless we're talking about a very small startup. In the article the author makes several statements that apply e.g. to SW dev but not product dev or vice-versa. I find the article confusing for this reason.

I gotcha. I guess the confusion from my end is that I’ve yet to have a software development job where I wasn’t developing a product. No one in the orgs I’ve been a part of refer to the “product” team as the “product development” team. It’s just the product team, and the development team.

If that’s not been your experience then maybe you fall outside the target demographic of this article? I say that because it was super clear to me exactly what the author was talking about (in fact it even resonated with other members of my scrum team).

Alternatively, I suppose my experience could be anecdotal and not what most development teams encounter daily and struggle with.

Yeah I can see what you mean in relation to being in the target demographics.

If I go mentally back to when I was in a small startup, then I could kinda see how the article makes sense, because as a technical co-founder I also had (partial) freedom to imagine how the product should be, besides having to actually write code. But then all the "politics-related" aspects that the article mentions (the whole "us vs. them" thing) make less sense because in a small startup there isn't as much "politics" as in a larger corporate environment...

Maybe the article applies to a "later stage/larger startup" environment, which I have never experienced, and maybe that's why I find it confusing.

Edit: another thing that you said and makes a lot of sense, is that your dev work often involves creating a product, however in my experience (at least since I left the startup world and went into enterprise) most work has been about dealing with a lot of legacy stuff and developing new features here and there, very rarely having to develop a new product from scratch.

Reply on news.ycombinator.com