A few years ago, I wrote a teaching case about a recently established marketing department in a large company. The department had been formed by merging three smaller units, and on paper, it looked like a fairly standard restructuring.
But something interesting happened when I used the case in class: my students often pointed out that the new department’s mandate seemed incoherent. It was supposed to both provide advice and services to internal units - and also monitor those same units for compliance with corporate marketing guidelines. In other words, the unit was meant to serve and control at the same time.
That tension stuck with me. If a large, resourceful organization can create a unit with such conflicting expectations, how often does this happen elsewhere? And what would the criteria be for a good mandate?
That question eventually became the seed for a longer research project - and a collaboration with my colleague Shawn Pope. When we turned to the academic literature to ground our work, we were surprised to find almost nothing. The idea of a “unit mandate” is familiar to most managers - everyone I spoke to could articulate their own - yet it has received little attention in organization theory.
That gap was part of our motivation for a paper we published in Academy of Management Perspectives. In it, we argue that organizations need more than inspiring purpose statements. They also need to align their formal structures with that purpose, through clearly formulated unit mandates.
The mandate problem becomes even more acute when organizations start integrating AI. New AI-enabled units get created, existing units get reshaped, and the boundaries between human and AI work need to be explicitly defined. Without a clear mandate, these units accumulate conflicting expectations - just like the marketing department in my teaching case.
At Reconfig, we use unit mandates as one of the building blocks when designing a target operating model. Mapping mandates across the organization makes structural conflicts visible before they become operational problems - and before a single real-world change is made.