Back in the good old days, when I had the luxury of managing just one type of employee, I believed that applying a sufficient amount of effort could solve nearly any problem. When my teams expanded to include developers, quality assurance experts, security groups, infrastructure engineers, human resources staff and the occasional janitor, I came to—for me at least—a startling realization: Work, even work guided by innovative process, is not the only controlling factor in job accomplishment. In fact, there exist roles and functions organized in a radically different way, calling for a completely different organizational approach.
I came to this realization in the middle of what I later described as a project meltdown. My team contained five groups, each with different responsibilities and functions. Three of the teams (development, deployment, and operations/support) "worked" diligently to create products for the client environment. Two of the teams (resources and quality assurance) provided logistical, management, and quality support to the other two. I spent my time working with the team leaders and communicating with the rest of the business.
About six months into a fairly large system update, work ground to a complete halt. We missed a deadline for the deployment of a new piece of the ERM. When I asked for an update on the time line, the development manager told me: "Never. Those damned idiots in QA are never going to get it together."
With that in mind, I called the QA lead. He told me roughly the same thing: QA could not approve a product until they got it, and Dev never produced anything to test. What was worse, in his mind, was that the developers were going around QA to deploy software into the environment with the help of the deployment and operations teams.
Something struck me during these conversations. It almost seemed as if the groups were talking about radically different work experiences. Given my understanding of process at the time, that triggered a warning bell in my mind.
After a good deal of consideration, I called a team-lead meeting. During the week before the meeting, I called each lead into a conference room. There, we diagrammed his work, his team's processes, and the roles/responsibilities assignments. Where he interfaced with other teams, we also outlined those outside roles from the leader's perspective.
A blinding flash of the obvious
A day before the meeting I asked my allies in the organization to keep everything off of my plate for a few days. Then I closed the meeting room door and set about analyzing my team leads' diagrams.
On one level, I was quite pleased. Everyone agreed, in a formal sense at least, on the basics of the IT process. There were a number of radical disagreements about the responsibilities of roles on other teams, but nothing out of the ordinary for a working shop.
On another level, I felt a sinking feeling in the pit of my stomach. The cause of the conflict, and of the inevitable cause of the delays, was vividly depicted on the whiteboards surrounding me.
The product teams (development and deployment) possessed relatively few external dependencies. Their roles and responsibilities responded directly to the amount of work they poured into them. If a member of those groups poured nine hours into a task, he got roughly nine hours of result.
The resources teams (quality assurance and resources) could barely function without outside assistance. Each role existed in an intricate web of interdependency with roles outside of their organization. QA could not change their test databases without help from the deployment group. Resources could not organize a meeting or pull together a packet without authorizations from each of the other groups. Their tasks were, in other words, highly dependent on the efforts of others. It did not really matter how much time and effort they put in; their dependencies were so great, and so strong, that they governed the tasks.
The operations/support team worked in a hybrid configuration. They had some roles and tasks that responded directly to work investment (e.g. customer support) and others (e.g., network analysis/troubleshooting) that relied on others to create results.
This suggested there were two, diametrically opposed ways to regard roles/tasks. In one, the actor's work determined the results. In the other, the actor's ability to manage his dependencies determined what he could accomplish.
Insight One: The conflict between dependency and work
This insight led me to another: These two ways of approaching work will always bring roles into conflict.
Work-governed actors believe, correctly, based on their own experience, that any task resolves with a sufficient application of time. They can often divide their work into unrelated categories and work simultaneously on several tasks at once.
Dependency-governed actors believe, again correctly, that effort resolves less than clear communications and the responsiveness of other actors. Their experience shows them that if they do not get cooperation from others they simply cannot do their jobs. Worse, they also know they will be held accountable if the task fails, even if they did everything within their role's authority.
This difference results in inevitable but predictable clashes. What we can predict, we can control and even mitigate to one degree or another.
Insight two: Differences in role organization
The difference in orientation between work- and dependency-governed roles also suggests a different approach to organizing role responsibilities.
Traditionally we organize role work in terms of logical distribution. We try to centralize authorities and make sure we know who, exactly, is responsible for each task. A role may have several related functions, sometimes spanning teams. This allows work-governed roles to work more swiftly; they know who to go to and what results to expect.
In dependency-governed roles we have to think in terms of dependency chains. In order to speed their operation, we have to reduce the dependencies, or at least streamline them in some way. If a person has to wait on three other people before she can begin her task, she will, by default, wait longer than if she has to wait for one.
Carrying the flash into the real world
With these insights in mind, I turned my attention to my problem. In a daylong meeting I asked my team leaders to walk me through their diagrams and how they interacted. We addressed the problems associated with each group. We talked about how the interactions worked or failed to.
In the end, we agreed to radically reorganize the responsibilities of resources and QA. QA retrieved its own domain, hardware, and databases to perform their testing. This set them back to their original configuration from a few years back, which had steadily eroded as development and deployment became frustrated. Resources gathered greater signature authority for purchases from the other teams and authority to communicate with outside departments on a continuing basis without authorization from the various team leads.
The reorganization cost us another two weeks of elapsed time while we got a grip on everyone's new responsibilities. However, it also allowed us to detect work vs. dependency conflicts before they arose. This, in turn, gave us a chance to avoid the kind of work stoppage we previously encountered without the application of managerial power.