Thinking in Systems as a Daily BA Habit

You do not need a system map for every requirement that crosses your desk, and treating every small change as though it needs a full diagram and a loop analysis will slow a team down for very little real benefit most of the time. What you actually need, in the overwhelming majority of cases, is much smaller than a diagram. One honest question, asked before most changes ship: what else is connected to this, and what is the most likely way the people affected by it will actually respond once they are living inside it rather than simply reading about it in an announcement. That single question carries almost all of the value this entire week has been circling, and it costs a couple of minutes rather than a workshop.

What this week actually built, in order

Monday opened with a queue fix that worked exactly as designed and still made things worse, because the pressure it relieved in one place simply moved to a part of the system nobody was watching yet. Tuesday gave a practical way to actually see those connections before touching anything, a page with the problem in the middle and every real, defensible influence drawn around it, including the arrows that loop back on themselves, which a straight-line process map has no way of showing at all. Wednesday named the two shapes those loops most often take, a reinforcing loop that feeds on its own success and a balancing loop that quietly resists every push against it, and why the instinct to simply push harder fails on both, just in opposite directions. Thursday added the one extra question that catches most of the expensive surprises before they ship: not just does this solve the problem in front of me, but what happens after people have had real time to adjust their own behavior around the change.

None of those four days required a certification, specialist software, or a background in formal systems modeling. Each one was a specific, nameable habit, learnable in an afternoon and genuinely useful the very next time a fix is about to ship.

Where this belongs in ordinary work

The honest risk with a week like this is that systems thinking starts to feel like a separate, more rigorous activity, something you do occasionally for a big strategic decision and otherwise set aside for the ordinary pace of daily requirements and process work. That framing undersells what actually makes this useful. The expense cap from Thursday was not a strategic decision requiring a steering committee. It was an ordinary policy change that any finance team makes regularly, and the one extra question that would have caught the purchase-splitting risk took about two minutes inside a normal conversation, not a dedicated workshop with its own calendar invite.

The habit belongs in the same place requirements gathering and stakeholder conversations already happen, folded into the ordinary rhythm of the work rather than bolted on as an extra formal step. When a new requirement comes in, alongside the usual questions about scope and acceptance criteria, one more line earns its place: what else does this touch, and what will the people on the other end of this change actually do once it lands. Asked that plainly, as a habit rather than a special occasion, it rarely adds meaningful time to a conversation that was already happening anyway.

The question worth carrying forward

If there is one thing worth taking from this entire week into Monday's next piece of work, it is this: a system is not a diagram you draw occasionally for the hard decisions. It is simply an honest acknowledgment that nothing in a real organization changes in isolation, and that the people inside any process respond to whatever incentive a change actually creates, not necessarily the one it was intended to create. Most expensive surprises in this line of work were never truly unpredictable in hindsight. They were a second-order question that nobody happened to ask out loud before the thing shipped, because the first-order answer looked good enough, and good enough felt like reason enough to stop looking.

That is a small, carryable habit, not a new discipline to master before it becomes useful. The next time a fix looks obviously right, before it ships, it is worth asking once what else is connected to it, and what the people living inside the change are most likely to actually do. Most of the time the answer will confirm the fix is genuinely fine. Occasionally it will save six weeks of confused complaints about a problem that was never really fixed, only moved.

I think about the queue story from Monday often, not because it was unusual, but because of how ordinary it was. Nobody involved was careless, and nobody was punished for the fix going sideways, because on paper the fix had worked. That is precisely what makes this worth building as a habit rather than filing away as an interesting story about one team's support queue. The next version of that same mistake is sitting in someone's backlog right now, waiting to ship, looking exactly as reasonable as the queue target did the day it was approved.

None of the five days this week asked you to become a systems modeler, and none of them required software, training, or a certification sitting between where you are now and being able to use this. What they asked for was smaller and, I think, more durable: a short list of questions worth carrying into ordinary work, asked often enough that they stop feeling like extra effort and start feeling like how the work is simply done. What else is connected to this. Is this effect feeding itself or resisting me. What happens after people have had time to actually live inside the change. Three questions, each one cheap to ask and expensive to skip, and that is most of what a system view actually adds to the job most days.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

NEXT WEEK

Lean Six Sigma for BAs Who Aren't Black Belts - What actually transfers from Lean Six Sigma into everyday BA work, without needing the full certification.