Many effective leaders I’ve worked with have the uncanny knack for working onleveragedproblems. In some problem domains, theproduct management skillsetis extraordinarily effective for identifying useful problems, but systems thinking is the most universally useful toolkit I’ve found.
If you really want a solid grasp on systems thinking fundamentals, you should readThinking in Systems: A Primerby Donella Meadows, but I’ll do my best to describe some of the basics and work through a recent scenario where I found the systems thinking approach to be exceptionally useful.
Stocks and flows
The fundamental observation of systems thinking is that the links between events are often more subtle than they appear. We want to describe events causally–our managers are too busy because we’re trying to ship our current project–but few events occur in a vacuum.
Big changes appear to happen in a moment, but if you look closely underneath the big change, there is usually a slow accumulation of small changes. In this example, perhaps the managers are busy because no one hired and trained the managers required to support this year’s project deadlines. These accumulations are calledstocks, and are the memory of changes over time. A stock might be the number of trained managers at your company.
Changes to stocks are calledflows. These can be eitherinflowsoroutflows. Training a new manager is an inflow, and a trained manager who departs the company is an outflow. Diagrams in this article represent flows with solid dark lines.
The other relationship, represented in this article by a dashed line, is aninformation link. These indicate that the value of a stock is a factor in the size of a flow. Indicated in this diagram by a dashed line. The link here shows that the time available for developing features depends on the number of trained managers.
Often stocks outside of a diagrams scope will be represented as a cloud, indicating that there is something complex happened there that we’re not currently exploring. It’s best practice to label every flow, and to keep in mind that every flow is a rate, whereas every stock is a quantity.
When I started thinking of a useful example of where systems thinking is useful, one came to mind immediately. Since reading Forgren’sAccelerateearlier this year, I’ve spent a lot of time pondering their definition of velocity.
They focus on four measures of developer velocity:
- Delivery lead timeis time from code being written to it being used in production.
- Deployment frequencyis how often you deploy code.
- Change fail rateis how frequently changes fail.
- Time to restore serviceis time spent recovering from defects.
The book uses surveys from tens of thousands of organizations to assess their overall producitivty and show how it correlates to their performance on those four dimensions.
These kind of intuitively make sense as measures of productivity, but let’s see if we can model these measures into a system we can use to reason about developer productivity:
- pull requestsare converted intoready commitsbased on ourcode review rate,
- ready commitsconvert intodeployed commitsatdeploy rate,
- deployed commitsconvert intoincidentsatdefect rate,
- incidentsare remediated intoreverted commitsatrecovery rate,
- reverted commitsare debugged into newpull requestsatdebug rate.
Linking these pieces together, we see afeedback loop, where the system’s downstream behavior impacts its upstream behavior. With a sufficiently highdefect rateor slowrecovery rate, you could easily see a world where each deploy leaves you even further behind.
如果您的模型是一个很好的一个,imp的机会rovement should be immediately obvious, which I believe is true in this case. However, to truly identify where to invest, you need to identify the true values of these stocks and flows! For example, if you don’t have a backlog ofready commits, then speeding up yourdeploy ratemay not be valuable. Likewise, if yourdefect rateis very low, than reducing yourrecovery timewill have little impact on the system.
Creating an arena for quickly testing hypothesis about how things work, without having to do the underlying work beforehand, is the aspect of system thinking that I appreciate most.
一旦你开始思考系统,你会发现it’s hard to stop. Pretty much any difficult problem is worth trying to represent as a system, and even without numbers plugged in I find them powerful thinking aids.
If you do want the full experience, there are relatively few tools out there to support you.Stellais the gold standard, but the price is quite steep, costing more than a new laptop for non-academic licenses. The best cheap alternative I’ve found isInsightMaker, which has some UI quirks but has a donation based payment model.