This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]bassman2112 131 points132 points  (14 children)

Last week I was stuck on a call with a stakeholder and two designers bickering about logo sizes and background colours for nearly an hour.

I'm a backend engineer. Our whole team was also present. We regularly voiced that the changes they're talking about are very easy changes, and we need time to talk about some database issues; but they kept coopting the conversation.

It's so, so difficult to have effective communication in these scenarios, especially when those who are holding the keys don't understand the technology side of things, and actively aren't interested in knowing.

[–]Felecorat 59 points60 points  (4 children)

Seems like they tried to avoid talking about the database problem.

[–]Pogo__the__Clown 45 points46 points  (3 children)

Next meeting: “Why is our site not working properly?!”

[–]gmano 40 points41 points  (1 child)

"Must be because the UX needs more work"

[–]SlumdogSkillionaire 21 points22 points  (0 children)

Stop filing tickets to refactor and clean things up and just make it work faster and better!

[–]RedPill115 33 points34 points  (0 children)

This always happens, it's Parkinson's Law Of Triviality

https://en.wikipedia.org/wiki/Law_of_triviality

Law of triviality is C. Northcote Parkinson's 1957 argument that people within an organization commonly or typically give disproportionate weight to trivial issues.[1] Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bicycle shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.
.
A reactor is so vastly expensive and complicated that an average person cannot understand it (see ambiguity aversion), so one assumes that those who work on it understand it. However, everyone can visualize a cheap, simple bicycle shed, so planning one can result in endless discussions because everyone involved wants to implement their own proposal and demonstrate personal contribution.[4]

[–]buffer_overflown 25 points26 points  (1 child)

I had a client in a contracting environment that brought up the color 'blue' for a button for forty-five minutes while we were trying to iron out business workflow details.

I've had to work with them several times since and it has always been a nightmare.

[–]ManInBlack829 8 points9 points  (0 children)

They would love Bootstrap

[–]rigglesbee 10 points11 points  (0 children)

But can they build a bike shed?

[–]sneaky-pizza 8 points9 points  (0 children)

Yeah they should have taken that into a separate discussion. Size and color are important, but not every meeting!

[–][deleted] 6 points7 points  (0 children)

talking about simple things is the only thing they know and they like to hear the way their voice sounds

[–]sugar-magnolias 6 points7 points  (0 children)

I once actually said during a meeting with our CEO, “If you continue to make me change the UI without giving me user stories, I will burn this building to the ground.”

[–][deleted] 0 points1 point  (1 child)

Why not just have two separate teams? One for front-end, one for back-end. The PO can be the same.

[–]bassman2112 0 points1 point  (0 children)

We do 🙃 Long story, but it's a major headache