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

101–110 of 128 posts

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

#101

Post by iancmceachern »

calderwoodra wrote: post #97
iancmceachern wrote: post #93

If the right decision isn't obvious to everyone in the room, including the least experienced person in the room, you don't have enough data to make the decision. You should break, get thr data, and regroup when you have the data to make thr proper decisions. Data driven decisions.

I'd love to ask anyone who's worked on present day Instagram/Facebook what the long term effects of data driven decision making is. My understanding is that it's been a toss up. I think PG has a tweet a while back like "some decisions are so bad, no one in their right mind would agree to this if there wasn't data to back it up". More of less saying, you can find data to support any decision, so why even be data drive…

I'd say their experience is an outlier. They are not the norm.

I'm speaking from a 20 year background designing medical devices and other critical infrastructure. In my world, like with airliners, it's important to get decisions right or people can be killed. Therefore, data driven decisions.

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

#102

Post by rpmisms »

mmcnl wrote: post #50
rpmisms wrote: post #45

Earlier quoted context omitted.

It's easy to say with a smile an a laugh, but definitely depends on your organization. I do tell people almost exactly this in my solo dev role, but more win the context of "I literally don't have the time to redo this, so let's get it right the first time".

I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.

No, I'm not a machine. I'm the only one who can do the work, so maybe listen to me when I tell you it's a bad idea.

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

#103

Post by symfoniq »

fusslo wrote: post #80
LAC-Tech wrote: post #11

Debate is a good if you all have a shared idea of what constitutes 'good'. IE, simplicity, performance, whatever.

I had a engineering lead who encouraged 'debate everything', but had the idea that 'good' meant 'his idea'. every new hire under him lasted about 8 months, then were burnt out and stopped being active in debate

I’ve worked (burned out) under this. Eventually I realized that “debate everything” just meant the boss really loved to debate, because he could always “win.”

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

#104

Post by feoren »

iancmceachern wrote: post #93

If the right decision isn't obvious to everyone in the room, including the least experienced person in the room, you don't have enough data to make the decision. You should break, get thr data, and regroup when you have the data to make thr proper decisions. Data driven decisions.

Yeesh, I don't know. I think we have enough data to decide the shape of the Earth, yet there are still Flat Earthers. Your approach works in an idealized world where everyone is perfectly rational and emotionless and all facts are perfectly knowable. That's really not the world we live in. This is basically a hardline stance at the extreme "endless debate" side: if literally anyone in the room is disagreeing, then you must not have enough data to make a decision yet? I don't see that working in practice.

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

#105

Post by pseudosavant »

tristor wrote: post #91
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…

Hard agree with this take. Also, a good PM should be technical enough to really understand not just how customers use the product but how the product works. you should be able to be the designated person to answer a question from customers when nobody else knows the answer. In my role as a PM, I'm usually the person the buck stops with for Sales, Support, Solutions Engineering, et al. You can't do that if you don't a…

As a PM, you unlock a lot of value by getting engineers out of a lot of these meetings, by being technically competent enough (for these contexts) to not need them 99% of the time. It isn't even just about the devs' time either. It is about their focus and reducing context switching too.

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

#106

Post by kevan »

mmcnl wrote: post #50
rpmisms wrote: post #45

Earlier quoted context omitted.

It's easy to say with a smile an a laugh, but definitely depends on your organization. I do tell people almost exactly this in my solo dev role, but more win the context of "I literally don't have the time to redo this, so let's get it right the first time".

I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.

> III. Professional Obligations

> 1. Engineers shall be guided in all their relations by the highest standards of honesty and integrity.

> ...

> b. Engineers shall advise their clients or employers when they believe a project will not be successful.

There's nuance around how hard you should push back on bad requests and where ownership/accountability and decision-making responsibility ultimately lie but providing professional judgement/advise/opinions is definitely in bounds for engineers.

[1] https://www.nspe.org/resources/ethics/code-ethics

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

#107

Post by rpmisms »

kevan wrote: post #106
mmcnl wrote: post #50

Earlier quoted context omitted.

I think it's an engineer's responsibility to present likely outcomes with their likelihood without judgment. Opinions are usually not needed unless asked.

> III. Professional Obligations > 1. Engineers shall be guided in all their relations by the highest standards of honesty and integrity. > ... > b. Engineers shall advise their clients or employers when they believe a project will not be successful. There's nuance around how hard you should push back on bad requests and where ownership/accountability and decision-making responsibility ultimately lie but providing pro…

I am not an accredited engineer, but I should probably read those guidelines. Thanks!

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

#108

Post by maxrecursion »

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…

I'm not a PM, but you are exactly the kind of PM I love to work for.

So many PMs are either over bearing or scared to make decisions; or, the worst, that do both, over bearing and micromanaging all the time and then blames the team when their decisions back fire.

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

#109

Post by iancmceachern »

feoren wrote: post #104
iancmceachern wrote: post #93

If the right decision isn't obvious to everyone in the room, including the least experienced person in the room, you don't have enough data to make the decision. You should break, get thr data, and regroup when you have the data to make thr proper decisions. Data driven decisions.

Yeesh, I don't know. I think we have enough data to decide the shape of the Earth, yet there are still Flat Earthers. Your approach works in an idealized world where everyone is perfectly rational and emotionless and all facts are perfectly knowable. That's really not the world we live in. This is basically a hardline stance at the extreme "endless debate" side: if literally anyone in the room is disagreeing, then yo…

This is reducto ad absurdum. It's not a 100% or 0% thing.

Obvious means that there is a 51% chance that decision a is better than decision b.

I'm advocating against just guessing when it's 50/50

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

#110

Post by hintymad »

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…

I also saw powerful product managers get support from higher-ups and then shovel their ideas down the throat of engineering orgs. A PM in Uber's Marketplace org used to create and present a brand new architecture for the entire Uber's marketplace. It was not concrete enough. It didn't really convince people of what problems to solve. It was not even a good architecture (maybe it was, but at least few people got convinced). In fact, the presentation didn't even get many questions but hundreds of blank stares. Needless to say, the architecture was not implemented. It was nevertheless quite a humiliation to the marketplace's eng org.
Post reply on HN