Types of Fiefdoms
From the mid 1990s to 2001, Robert Herbold was the COO of Microsoft. Under his tenure, the organization experienced impressive growth in both profits and culture. He wrote a book titled The Fiefdom Syndrome, in which he details the damage that fiefdoms inflict on organizational cultures. In this book, he describes six types of corporate fiefdoms, as follows:
- Personal—Fiefdoms that a single, broadly influential individual creates.
- Peer—Individuals or groups of individuals that operate their own fiefdoms at the same level.
- Divisional—Large product lines or divisions that operate as distinct entities.
- Top-Tier—Fiefdoms in which the heads of an organization cut themselves off from the broader organization.
- Group—Relatively small groups of people that form around some common task, responsibility, or objective.
- Protected—When a top executive or board sanctions, harbors, or even creates a fiefdom and provides long-term protection to it by sheltering it from financial or strategic scrutiny.
Each of these six types of fiefdoms is very dangerous to the organization in which they exist. When I look specifically at the UX organizations within companies, I see two very common types of fiefdoms. Often, these two types combine, which makes them especially difficult to control. The most common type of UX fiefdom is the Group fiefdom, which sometimes results when a UX team is brought into an organization specifically to fix something or has carte-blanche responsibility for design. More and more frequently, this type of fiefdom occurs in combination with a Protected fiefdom, where an executive sponsor was responsible for bringing in the UX team and, by his or her actions or sheer influence, allows such a fiefdom to fester, grow, and, ultimately, infect all parts of the organization before shutting it down.
How Do UX Fiefdoms Operate?
Fiefdoms operate around a very common set of human behaviors. The irony is that, when designing applications and services, UX groups run into other fiefdoms all the time. Over the years, I have consulted with a number of business groups in customers’ organizations where I have seen firsthand the difficulties that exist in designing something that spans multiple fiefdoms.
First and foremost, fiefdoms try to control the data. Fiefdoms thrive when the people within them place more energy and emphasis on demonstrating that they are doing well than on changing their behavior to improve their actual performance. As UX professionals, we see this all the time in business groups. Have you ever tried to design an application that would streamline access to data and task processes across multiple business groups? Suddenly, you hear about the ways in which each business group is unique and learn that each has its own system that the other business groups could not possibly replicate. These are corporate fiefdoms at work, and they destroy an organization’s ability to innovate, grow, and earn respect.
Similarly, whenever UX groups refuse to share information, create their own language and data models, or try to restrict other groups’ access to their methods and operational processes, they are creating their own fiefdoms. This happens whenever a UX group tries to create a moat around design and acts in a way that shows they—and they alone—are responsible for design. In essence, they create a fiefdom that isolates User Experience from the rest of the company.