10 ms·

Work is work, in which returns diminish (2020)

227 points by typingcyclist 4y ago

burlesona 4y ago
Previously submitted 18 times. Most extensively discussed here: https://news.ycombinator.com/item?id=22797687 https://news.ycombinator.com/item?id=22797687
- admiral33 4y ago
  This is the first time I'm seeing it. If resubmissions were forbidden I wouldn't have ever known of its existence. I'm not sure what the solution is, but I'd like to think removing it from my cognitive landscape for the sake of a forum host (a stranger) isn't it.
  - tptacek 4y ago
    Reposts are fine if it's been a year or more since the last discussion. It's helpful to have links to the previous discussions, hence, the link above.
    - linkdink 4y ago
      Why isn't there a button for this? There's one for the domain as a whole, but not for the full link.
      - robocat 4y ago
        There is a button: the “past” link below the title on this page. The link often works pretty well, but not in this case because the title “work is work” is particularly non-specific. You can easily search for past HN submits and comments using: https://hn.algolia.com/ https://hn.algolia.com/ e.g. https://hn.algolia.com/?query=https%3A%2F%2Fcodahale.com%2F%2Fwork-is-work https://hn.algolia.com/?query=https%3A%2F%2Fcodahale.com%2F%... or add dashes e.g. search for work-is-work https://hn.algolia.com/?query=work-is-work https://hn.algolia.com/?query=work-is-work (Algolia search isn’t parsed like Google so quoting is not useful).
        linkdink 4y ago
        The past button, like you said, doesn't always work like that. And I know how to search. I'm wondering why there isn't a button when people always post comments to achieve the same thing a button could.
  - pdpi 4y ago
    When something gets reposted, it's fairly common for somebody to comment with previous discussions. I hadn't seen this submission before either, but I'd also not seen the discussion OP linked.
    - deleted 4y ago
      [deleted]
molsongolden 4y ago
I periodically reread this post to remind myself of the communication overhead involved when scaling an org. People love to model headcount and work capacity linearly but it just never works out that way (and Coda explains why).
- AnimalMuppet 4y ago
  It's not just coherence and contention costs (though I hadn't considered them before, and they definitely exist). The real problem is that brain-to-brain transfer of information is really hard. It is both slow and lossy. And the bigger the organization, the more times information has to transfer from one person to another.
phuff 4y ago
I know this has been discussed and rediscussed but the notion of thinking about human organization blackboxes trading work with each other the same way we think about how distributed systems blackboxes trade work and communication with each other I think is a huge insight for helping software engineers understand the complexity of human organizations. You want to avoid single points of failure, optimize bottlenecks, build in redundancy in similar ways etc. Etc. It's a great insight.
- emmelaich 4y ago
  Increasing parallelism and optimising bottlenecks is the way to performance. Put this way, be careful how much redundancy you add; as it is likely to increase complexity and reduce parallelism. As an aside this is one of the major goals of Agile. Having smaller tasks increases the potential for parallelism. As well as the more obvious ability to change direction. Lastly, regarding applicability of distributed systems thinking to people, see https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_of_Computational_Scalability https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_... which is applicable to both imho.
  - Spivak 4y ago
    Agile's main innovation is organizing projects as a (mostly) always shippable series of iterations (i.e. "what do you want next"). But the actual "how" with cards, points, sprints, boards, workstreams leaves a lot to be desired if parallelism is the goal. Communication costs are really high when every one is micro-siloed, hand-offs, which are serial, are costly and involve a lot of relearning the same context, and there is more integration work which is also serial. I think it's possible to have good parallelism within Agile but I don't think it's the Agile that makes it happen.
jollybean 4y ago
"The work capacity of an organization scales, at most, linearly as new members are added. " WTF? This is a bad way to think about the 'division of labour'. One man cannot ever get over a 10 foot wall. Two men together can absolutely do it. 'Work' is not the measurement, 'productivity' is. Even the fleeting thinker, who works only 1 day a week, but shows up every day, may be absolutely critical to making things work. Paid for that input, when it matters, not 'daily wages'.
- hinkley 4y ago
  It's worse even than that. "At most linearly" is someone's idea of subtle irony. You only get linearity if you discover the existing team is less capable than the newly added members, or you're asleep and this is a dream. If the value of new people diminishes logarithmicly, or much more likely, at the square root of the number of people, you must tackle tasks that a smaller team could not. Otherwise you'll be out-competed by a handful of smaller competitors. Yes, you can do things a smaller team couldn't do, but you don't really have a choice, if you want to survive.
  - elcomet 4y ago
    > You only get linearity if you discover the existing team is less capable than the newly added members Could you explain your reasoning? This doesn't seem right to me. If you have linearity, this means that every new individual is exactly as productive as all other individuals
    - hinkley 4y ago
      If you get twice as much work done by 10 people as 5, you need to think about what the new people brought to the table, or the old ones don’t. If the team didn’t have a facilitator, for instance, some team members may not be coordinating, causing issues with finishing tasks. Because despite having a factorial increase in communication paths, you still got twice as much done? Are you sure? You have to ask these questions because at worst something bad is happening. At best someone new brought in new techniques that work better than your old ones. You need the answer in either case.
jdougan 4y ago
This reads a lot like Engelbart's work on organizational augmentation/collective IQ etc. Tough stuff to get right. https://robm.me.uk/2021/07/collective-iq-improvement/ https://robm.me.uk/2021/07/collective-iq-improvement/ https://www.dougengelbart.org/content/view/256/340/ https://www.dougengelbart.org/content/view/256/340/
mattacular 4y ago
robotresearcher 4y ago
This analysis assumes that a unit of work is fungible. This may be nearly true in a large org on average but may be far from true in a small org. To see this, consider that adding a sales person to a group of engineers, or vice versa, could have a nonlinear improvement in revenue. It’s an awful buzzword to be sure, but superlinear gains from functional diversity is called synergy and it’s possible.
- quickthrower2 4y ago
  It also ignores ingenuity. 1 person can outdo a 100 with the right idea. Infact I was in a 10 way meeting today, first time in years and was reminded how superficial the discussion has to be as the number of people goes up. Simply because of coordination.
- hammock 4y ago
  >superlinear gains from functional diversity is called synergy Are you referring to the division of labor (specialization)?
  - robotresearcher 4y ago
    The happy sum of an appropriate amount of that, yes.
- sdwr 4y ago
  An old woman cornered me and a friend outside a few years back and ranted about synergy. I remember her wrinkled face and the manic glint in her eyes. Never going to lose the association between her and that word.
- Spivak 4y ago
  > This analysis assumes that a unit of work is fungible. This is a fair assumption when we're talking about organizing work within homogeneous teams that have (and ultimately are defined by) a single shared work stream. Every individual person on the team may have things they're better at, more historical knowledge on, or a warm cache, but it's generally assumed that any team member should be able to pick up any task. A good manger/scrum master/whatever will end up organizing work to take those things into account but it's an optimization not something fundamental.
stavros 4y ago
Regardless of the content, it strikes me that this author is a bit stuck in his own head? He uses rare words when common ones will do ("dyad"? What's wrong with "pair"?), passingly mentions obscure terms for no reason, and in general writes like the less the reader understands, the smarter the material was.
- actionfromafar 4y ago
  Okay, playing the devils advocate here, but sometimes the "lingo" is useful. Grabbing a "couple of beers" could really mean a "bunch of beers". But a "dyad of beers" is very explicitly exactly two beers.
  - stavros 4y ago
    But so does "two beers", and it doesn't require you to know a random Greek word. I mean, it doesn't necessitate you to ken an aleatorial Hellenic lexis.
  - ciphol 4y ago
    So is a "pair of beers".
    - actionfromafar 4y ago
      To me "a pair of" can colloquially (see, I did it again) mean "a bunch of".
      - jdmichal 4y ago
        I'm with you on "couple" potentially not being exactly two, though I tend to default to using "few" in such cases. But I can't sign up for "pair" not being exactly two. Yay language!
        ramphastidae 4y ago
        If someone puts on a pair of jeans followed by a pair of socks, how many articles of clothing have been put on? :)
015a 4y ago
> Keep the work parallel, the groups small, and the resources local. I think about this a lot in software organizations. Like most takes, I'm probably wrong. Keeping work parallel is, well, hard, and context dependent. Not worth commenting on. Keeping groups small is something we have plenty of prior art on; as Bezos said, two pizza teams, whatever. I may disagree with his exact number, and he may disagree with how much pizza I can eat in one sitting, but the gist is there. Keeping Resources Local is the most interesting one. The biggest productivity sinks I observe in my own line of work, and those around me, is absolutely quantified proximate to: "dependency on this thing we don't control". Here's an example: Everything has to be run in our one single kubernetes cluster. That cluster has some rules about how things are deployed, to avoid tragedies of the commons, like isolated namespaces and process security levels and whathaveyou. What's interesting, to me, is how this could so easily and correctly be viewed as either a productivity gain or sink. On the one hand: Teams don't have to create and manage their own kubernetes clusters. Big win, that sucks to manage. On the other hand: we do have to integrate and hold a dependency on the Kubernetes Team or the DevOps team for X, Y, Z of this feature development. That's a negative. I think it turns out being related to that next Principal From Beyond Space And Time: You can develop force multipliers, but oftentimes the development and maintenance of those force multipliers becomes a non-local resource that every team suddenly gains a dependency on. Its really easy to see the upside of a shared cluster. But let's say I'm on a team that just needs to get a static site hosted on the internet. Well, rules are rules, we use k8s; for my team and my work, this "asset" is actually a net productivity loss. We never would have hosted our own cluster in the first place, maybe we use fly.io or whatever. You can argue that the standardization or the single-pane-of-glass security controls or whatever ultimately make it a net organizational win, but I think that's diving too specific into the example: the point is that these force multipliers can actually become force dividers over time, as their complexity increases to account for a wider variety of complex use-cases, and left behind are the (significant number of) teams still on square 1 or 2. I don't want to understate how big a problem I think this is in modern software engineering; I think this is a big contributor for why software teams oftentimes trend toward stagnation. The buzzword is Complexity, but more specifically: every force multiplier is an abstraction layer which hides complexity, poorly, then you hire on new engineers or need to train up in a part of the system you've never worked in, and the abstraction disappears. I'm not saying any of this to suddenly present a solution. I don't know. Some of the things I think about though: I know this is oftentimes perceived as a soundbyte, but: I really think the best engineers are those with a really strong allergy to complexity. And, unfortunately, in most organizations this isn't rewarded. We reward "woah that's an awesome, complex system you designed that accounts for fifty-six different use-cases, exceeds expectations". We reward "woah, you were absolutely on top of that incident, you identified that fix super quick". We don't reward "woah, that comment you left on that other guy's RFC about how we shouldn't implement this was extremely well-reasoned, exceeds expectations". We don't reward "that thing you built hasn't had an incident in two years". Every organization is different; because every engineer is different. Some organizations are better than others. But I think the average isn't allergic enough; and I think its not even close. Second; I think Bezos' model of "everything should be an API" is extremely good, and roughly zero companies take it to the extreme it should be. Teams should communicate with each other the same way they communicate with customers, in every meaningful way. Instead, what we oftentimes end up with is: oh, you've got an API that you want on api.mycompany.com, you'll have to use the API Gateway that the Service Platform team developed, then use this npm library we published to expose a standard API interface, and register your schemas with... At a deep enough level, this guidance will start breaking down. For example, with apis: You probably do want your api on api.mycompany.com, or at least mycompany.com; so there's at least some coordination with the team that runs the domain name, and some kind of gateway may be necessary. For websites, ultimately there's one bundle to serve, and as much cohesion in design patterns between pages is a Good Thing. But, similar to the allergy to complexity, I think our industry-wide allergy to inter-team dependency isn't strong enough. This can oftentimes surface in the very tactile details about how things are developed. Let's say your goal is: a single centralized documentation page for the API. Routes are managed by twenty different teams depending on the product. This is a massive coordination problem. First, we could ask: Does it need to be single and centralized? Or could each team, which corresponds well to a product, get their own product.api.mycompany.com domain name, then they run everything? The prevailing wisdom is: nah it needs to be centralized; and there's that lack of an allergy surfacing again. But ok; We The Company say every team needs to expose a GraphQL API or whatever, schemas on some HTTP-accessible path, register with the load balancer, register with our schema repository, and we've basically slid down the hill toward making this coordination problem as difficult as it possibly could be. What if, instead, we did something like: the team which runs this documentation platform runs jobs which regularly scan every repository in our Github org, looking for a landmark file that says back "I'm a service register me"; and they get automatically registered? That would help reduce coordination a ton! Now, what if that landmark file was, say, just a GraphQL schema file? "As long as you put your GraphQL schema file anywhere in your repository, we'll find it and you'll get documentation instantly". I think one of the core things that every member of engineering leadership needs to do is: keep an inventory of the "typical dependencies" an average team in your company has on other teams. API gateways, kubernetes or AWS infrastructure, logging pipelines, metrics dashboards, alerting, downstream services, libraries; if a team generally has to interface in ANY capacity with something another team owns, write it down. Regularly revisit that list; query your engineers to see if its grown or shrank; then make an active effort to shrink the size of the list, or the size of every dependency on it. In large orgs, there is quite possibly no more impactful way to increase the productivity of your teams than right-sizing this list (usually down).
kapilkchaurasia 4y ago
knorker 4y ago
There's a lot of good here, but also: > Successful new products can be incrementally integrated with the existing products where it makes sense, and tooling, libraries, and frameworks can be developed by force multiplier teams to reduce both time-to-market of new products and the carrying costs of existing products Yeah... This is why communication is often needed in a full mesh. Look at major companies (ehem, one in particular) and see if you think their products make sense in their integration. Like did chat app X team talk to chat app Y team? Likely not. Larger orgs move slower because they're trying to build coherent larger wholes. And that's harder. It's not hard to launch 10 chat apps a year if it doesn't have to fit into any coherent whole. Like do you think DigitalOcean just needs to hire disconnected teams, and will end up with something that isn't a frankenmonster crying "kill me"? Their VM service works fine. Adding another that works fine is not hard. Building all services needed for a major customer to "go cloud"... you won't get there that way. (Not saying DO is doing anything wrong. Quite the opposite. I'm saying they can't just hire 100 parallel teams and end up being AWS)
stevebmark 4y ago
Could someone summarize this article? This article is condescending and very poorly written, I can't stand to try to finish it.
- jevgeni 4y ago
  Here's a recap. - The guy was a principal engineer at Mailchimp. - Assumes he solved the problem of organizational complexity. - Quotes the Stanford Encyclopedia of Philosophy instead of any relevant operational or organizational research. - Firms tend to ignore outside perspectives and examples. (which is often true) - Assumes an organization is a distributed computational process. (it's not) - Kant. - The *amount* of work (i.e. work hours) a company can dish out grows linearly with headcount. - Time for parallel tasks amortizes to zero if more resources are added. (no idea what this means...) - Assumes organizations only write software. - Assumes people know or care what "superlinear productivity" is. - Assumes productivity = added value. - Says that orgs should optimize for individual productivity. - Queue theory and King's formula and hand-waving about contention - Management consultants are bad at writing code. - (I gave up after that)
semasad 4y ago
We can discuss if we agree/disagree, but something about this post is non-debatable: any change in the way of work is trying to innovate in a 200,000 years "business", we should take this more serious. Maybe, remote work is a first step? we have been working side by side (at the same place) for a lot of time, and this change is the first one impact one of the most important metric: productivity.
- _glsb 4y ago
  Individual productivity is not a metric to optimize for in an org.
  - semasad 4y ago
    Was not the point, just saying is essential to understand any change on how we work is a change of how we do things for 200,000 years.
raydiatian 4y ago
Jesus Christ author, this isn’t the GRE. Use simpler fucking English.
- hansvm 4y ago
  "gets panicky" "agile or scrum or whatever" "most explanations ... are crap" "informs how much shit we can expect to fit in a bag" "the floor is lava" "chattier than others, ... communication is essential" "punt on coherence and just ride dirty" "put their eggs in a single basket" "blistering number of new products" "super weird hobbies" Scanning the essay, most of it is pretty tame. There are a few uncommon words in an essay long enough for statistically some of it to be uncommon. What exactly is the objection?
  - sooheon 4y ago
    In the very beginning, "emic" and "etic" are introduced (and defined in plain english inline). They are never used again. The author could have just used the plain english and got on with it.
    - 314 4y ago
      Reading the definitions those two words do capture exactly what is being described, while plain english would be much more verbose to do the same. I had not encountered them before but they seem like useful words in this context.
    - phantomathkg 4y ago
      Giving the author the benefit of doubt, what if the term emic and etic are wider used in the research of organisation performances?
      - jevgeni 4y ago
        "Outside-in view" is usually used. Also, there are the classic "exogenic" and "endogenic".
    - 4y ago
MuffinFlavored 4y ago
How many of us don't like our jobs?
d0liver 4y ago
Humans are probably a lot more like plants than distributed computing systems. Everyone likes a different environment. We bear different kinds of fruit. You can't just uproot a person randomly and move them around and expect everything to be the same. We put roots out into every available nook and cranny, bending around each other to get what we need. Throwing a new person into the mix changes everything. Reasoning about humans as cogs is inevitably going to be a really awful way to get people and companies to be productive - most of it isn't that. However, humans, like plants, are able to survive and sometimes thrive in really terrible conditions _despite_ those conditions. This is what you see at Amazon; if you throw enough money at anything then you're going to get some kind of result. But, despite Amazon, Microsoft, and Google having billions and billions of dollars to throw at this stuff we mostly still grab for Open Source tools (and so do they). That's largely because the workflows the Open Source community use actually work and that's mostly because they get the human stuff right. The whole "man hours - overhead = man joules" thing doesn't math and using that as a basis for any kind of analysis is going to lead to weird places. There are elements of human workflows that fit into these boxes - the really mundane work. Reasoning about mundane processes through this lens is maybe a good idea to the extent that mundane work can't be swapped out for more interesting work. The problem is that what we really want is to excel at the stuff that isn't mundane (the force multiplier shit) and that needs an entirely different framework that reasons about humans as humans rather than machines.
- Pelam 4y ago
  The way I read it, he is starting from the "cogs" premise (which may appeal to some people in some situations), and ends up defending rather humane sounding "local" principles. One possible tl;dr is: Objective analysis and queuing theory leads to _rejecting of_ all kinds of Talylorian cogs-and-factory-lines style organizational models and hypotheses in software work. Here is btw. a book with empirical results about software work perhaps pointing a bit in the same direction: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno...
- caust1c 4y ago
  I think you miss the point of the article a bit. I believe what he's getting at is this: there tends to arise bottlenecks in any growing organizations which prohibit them from moving as fast as every individual operating at full capacity, whatever that individual's capacity may be. Intuitively, in smaller organizations these bottlenecks are fewer, and in an organization of 1, your individual capacity is only limited by your physical and mental constraints. So yes, it's important to keep in mind that everyone's different but there is definitely excellent insight into how people work together effectively in large groups.
Barrin92 4y ago
this article is the unholy alliance of buzzword and business speak combined with little non-trivial content. Human organizations don't function like distributed computers just because one assumes so, they don't simply do static work. The most glaring problem is that there's no quantity/quality distinction in the piece. The core theory is: "The work capacity of an organization scales, at most, linearly as new members are added" This is trivially untrue because larger groups enable new complexity to emerge. 10 people can't build you CERN, even if you give them endless amounts of time. They don't hold enough information. A city isn't merely a village of 150 people multiplied by a thousand, and so forth. Quantity has a quality of its own and new behavior emerges from changes in size itself. Factoring work into little modules as the article suggests is the same kind of error behind microservice advocacy. The interesting thing isn't the performance of parts of the system or the sum of its parts, but only of an organization as a whole, including dynamics between it's parts, which in any complex system aren't linear, dynamic or even predictable.
trhoad 4y ago
I must be stupid because I understood very little of this. The cynic in me says it sounds a lot like pseudo-intellectual-babble, but maybe I'm wrong. I can pick out so many parts that seem to be an extremely odd take on things, but this one stood out: > the total time spent communicating will grow quadratically as the work capacity of the organization grows linearly. The assumption being that everybody needs to speak to everybody else as the organisation grows, which is a spectacularly daft assumption.
- mellavora 4y ago
  It is actually a fundamental insight. The same principle explains why the cortex has developed functional areas, and the advantages of mylenation. It also underlies Dunbar's rule on group sizes and how organizations scale. The point is exactly as you say, everyone does NOT need to speak to everyone else-- but you then have to structure the communication channels. This is a different challenge in a 15 person org than a 3 person org. Let alone a 150 person org. If you've ever been on a team which went from 5 to 8 people, you've seen this play out. God help you if the team crosses 15 people and you don't realize this triggers a phase shift.
dirkc 4y ago
> Therefore, our only hope for superlinear productivity lies in changing the task which is being executed. This is the key insight for me. If you're adding people to a team but you're not putting them in a position to affect what work that is being done you will be stuck with the linear scale as the ceiling This helps me explain an intuitive belief that I've always held for a long time, you should have a say over what you're doing. If I can't influence what work is being done and how it's being done, I don't feel like I can contribute much. I was hoping the rest of the article would talk about how to build an organization geared towards empowering employees, but it seems to focus on strategies for dividing up work and suggesting that companies should just become more companies under one umbrella to try and reach the linear scale ceiling, blegh!
solidist 4y ago
Software is "nice" because I can flex muscles and achieve things independent of "work." Many endevours require groups of humans to do; it is tablestakes. Writing is the same, and hence why I like it so much.
BEMBIYGY 4y ago
Helo

227 points by typingcyclist 4y ago

Previously submitted 18 times. Most extensively discussed here: https://news.ycombinator.com/item?id=22797687 https://news.ycombinator.com/item?id=22797687

admiral33 4y ago
This is the first time I'm seeing it. If resubmissions were forbidden I wouldn't have ever known of its existence. I'm not sure what the solution is, but I'd like to think removing it from my cognitive landscape for the sake of a forum host (a stranger) isn't it.
- tptacek 4y ago
  Reposts are fine if it's been a year or more since the last discussion. It's helpful to have links to the previous discussions, hence, the link above.
  - linkdink 4y ago
    Why isn't there a button for this? There's one for the domain as a whole, but not for the full link.
    - robocat 4y ago
      There is a button: the “past” link below the title on this page. The link often works pretty well, but not in this case because the title “work is work” is particularly non-specific. You can easily search for past HN submits and comments using: https://hn.algolia.com/ https://hn.algolia.com/ e.g. https://hn.algolia.com/?query=https%3A%2F%2Fcodahale.com%2F%2Fwork-is-work https://hn.algolia.com/?query=https%3A%2F%2Fcodahale.com%2F%... or add dashes e.g. search for work-is-work https://hn.algolia.com/?query=work-is-work https://hn.algolia.com/?query=work-is-work (Algolia search isn’t parsed like Google so quoting is not useful).
      - linkdink 4y ago
        The past button, like you said, doesn't always work like that. And I know how to search. I'm wondering why there isn't a button when people always post comments to achieve the same thing a button could.
- pdpi 4y ago
  When something gets reposted, it's fairly common for somebody to comment with previous discussions. I hadn't seen this submission before either, but I'd also not seen the discussion OP linked.
  - deleted 4y ago
    [deleted]

molsongolden 4y ago

I periodically reread this post to remind myself of the communication overhead involved when scaling an org. People love to model headcount and work capacity linearly but it just never works out that way (and Coda explains why).

AnimalMuppet 4y ago
It's not just coherence and contention costs (though I hadn't considered them before, and they definitely exist). The real problem is that brain-to-brain transfer of information is really hard. It is both slow and lossy. And the bigger the organization, the more times information has to transfer from one person to another.

phuff 4y ago

I know this has been discussed and rediscussed but the notion of thinking about human organization blackboxes trading work with each other the same way we think about how distributed systems blackboxes trade work and communication with each other I think is a huge insight for helping software engineers understand the complexity of human organizations. You want to avoid single points of failure, optimize bottlenecks, build in redundancy in similar ways etc. Etc. It's a great insight.

emmelaich 4y ago
Increasing parallelism and optimising bottlenecks is the way to performance. Put this way, be careful how much redundancy you add; as it is likely to increase complexity and reduce parallelism. As an aside this is one of the major goals of Agile. Having smaller tasks increases the potential for parallelism. As well as the more obvious ability to change direction. Lastly, regarding applicability of distributed systems thinking to people, see https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_of_Computational_Scalability https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Law_... which is applicable to both imho.
- Spivak 4y ago
  Agile's main innovation is organizing projects as a (mostly) always shippable series of iterations (i.e. "what do you want next"). But the actual "how" with cards, points, sprints, boards, workstreams leaves a lot to be desired if parallelism is the goal. Communication costs are really high when every one is micro-siloed, hand-offs, which are serial, are costly and involve a lot of relearning the same context, and there is more integration work which is also serial. I think it's possible to have good parallelism within Agile but I don't think it's the Agile that makes it happen.

jollybean 4y ago

"The work capacity of an organization scales, at most, linearly as new members are added. " WTF? This is a bad way to think about the 'division of labour'. One man cannot ever get over a 10 foot wall. Two men together can absolutely do it. 'Work' is not the measurement, 'productivity' is. Even the fleeting thinker, who works only 1 day a week, but shows up every day, may be absolutely critical to making things work. Paid for that input, when it matters, not 'daily wages'.

hinkley 4y ago
It's worse even than that. "At most linearly" is someone's idea of subtle irony. You only get linearity if you discover the existing team is less capable than the newly added members, or you're asleep and this is a dream. If the value of new people diminishes logarithmicly, or much more likely, at the square root of the number of people, you must tackle tasks that a smaller team could not. Otherwise you'll be out-competed by a handful of smaller competitors. Yes, you can do things a smaller team couldn't do, but you don't really have a choice, if you want to survive.
- elcomet 4y ago
  > You only get linearity if you discover the existing team is less capable than the newly added members Could you explain your reasoning? This doesn't seem right to me. If you have linearity, this means that every new individual is exactly as productive as all other individuals
  - hinkley 4y ago
    If you get twice as much work done by 10 people as 5, you need to think about what the new people brought to the table, or the old ones don’t. If the team didn’t have a facilitator, for instance, some team members may not be coordinating, causing issues with finishing tasks. Because despite having a factorial increase in communication paths, you still got twice as much done? Are you sure? You have to ask these questions because at worst something bad is happening. At best someone new brought in new techniques that work better than your old ones. You need the answer in either case.

jdougan 4y ago

This reads a lot like Engelbart's work on organizational augmentation/collective IQ etc. Tough stuff to get right. https://robm.me.uk/2021/07/collective-iq-improvement/ https://robm.me.uk/2021/07/collective-iq-improvement/ https://www.dougengelbart.org/content/view/256/340/ https://www.dougengelbart.org/content/view/256/340/

mattacular 4y ago

robotresearcher 4y ago

This analysis assumes that a unit of work is fungible. This may be nearly true in a large org on average but may be far from true in a small org. To see this, consider that adding a sales person to a group of engineers, or vice versa, could have a nonlinear improvement in revenue. It’s an awful buzzword to be sure, but superlinear gains from functional diversity is called synergy and it’s possible.

quickthrower2 4y ago
It also ignores ingenuity. 1 person can outdo a 100 with the right idea. Infact I was in a 10 way meeting today, first time in years and was reminded how superficial the discussion has to be as the number of people goes up. Simply because of coordination.
hammock 4y ago
>superlinear gains from functional diversity is called synergy Are you referring to the division of labor (specialization)?
- robotresearcher 4y ago
  The happy sum of an appropriate amount of that, yes.
sdwr 4y ago
An old woman cornered me and a friend outside a few years back and ranted about synergy. I remember her wrinkled face and the manic glint in her eyes. Never going to lose the association between her and that word.
Spivak 4y ago
> This analysis assumes that a unit of work is fungible. This is a fair assumption when we're talking about organizing work within homogeneous teams that have (and ultimately are defined by) a single shared work stream. Every individual person on the team may have things they're better at, more historical knowledge on, or a warm cache, but it's generally assumed that any team member should be able to pick up any task. A good manger/scrum master/whatever will end up organizing work to take those things into account but it's an optimization not something fundamental.

stavros 4y ago

Regardless of the content, it strikes me that this author is a bit stuck in his own head? He uses rare words when common ones will do ("dyad"? What's wrong with "pair"?), passingly mentions obscure terms for no reason, and in general writes like the less the reader understands, the smarter the material was.

actionfromafar 4y ago
Okay, playing the devils advocate here, but sometimes the "lingo" is useful. Grabbing a "couple of beers" could really mean a "bunch of beers". But a "dyad of beers" is very explicitly exactly two beers.
- stavros 4y ago
  But so does "two beers", and it doesn't require you to know a random Greek word. I mean, it doesn't necessitate you to ken an aleatorial Hellenic lexis.
- ciphol 4y ago
  So is a "pair of beers".
  - actionfromafar 4y ago
    To me "a pair of" can colloquially (see, I did it again) mean "a bunch of".
    - jdmichal 4y ago
      I'm with you on "couple" potentially not being exactly two, though I tend to default to using "few" in such cases. But I can't sign up for "pair" not being exactly two. Yay language!
      - ramphastidae 4y ago
        If someone puts on a pair of jeans followed by a pair of socks, how many articles of clothing have been put on? :)

015a 4y ago

> Keep the work parallel, the groups small, and the resources local. I think about this a lot in software organizations. Like most takes, I'm probably wrong. Keeping work parallel is, well, hard, and context dependent. Not worth commenting on. Keeping groups small is something we have plenty of prior art on; as Bezos said, two pizza teams, whatever. I may disagree with his exact number, and he may disagree with how much pizza I can eat in one sitting, but the gist is there. Keeping Resources Local is the most interesting one. The biggest productivity sinks I observe in my own line of work, and those around me, is absolutely quantified proximate to: "dependency on this thing we don't control". Here's an example: Everything has to be run in our one single kubernetes cluster. That cluster has some rules about how things are deployed, to avoid tragedies of the commons, like isolated namespaces and process security levels and whathaveyou. What's interesting, to me, is how this could so easily and correctly be viewed as either a productivity gain or sink. On the one hand: Teams don't have to create and manage their own kubernetes clusters. Big win, that sucks to manage. On the other hand: we do have to integrate and hold a dependency on the Kubernetes Team or the DevOps team for X, Y, Z of this feature development. That's a negative. I think it turns out being related to that next Principal From Beyond Space And Time: You can develop force multipliers, but oftentimes the development and maintenance of those force multipliers becomes a non-local resource that every team suddenly gains a dependency on. Its really easy to see the upside of a shared cluster. But let's say I'm on a team that just needs to get a static site hosted on the internet. Well, rules are rules, we use k8s; for my team and my work, this "asset" is actually a net productivity loss. We never would have hosted our own cluster in the first place, maybe we use fly.io or whatever. You can argue that the standardization or the single-pane-of-glass security controls or whatever ultimately make it a net organizational win, but I think that's diving too specific into the example: the point is that these force multipliers can actually become force dividers over time, as their complexity increases to account for a wider variety of complex use-cases, and left behind are the (significant number of) teams still on square 1 or 2. I don't want to understate how big a problem I think this is in modern software engineering; I think this is a big contributor for why software teams oftentimes trend toward stagnation. The buzzword is Complexity, but more specifically: every force multiplier is an abstraction layer which hides complexity, poorly, then you hire on new engineers or need to train up in a part of the system you've never worked in, and the abstraction disappears. I'm not saying any of this to suddenly present a solution. I don't know. Some of the things I think about though: I know this is oftentimes perceived as a soundbyte, but: I really think the best engineers are those with a really strong allergy to complexity. And, unfortunately, in most organizations this isn't rewarded. We reward "woah that's an awesome, complex system you designed that accounts for fifty-six different use-cases, exceeds expectations". We reward "woah, you were absolutely on top of that incident, you identified that fix super quick". We don't reward "woah, that comment you left on that other guy's RFC about how we shouldn't implement this was extremely well-reasoned, exceeds expectations". We don't reward "that thing you built hasn't had an incident in two years". Every organization is different; because every engineer is different. Some organizations are better than others. But I think the average isn't allergic enough; and I think its not even close. Second; I think Bezos' model of "everything should be an API" is extremely good, and roughly zero companies take it to the extreme it should be. Teams should communicate with each other the same way they communicate with customers, in every meaningful way. Instead, what we oftentimes end up with is: oh, you've got an API that you want on api.mycompany.com, you'll have to use the API Gateway that the Service Platform team developed, then use this npm library we published to expose a standard API interface, and register your schemas with... At a deep enough level, this guidance will start breaking down. For example, with apis: You probably do want your api on api.mycompany.com, or at least mycompany.com; so there's at least some coordination with the team that runs the domain name, and some kind of gateway may be necessary. For websites, ultimately there's one bundle to serve, and as much cohesion in design patterns between pages is a Good Thing. But, similar to the allergy to complexity, I think our industry-wide allergy to inter-team dependency isn't strong enough. This can oftentimes surface in the very tactile details about how things are developed. Let's say your goal is: a single centralized documentation page for the API. Routes are managed by twenty different teams depending on the product. This is a massive coordination problem. First, we could ask: Does it need to be single and centralized? Or could each team, which corresponds well to a product, get their own product.api.mycompany.com domain name, then they run everything? The prevailing wisdom is: nah it needs to be centralized; and there's that lack of an allergy surfacing again. But ok; We The Company say every team needs to expose a GraphQL API or whatever, schemas on some HTTP-accessible path, register with the load balancer, register with our schema repository, and we've basically slid down the hill toward making this coordination problem as difficult as it possibly could be. What if, instead, we did something like: the team which runs this documentation platform runs jobs which regularly scan every repository in our Github org, looking for a landmark file that says back "I'm a service register me"; and they get automatically registered? That would help reduce coordination a ton! Now, what if that landmark file was, say, just a GraphQL schema file? "As long as you put your GraphQL schema file anywhere in your repository, we'll find it and you'll get documentation instantly". I think one of the core things that every member of engineering leadership needs to do is: keep an inventory of the "typical dependencies" an average team in your company has on other teams. API gateways, kubernetes or AWS infrastructure, logging pipelines, metrics dashboards, alerting, downstream services, libraries; if a team generally has to interface in ANY capacity with something another team owns, write it down. Regularly revisit that list; query your engineers to see if its grown or shrank; then make an active effort to shrink the size of the list, or the size of every dependency on it. In large orgs, there is quite possibly no more impactful way to increase the productivity of your teams than right-sizing this list (usually down).

kapilkchaurasia 4y ago

knorker 4y ago

There's a lot of good here, but also: > Successful new products can be incrementally integrated with the existing products where it makes sense, and tooling, libraries, and frameworks can be developed by force multiplier teams to reduce both time-to-market of new products and the carrying costs of existing products Yeah... This is why communication is often needed in a full mesh. Look at major companies (ehem, one in particular) and see if you think their products make sense in their integration. Like did chat app X team talk to chat app Y team? Likely not. Larger orgs move slower because they're trying to build coherent larger wholes. And that's harder. It's not hard to launch 10 chat apps a year if it doesn't have to fit into any coherent whole. Like do you think DigitalOcean just needs to hire disconnected teams, and will end up with something that isn't a frankenmonster crying "kill me"? Their VM service works fine. Adding another that works fine is not hard. Building all services needed for a major customer to "go cloud"... you won't get there that way. (Not saying DO is doing anything wrong. Quite the opposite. I'm saying they can't just hire 100 parallel teams and end up being AWS)

stevebmark 4y ago

Could someone summarize this article? This article is condescending and very poorly written, I can't stand to try to finish it.

jevgeni 4y ago
Here's a recap. - The guy was a principal engineer at Mailchimp. - Assumes he solved the problem of organizational complexity. - Quotes the Stanford Encyclopedia of Philosophy instead of any relevant operational or organizational research. - Firms tend to ignore outside perspectives and examples. (which is often true) - Assumes an organization is a distributed computational process. (it's not) - Kant. - The *amount* of work (i.e. work hours) a company can dish out grows linearly with headcount. - Time for parallel tasks amortizes to zero if more resources are added. (no idea what this means...) - Assumes organizations only write software. - Assumes people know or care what "superlinear productivity" is. - Assumes productivity = added value. - Says that orgs should optimize for individual productivity. - Queue theory and King's formula and hand-waving about contention - Management consultants are bad at writing code. - (I gave up after that)

semasad 4y ago

We can discuss if we agree/disagree, but something about this post is non-debatable: any change in the way of work is trying to innovate in a 200,000 years "business", we should take this more serious. Maybe, remote work is a first step? we have been working side by side (at the same place) for a lot of time, and this change is the first one impact one of the most important metric: productivity.

_glsb 4y ago
Individual productivity is not a metric to optimize for in an org.
- semasad 4y ago
  Was not the point, just saying is essential to understand any change on how we work is a change of how we do things for 200,000 years.

raydiatian 4y ago

Jesus Christ author, this isn’t the GRE. Use simpler fucking English.

hansvm 4y ago
"gets panicky" "agile or scrum or whatever" "most explanations ... are crap" "informs how much shit we can expect to fit in a bag" "the floor is lava" "chattier than others, ... communication is essential" "punt on coherence and just ride dirty" "put their eggs in a single basket" "blistering number of new products" "super weird hobbies" Scanning the essay, most of it is pretty tame. There are a few uncommon words in an essay long enough for statistically some of it to be uncommon. What exactly is the objection?
- sooheon 4y ago
  In the very beginning, "emic" and "etic" are introduced (and defined in plain english inline). They are never used again. The author could have just used the plain english and got on with it.
  - 314 4y ago
    Reading the definitions those two words do capture exactly what is being described, while plain english would be much more verbose to do the same. I had not encountered them before but they seem like useful words in this context.
  - phantomathkg 4y ago
    Giving the author the benefit of doubt, what if the term emic and etic are wider used in the research of organisation performances?
    - jevgeni 4y ago
      "Outside-in view" is usually used. Also, there are the classic "exogenic" and "endogenic".
  - 4y ago

MuffinFlavored 4y ago

How many of us don't like our jobs?

d0liver 4y ago

Humans are probably a lot more like plants than distributed computing systems. Everyone likes a different environment. We bear different kinds of fruit. You can't just uproot a person randomly and move them around and expect everything to be the same. We put roots out into every available nook and cranny, bending around each other to get what we need. Throwing a new person into the mix changes everything. Reasoning about humans as cogs is inevitably going to be a really awful way to get people and companies to be productive - most of it isn't that. However, humans, like plants, are able to survive and sometimes thrive in really terrible conditions _despite_ those conditions. This is what you see at Amazon; if you throw enough money at anything then you're going to get some kind of result. But, despite Amazon, Microsoft, and Google having billions and billions of dollars to throw at this stuff we mostly still grab for Open Source tools (and so do they). That's largely because the workflows the Open Source community use actually work and that's mostly because they get the human stuff right. The whole "man hours - overhead = man joules" thing doesn't math and using that as a basis for any kind of analysis is going to lead to weird places. There are elements of human workflows that fit into these boxes - the really mundane work. Reasoning about mundane processes through this lens is maybe a good idea to the extent that mundane work can't be swapped out for more interesting work. The problem is that what we really want is to excel at the stuff that isn't mundane (the force multiplier shit) and that needs an entirely different framework that reasons about humans as humans rather than machines.

Pelam 4y ago
The way I read it, he is starting from the "cogs" premise (which may appeal to some people in some situations), and ends up defending rather humane sounding "local" principles. One possible tl;dr is: Objective analysis and queuing theory leads to _rejecting of_ all kinds of Talylorian cogs-and-factory-lines style organizational models and hypotheses in software work. Here is btw. a book with empirical results about software work perhaps pointing a bit in the same direction: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno...
caust1c 4y ago
I think you miss the point of the article a bit. I believe what he's getting at is this: there tends to arise bottlenecks in any growing organizations which prohibit them from moving as fast as every individual operating at full capacity, whatever that individual's capacity may be. Intuitively, in smaller organizations these bottlenecks are fewer, and in an organization of 1, your individual capacity is only limited by your physical and mental constraints. So yes, it's important to keep in mind that everyone's different but there is definitely excellent insight into how people work together effectively in large groups.

Barrin92 4y ago

this article is the unholy alliance of buzzword and business speak combined with little non-trivial content. Human organizations don't function like distributed computers just because one assumes so, they don't simply do static work. The most glaring problem is that there's no quantity/quality distinction in the piece. The core theory is: "The work capacity of an organization scales, at most, linearly as new members are added" This is trivially untrue because larger groups enable new complexity to emerge. 10 people can't build you CERN, even if you give them endless amounts of time. They don't hold enough information. A city isn't merely a village of 150 people multiplied by a thousand, and so forth. Quantity has a quality of its own and new behavior emerges from changes in size itself. Factoring work into little modules as the article suggests is the same kind of error behind microservice advocacy. The interesting thing isn't the performance of parts of the system or the sum of its parts, but only of an organization as a whole, including dynamics between it's parts, which in any complex system aren't linear, dynamic or even predictable.

trhoad 4y ago

I must be stupid because I understood very little of this. The cynic in me says it sounds a lot like pseudo-intellectual-babble, but maybe I'm wrong. I can pick out so many parts that seem to be an extremely odd take on things, but this one stood out: > the total time spent communicating will grow quadratically as the work capacity of the organization grows linearly. The assumption being that everybody needs to speak to everybody else as the organisation grows, which is a spectacularly daft assumption.

mellavora 4y ago
It is actually a fundamental insight. The same principle explains why the cortex has developed functional areas, and the advantages of mylenation. It also underlies Dunbar's rule on group sizes and how organizations scale. The point is exactly as you say, everyone does NOT need to speak to everyone else-- but you then have to structure the communication channels. This is a different challenge in a 15 person org than a 3 person org. Let alone a 150 person org. If you've ever been on a team which went from 5 to 8 people, you've seen this play out. God help you if the team crosses 15 people and you don't realize this triggers a phase shift.

dirkc 4y ago

> Therefore, our only hope for superlinear productivity lies in changing the task which is being executed. This is the key insight for me. If you're adding people to a team but you're not putting them in a position to affect what work that is being done you will be stuck with the linear scale as the ceiling This helps me explain an intuitive belief that I've always held for a long time, you should have a say over what you're doing. If I can't influence what work is being done and how it's being done, I don't feel like I can contribute much. I was hoping the rest of the article would talk about how to build an organization geared towards empowering employees, but it seems to focus on strategies for dividing up work and suggesting that companies should just become more companies under one umbrella to try and reach the linear scale ceiling, blegh!

solidist 4y ago

Software is "nice" because I can flex muscles and achieve things independent of "work." Many endevours require groups of humans to do; it is tablestakes. Writing is the same, and hence why I like it so much.

BEMBIYGY 4y ago

Helo