Once upon a time I had a client that had five semi-autonomous LoBs (Lines of Business for the acronym challenged).

Each LoB had its own CIO who reported to its CEO. The Corporate CIO, who reported to the enterprise CEO, made six.

The corporate CIO owned the company’s data centers, the use of which was charged back to the LoB CIOs, making the latter the former’s customers, by definition. The corporate CIO also owned enterprise architecture, leading the LoB CIOs to report to him on a dotted-line basis.

Yes, that’s right: The corporate CIO’s customers reported to him.

Which leads to this conclusion about organizational charts: There might not be any such thing as a perfect one, a point we’ve explored over the past couple of weeks, but there is such a thing as an org chart that’s more imperfect than it has to be.

Org charts that rely excessively on dotted-line reporting relationships are in the forefront.

Start here: Org charts, before they accomplish anything else, depict delegated responsibilities. If, for example, the org chart has a Chief Revenue Officer, to whom a VP of Sales and VP of Marketing report, it means the CRO has delegated responsibility for selling and marketing.

Because the org chart describes delegation, it also describes who gives work direction to whom. Except … with sales and marketing reporting to a C-level position that reports to the CEO, that leaves the company’s product managers out in the cold. Shouldn’t they, or perhaps the product-line managers they report to, give work direction to the CRO?

Common sense, whatever that is, dictates they should. And so the CEO establishes a dotted-line relationship through which the CRO reports to whoever owns product management.

With perhaps one exception, dotted-line relationships are a mistake. The exception, with few exceptions to the exception: project managers, who will report to the administrative manager accountable for their overall performance, and an executive sponsor, who is accountable for the whole project and, by extension, makes decisions and gives day-to-day work direction to the project manager.

Unless the company wants to run its projects without sponsors (NOOOOOoooooo!) or doesn’t want to give, for example, raises to its project managers, some sort of dual reporting relationship is hard to avoid.

Using dotted-line relationships anywhere else adds, not to put too find a point on it, confusion without clarification. We don’t need a dotted line to figure out the VP of Sales and head of product management are supposed to work together to increase product sales. Nor does the dotted line clarify how the VP of Sales is supposed to resolve the conflicting priorities inherent in selling multiple products and services.

Which leads to the question, why are dotted lines so popular? The answer, I think, is that for many executives, reorganizations are the tool of choice in their how-to-fix-performance toolbox. And to be fair there’s some logic to this thought process.

What it is: On every org chart, each line separating two workgroups adds a barrier to getting work done when the two workgroups both contribute to the work. Therefore, the thought process goes, when work isn’t getting done, re-drawing the org chart so the workgroups in question are closer together should remove, or at least reduce, the size of the barrier.

Which would be just fine and dandy except that the org chart redrawing adds distance between the workgroups in question and other workgroups they have to work with to get other work done.

Reorganizations, that is, mostly fix what’s broken by breaking what’s fixed.

But is there a better alternative? Or, to borrow a line from Argo, is reorganizing, in spite of its flaws, the best bad plan we have?

Fortunately, there are better alternatives. We discussed two of them last week — Centers of Excellence and their less-reliable cousins, Communities of Practice.

A more general solution is to fix the business culture and thinking about what the org chart means.

The shift: When anyone thinks a dotted line will fix anything, redirect their perspective so they understand no line of any kind will help. What will help is the assumption of collaboration, where leaders expect everyone working on anything will automatically bring in whoever else they need to work with get it done.

As for the org chart itself, it’s John Venn to the rescue.

Not, you understand, an actual Venn diagram. Depicting the entire enterprise as overlapping circles isn’t really practical and will just make your head hurt.

But the thought process behind it, re-envisioning the org chart’s boxes and lines as Venn’s overlapping circles?

It will help everyone connect the dots on why not to draw dotted lines.

When we delegate responsibility, we’re frequently told, we must also delegate commensurate authority. Otherwise, we can’t hold delegates accountable.

As with so many other what-we’re-frequently-told statements, it’s more plausible than accurate.

Start with the organizational chart. What it does is document operational delegation — how the CEO has delegated responsibility (and, in theory, authority) for everything that has to happen for the organization to succeed.

Imagine you’re Director of Sales for a company that sells a variety of widgets, gadgets, and doohickeys. The company’s strategic plan calls for a 20% year-over-year increase in Gadget sales. You’re responsible, so you ask your top Gadget sales reps what they need to hit the target.

“Fix the product,” they tell you. “Our gadgets are the worst in the industry.”

So you convene a Gadget Redesign Committee, which dutifully creates new-and-improved Gadget specifications. You bestow them to the Director of Gadget Engineering.

Who bestows them right back, because he, not you, is responsible for and has authority over gadget specifications.

His strategic target is a 10% increase in gadget manufacturing efficiency. Your designs would reduce it. And you’re invading his delegated-authority turf.


No matter how you draw the boxes and connecting lines, anything important that has to happen crosses organizational boundaries. Successful products, for example, require research-and-development, design, engineering, supply chain management, manufacturing, distribution, sales, marketing, and advertising, and I’m sure I missed a few others.

Which illustrates why, as pointed out last week, there’s no such thing as a perfect org chart.

One solution is to create cross-functional teams to address boundary-crossing responsibilities. These work well when pointed at problems that require collaboration among those competent at the different disciplines required for success at whatever it is that needs to be successful.

But cross-functional teams are less well suited to when the company needs to be competent at something, with “something” encompassing organizational capabilities like: Project management, architecture, process design and management, organizational change, and quality assurance, to name a few.

That’s where Centers of Excellence (CoE) and Communities of Practice (CoP) come into play. Both are boundary-spanning entities whose goal is to improve organizational competence at a specified discipline.

Where they differ: CoEs are official entities with assigned leadership, budgets, and goals. CoPs, in contrast, are, as the name implies, true communities — self-organized, with goals defined informally and by consensus, and with the time and effort required for their success donated by community members on top of their official responsibilities.

Compare a CoE to, say, a Project Management Office (PMO).

With a PMO, the CEO has delegated both responsibility and authority for improved project success. Having authority, the head of the PMO is in a position to define and enforce the use of the company-standard project management methodology.

But as the head of every other organization has the equally delegated authority to run their operation as they see fit, including how they manage projects, conflict is built into this arrangement, right down to its core.

The head of the Project Management CoE, in contrast, is responsible for improving project management practices with no enforcement authority. Lacking authority, the CoE has to make use of a more subtle toolkit, one that includes internal marketing, persuasion and influence, a curriculum with certifications along the way, and one-on-one selling to managers throughout the enterprise.

When you can’t dictate you have to communicate and deliver benefit.

How about CoPs? As self-organizing entities they have a lot in common with volunteer organizations outside a business setting: They depend on the enthusiasm, commitment, and evangelism of people deeply committed to the practice in question. Usually, they’re even more dependent on a highly skilled, even-more-committed, charismatic leader to hold everything together, especially as many volunteers, in the absence of financial compensation, expect payment in the form of ego gratification.

CoPs can and do provide a lot of value. But they’re an unreliable organizational solution, because expecting a CoP to happen on its own is just trusting to luck. If a useful one does form, encourage it. Just don’t rely on it.

Can’t execs drive the process? No, for a simple reason: The act of encouraging a handful of experts to form a CoP instantly transforms it into a CoE, by definition.

By all means support CoPs whenever they form. But as a reliable way to increase organizational competence, CoEs are the way to go.

One last thought: Imagine the company has chartered several CoEs. Some work better than others. Should you charter a Centers of Excellence Center of Excellence?

Repress the thought. That way lies madness. Or at a minimum, uncontrolled recursion.