"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.
> "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.
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.
> 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.
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.
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.
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.
I agree. This was a long boring joke with an anti-climactic punchline. This guy sucks at handling his boss and his client. I've done agency work for over a decade now. I've worked with people like this and they're annoying.
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.
It’s more about the realizations that there are things making your life at work a hell that you simply cannot do anything against. It also shows the only two options that you have to get out of that situation: moving on, or stopping to care.
I am not a fan of it either, but it's a scenario that you will eventually run into the longer you are at it. At some point you have to cut your losses. Part of that is deciding what the personal investment has cost you over time versus moving on to the next thing and striving to learn when there is no sane way forward.
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.
I agree. His boss is very much to blame for this. He is awful, basically siding with the client against the team he is meant to protect.
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.
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.”
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.
I believe one of the main benefits of demos is to expose that disconnect.
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.
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]
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.
The saddest part of people's education in this field is that no one tells us the details about software development. Programming is about computers, but software development is about people. When I was starting out no one explained to me that everything at work is a negotiation. Always being agreeable isn't good for you and really not the person you're talking to either. You need to come to an understanding with them that if they are asking for something, you are going to define for them what they should expect in return. At times, sure, you say, "Yeah that's no big deal." and other times, it's "This isn't a wise decision we need to take another path." Most of the time it's somewhere in the middle and you need to understand how to talk to someone to come to a compromise and get what you want to.
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.
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?
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.
> 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..."
Where was the project manager in all of this? There should be a dedicated person whose role is to manage scope creep, track milestones and completion, be firm on commitments, handle/mollify the personalities on the client side, etc. If you were being expected to do this as well as doing the code, you should have asked for two salaries!
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.
> 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.
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?
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.
> The problem is the relative social status between the client and Geon.
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”.
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.
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.
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.
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.
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.
>> 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".
Abstractions leak, bad interactions occur, you have to refactor, or work around bugs or -worse- design flags in various interfaces, and now the simple thing ain't.
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!”.
There are two (related) problems that I've experienced here.
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!").
> 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
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.
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.
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.
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.
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.
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.
> 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.
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.
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 col...
60 comments
[ 2.8 ms ] story [ 130 ms ] threadThe 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.
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.
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.
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.
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.
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]
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.
This is a bold assumption
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”.
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
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.
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
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.
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.
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".
Then you do it again.
Then again.
Then some more.
Suddenly it's not that easy anymore.
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.
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.
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.
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 col...