Systems Thinking isn't a Personality Trait, it's a Habit

The symptom isn't the system: a CFO's year-end target, a queue that quietly dried up, and why the fix was nowhere near either project everyone had signed off on

Home • About • Projects • Blog • Resources • Contact

The gap between "we can build this" and "we understand what this touches" used to be measured in quarters. AI-accelerated development has compressed it to days, raising the stakes on good judgment happening before the build starts despite the temptation to dive in.

People often see "systems thinking" as meaning seeing the big picture or joining the dots. In practice, for me it's three specific habits, and the discipline to keep using them once things get pressured.

A CFO, under pressure to hit a year-end target, said in passing that the numbers would work if the business could roughly double loan applications processed per month. This then became the immediate priority. Leadership proposed focusing two workstreams to get there: a self-serve application portal, and automated pre-vetting to speed up intake. I argued they couldn't be treated as separate, since self-serve application and vetting weren't independent levers, but fed the same pipeline, and splitting them meant nobody would be accountable for whether the pipeline as a whole could actually carry double the volume. I ended up leading the combined workstream from there, and reviewed the entire pipeline and all the data we had on what was occurring at each stage, leading me to ask the obvious next question: ‘did we actually have underwriting capacity to process double the applications once they arrived?’. Nobody had checked; moreover, there was no readily available data on this at all.

Almost as soon as the working group formed, an incident was declared. The system wasn't showing enough applications as ready to move into underwriting, throughput was dropping below normal, and it looked like a platform fault - it was proposed the platform was incorrectly filtering out applications. After investigation it turned out not to be a platform fault at all, we were genuinely running out of applications ready to be underwritten.

In the name of cutting underwriter review time and cost per file, the business had recently rolled out a rule requiring every supporting document to be fully uploaded before an application could enter the underwriting queue. It had been piloted with a handful of users for a few weeks, shipped, and never monitored properly afterward.

I took the data on how quickly applicants actually completed their document uploads and modelled the counterfactual: if we removed underwriting delay altogether and moved every application into the queue the moment it was submitted, would doubling volume even be achievable. The data clearly showed it could not - three weeks after being asked for their documents, over half of applicants still hadn't started uploading them. Self-serve intake would achieve nothing, because the real block sat earlier in the pipeline than either proposed workstream touched.

Leadership's first instinct was a workaround: let applications proceed to underwriting as an exception, even where some of the documentation was still outstanding. The data ruled that out too as the stalled segment, representing over half of all applicants, hadn't started uploading anything at all, and the smaller group who had made some progress were consistently avoiding the one document every underwriter regarded as the most necessary. We tested a set of reminder texts to see whether a lighter nudge would shift things. It moved the needle slightly for people who were already close to finishing, but did nothing at all for the genuinely stalled majority segment; moreover this generated complaints from applicants who said the reminders felt like harassment.

The actual fix had nothing to do with either original workstream. Instead we needed to redesign the upload experience specifically around the applicants who were stalling rather than the general population: explaining plainly why each document was needed and how it would be used, addressing the concerns people were most likely to have upfront, giving realistic time estimates, and showing progress as they worked through it, so the task read as one short step rather than a wall of paperwork. Alongside that, drawing on an approach a colleague had used to solve a similar problem elsewhere, we looked to trial having someone call the most stalled applicants directly, offer to talk them through the first few questions there and then, and promise a callback within the hour if they still hadn't finished on their own.

Mapping the pipeline properly surfaced two further problems nobody had planned for: if the fix worked, the existing pool of applicants waiting for underwriting would run out within weeks, meaning we needed to start generating new demand much earlier than anyone had assumed, and underwriting capacity itself still hadn't been planned for the volume leadership actually wanted.

None of this meant the original ideas were wrong. I continued to champion self-serve status tracking and the ability for applicants to amend their own submissions, with a longer-term view to full self-serve application intake, and I supported simplifying and automating the vetting. What changed was refusing to let either be judged in isolation from the system they sat inside.

Everything above played out over a couple of weeks, with a working group, a formally declared incident, and a fair amount of friction along the way; but that cadence is disappearing. The harder question is whether the same discipline survives when a product manager can prompt an AI tool into a working prototype of a new intake flow before lunch and have it in front of real users by the end of the day, with no working group and no incident review to force anyone to ask what else it touches. My view is that the discipline matters more under that kind of compression, because the compression removes exactly the pauses that used to force the upstream and downstream questions to get asked, whether anyone meant to ask them or not. If a team of mine builds something in an afternoon I still expect the same pre-build considerations to take place:

The CFO and the rest of leadership were the obvious stakeholders here, the ones asking for the number by a fixed date. The actual constraint sat with people nobody had thought to ask: the underwriters whose capacity nobody had checked, and the applicants whose stalled progress through a form was quietly capping the entire pipeline. This is why good discovery remains vital.

I also have teams run a pre-mortem with engineers, frontline staff and anyone downstream before committing to a plan, not after it's already underway. Pre-mortems force the question of who else this actually touches, and what might not have been considered, while there's still time to change course.

These habits are a culture that can be built rather than a personal trait. We need to ensure that even under pressure, and even building at speed, it’s hard-wired into teams that they’re clear on what sits upstream of the problem they've been handed, what sits downstream of the fix they're about to ship, and whether they can honestly say it would move the primary outcome metric. If the answer to any of these is that they don't know, these aren’t details to fill in later. We need to make sure teams still have the space to take stock and do the necessary work. Building that expectation into a team, so people still take the time even when the tools would let them skip it, is culture, and it has to be shaped from the top down. Whatever number your teams are being asked to double, ensure they check every stage of the pipeline before they touch the one everyone's already looking at.