“Work Is Work” by Coda Hale
“Work Is Work (in Which Results Diminish)” is an article from Coda Hale.
Its main topic is that scaling teams is hard.
Internal tooling, training, and services must be developed and fielded to ensure that all members are able to work on problems of continuously increasing impact. The ceaseless pursuit of force multipliers is the only possible route to superlinear productivity improvements as an organization grows.
I absolutely agree. When adding more people to the organization, the best thing you can do is to make them work on something that improves productivity of everyone else. Being it a good CI system, internal frameworks, documentation, etc.
Code is smartly using queueing theory to explain managerial issues:
As with writing highly-concurrent applications, building high-performing organizations requires a careful and continuous search for shared resources, and developing explicit strategies for mitigating their impact on performance.
At some point, adding new members can cause the organization’s overall productivity to decrease instead of increase, as the increase in wait time due to contention is greater than the increase in work capacity. (This is the organizational version of the latency spikes we see as servers become overloaded.)
While the consultants can indeed move quickly in a low-contention environment, integrating their work product back into the contended resources often has the effect of ballooning […] how long a critical section is held. This produces a quadratic spike in wait times which increases utilization which in turn produces a superlinear spike in wait times.
The more distance between those designing the organization and the work being done, the greater the risk of unmanaged points of contention. Top-down organizational methods can lead to subdivisions which seem like parallel efforts when listed on a slide but which are, in actuality, highly interdependent and interlocking.
Staffing highly sequential efforts as if they were entirely parallel leads to catastrophe.
[…] the total time spent communicating will grow quadratically as the work capacity of the organization grows linearly.
[…] pair-wise communications don’t need to be formal, planned, or even well-known in order to have costs. Neither your employee handbook nor your calendar are accurate depictions of how work in the organization is done.
Informal communication is often forgotten about.
Of course, one of the tools that can help with this is applying microservices. I personally think that microservices architecture solves leadership problems, not technical. Though, it also should be done right.
The key word there is independent. Slicing your shit up into a hundred microservices will not help you if everyone needs to change ten of them to get anything done.
There are solutions, with some of those I do agree wholeheartedly.
To avoid that, organization leaders should keep the development of a product portfolio as an explicit goal. Feature or product ideas which are complimentary to the organization’s overall business strategy but don’t naturally coexist with the main product can be developed as separate products by independent teams.
… tooling, libraries, and frameworks can be developed by force multiplier teams to reduce both time-to-market of new products…
This is the one point that I disagree with. Trying to do the whole portfolio on a unified “framework”, makes this framework and the team behind it the bottleneck of the organization. You can and likely will end up with “having to change ten of them”, just like the author pointed out earlier.
If you are building everything in the same way, you are missing out on some innovation that new approaches and new technologies can bring to your other products.
removing a feature from a product involves the same contention and coherence costs as adding a feature
100% that! A lot of people for some reason think that adding a feature is harder than removing it. For non-trivial features it is not true. You can break half of the product by trying to remove the traces of a feature.
Remainders of old features will haunt the codebase forever, making it is less secure, harder to change and harder to onboard new people on.
Synchronous meetings should be reserved for low-latency collaboration on complex issues; likewise, collaboration should be reserved for synchronous meetings.
In the ideal world, yes.
Companies are groups of people being compensated for having to spend some of their finite lifetimes not being with their partners, children, pets, or super weird hobbies.
One more important view point there.
