Share my understanding of systems rather than improve arbitrary KPIs

This is the 6th post from my sincere dev manifesto series.

We build a system, for a system, within a system, from a system.

Systems are made of constraints, nodes, queues, mathematics.

They’re made of granularity levels. None of them has the properties of its components. Most of them can’t be understood by decomposing them.

Because I’m interested in these subjects, I look at the systems and subsystems as wholes. I look at the flow, at problems being worked on instead of how hard people work or how KPIs are met.

So I see issues that people can’t understand when they count on the system to be predictable. I see bottlenecks and bad optimizations before the red from watermelon indicators reaches their skin. I see illusions, sometimes self-realizing, but rarely close to an optimal.

OK, a common example: a well utilized highway is a parking lot. Optimizing a system for resource utilization makes it grinds to a halt. That’s Little’s law. Mathematics.

People usually refer to smells and heuristics coming from systems thinking as counterintuitive. I’m not sure why. Probably because it’s the opposite of what we learn in MBAs. Maybe because some of these insights get into cognitive biases’ way. Anyway they seem quite intuitive to me and many more people. It looks like we are not a majority.

So I’m happy to share my point of view and explain why. The latter part is not very difficult, because it’s easier to point to studies and places where they work, instead of just saying “we’ve always done it this way”. What’s more difficult is to help people actually understand, unlearn.

A few more examples ?

  • If you don’t know whether you can predict the consequences of your context, you’re probably in a complex domain. Iterate, formulate and validate hypotheses.
  • What you deliver changes the expectations of your users. Iterate.
  • A big system can be more predictable than its parts. Decomposing things is not the silver bullet. Create your own process iteratively.
  • An idea, however great it looks like, might have catastrophic results. Cobra effect. Iterate.
  • Whatever your goals, you don’t have the capacity to do what you would like to be done. Do Many More Much Smaller Steps.
  • Individual incentives are useless to harmful.
  • People will destroy the system for optimizing KPIs.
  • You will ruin your life trying to predict the future.
  • Dependencies (between backlogs but not necessarily) are generally worse than duplication.
  • Estimating workloads for batons mostly sitting in queues is useless… expect maybe for maximizing utilization.
  • Both autonomy and alignment are important. An organization is more than a bunch of teams.
  • But to go faster, you need to push as many decisions as possible to where the information actually is.

We could go on for books.

I commit to sharing the knowledge that all current problems come from the system that is perfectly optimized for them to occur.


One comment

  1. Pingback: Sincere developer manifesto | AAAgile

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s