Complexity in software projects!

There is a lot of Twitter noise at the moment around engineers shipping a feature in 1 week or risk being fired.

I have no opinion on the morality of the ask. Just because it isn’t an interesting question at all.

I do have an opinion on the generalizability of the problem. In most contexts, the accepted rule of thumb is that every team is working with 3 constraints: scope, cost and time. The conventional wisdom is that you can win in only 2. If you fix scope and time, you pay a high cost to get it done on schedule.

In my experience, the model breaks down for truly exceptional teams because of one single factor: complexity. These teams master complexity to move an order of magnitude faster than a comparable. Complexity in software teams is usually around two axes; tools and org structures.

Tools: Narrowly scoped building blocks that are easy to extend and opinionated about the choices being made allow for rapid iterations. Gifted thinkers can break down a scope into parts (or edit scope slightly) to make it fit into generalizable parts.

Org structures: Transfer of ownership for software is always messy, without exception. Within org structures, the key problem to solve is to ensure that the broken down scope is owned by as few people as possible to reduce handoffs.

If leaders invest in reducing complexity across both axes, teams can build with a lot of agility. A collection of exceptional teams delivering things on time, in cost and per quality standards from the founder of Stripe is one way to go down this rabbit hole. The rapid emergence of one or two person startups which become unicorns is a clear signal that it can be done if someone is thoughtfully managing complexity.

It is hard, and hence, rare.