Behaviour over Time Charts

Purpose

Behaviour over Time, or BOT, charts are the foundation of system diagnosis. In software development we tend to view systems as isolated events such as incidents, sprints, or spikes. A BOT chart forces us to zoom out of operational noise and recognize that today's event is only a single data point in a much larger multi-year curve. It reveals whether a problem is growing, decaying, oscillating, or crashing into a hard physical limit such as an S-curve.

Context of Use

BOT charts are often the first step in almost any root-cause analysis in system design. Before you try to understand why the Jenkins server is on fire today, you need to sketch how the build queue behaved over the last 24 months. Without that historical timeline, you are guessing blindly.

Step by Step

1.Define the issue: Choose the critical variable you want to examine, such as defect rate, developer turnover, or technical debt.

2.Stretch the time axis: Go back far enough to see real patterns. Think months or years, not days.

3.Draw the curve: Sketch the rough course of the variable on the Y-axis. Is it steadily rising? Is it oscillating wildly?

4.Overlay related curves: This is where the magic happens. Draw the same chart for external driving forces, such as the number of new features per sprint, and place it over the first chart to detect delayed correlations.

Example

An engineering team complains that release frequency is falling. Graph 1, deployments per week, trends downward. They blame QA. An architect adds Graph 2, number of microservices in the system, which shoots upward, and Graph 3, number of DevOps engineers, which stays flat. The behavior over time shows the reality: the decline in release frequency is not QA laziness but the mathematical collision between exploding architectural complexity and stagnant deployment capacity.

Diagram

How Diagnosis Turns into Action

The most valuable aspect of BOT charts in architecture is that they make delays visible. If management applies intense pressure, velocity may rise in the short term. Six months later, bug rates explode while velocity collapses. If you had looked only at snapshot metrics in Q3, you would have missed the pattern. The BOT chart proves a Fixes That Fail dynamic: the short-term speed hack in Q1 kills the system in Q3 with delay.

When This Method Fits Best

Unlike Stock and Flow Mapping, which formulates hard physical equations, BOT charts often rely heavily on qualitative judgment. It is completely valid to place soft variables such as developer morale or architectural clarity on the timeline as hand-drawn curves.

How to Use the Diagnosis in Everyday Work

Make it a rule that no architecture discussion about an acute problem happens without a BOT chart. If someone says, "We need a bigger cache, we are at the limit," send them to the whiteboard to draw cache hit ratio, latency, and user logins over the last two years as three curves. The gaps between the curves often show that the real problem started somewhere else.

First Analysis Steps

In workshops, BOT charts are not about building a perfectly accurate spreadsheet. They are conversation tools. Let the principal developer sketch a curve, then let the product owner draw a competing curve in red if they experienced the history very differently.

How You Recognize a Useful Diagnosis

Does your DORA metrics dashboard show not only current gauges but also hard line charts that visualize decline or improvement over the last 24 months?

Sources

John Sterman — Business Dynamics, Chapter 5: BOT Graphs (McGraw-Hill, 2000)

The Systems Thinker: Behaviour Over Time Diagrams

Peter Senge — The Fifth Discipline Fieldbook (Doubleday, 1994)