I'm Sandra Halling.

I've been doing some version of this work for twenty years, across organizations of varying size and configurations.

When I was in my mid-twenties, I did the foundational work of my career at a large international archiectural and engineering firm (RTKL — long before the Callison merger, around the time of the original ARCADIS acquisition).

I reported to the head of marketing and communications but had minimal supervision, because functionally I operated on the MIS team. Everyone on the MIS team was ten to fifteen years my senior. It was mentorship by fire, and I am deeply grateful for that experience. It shaped how I see systems, operations, and authority design permanently.

At the time, the firm had no CRM and little in terms of standard marketing process. I designed both and rolled them out firmwide across ten offices worldwide. (I was ~26.)

Part of that system held for ten years. They invited me back years later when the firm was considering new modules of the same ERP and we discussed what had held versus not. Durability is the key measure of success for my work.

What that project actually was, in retrospect, was a structural governance engagement disguised as a technical implementation.

That pattern repeated across the two decades that followed — across independent engagements and inside companies building structure in real time:

I was brought in to build or fix a system, but what was really not working was the structure.

Working across that many organizations under real operational pressure taught me what breaks first when structure has not been designed to hold.

Structural failures are often blamed on commitment, communication, systems, tooling, or interpersonal issues long before authority, ownership, and decision rights are examined.

But the patterns are consistent and predictable.

• Ambiguous authority means decisions stay open, route sideways, and collapse at the top.
• Unclear ownership means the people doing load-bearing work absorb consequences they did not create.
• Urgency as an operating model redirects capacity into containment that reads, from the outside, as execution failure.

These issues are not about which application your using or how you're resourced. They are structural.

As for me and my work? The door changed. The problem did not.

Once you see structural design, it becomes very hard to unsee — so eventually I stopped offering technical implementations as the entry point.

The practice is organized around a simple premise: most organizational instability is not caused by bad people, weak strategy, or insufficient effort.

It is caused by authority, ownership, consequence, and decision design coming apart from each other — slowly, usually silently, until something visible fails.

The work is to find where that separation happened, name it accurately, and determine what can change without making things worse.

Left unchecked and uncorrected the downstream consequence is genuine dysfunction.

I describe it simply because at the heart of it, it is simple. The situations it applies to are not.

My services prevent depdendency (that could inadverently make things worse) by requiring engagements be prepaid, time-bound, and exit-defined.

That structure protects both of us.

I do not have an implementation arm, a firm, or an incentive to recommend solutions that require my continued presence. The independence is what makes the structural read clean.

The work may be sobering, but I am delightful.

You'd have to experience that combination to believe it.

Want to see for yourself? Join my email list below and get practical structural signal in your inbox.