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.

Project meltdown

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

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

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

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.