Live data from Hacker News

Balancing engineering cultures: Debate everything vs. just tell me what to build

fishmanafnewsletter.com

31–40 of 128 posts

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#31
post #9
post #4

Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want. Maybe schedule in some rework time to try again. That way, developers move quickly and sooner or later start building useful things. "Just tell me what to build" is a dangerous attitude to foster. It pushes more work into the management layer which is already a bottleneck for ma…

> Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want. My preferred method of development is tell me what you think you want, then be available for the stream of questions I'll be asking you to make sure what you need is accomplished. I've found that it's almost always a bad idea, for everyone involved, to implement what someone s…

Very much this. I have a long-standing saying that I share with those that want to bypass the "explain your goals to me" portion of the conversation and want to skip to "just do what I asked."

"Be very careful what you ask for because if I really dislike you I'll give you EXACTLY what you ask for and you'll find out quickly how much you didn't want that."

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#32
Sometimes (but not always) the reason for these cultures is more due to nature than nurture, in which case it can be virtually impossible to change without replacing people.

I worked on a team that went from a very strong "debate everything" culture to a very apathetically strong "just tell me what to build" culture, and it was primarily due to the hires we made. We hired for the ability to grow technically, and that certainly proved true. But the interest in the "why" behind the work never developed the way the "debate everything" folks assumed would happen with all good devs. The QA team cared, and remained in "debate everything" mode, but the dev team eventually just wanted to be left alone to focus on relatively meaningless (without context) work. No amount of connecting the dots to real user need seemed to really get through. They just wanted semi-challenging technical problems, and a paycheck. Nothing wrong with that in moderation, but it ended up infecting the entire team.

So be careful how you hire. If you have a blind spot for this phenomenon and hire exclusively for technical skill and/or potential, you might just get unlucky and end up with a critical mass of "just tell me what to build", and then you're screwed, because you'll have a technically strong team that has zero interest in understanding the bigger context of their work, forcing you to choose between getting sucked into the codependent relationship, or resigning yourself to doing the wrong thing with great technical prowess.

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#33

I think "debate everything" comes from: 1. Uncertainty. People haven't done X before, and are concerned about the outcome, so they delay, by debating. They don't know whether they're right or wrong. They're really just trying to figure out their own opinion. So they will bring up objections, even if they don't actually have a concrete reason to object. They just literally don't know if something is valid, so they pos…

I believe there is a form of PTSD that develops within toxic software development jobs and I wish it would receive more legitimate attention and treatment options.

I have tried to explain to my therapist why I have developed something like PTSD around peer reviews... yes, we all say "you are not your work" but that does not excuse being (dare I say) abusive in comments on PRs.

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#34
post #6
post #4

Culturally it is best to train developers to just do something, then provide non-judgemental feedback when what they do isn't what you want. Maybe schedule in some rework time to try again. That way, developers move quickly and sooner or later start building useful things. "Just tell me what to build" is a dangerous attitude to foster. It pushes more work into the management layer which is already a bottleneck for ma…

I don’t live in an alternate universe where “Maybe schedule in some rework time to try again” ever actually happens.

Maybe look for a new job?

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#35
post #19

The endless debates wear me out. Sometimes I just want the engineers to just do. It's labor for me to tell someone their idea is bad, both mentally and emotionally. At the beginning of the relationship, you have to engage in that labor to get people to trust you. But if it continues to break down, I try to figure out why and it's usually because another designer/PM were flippant in their choices.

I wonder why your engineers are endlessly sharing bad ideas, I haven’t run into that

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#36
I had such a great company social night, talking with an engineer who got his start here ~5 year ago.

They were taking about how they just want people to have a well formed idea of what to build, to be able to hand off clear expectations, and let him roll. For curiosity sake I started asking about other times: has there been a time where you've felt on the line, been the one who has to figure out what to do?

They paused for a bit & then said yeah, actually... They had been battlefield promoted after two higher ups on a team had left & it was just them running this product. They said they had little idea what they were doing but the company trusted them & let them hack through it. They loved that time. Finding out what to doz being given problems and the freedom to solve it was a highlight of their life, they said.

A lot of people don't want to play the game. Especially when we are forced to collaborate with non-technicals, it's incredibly hard to justify and explain ourselves & to share power & compromise with these people who lack competency to judge, assess, negotiate.

The title here omits the gods truth as an option: we the engineers know & can assess & you the business/product don't have the technical chops to debate, nor do you understand what is to be built. The premise presented is "debate vs do" as they say it, as though product and product alone understands do. But I think most engineers live in pain and dissonance and sadness, feel an incredible impedance and struggle, because most businesses/product have only the faintest fragmentary fake propped idea of what do is. It's a fiction. And it's up to engineers to cobble together some vaguely competent rendition of the fairy tale nonsense product tells itself it's come up with and that engineers need to just do.

The phrasing here could not be more slanted. Run, engineer, run, from the dented terrors that would think their product sensibilities have fully flushed out the idea, that think there is no cause for "debate" or sussing out how really to do a things that think only to "do" what the master product says is necessary.

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#38

This is the most common failure mode I’ve experienced: > A critical piece of avoiding endless debate is to know who makes the final decision and how it gets made. Consensus-seeking leads to endless debate. Every rapidly growing company I’ve worked for has reached a point where we have product managers and program managers and engineers and engineering managers and stakeholders and suddenly nobody can even identify wh…

I don't think consensus-building is necessarily bad on it's own. Depending on the environment, when people don't feel like they have an opportunity contribute, it can potentially lead to other issues.

To your point, I think a lack of leadership can kill a consensus-building process. Whoever is coordinating needs the authority and will to end the discussion when the time is right (among other things.) Otherwise, it really can become endless debate and drawn out attempts to get some unwilling party onboard.

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#39
post #5

Brought to mind what I am reading in Corporate Rebels and really like the concept that Haier used. https://www.corporate-rebels.com/blog/next-influential-manag...

This Haier? https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Where a bunch of corporate fascists took such umbrage over debate/exploration over how their corporate envisioned scenarios were to work that they started pursuing legal action? Against open source people making Home Assistant integration?

These people basically went thermonuclear in terms of cancelling possible debate & enforcing top down decision making. Utterly unwilling to listen or permit a single other opinion other than what their top-down management built.

I cannot think of a better company to serve as a warning sign for what to never ever do. Seeing yourself & your own vision of the product as God & any deviation or discrepancy or other opinion as something to be squashed. Usually lawyers aren't involved as Haier did in their quest to stop out undogmatic use, but alas this kind of managerial hubris & self importance from the product world seems all too typical & all too poisonous; an unwillingness to let anyone else explore bounds of possibility, lest it gets in the way of those egos assured they've built a perfect little terrarium for the users to play inside.

They calmed down eventually, with an incredibly useless & empty press release hinting that they were backing off. But this seems like one of the most powerful examples of a company chuffed up on hubris unwilling to permit even the hint of debates.

Re: Balancing engineering cultures: Debate everything vs. just tell me what to build

#40
Organizations that debate everything and do nothing are afraid of other people being upset with them for doing the wrong thing.

Organizations that do nothing until someone else tells them what to build are afraid of sticking their necks out for some dominant manager to just ignore them anyway.

This is why executives and managers are recommended to foster psychological safety. Respect the efforts of people who built some skunkworks project, then discuss realignment with them afterwards (understanding that you, the executive, may need to be the one who re-aligns). Encourage people who never stick their necks out to start to tell you what they think, even if only privately at first, and eventually hopefully they'll start to join the discussion too.

There's a lot of talk about clarifying who exactly the decision-maker is in any situation. It's a nice fantasy to think that the decision-maker should always be some kind of manager or executive, but the truth is, if you issue a dictate from on high to someone to do something that they deeply disagree with, eventually everybody's going to leave. That's not the way you lead people. Ultimately, the person who does the work is the person who decides - all that you can ask from them, as a manager, is for them to listen to you (and other stakeholders) first, especially since someone who never does as they're asked is someone who will, sooner or later, get fired. But no manager can truly control the actions of their subordinates, and the wise manager understands that and channels that into productive workers who are mostly (but never fully!) aligned with the organization.

Post reply on HN