Navigate Best Practice—Following Authority Tracks

Delegated Authority Is Not Linear

When I see governance explanations, they are usually expressed as neat vertical models with crisp vertical authority domains. Reality has nothing to do with these simple diagrams.

No decision drops down a simple vertical authority path. Nor is there ever one corporate priority. Searching for the priority and the decision-maker is a fool's errand.

We have a few tools to help us think this through.

Michael Porter gave us value chains—primary and supporting. The primary value chain is optimized for the customer relationship. Other parts support the primary value chain, by providing the benefit of scale on an activity that is common.

SABSA gave us the concept of risk, or governance, domains.

John Carver gave us the concept of 'negative space'. The space where the delegate is expected to make their own decision.

I have always liked Carver's simple example where the board demands more revenue. With no constraints, the CEO is free to try raising prices, growing market share, entering new markets, or creating new products. With the simple demand—more revenue—we have a performance expectation but no constraints.

That CEO has a lot of options. Far more options than if the board had said 'Grow revenue with existing products in current markets'. The simple change filled in the CEO's decision space. Decisions have already been made. New markets and new products just vanished from her decision space.

Using SABSA's risk domains, we get a richer story. Risk, or governance, domains allow us to model additional delegation. We have the tools to follow a delegation and see the decision space change shape. Our CEO can take her directions and her product portfolio and request:

• Product Family A, grow market share and revenue in their existing customer segments with existing products
• Product Family B, grow revenue through price optimization from their existing customer segments with existing products
• Product Family C, increase margin contribution by holding prices and lowering the cost of goods

All of a sudden, the simple top-level direction has changed shape. We have one product family chasing revenue through market share, another through price, while a third has been told the measure of success is margin, not revenue.

That is just part of the primary value chain—product. Important, but not the whole story.

Our CEO can also look at another leader, then direct them to pursue a process improvement. Look at her Finance lead and demand more efficient Finance operations measured by improving from the 30 days to close the books to 14. Look at her IT lead, and ask for IT costs to shrink relative to revenue. Look at her HR lead and ask something else.

What is Finance's priority—helping Product Family C understand their cost model or cutting the time to close the books?

What is IT's priority—cutting IT costs, helping Finance automate closing the books, helping Product Family C introduce new automation technology to cut costs, or helping Product Family A introduce new technology to support customer engagement and cross-selling?

What is Product Family B's priority getting a better price point or helping finance by simplifying revenue recognition, or helping IT by retiring an obsolete system?

If you are looking for a simplistic binary answer, you will never find one.

With a simple binary direction to do this, you have moved from architecture to implementation.

Our CEO went around the room, looked someone in the eye, and requested a specific outcome. She provided direction and delegated authority. She will be asking for progress on every requested outcome.

Thinking in SABSA governance domain terms, we can extend the cascade. Every decision domain can further delegate part of itself. The Lead of Product C can turn to someone and say, "Drop overhead". Look someone else in the eye and say, "Reduce warranty claims." Then look to the other end of the table and say "Redesign Product X, I expect the same value for half the cost."

At every point, SABSA tells us that the domains are peers. They each have an accountable span of authority. Within that span, and within their constraints, they have decision-making power.

The challenge is the shape of the decision space. It is controlled by decisions taken elsewhere. Above in the chain of command, or across the organization down a different delegated path.

Every decision domain has a unique shape to its decision space. Direction from above—distinct performance expectations, different constraints, and usually totally different risk appetites. Every step down the cascade there was a decision to act. There was time to advise about alternatives. Then the transition to owning the decision, like the superior architecture it is.

We see friction when these different cascading requests collide at the edges of different decision domains.

My simple example above—Products A, B, and C, Finance, IT, and HR—is loaded with friction.

Friction drives creativity. Friction allows the CEO, or the boss' boss' boss, to get the best balance between competing expectations. The CEO doesn't have to pre-answer every question. Her team can work it out. Her team can figure out the best way for Product Family B to improve its price, while Finance closes the books faster, and IT drives down the cost of supporting the business.

To quote one of my favourite executives, 'I can work out the answer to my question. But then I'd be doing your job. I wouldn't be doing mine. If I have to do your job, I won't need you standing around watching me work.'

Our organizations are designed to unleash the creativity and intellectual power of our people. Not having a set of drones working to command. We get unleashed creativity and intellectual power through friction and by making the delegated decision space large.

Finding the Path

Last winter, I went snowshoeing to a set of lakes I hadn't been to in 20 years. The world looks completely different covered in 10–15 feet of snow. Meadows and creeks vanish. Even trees. At one point, I was stumped. Hip-deep in Rocky Mountain powder, trying to reason out whether the best route was up the hill, across the hill, or around the hill.

Then I saw a clue—downhill to the left, animal tracks heading across the hill, but lower. A half hour later, I had made it to the day or two old cougar tracks. Cougar tracks going my way—towards the lakes. The cougar led me almost all the way to the first lake. It was an elegant path. The cougar dodged all the obstacles. It avoided all the deep powder snow I had been bashing through.

When we are finding the path through a maze of intersecting authorities, we should follow the basic clues. Like I was doing when I looked at the contours of the land.

Michael Porter's value chain gives us the main contours. The primary value chain is why we are in business and our value proposition. We can be a price leader. We can be a feature leader. We can sell a solid, integrated mainstream answer. Frankly, the configuration choices of the value chain explain the contours of our operating model and value positioning.

Bang! We now know what some big decisions are. Everybody—Primary and Supporting—has no freedom to change the contours of our business. On my snowshoe trip Mt Bogart, Mt Sparrowhawk, and Mt Allen showed the contours of my path to the lakes. I had to weave around Allen and Bogart.

Then we can look at more detail. All our Products are working with what they have—Product Family A, B & C are all using existing segments and products. A wants to sell more things. B is expected to sell more expensive things. While C is expected to lower the cost of its things.

IT, Finance, and HR are supporting business units. They exist for one reason—help the primary activities do their primary activities better. Full stop.

IT only exists because your organization has a reasonable expectation it will gain efficiency and quality through scale. Think about it, gaining efficiency through scale is why supporting functions are tolerated. Every primary activity could do Finance and HR—just look at a conglomerate. Most of the time is less efficient and a distraction from delighting customers.

Supporting business functions have delegated authority in their function. Not unconditional authority. Very constrained authority. Supporting business units must enable the primary function do its purpose better with support than without.

Let's dwell here for a minute. Every primary function can do the work of a supporting function. Yet, every minute they spend doing so is a distraction from their primary mission.

Worse, every minute they spend working around a supporting unit is double waste. The primary function is distracted, the primary function is wasting effort compensating, and the supporting function exists.

Right here, the key limitation in decision authority for a supporting function. They must support the primary function. They must deliver efficiency of scale and enable a better primary function than the primary function can do alone.

This is the critical point. The moment supporting functions cease accelerating the primary function, a supporting business units loses its reason for corporate existence.

In governance terms, that is the primary constraint on their decision space—is this choice making someone else better. In governance terms, this is why primary functions push back when their function is interfered with.

Operationally, this is why supporting functions are so cost-sensitive. Support is pure overhead. They are a burden. They must justify themselves every day by being more effective and efficient than the primary function can be going it alone.

All of a sudden, we have some very fine-grained contours in our complex decision matrix.

Finance can reach into a product's revenue recognition activity and take company-wide decisions because they are providing company-wide efficiency gain. The decision criteria is not to provide Finance an efficiency gain. The criteria is to make the company more efficient in an activity no customer cares about.

Think about it, is a Bosch washing machine more attractive because Bosch pays its taxes? Nope. A Bosch washing machine is more attractive through a consumer's complex value calculation—brand, quality, features, price. Paying taxes is an overhead burden. Finance exists because they do all Finance things cheaper and easier.

Remember, every conglomerate, like Berkshire Hathaway, demonstrates the limits of scale. Berkshire doesn't have one hyper-scaled Finance department, they have gazillions.

When a supporting unit delivers the benefit of scale, it gains the authority. They are allowed to intrude into decisions a different part of the company would make if they were a clean business. IT, as experts in data management, can make rules that Finance and HR must follow if, and only if, they deliver two things—better Finance and more efficient data management.

Concluding Following Authority Tracks

We took a long and winding journey to discover the roots of delegated authority.

Our organizations are designed around delegated authority. SABSA's governance domains give us a great conceptual model. The domain has delegated authority and is measured by a unique set of directions—purpose, performance expectation, constraints, and risk appetite.

Carver's decision space helps us understand the complex web of constraints. Constraints that come from above and constraints that come from the side. Constraints that come from the side are always limited. Authority to intrude into a peer decision domain is always constrained.

A core constraint is Porter's value chain. The classic Porter diagram has supporting functions on-top. When I look, I'm reminded that every supporting function is a burden that the primary activities carry. It reminds me of the critical constraint on their decision domain—justifying their burden by making the primary functions better.

Primary functions are tested by margin. Primary functions that drive up the cost of doing business are not improving the company. Instead, they are pulling it down. When shared services make the whole company more efficient, deliberately choosing duplication carries an efficiency and effectiveness burden of proof.

We know our organizations are designed to expose this friction. We test primary activities focusing on value. We test common activities for efficiency and effectiveness of consolidation. We test supporting functions on efficiency—the efficiency of the whole organization. No simple fake-saving by burden shifting.

Enterprise architecture is all about authorized architecture decisions. As enterprise architects we need to navigate the complex web of authority. As advisors we need to help localized decision makers make better choices.

When we do we help the leadership team work out the conflicts. After the decision to act, the task is for the team to figure out the best way for Product Family B to improve its price, while Finance closes the books faster and IT drives down cost. While we are at it, Product Family A will have a path to grow market share and revenue, besides Product Family C's cost savings.

Heck, then we get to tackle the initiative web—the new market initiative, the cost saving initiative, the simplification initiative, the local improvement initiative, and a bunch of everyday sustainment and maintenance work.

In all of my work I am testing the decision space. Decision space tells me who the authoritative stakeholders are, what they have been asked to deliver, their constraints, and where they have freedom.

The contour of our organization—primary or supporting, operating model, and value chain configuration— helps us see the probable decision authority and decisions already taken.

We use  SABSA's governance domains and Carver's negative space as concepts. I'll often sketch governance models on my whiteboard. For this exercise, a formal model is rarely useful.

Usually, I'm good with a summary:

• Product Family A must grow market share
• Product Family B must improve price
• Product Family C must lower the cost of goods
• Finance must cut closing time by 50%
• IT must lower costs as a share of revenue

It lets me fit the initiative web—new market, cost saving, simplification, local improvement and everyday sustainment—into the decision authority.

I fit everything together because the core of delegated authority are cascading directions—performance expectations, constraints, and risk appetite.

IT must lower costs as a share of revenue. It follows that a change:

• delivering a cost reduction that meets performance expectations
• focused on a different positive goal, like expanding a capability, is constrained by IT not increasing costs more that revenue grew

Here is my challenge this week. Look at any initiative you are thinking about. Where do your stakeholders have free and unfettered decision authority? What have they been asked to do? What are their explicit and implicit constraints? Do you know the contours of the decision landscape?

Do you know where decisions are already made? Where a different decision-maker has authority? What are the delegated performance expectations, constraints, and risk appetite?

Next week we'll move to implementation governance. We'll talk about ensuring our architecture follows the best practice of enabling creativity by maximizing the decision space of the implementer. Then we'll look at testing implementation decisions against the target architecture. Not some domain subset, an enterprise architecture target is the cross-domain set of previous decisions and current direction—performance expectations, constraints, and risk appetite.

Have a great week!

As always, I welcome your feedback and questions.

Regards,

Dave

Dave Hornford  Conexiam