I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

Tuesday, July 30, 2013

Conflict, Part I

Product management was never a formal responsibility; it just sort of happened.

Early on, it was driven by what the technical wizards came up with. But the magic left the development team years ago: it had been gutted by several rounds of staff cuts that took the garrulous personalities and innovative thinkers. It took the wind from development's sails: those who were still on the payroll were just happy to have kept their jobs. They adopted a "just tell us what you want us to do" attitude about the products.

At that point, product decisions were made by sales. The sales team was larger than it had ever been, but it had struggled. Each quarter they set lofty sales targets, and each quarter they fell short. This made them jittery about revenue: they spent more time in internal meetings discussing how not to lose revenue than they did meeting with clients to find ways to generate more. In addition, product training hadn't been refreshed in years, and they never formalized an onboarding process for new salespeople, so their grip on the products they were selling and the clients to whom they were selling was not that strong. The net effect was a chronic lack of confidence: the sales team automatically negotiated from a position of weakness and never met a dollar of revenue they didn't like. The impact on product was to pile on feature after feature and request after request.

Company leadership eventually formed a product management team, staffing it with existing employees. Although they had product responsibility, it was clearly going to take some time for this group to learn enough about the customers, users and the products to be effective in a product management role.

This created a product leadership vacuum that was partially filled by the graphic design team.

Like most software companies, user experience was originally driven by developers: screen layout, workflow, and even general appearance were byproducts of decisions made during development. Uncharitable customer feedback on usability of the software led to the creation of a small in-house graphic design team. They met with instant success: the polish they put on the software won praise from customers.

At some point, the graphic design team began to self-style themselves as a User Experience (UX) group. This was a logical evolution that would provide career development opportunities. It was also an essential competency that was conspicuous by its absence in a software company. Executive leadership was thrilled by what they saw as the design team stepping up to fill an essential need. They gave the team encouragement, and a slightly bigger budget.

As practiced, UX was largely an extension of graphic design work, creating more comprehensive interface design at the panel level. In one sense, this was pragmatic: because the company had not historically invested in skill acquisition and capability development, it was reasonable to assume UX skills would be acquired incrementally and the capability developed organically. In another, it was naive: the UX team weren't familiar with things like personas, value stream mapping and other essential inputs to software design. They were on a self-directed voyage of discovery, moving at a slow pace. Capability would trail aspiration for a long, long time.

This put UX and development into direct conflict with each other. UX felt that development was uncooperative with the design process: they saw development doing their own thing, or stonewalling, or being outright obstinate. Development had a different perspective. They saw design infringing on work that had always been the purview of development. They also felt it wasn't improving the development process: more detailed screen layouts without accompanying context about users and scenarios wasn't all that helpful, and it was eating into the alloted time for coding and testing. Development felt increasingly frustrated, believing they had less time and less control over what they did.

One day, following a particularly contentious design meeting, the development director put his complaints, criticisms and demands into an e-mail to the head of design. He was tired of design impinging on development's turf, taking too much time to do inadequate work and leaving development to scramble to meet deadlines and struggling to work within a UX framework he felt was incomplete. The e-mail was not personally insulting, but his frustrations were obvious. And although he proposed some reassignment of responsibility, his main message to design was "back off".

The e-mail didn't just travel from the development director to the head of design. Each shared it with superiors and colleagues. It eventually found its way to the company president and CEO.

The president reacted by sending a one-line e-mail to the development director: "I won't tolerate behaviour like this in this company!"

* * *

For most managers, conflict is unwelcome. It creates work: the manager has to smooth over hurt feelings, come to the defense of an accuser or accused, and navigate the power politics that conflict stirs up. It exposes ambitions that set a tone of competitiveness, distrust or fear. It lays bare opinions, frailties and passions that many believe have no place in the workplace. It creates the appearance that the manager doesn't have control of his or her people.

But conflict in an organization is inevitable. Conflict arises from the collision of competing interests, and every company has a rich diversity of interests. There are the company goals (in effect, those set by leadership), such as revenue targets. There are objectives people have for their departments, such as to add new positions and hire more people. There are individual goals, such as career ambitions or control over what one works on. These interests will never be in perfect alignment. And they are always present: it is irrational to expect there will never be conflict, that company interests are the only ones that matter and that people will subordinate their interests to those of their employer.

Conflict is also healthy. It exposes fault lines, real and imagined, in an organization. It indicates engagement: when people don't feel motivated enough to enter into conflict, it suggests they're not optimistic that their goals can be met by the organization, or that they don't believe the organizations goals are worthwhile. It also fosters innovation: passionate, engaged people publicly advocating divergent opinions will come up with creative solutions to organizational problems. Lethargic passengers in an organization rife with groupthink will not.

As I wrote above, it is irrational for a leader to expect that there will never be conflict. Yet many leaders intrinsically assume that people subordinate themselves in service to the company. In doing so, leaders deny the relevancy and even the existence of interests outside of those held by the leadership. This is, according to Burrell and Morgan1 what is called a "unitary" philosophy of management. The organization is seen as being united under a common set of goals and uniformly pursuing them as a team. Authority is derived from the hierarchy and responsibilities are narrow: managers have the right to manage and employees the duty to obey, and everybody is expected to do no more and no less than the job to which they have been assigned. Unitary leaders regard conflict as uncommon and temporary, something to be removed by managers. Instigators of conflict are regarded as troublemakers.

The unitary philosophy aligns with traditional ways of seeing an organization: as a top-down, command-and-control, static operation. At first glance, unitary leadership would appear to be out of touch and out of date in the era of mobile and empowered knowledge workers in increasingly dynamic businesses. Still, it remains very appealing to leaders, managers and subordinates alike. For one thing, it deals with sociological complexities of the workplace by ignoring them. For another, it imposes a facade of unification under which symbols, rituals, process and reporting structure can be brought to bear to create organizational order. As a result, it reduces management to a technical problem of defining and tracking tasks, and measuring performance against those tasks. This is the key to its appeal: business is a whole lot easier when it's a one way street!

An alternative2 to the unitary philosophy, called pluralism3, conceptualizes the organization as a coalition of diverse people. To the pluralist, conflict in an organization is inherent and routine, and the pluralist leader looks at conflict as an opportunity for change and evolution. Authority in the organization is diversified and constantly changing, as are each person's scope of responsibilities. People are expected to seek ways to collaborate to achieve organizational goals. This final point is key to understanding the role of conflict. In the unitary organization, people are confined to roles and the manager creates order. In the pluralist organization, people constantly collaborate to create a new order.

Let's look at our case study from a pluralist leadership perspective. First, the pluralist must understand the other person before trying to be understood themselves. The development director may feel frustrated, but has to realize that development abdicated leadership years ago when it became a passenger in product management. The spat with design is simply the latest event in a long trend of largely self-inflicted decline. The development director must also recognize how the design team was trying to evolve a design capability. Similarly, the UX lead must understand the gap between interface design and UX and how development has historically bridged that gap while it develops. Next, the organization leader must then facilitate a collaborative outcome that will improve the state of the organization overall, not a compromise that subordinates one collection of objectives to another to expedite the task at hand. In this case, the company might hire in analysts or train people in developing personas and workflows and restructure the development cycle to incorporate more thorough user experience design activity.

The extent to which a leader accommodates versus imposes has a dramatic impact on the character of the organization he or she leads.

The pluralist organization is a "big tent" that welcomes diversity and divergent opinions and goals. It will be attractive to drivers (people who get stuff done) and creative thinkers. Each person must be a pluralist: they have to work in collaboration with other people to achieve the maximum superset of outcomes. As a group they must be highly skilled, but to a person it is less important to be skilled than it is to have the disposition to learn. This is because the capability of the group supersedes that of any one person, whereas the aptitude to learn and change makes for stronger interpersonal partnerships. The result is an organization of peers that is more flat than hierarchical, that moves in fits and starts but requires less hands-on, in-the-weeds management. Facilitators do well in the pluralist organization, task tyrants do not.

In comparison, the unitary organization does not accommodate alternative (let alone competing) goals to those set by the business leadership. As a result, it will attract passengers, people who are largely content to do as they are told. This means the unitary organization will be less diverse, more sullen, and more fragile than the pluralist organization. But that isn't to say that the unitary organization is staffed with soulless go-bots who do the bidding of their paymasters: every person in a unitary organization will still harbor personal objectives, some which will be in perfect alignment with those of the organization, and some which will be wildly divergent to them. Each person will still go in pursuit their own objectives to one degree or another, but because a unitary organization has no tolerance for goals other than its own, people will pursue their objectives below the organization's radar to avoid conflict. The proliferation of all these invisible individual agendas reduces management to meticulous supervision of and continuous negotiation with each employee just to achieve the simplest of organizational objectives. Ambitious goals are out of the question.

The pluralist organization is more vibrant, diverse and robust than its unitary counterpart. These are important characteristics for professional, knowledge and creative businesses. They are also increasingly important to industrial firms as they become more knowledge-based businesses. At a macro level, businesses have to be more environmentally aware and adaptive to a degree their industrial forebears did not. At a micro level, highly skilled technical and knowledge workers are scarce, increasingly complex business context makes people far less interchangeable, and employee mobility has never been greater.

Being a pluralist is a struggle against entrenched patterns and expectations. Stories of leadership are dominated by people who espoused a unitary philosophy, from Julius Caesar to Steve Jobs. Unitarism is entrenched in business and even societal norms.

Still, it is a choice that every leader makes, and the decision to impose, deny and steamroll or accommodate, facilitate and explore will impact the nature and character of the organization. For the leader, one truth stands above all others: you get the organization you deserve.

Choose wisely.



1Morgan, Gareth. Images of Organization, page 189.

2There is another alternative to the one discussed here, called radicalism. We'll look at radicalism and why we need more radicals in the software business in a future post.