Work is work, in which returns diminish (2020)

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.

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).

> 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)