
The Trick - geon
https://www.reddit.com/r/talesfromtechsupport/comments/hrn8ih/the_trick/
======
tmountain
Was not a fan. Basically reads as--I could not get on the same page as the
client, my boss was useless in helping with these interactions (but... is the
"best boss ever"), so they took me off the project, and a jaded / more
experienced developer told me that he'd lost his passion for the work, so
apathy must be the solution to communication issues.

~~~
justwalt
Same, it seemed like the story was building up to something and then ends
abruptly with that quip.

I think at some point, the average poster on that subreddit started posting
longer and longer stories rather than just humorous short ones, and that’s
when it became less enjoyable to read. There are folks who post stories with
“chapters” that become wildly popular, but they’re always very light in
substance. I don’t see the appeal.

------
motohagiography
Every enterprise project ever. If you don't set personal boundaries at the
outset, that client is just going to ride you until you drop. Consider what
people who don't make things actually do for a living. They "manage" dynamics,
which means you have a black box with inputs and outputs, and your job is to
constantly tweak and regulate the inputs to increase the outputs. The black
box in this case is the author's project, which he is describing being tweaked
and regulated to produce an output. The problem is the author demonstrated to
the customer out of the gate that being dominated gives the desired output,
and so the author received the behaviour he specifically rewarded.

A product manager or owner can handle a dominating customer by managing those
boundaries. Not all PMs do, but this customer would have been manageable if
either the author or his boss had a spine.

Consider that the extreme of agreeableness becomes oily, deceptive, and even
mendacious when someone is pushed past their limit, which is why so many
managers can seem untrustworthy. The cycle was that this "Alpha" customer kept
pushing to see if the author had a bottom or backbone, and when he didn't find
one, he became less and less trusting, pushing even more and then finally just
taking control of a process he perceived as out of control for lack of
anything solid.

~~~
geon
Thanks for your insight. You may very well be right about the client looking
for more resistance.

How could I have given more resistance? I don’t see how I could have had more
of a “spine” without it turning into a shouting match. But perhaps that was
what the client wanted?

Having had all my opinions so completely disregarded was very frustrating. I
seriously do not believe it would have been possible to somehow educate the
client and help them understand the need for my suggested changes.

The only option left was dropping them. Or was there any other solution?

~~~
motohagiography
The longer it was left, the harder the change would have been as by the time
you had to drop them, the relationship was considered unsalvageable by all
parties. I think your boss should have taken more ownership earlier. Turning
it around probably wasn't going to happen because it would have been a 180
renegotiation of how you related.

To be fair, the customer also seemed to hustle you with a variation of "if
you're a good guy, do me this small favour?" followed up with, "why won't you
do me this next favour, I thought you were a good guy, now I'm unhappy..." and
then leveraged the sunk cost you already put into the project to add
incremental scope.

The conversations I have begin with things like, "let's decide on outcomes and
we'll get you there." Full stop. This is before you start working, because if
you start working without an agreed outcome, your project is not delivering
professional service value, it's being their employee. You're doing the
favour. I get Agile is iterative with constant customer feedback, and this
customer wanted a waterfall commitment process, but the job of your boss (imo)
was to bridge those needs.

It's great when a customer is happy, but that's the effect of providing value
and solving their problems, happiness itself is not the job. I wouldn't worry
about shouting matches, they're just a front. It's never the biggest dog that
barks. Personally, I'm immediately suspicious of people who act unhappy
because they only act that way because they think it works. So there wasn't a
tactical change that would have made this relationship different, but there is
a different way to relate in general that will ensure it doesn't happen again.

~~~
geon
Thanks. Very insightful.

> To be fair, the customer also seemed to hustle you with a variation of "if
> you're a good guy, do me this small favour?" followed up with, "why won't
> you do me this next favour, I thought you were a good guy, now I'm
> unhappy..."

Yup. Was I being manipulated?

------
lordnacho
The problem is the relative social status between the client and Geon.

If the client had heart palpitations and Geon was a cardiologist, this
wouldn't happen. You would not have Mr Alpha explaining to the doctor how he
needs to do the scan and the surgery, and being very cross when he didn't get
his way. Even though Mr Alpha probably cares more about his heart working than
a user interface.

The same goes for pilots and other professionals, they get less crap than they
would if they didn't have some sort of status that prevents most of the
I-know-best crowd from sticking their heads in.

For some reason, software doesn't have that feel to it. In many places, it's a
sort of implementation detail, where the generals have already decided the
strategy, and the devs just have to follow the orders.

It would be good with some cultural change around what people think devs do
and what you can say to them.

~~~
SifJar
> If the client had heart palpitations and Geon was a cardiologist, this
> wouldn't happen. You would not have Mr Alpha explaining to the doctor how he
> needs to do the scan and the surgery, and being very cross when he didn't
> get his way.

This is a bold assumption

~~~
lordnacho
I'm not saying nobody's ever done that. But you cut most of the little
annoying people with a bit of status. Ever sat in a lecture by someone famous,
vs one by some random grad student?

~~~
csours
Most people take doctors seriously, but "Alphas" do exactly the same thing to
doctors and lawyers and other professionals that they do to programmers and
tech support etc.

------
umvi
I was hoping Geon was going to do a psychological trick to make the client
happy, but nope... "the trick" is to just stop caring (spoilers).

With people like Alpha you have to be very strict about adhering to the
contract and not an iota more.

It's like the classic meme:

"I design everything": $100

"I design, you watch": $200

"I design, you help": $500

"You design, I help": $1000

"You design, I watch": $5000

"You design everything": $10000

------
controlledchaos
I gotta say. I am not impressed with how the author handled the client
interaction. There are better ways to handle a stubborn client other than,
“I’m better at this than you are and that’s that.” There doesn’t seem to have
been a clear understanding about what the scope of the project was, so Alpha
really thought it was his project to do with what he pleased. The author does
indeed need to work on his people skills. Communication is weird, complicated,
and important.

~~~
geon
> There are better ways to handle a stubborn client other than, “I’m better at
> this than you are and that’s that.”

While I can see how you got that impression, it is not how it happened.

I carefully explained all my suggestions and backed them up with UI
conventions, implementation details and code reuse. Nothing helped.

For example, the same data could be edited from 3 subtly different screens. I
suggested it should be broken out into a separate dialog that could be reused.
It would be more consistent, be more in line with virtually all other
software, quicker to implement and less error prone. No go.

~~~
uldos
Don't want to sound arrogant, but it seems that projects like this was a good
lesson for you. With one lesson (among many others), that "I carefully
explained all my suggestions and backed them up with UI conventions..." will
not work with some people (technical ones) and there should be other styles of
communication in your toolbox. I learned this the hard way when I wanted to be
a freelancer and had to do everything (coding, managing project, accounting)
on my own. Now I work at a company as a coder and project managers are
"shielding" me from clients eccentric needs.

------
YeGoblynQueenne
>> Alpha: No. Since we have little time, it is important that you complete one
powerpoint screen at a time and NOT go back to it. When it is done it is DONE.
I absolutely do not want to hear that you are rewriting code that has already
been completed.

This reminded me of something an acquaintance had once said, about "the least
productive workers", by which they meant programmers. It seems this is a
common theme among non-technical co-workers at tech companies. Basically,
there is a sense that programmers somehow overcomplicate things and that
everything would go so much more smoothly if only programmers learned to do
the simple thing that everyone else can see is so easy to do. Common sense,
innit.

The same spirit is behind requests to do something "simple" that "doesn't need
much work". "It's just a few lines in SQL, you can do it real quick". Of
course, it never is. But if you say, "yeah, it's easy, I'll do it" (because
you haven't learned yet) it _will_ take a lot of work, you _will_ take much
more than a little time and they _will_ be displeased with you because you're
"taking so long for something that is so easy".

~~~
larrywright
I once sat in a meeting where a high up person was giving us requirements for
a new feature she wanted to add to our application. It was adding a button to
the screen, and when the user clicked the button it would initiate some
complex logic and actions that would be invisible to the user.

When we gave her the estimate for the change, she went nuts. She couldn’t
understand why it was going to take so long and cost so much. No matter how I
tried to explain it to her, all she said over and over was “It’s just a
button!”.

~~~
_ZeD_
"so, you want just a button? or a button that _works_?"

------
edw519
Customers almost always know "What" (they're not making this up).

They usually know "Why".

Then never know "How".

So, the "What" is theirs, the "Why" is ours, and the "How" is mine. All
documented and agreed upon before a single line of code is written (except for
a prototype, wireframe, or proof of concept).

Take the time and energy to do this up front or stop caring. Your choice.

------
sequence7
Everyone seems to come out pretty badly from this story.

The client clearly isn't good at working with people.

As noted by controlledchaos the author isn't good at working with clients,
communicating complexity is hard to do but it's essential to work through this
with a client. It can be very frustrating and takes a lot of time but just
stating that you're an expert is never going to win anyone over. You have to
demonstrate that fact to them and understand their goals and motivations.

The author's boss sucks, he basically threw the author to the wolves and only
stepped in at the last minute by which time it was too late.

The senior developer's advice to not care is toxic.

------
csours
Lots of comments here, none about the core of the issue as I see it.

OP and OP's manager allowed "Alpha" to design the UI, and then to state that
the mocks were the specification.

There's no shorter road to frustration than allowing UI mocks as a
specification. UI mocks as a talking point are great; UI mocks as a spec are
cancer mixed with broken glass. See [0] for some discussion from yesterday.

Words in a spec are abstract, but pictures are concrete. People get fixated on
pictures. People also fall in love with their own creation. Allowing the
customer to create the mocks almost guarantees that they will not be
reasonable about them. Not only are they in love with their ideas, they're
also in love with their imagined implementation.

I get it! Imagining the implementation is my favorite part of software! For
someone with lower introspection and empathy it can feel like an attack when
someone wants to change the thing you've fallen in love with.

0\.
[https://news.ycombinator.com/item?id=23837406](https://news.ycombinator.com/item?id=23837406)

~~~
geon
> People also fall in love with their own creation.

That was exactly what happened! I have used those exact words when talking
about it.

> Allowing the customer to create the mocks almost guarantees that they will
> not be reasonable about them.

Oh. I wish I had known that. Any other examples you can share?

~~~
csours
I work on mainly company internal projects, so not exactly equivalent. I had
two projects shortly after transitioning from tech support to test where the
pictures of the UI was the specification. After having a terrible experience
on both of them, there was another project where the "owner" wanted to give us
drawings of how the screens should look. We let them make the drawings, but we
did not track them as requirements or specifications. It went all right, not
great.

I've worked on other projects where we had an actual UX designer, and those
went much better. UX is not taken very seriously by many people in tech, but
it's our equivalent of industrial design.

------
zug_zug
I read this hoping there was going to be some educational "trick" it taught.
Was disappointed, just sounds like somebody who wants to be purely technical
is stuck working with difficult people.

Geon should either change or jobs (to something less client-facing), or accept
the job as it lies, which would involve recognizing
psychology/therapy/emotions is a huge part of client interactions. In this
case "alpha" clearly has a lot of emotions influencing his decisions,
understanding those and getting him to like you is probably part of being a
good contractor.

If he perceived his work was dealing with a complete wildcard, and managed to,
that's something Geon can take pride in.

[Not to say any of this is common-sense, when I was young I probably would
have felt like such projects were a waste of my time]

------
arethuza
I literally had someone tell me once after a demo of progress on a project: _"
That may be what I asked for but its not what I want"_.

~~~
pastorhudson
Depending on the tone that could show a lot of self awareness. I’d respond “I
totally understand! That’s why we said at the get go this stuff is hard.
Sometimes we can’t see what we want till we try to build it. Let’s figure out
what’s off about this and setup some more sprints.”

~~~
arethuza
I very much took the tone to mean: "I'm a very senior manager at this company
and I can be as unreasonable as I want and you can't do much about it".

It was an internal project at a large company and there was a fair amount of
politics. I just loved how he managed to say something like that without a
trace of contrition - not like this was the first time he'd seen it.

------
lmilcin
Well, so there is couple of issues with "not giving a shit".

The problem is that it is all too easy to normalize this and get in a habit of
stopping giving a shit for smaller and smaller reasons. You begin
rationalizing your reasons and at all times feel completely justified in your
not-giving-a-shit attitude.

I don't want to be the person that doesn't give a shit. "Not giving shit" is
exactly opposite of what I would like to be doing. The moment this happens I
feel I will become mindless drone that I have complained about for so long.

I believe solution in this case would be to stop for a second and propose to
clearly attribute design to the person that proposed and required the design
to be this and not the other way. Being able to decide something is in my book
synonymous with responsibility. If I decide, I take responsibility for the
decision, if I do not decide, I feel no responsibility. It is just a matter of
communication to explain to everybody else who is decisionmaker in which
aspects of the project.

~~~
odonnellryan
There's a difference between not giving a shit and not allowing this type of
behavior to impact you negatively. I might casually describe the latter as not
giving a shit.

~~~
lmilcin
I think if you care for your project and take pride for the result it is going
to be difficult to separate both (not impossible, just extremely difficult).

I personally find it very difficult to accept outside direction to meddle in
the project if I see it is clearly unwarranted, meddlesome and damaging to the
project.

If I feel responsibility for the wellbeing of the project I also feel
responsibility to act on such damaging attempts and it is difficult to act
with conviction if you feel dispassionate.

------
legulere
> to plan everything out in detail and start building it all at once very
> rarely works, is expensive, slow and can’t handle changing requirements. And
> requirements always change.

I’m struggling with the opposite. 90% of what we have to do is realizing
requirements we get from externally (our competitors get the same requirements
more or less). We can only release an update when we have done all the
external requirements. Still we’re supposed to be an agile company so you
don’t work directly with the external requirements but a project manager
creates a stream of work items, so you never have the time to try to get the
big picture.

Most of the time you don’t know what you have to create and working in
increments makes sense to find that out. But there’s also stuff that you can
plan for ahead. If you don’t you will end up with a worse product and you will
also drive people mad.

------
Y_Y
The title isn't very good, but neither is the story.

------
BlakeMcLeod
User testing the UI is a powerful tool to keep scenarios like these from
creating scope creep and bad design. Your client wants to design? Sure, we can
test that design and see if the target audience can use it to accomplish your
business goals.

------
skmurphy
It seems like the core of the disconnect was that the customer ("Alpha") was
designing screen using power point at a font size and page size that did not
translate well into actual screen real estate. I wonder if the developer could
have provide a PPT template that had a page size and font size that would
minimize the gap--and first prototyped in PPT to point out problems at low
cost.

~~~
geon
> and first prototyped in PPT to point out problems at low cost

That part actually worked excellently. The problem was that when the problems
were pointed out, they were completely disregarded.

------
xwdv
I had an annoying micromanaging client like this once that insisted on
designing an entire UI and then just having me implement it exactly as is, of
course the design was terrible.

When I suggested why he didn’t just write up some code to go along with it, he
told me he doesn’t know how to write code.

And I replied that I was confused, because until now he seemed very confident
doing shit he knows nothing about.

Never heard from him again.

------
cammil
In my opinion:

If you cannot communicate effectively with your customers it is your fault,
not the customer's.

The customer _is_ always right in the sense that they are the only ones that
know what they want, like and don't like. Either you can figure that out
correctly or you can't. That is a very important part of your job.

Whether you want to deliver what your customers want is a whole other
question. You don't have to deliver things you haven't agreed to.

Basically, I think the author of this post has a poor perspective, and another
one might work much better for all involved.

------
tmaly
Great post. He should have just sucked it up and billed the hell out of
Alpha's company. Let him pay for his ways.

------
CapitalistCartr
"Alpha" is a sociopath. You'll never win playing their game; document
everything in writing, fire the customer as soon as posible.

~~~
kerkeslager
It's unlikely that you've achieved a difficult clinical psychological
diagnosis by reading a one-sided second-hand account.

~~~
corty
"sociopath" isn't even a diagnosis in most of the world. That said, there is a
distinct recognizable group of people exhibiting such dominant-abusive
behaviour and they are easy to recognize. We all know our schoolyard bully or
neighborhood tyrant.

~~~
kerkeslager
> "sociopath" isn't even a diagnosis in most of the world.

The fact that much of the world doesn't consider this a valid diagnosis even
when it's done by a professional does not add credibility to your amateur
diagnosis.

> That said, there is a distinct recognizable group of people exhibiting such
> dominant-abusive behaviour and they are easy to recognize. We all know our
> schoolyard bully or neighborhood tyrant.

Yes, we all recognize these archetypes of people who, more often than not,
aren't sociopaths.

------
rkagerer
Never let the client dictate the _how_. Focus on outcomes.

It sounds like this was a tough person to work with. I've been a consultant
(independent and on behalf of larger enterprise vendors) for some 20 years.
After reading your story, that's my strongest piece of advice to you.

Would you tell the carpenter renovating your house what technique he should
use at his tablesaw? Try it and see how long it takes before he walks off the
job.

" _I began to explain the methodology we like, that I personally as well as
most of the software industry believes in; minimum viable project. In
essence... "_

Your shop uses MVP, tell them that's how you'll deliver. Don't get technical.
Just "we'll start with a small prototype to get something in your hands
quickly, then fill in the features from there".

 _" Whoa! The sketches have suddenly become a specification. Inconsistencies
and all."_

Good on you for recognizing what happened. When you realized the PowerPoint
became a defective spec, you needed to go back to the client and make them fix
it before you accepted it. "Sorry, what you've sketched for this room can't be
built."

That's part of your job. It's clear you have a lot of professional pride -
don't be an architect who allows construction to begin knowing the rafters
will crash down on someone's head.

 _I carefully explained all my suggestions and backed them up with UI
conventions, implementation details and code reuse._

Readiness to explain your recommendations is an asset. Unfortunately this time
you were speaking into a black hole. I'm sure by this point you saw the
pattern in your working relationship with the customer - the more detail you
expose, the more control over it they try to exert. With this guy in
particular, you need to actively avoid that trap, and project strong signals
as to what is and is not in his purview. Clearly the client was invested. A
really talented PM will steer that energy to where it's useful (or at least
someplace less destructive).

Again, avoid diving into nitty gritty implementation details and talking about
things like "code reuse" with the client. You're not selling them a
methodology, you're selling them a product.

I hate to say it, but ultimately I think you needed to "alpha up". It's clear
you were intimidated by this guy. He's big, strong, powerful, older and bull-
headed. If you met him and his clan in a tribal woods setting it would make
sense to submit. But in a software development setting, you're the authority.
Act like it. You're not a junior fellow. You have good judgement, a wealth
experience and a strong sense of what works and what doesn't. BE the expert
the client is paying you to be. Be opinionated on the stuff you know. Flex
that opinion, and don't be afraid to tell a client "that won't work, here's
why". It's good you want to make them happy, but that doesn't mean blindly
doing everything they ask. A customer relationship is just like any other, and
it's normal for some frustration and conflict to develop along the way. Don't
be afraid to exercise your professional judgement and take charge.

Work on projecting confidence. You don't even have to pretend - confidence can
come from experience, and this project was a formidable teacher. Draw on this
well next time you need to convince yourself to be more assertive.

There's a comment elsewhere on this page suggesting ' _the problem is the
relative social status between the client and Geon_ ' and you mentioned your '
_suggestions were so completely disregarded. There was no motivation, or
reasoning given. Just "no, do it my way"_'. It's also been proposed this
wouldn't happen to a doctor or cardiologist.

I think software developers tend to be more reserved individuals; there's even
this colloquial stereotype they're what became of the "wimps" you knew from
childhood. Behind that cautious demeanor may be someone who really knows their
stuff. If doctors don't have to deal with condescension as often, one reason
is they don't put up with it. Mine would probably tell me firmly "Decide as
you will, but I'm the expert and I'm telling you X is a problem, you need to
do Y, and if you don't, Z will happen." They'll also refuse to prescribe or
perform a procedure they feel is plainly not in the interest of the patient.

Please don't take the advice of your coworker to stop caring. Rather, care
enough to push back. Hopefully you work for a company that will support you.
If I was your CEO I'd put someone with grey hair on the project to help stick-
handle this client, and if that didn't work I'd intervene personally to
clarify the roles (which we tend to set out clearly in our contracts).

------
dilandau
If his boss/company weren't desperate for the contract, they wouldn't tolerate
crazy shit like this. If the customer has no incentive _not_ to ask for
whimsical shit all the time, then they're absolutely going to ask for
whimsical shit. This is especially a huge problem when you are dealing with a
group of people rather than project-manager to project-manager, although that
doesn't sound like the case in this story. At any rate, here is my take: find
a better job for a more financially secure company. Then you won't have to
deal with flakes.

