
Why Don't They Trust Us? - pierreneter
https://hackernoon.com/why-dont-they-trust-us-9d942338d848
======
kirkules
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.

------
subway
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.

~~~
bcarroll22
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.

------
charlieflowers
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.

~~~
aasasd
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.

------
joe_the_user
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.

~~~
bcarroll22
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.

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

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

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

Confusing article...

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

~~~
mastazi
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.

~~~
bcarroll22
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.

~~~
mastazi
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.

