Live data from Hacker News

Engineering Intensity

ruiper.es

11–15 of 15 posts

Re: Engineering Intensity

#11
post #9

Large corporations have this sort of structure where you're a node in a graph performing a niche service(s) in a series of steps where there are dependencies and you are also a dependency for later stage services. Working every second of the day and working really hard, doesn't actually do anything since you're just one cell in a slime mold. Rather, you wait for another node to deliver some sort of task, do your part…

Yeah this mirrors my thoughts as well. Individual training for endurance, speed, accuracy, power all have analogues in for intellectual work. So if you're optimizing for your own individual performance then this analogy makes a lot of sense.

But in a team setting, the goal is some external output that depends primarily on efficient collaboration. Individual capabilities still matter, but it's how they are applied in concert that delivers results. From this perspective, pacing the team isn't necessarily about preventing burnout, but more that it hits diminishing returns pretty quickly, and becomes counter-productive when the team gets stretched too thin to react to new inputs that inevitably come.

Re: Engineering Intensity

#13
post #9

Large corporations have this sort of structure where you're a node in a graph performing a niche service(s) in a series of steps where there are dependencies and you are also a dependency for later stage services. Working every second of the day and working really hard, doesn't actually do anything since you're just one cell in a slime mold. Rather, you wait for another node to deliver some sort of task, do your part…

Something very similar is the theme of the book "The Goal" by Eli Goldratt, which outlines the theory of constraints in a factory setting. The key is to identify bottlenecks and use them to increase/control throughput to match the downstream demand.

Re: Engineering Intensity

#14
post #9

Large corporations have this sort of structure where you're a node in a graph performing a niche service(s) in a series of steps where there are dependencies and you are also a dependency for later stage services. Working every second of the day and working really hard, doesn't actually do anything since you're just one cell in a slime mold. Rather, you wait for another node to deliver some sort of task, do your part…

Yeah this mirrors my thoughts as well. Individual training for endurance, speed, accuracy, power all have analogues in for intellectual work. So if you're optimizing for your own individual performance then this analogy makes a lot of sense. But in a team setting, the goal is some external output that depends primarily on efficient collaboration. Individual capabilities still matter, but it's how they are applied in…

I've always use the analogy of congestion collapse when you try to shove to much "stuff" (network packets, cars, work, whatever) through the pipeline.

Re: Engineering Intensity

#15
post #9

Large corporations have this sort of structure where you're a node in a graph performing a niche service(s) in a series of steps where there are dependencies and you are also a dependency for later stage services. Working every second of the day and working really hard, doesn't actually do anything since you're just one cell in a slime mold. Rather, you wait for another node to deliver some sort of task, do your part…

Great point. It’s never occurred to me until now, but Amdahl’s Law has great application here.

I never want to be the “weak link” in the chain, but overworking myself to deliver my piece in a large project usually has negligible impact, if any. Usually it just ends up providing buffer for other teams that end up using more time.

Post reply on HN