The Trick
reddit.com
reddit.com
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.
The danger is that you may start to look for a point of no return when there are still paths forward. It's easy to develop bad habits that make this a more common scenario than it really should be. I don't know the answer to this, other than to make sure you aren't the problem. It requires constant, honest assesment from yourself, and (perhaps just as important) from others.
It is very important to separate the domain of responsibility:
What to do -> the client
How to do it -> the developer
Sure, there can be interactions both ways between the dev/architect and the client but you must be ready to defend your borders (i.e. the implementation) very fiercely with difficult clients. The dev didn't do it and got no respect back.
I can't blame the poor dev too hardly though. Life really sucks when you have to work against your boss and the client.
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.
I worked for a company where one of the owners signed a contract that said we would do "some" enhancements to an existing system, and the client defined when the project was complete. Amazingly the executives were dumbfounded when the client took full advantage of the word "some" and wouldn't pay until everything they wanted was complete.
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?
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.
> 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?
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.
When we act like a coding-machine, we get treated like one.
Not only the social hierarchy, but age/experience and projected confidence.
At least I think that was it. Because my suggestions were so completely disregarded. There was no motivation, or reasoning given. Just “no, do it my way”.
This is a bold assumption
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
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.
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".
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!”.
1. Most of what we make (in software) is invisible to the user. So when they see a shiny GUI they think that's it, they don't see the 10 million SLOC underneath it making everything work across dozens or hundreds of servers of all kinds. If you make a change that makes the whole thing more stable or slightly faster, but doesn't impact the presentation, they think you've done nothing but remove, their conception of, a sleep(1000) from the code somewhere.
2. Our code is, hopefully not the entirety of, our design but also our implementation. As we add things we have to change the design because of a realization ("Oh! This is redundant, I could collapse this into a common class or template and then specialize for these 4 cases, I've just removed 40k lines of code and made maintenance a crap ton easier!") or a change in requirements ("The customer needs us to store phone numbers and send reminder calls based on appointments, how do we want to do that?"). In other engineering disciplines you (generally) spend a lot more time on the design before you get to the implementation. You don't build half a bridge while finishing the design for the other half. But our software does seem to come out in that fashion because requirements aren't fixed, or it's hard to delineate between prototype and final product.
These things, combined, account for most of the issues I've had trying to explain schedules and delays to people, or why we had to scrap 10k lines of code ("You wasted three months writing that!").
The analogy is flawed, because ”building” the software is the job of the compiler. Programming is all design.
And many bridges can be built using the same design, possibly with some parameters adjusted. When the same thing is done with software, it is so trivial to recompile that it doesn’t “count”. So you get fully custom software design compared to routine “compiles” of bridge blueprints.
Then you do it again.
Then again.
Then some more.
Suddenly it's not that easy anymore.
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.
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.
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.
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?
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.
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]
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.
You can ask people to think through how the software should work, and they may earnestly do their best, and they may give you clear answers about what they truly believe they want. But put the actual software in front of them and show it in operation or (better) have them try to use it, and suddenly a bunch of new insights will become crystal clear to them.
In theory, people could reason through all this stuff, but it's not how most people's minds work. It's a natural tendency to avoid engaging your mind in what feels too hypothetical. Most people need to feel like they're in the actual situation before the mental juices really start flowing.
The corollary is that the earlier you can do a demo, the less time you waste working toward requirements that are wrong. If all other things are equal, doing demos as early as possible should minimize that.
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.
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.
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.
That part actually worked excellently. The problem was that when the problems were pointed out, they were completely disregarded.
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.
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.
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.
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).