Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fishmanafnewsletter.com

Post reply on HN
Print view View original

81–90 of 128 posts

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

#81

Post by marcosdumay »

leetrout wrote: post #33
throwawaaarrgh wrote: post #14

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.

As a rule, work related trauma is a tabu that can not be mentioned in any circle.

And, since software development is a mostly creative work, software developers are strongly impacted by it.

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

#82

Post by Reimersholme »

llamaLord wrote: post #68
Aurornis wrote: post #13

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…

As a PM, I believe what you're describing is the torrent of people who used to work as "project managers" and "business analysts" who've transitioned into Product for the higher pay, without appreciating any of the differences between the roles. IMO, the fundamental role of a PM is to make the decisions nobody else wants to (and own the consequences of them). If my team is making progress and decisions are being made…

[dead]

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

#83

Post by starbugs »

DeathArrow wrote: post #60
Aurornis wrote: post #13

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…

So we're better with benevolent dictators.

> So we're better with benevolent dictators.

Making a decision based on input from relevant coworkers while being competent in the domain you are making the decision in isn't exactly dictatorship?

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

#84

Post by agentultra »

I didn't really vibe with this dichotomy but I did get the sense that both of them seem like a symptom I have seen often:

Too many chefs, not enough cooks

In general this happens when companies over-value management. If you find each "team" of 3-7 software developers have at least 3 "managers" on the team (in addition to the visual designer and other folks in productive roles): you've got too many chefs. Decisions have to go through the committee, the process, etc. Software developers that are making the product itself are rational, intelligent, capable people whose hands become tied behind meetings, documents, and permission-seeking. Too many chefs make for busy work and they focus on the wrong work.

One manager for 5-8 software developers is often good enough. Someone who interfaces with HR, handles administrative tasks, and is the voice of the team to the rest of the company at meetings. A good manager enables the team to do their best work and stays out of the way.

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

#85

Post by [deleted] »

blitz_skull wrote: post #72
llamaLord wrote: post #68

Earlier quoted context omitted.

As a PM, I believe what you're describing is the torrent of people who used to work as "project managers" and "business analysts" who've transitioned into Product for the higher pay, without appreciating any of the differences between the roles. IMO, the fundamental role of a PM is to make the decisions nobody else wants to (and own the consequences of them). If my team is making progress and decisions are being made…

Damn I wish any PM I had ever worked with had this attitude. Honestly I don’t recognize any of this ownership in the last few companies I’ve worked with. PMs are just people that don’t talk with customers, review a product backlog, and cover their eyes and point at the Feature du jour. I wish more PMs had your ownership approach.

[deleted]

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

#86

Post by williamcotton »

llamaLord wrote: post #68
Aurornis wrote: post #13

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…

As a PM, I believe what you're describing is the torrent of people who used to work as "project managers" and "business analysts" who've transitioned into Product for the higher pay, without appreciating any of the differences between the roles. IMO, the fundamental role of a PM is to make the decisions nobody else wants to (and own the consequences of them). If my team is making progress and decisions are being made…

Mismanagement leads to failure. Failure leads to layoffs.

We’ve hit industry maturity with ever slimming margins but with management still operating like costs don’t mean anything. If management was doing their jobs they would discover the cost of meetings and ultimately the cost of indecision!

PMs shouldn't have to fix organization dysfunction while operating in Hero Mode.

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

#87

Post by michaelmior »

agentultra wrote: post #84

I didn't really vibe with this dichotomy but I did get the sense that both of them seem like a symptom I have seen often: Too many chefs, not enough cooks In general this happens when companies over-value management. If you find each "team" of 3-7 software developers have at least 3 "managers" on the team (in addition to the visual designer and other folks in productive roles): you've got too many chefs. Decisions ha…

It seems like this can also happen when management is under-valued and each individual contributor can always make all their own decisions. I'm sure this can work on a team disciplined enough to share important design decisions they make with each other and to voluntarily adhere to some design decisions they may not entirely agree with. But for a lot of teams, without someone taking the lead on making important decisions, you end up lost.

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

#88

Post by orangevelcro »

HelloNurse wrote: post #56
uoaei wrote: post #21

If you're on the side of "just tell me what to build", you better really, really trust your leads and managers. Bad managers can destroy engineering culture in an instant to the point where "just tell me what to build" becomes a symptom of burnout and not a bona fide aspect of a work culture.

The next level of burnout is the double bind. I am not empowered to make decisions, I have nobody to discuss meaningfully with, and I'm told what to build perentorily but vaguely and often incorrectly. Will I be able to read the mind of my boss? Better to stall, complain, and avoid making mistakes.

This describes the job I recently left to a T. Drained the life out of me.

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

#89

Post by strgcmc »

baq wrote: post #44
orand wrote: post #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…

You say it’s a hiring problem and I see an incentives problem… either way a management failure but what you describe should’ve been reorged promptly.

Incentives operate on a slow time-scale. Let's say you have a decent team as a baseline, but starting to fall into this "just tell me what to build" apathetic failure mode. How would you turn this ship around?

As a manger, you could go as far as saying explicitly -- "hey, any engineer who demonstrates customer obsession and shows attention to impact, will receive their choice of project to work on, will get promoted faster and higher than those who don't, etc.", but this is unlikely to create a positive outcome. At best, 1-2 people may rise up, but the rest of the team will resent them for "try-harding" probably; crabs-in-a-bucket mentality is a very natural human group phenomenon. And now you've got 1-2 "stars" who won't want to stick around to deal with the rest of the shitty team members, so once they leave, you're back at square one.

Reorging is a reasonable step to take, but it's risky and you could just as well end up "infecting" other orgs or team members, by carrying the contagion of bad culture with you.

Firing and hiring again more carefully, is honestly both faster and more direct, and shouldn't be seen as a "last resort" option IF the culture is truly too far gone AND the culprits are readily identifiable. First step is probably to make sure you have a firm and accurate diagnosis of the problem, then if you're 99% sure you can identify the right people to fire -- go ahead and fire them.

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

#90

Post by strgcmc »

wizhi wrote: post #53
eastbound wrote: post #47

Earlier quoted context omitted.

Another startup founder here. I regret not working early enough with an HR expert. It takes forever (any many relationships and many tries) to find the correct one, but: - They’ll help you profile who you need. Questions you would never have dared asking, like “Tell me a situation when you reacted to xyz”, not only they filter the person, they also change the attitude of the relationship, the person itself goes from…

How would me answering how I once "reacted to xyz" make me any more likely to "put the extra neurons in"?

Those types of questions are likely to engage "problem solvers", aka people who don't just wait to be told what to do, but who actually demonstrated proactive critical thinking by reacting to a challenge. Those types of people are more likely to put extra neurons in for future problems (contrary to stock markets, past performance is actually a strong indicator of future success, when it comes to hiring).

If you don't have any scenarios from your work experience where you can demonstrate being a "problem solver" who reacts to stuff, then you probably aren't someone to likes to fire up the extra neurons, and hence wouldn't be a fit for the parent comment's desired team/org profile.

Post reply on HN