Tag Archives: analytics organization

Organizing the Digital Enterprise

At the Digital Analytics Hub in Europe I facilitated a conversation around enterprise digital transformation. We covered a lot of interesting ground, but organizing digital in the enterprise was the most challenging part of that discussion.

It’s a topic you can easily find yourself going around in circles with as people trot out opinions that sound right but sail past each other. That’s especially true since different organizations start (and want to finish) in very different places.

To get around that, I framed the problem in “state-of-nature” terms. If you were starting a digital organization from scratch in an enterprise, how would you organize and staff it?

But before we could answer that question, we had to consider something even more basic.

Should a “digital” organization be separate?

There’s a pretty strong sense these days that walling off digital from the rest of the organization gets things wrong from the outset. Digital should be embedded right into the DNA of the core organization. In a mature organization, there was a pretty broad consensus that digital isn’t a separate function. On the other hand, what if you’re not mature? Can you embed digital directly and grow it right if it’s inside the huge, complex structures that pervade an existing large enterprise? Even strong proponents of the “digital needs to be organic in the organization” point of view seemed to concede that incubation as a separate organization is often necessary to getting digital done and setup right. Of course, taking the incubation strategy is going to leave you with an organizational debt that at some point will have to be paid. The more successful you are and the larger and faster digital grows, the harder it’s going to be to re-integrate digital back into the organization.

I see both sides of this argument (and I’m sure there are more than two sides to be had). I’m just not a big believer in hard-and-fast right answers when it comes to organizational design.

If you have a strong digitally-experienced leader on your executive team and you have solid relationships between marketing and IT, maybe you try to transform digitally within your existing structures. If you’re not that lucky (and that is pretty lucky), maybe incubation with a strategy for integration is the right answer.

Having gotten to the point where most people conceded that incubation might sometimes be necessary, we returned to the “state-of-nature” question and discussed building out an incubated organization. Most people set product teams at the heart of that organization and agreed that these product teams should be organized very much along the lines that I described in my videos on enterprise transformation: agile-based product teams that include IT, creative and analytics people (behavioral, customer and attitudinal) all working together. In this model, there’s no pass-off from design to implementation to measurement to testing. The same teams that built a project optimize it – and there’s analytics at every step of the process.

I believe this is an incredibly powerful model for getting digital products right – and it’s a model that resonated across a pretty wide swath of different organizations – from giant retailers to very modest start-ups.

But it’s far from a complete answer to creating a digital organization.

Suppose you have these great integrated teams for each digital product, how do you handle all the ancillary functions that the large enterprise has developed? Things like finance and HR, for example. Do they need to be re-created inside a digital organization?

My reaction – and it was common – was that such functions probably don’t need to be re-created inside digital. Including these functions in digital doesn’t seem fundamental to getting digital right.

This point-of-view, however, was immediately challenged when it came to HR. The difficulties of digital hiring are well known – and it isn’t just finding resources. Traditional HR approaches to finding people, vetting candidates, compensation, and promotion bands are all problematic in digital. And if you get the people element wrong, everything else is doomed.

So once again, if you’ve got HR folks willing to work with and adapt to the needs of your digital leader, maybe you can leave existing structures intact and keep HR centralized. But HR is the wrong place to wimp out and leave your digital team without the power to execute the way they need to.

Bottom line? If my digital leader really wanted to own their own HR, I’d say yes.

Other functions? I don’t really know. Is it fundamental to digital execution? Does it need to be done differently in digital? Wherever the answer is yes, then it’s going to be a debate about whether it should live inside an incubated digital organization or be an outside service to it.

There’s another challenge that cuts even closer to the bone and lies at the heart of the challenge to the large enterprise. If you have a single digital product (like a pure-play startup might), you don’t have to worry about the relationship between and across teams and functions. But in a larger enterprise – even when it’s incubated – digital is going to require multiple product teams.

How do management lines work across those teams? Are the IT folks across product teams in the Digital IT organization and are they “managed” by Digital IT? Or are they managed by their Product Owner? In one sense, the answer seems obvious. On a day-to-day basis they are managed by their Product Owner. But who owns their career? What’s a career path like? How do Digital IT folks (or analysts) across product teams communicate? Who makes centralized decisions about key technology infrastructure? Who owns the customer?

Every one of these is a deep, important question with real ramifications for how the organization works and how you take a single product model and scale it into something that preserves the magic of the integrated team but adapts to the reality of the large, multi-function enterprise.

It was here, not surprisingly, that one of the participants in our DA Hub conversation trotted out the “dotted line”. Now it happened to be a consultant from a fellow big-4 and I (too glibly, I’m afraid) responded that “dotted lines are what consultants draw when they don’t have a good answer to a problem”.

I both regret and endorse this answer. I regret it because it was far too glib a response to what is, in one sense, probably the right answer. I endorse it because I think it’s true. God knows I’ve drawn these dotted lines before. When we draw a dotted line we essentially leave it up to the organization to organically figure out how it should work in day-to-day practice. That’s not necessarily a bad thing. It’s probably the right answer in a lot of cases. But we shouldn’t kid ourselves that just because it might be the right answer that makes it a good answer. It’s not. It’s a “we’re not the right people at the right time to answer this question” kind of answer. Knowing enough to know you’re not the right people at the right time is a good thing, but it would be a mistake to confuse that with actually having a good answer to the question.

So here’s my best attempt at a non-dotted line organization that integrates Product Teams into a broader structure. It seems clear to me that you need some centralized capabilities within each function. For Digital IT, as an example, these centralized teams provide shared services including enterprise technology selection, key standards and data governance. In analytics, the centralized team will be responsible for the overall customer journey mapping, analytics technology selection and standardization, a centralized analytics warehouse, and standards around implementation and reporting.

How big and inclusive does the centralized team need to be? Thinking there’s one right answer to this question is a kind of disease akin to thinking there’s some right answer to questions like “how large should government be?” There isn’t. I tend to be in the “as small as practical” school when it comes to centralization – both politically and in the enterprise. The best IT, the best creative, the best analytics is done when it’s closest to the business – that means out there in those Product teams. That also means making sure you don’t incent your best people out of the product teams into centralized roles so that they can “advance” and make more money.

It used to drive me crazy to see good teachers promoted to administrative roles in schools. You can’t blame the teachers. When you’ve got a family to feed, a house to buy, a nice to car to own, you’re not going to stay a teacher when your only path to more money and prestige is becoming an assistant principal. But you don’t see the Cleveland Cavaliers promoting Lebron from player to coach. It’s a terrible mistake to confuse rank with value.

I’m a big believer in WIDE salary bands. One great developer is worth an army of offshore programmers and is likely worth more than the person managing them. Don’t force your best people to Peter Principle themselves into jobs they hate or suck at.

So instead of creating progressions from Product teams to central teams, I’d favor aggressive rotational policies. By rotating people into and out of those central teams, you ensure that central teams stay attuned to the needs of the Product teams where work is actually getting done. You also remove the career-path issues that often drive top talent to gravitate toward centralization.

Communications and collaboration is another tricky problem. Collaboration is one of the most under-invested capabilities in the organization and my Product team structure is going to make it harder to do well. For areas like analytics, though, it’s critical. Analysts need to communicate practices and learnings across – not just within – product teams. So I’d favor having at least one role (and maybe more) per area in the central team whose sole function is driving cross-team communication and sharing. This is one of those band-aids you slap on an organizational structure because it doesn’t do something important well. Every organizational structure will have at least a few of these.

In an ideal world, that collaboration function would probably always have at least two resource slots – and one of those slots would be rotated across different teams.

My final structure features highly integrated product teams that blend resources across every function needed to deliver a great digital experience. Those teams don’t dissolve and they don’t pass off products. They own not just the creation of a product, but its ongoing improvement. Almost needless to say, analytics (customer, behavioral and attitudinal) is embedded in that team right from the get-go and drives continuous improvement.

Those teams are supported by centralized groups organized by function (IT, Design, Analytics) that handle key support, integration and standardization tasks. These centralized teams are kept as small as is practical. Rotational policies are enforced so that people experience both centralized and product roles. Salary bands are kept very wide and the organization tries hard not to incent people out of roles at which they excel. Included in the centralized teams are roles designed to foster collaboration and communication between functional areas embedded in the product teams.

Finally, support functions like HR and Finance are mostly kept external. However, where compelling reasons exist to incubate them with digital, they are embedded in the central structure.

I won’t pretend this is the one right answer to digital organizational structure. Not only does it leave countless questions unanswered, but I’m sure it has many problems that make it fatally flawed in at least some organizations.

There are no final answers when it comes to organizational design. Every decision is a trade-off and every decision needs to be placed in the context of your organization history, culture and your specific people. That’s why you can’t get the right answer out of a book or a blog.

But if you’re building an incubated digital organization, I think there’s more right than wrong here. I’ve tried to keep the cop-outs and dotted lines to a minimum and focused on designing a structure that really will enable digital excellence. I don’t say deliver it, because that’s always up to the people. But if your Product Managers can’t deliver good digital experiences with this organization, at least you know it’s their fault.

Productivity is Our Business. And Business isn’t Good

A little while back there was a fascinating article on the lack of productivity growth in the U.S. in the past 4-5 years. I’ll try to summarize the key points below (and then tell you why I think they’re important) – but the full article is very much worth the read.

Productivity Growth

Let’s start with the facts. In the last year, the total number of hours worked in the U.S. rose by 1.9%. GDP growth in the last quarter exactly matched that rate – 1.9%. So we added hours and we got an exact match in output. That might sound okay, but it means that there was zero productivity growth. We didn’t get one whit more efficient in producing stuff. Nor is this just a short term blip. In the last four years, we’ve recorded .4% annual growth in productivity. That’s not very good. Take a look at the chart above (from the New York Times article and originally from the Labor Department) – it looks bad. We’re in late ‘70s and early ‘80s territory. Those weren’t good years.

The Times article advances three theories about why productivity growth has been so tepid. They classify them as the “Depressing” theory, the “Neutral” theory and the “Happy” theory. Here’s a quick description of each.

Depressing Theory

The trend is real and will be sustained. Capex is down. The digital revolution is largely complete. People aren’t getting significantly more productive and the people returning to the work-force post-recession are the least productive segment of our workforce. On this view, we’re not getting richer anytime soon.

Neutral Theory

There’s a lot of imprecision in measuring productivity. With fundamental changes in the economy it may be that the imprecision is increasing – and we’re undercounting true productivity. As measurement professionals, we all know this one needs to be reckoned with.

Happy Theory

We’re in an “investment” period where companies are hiring and investing – resulting in a period of lower-productivity before that investment begins to show returns and productivity accelerates. Interestingly, this story played out in the late ‘90s when productivity slowed and then accelerated sharply in the 2000s.


Which theory is right? The Times article doesn’t really draw any firm conclusions – and that’s probably reasonable. When it comes to macro-economic trends, the answers are rarely simple and obvious. From my perspective, though, this lack of productivity is troubling. We live in a profession (analytics) that’s supposed to be the next great driver or productivity. Computers, internet, now analytics. We’re on the hook for the next great advance in productivity. From a macro-economic perspective, no one’s thinking about analytics. But out here in the field, analytics is THE thing companies are investing in to drive productivity.

And the bad news? We’re clearly not delivering.

Now I don’t take it as all bad news. There’s a pretty good chance that the Happy theory is dead-on. Analytics is a difficult transformation and one that many companies struggle with. And while they’re struggling with big data systems and advanced analytics, you have a lot of money getting poured into rather unproductive holes. Word processing was almost certainly more immediately productive than analytics (anybody out there remember Wang?) – but every sea change in how we do things is going to take time, effort and money. Analytics takes more than most.

Here’s the flip side, though. It’s easy to see how all that investment in analytics might turn out to be as unproductive as building nuclear missiles and parking them into the ground. If they were ever used, those missiles would produce a pretty big bang for the buck. In the case of ICBM’s, we’re all happiest when they don’t get used. That’s not what we hope for from analytics.

Of course, I’ve been doing this extended series on the challenges of digital transformation – most of which revolves around why we aren’t more productive with analytics. Those challenges are not, in my opinion, the exception. They’re the rule. The vast majority of enterprises aren’t doing analytics well and aren’t boosting their productivity with it. That doesn’t mean I don’t believe in the power of analytics to drive real productivity. I do. But before those productivity gains start to appear, we have to do better.

Doing better isn’t about one single thing. Heaven knows it’s not just about having the newest technologies. We have those aplenty. It’s about finding highly repeatable methods in analytics so that we can drive improvement without rock-stars. It’s very much about re-thinking the way the organization is setup so that analytics is embedded and operationalized. It’s even more about finding ways to re-tool our thinking so that agile concepts and controlled experimentation are everywhere.

Most companies still need a blueprint for how to turn analytics into increased productivity. That’s what this series on digital transformation is all about.

If you haven’t yet had the opportunity to spin through my 20min presentation on transforming the organization with analytics – check it out.

After all, productivity is our business.

The Agile Organization

I’ve been meandering through an extended series on digital transformation: why it’s hard, where things go wrong, and what you need to be able to do to be successful. In this post, I intend to summarize some of that thinking and describe how the large enterprise should organize itself to be good at digital.

Throughout this series, I’ve emphasized the importance of being able to make good decisions in the digital realm. That is, of course, the function of analytics and its my own special concerns when it comes to digital. But there are people who will point out  that decision-making is not the be all and end all of digital excellence. They might suggest that being able to execute is important too.

If you’re a football fan, it’s easy to see the dramatic difference between Peyton Manning – possibly the finest on-field decision-maker in the history of the game – with a good arm and without. It’s one thing to know where to throw the ball on any given play, quite another to be able to get it there accurately. If that wasn’t the case, it’s probably true that many of my readers would be making millions in the NFL!

On the other hand, this divide between decision-making and execution tends to break down if you extend your view to the entire organization. If the GM is doing the job properly, then the decision about which quarterbacks to draft or sign will appropriately balance their physical and decision-making skills. That’s part of what’s involved in good GM decisioning. Meanwhile, the coach has an identical responsibility on a day-to-day basis. A foot injury may limit Peyton to the point where his backup becomes a better option. Then it may heal and the pendulum swings back. The organization makes a series of decisions and if it can make all of those decisions well, then it’s hard to see how execution doesn’t follow along.

If, as an organization, I can make good decisions about the strategy for digital, the technology to run it on, the agencies to build it, the people to optimize it, the way to organize it, and the tactics to drive it, then everything is likely to be pretty good.

Unfortunately, it’s simply not the case that the analytics, organization and capabilities necessary to make good decisions across all these areas are remotely similar. To return to my football analogy, it’s clear that very few organizations are setup to make good decisions in every aspect of their operations. Some organizations excel at particular functions (like game-planning) but are very poor at drafting. Indeed, sometimes success in one-area breeds disaster in another. When a coach like Chip Kelly becomes very successful in his role, there is a tendency for the organization to expand that role so that the coach has increasing control over personnel. This almost always works badly in practice. Even knowing it will work badly doesn’t prevent the problem. Since the coach is so important, it may be that an organization will cede much control over personnel to a successful coach even when everyone (except the coach) believes it’s a bad idea.

If you don’t think similar situations arise constantly in corporate America, you aren’t paying attention.

In my posts in this series, I’ve mapped out the capabilities necessary to give decision-makers the information and capabilities they need to make good decisions about digital experiences. I haven’t touched on (and don’t really intend to touch on) broader themes like deciding who the right people to hire are or what kind of measurement, analysis or knowledge is necessary to make those sorts of meta-decisions.

There are two respects, however, in which I have tried to address at least some of these meta-concerns about execution. First, I’ve described why it is and how it comes to pass that most enterprises don’t use analytics to support strategic decision-making. This seems like a clear miss and a place where thoughtful implementation of good measurement, particularly voice-of-customer measurement of the type I’ve described, should yield high returns.

Second, I took a stab at describing how organizations can think about and work toward building an analytics culture. In these two posts, I argue that most attempts at culture-building approach the problem backwards. The most common culture-building activities in the enterprise are all about “talk”. We talk about diversity. We talk about ethics. We talk about being data-driven in our decision-making. I don’t think this talk adds up to much. I suggest that culture is formed far more through habit than talk; that if an organization wants to build an analytics culture, it needs to find ways to “do” analytics. The word may proceed the deed, but it is only through the force of the deed (good habits) that the word becomes character/culture. This may seem somewhat obvious – no, it is obvious – but people somehow manage to miss the obvious far too often. Those posts don’t just formulate the obvious, they also suggest a set of activities that are particularly efficacious in creating good enterprise habits of decision-making. If you care about enterprise culture and you haven’t already done so, give them a read.

For some folks, however, all these analytics actions miss the key questions. They don’t want to know what the organization should do. They want to know how the organization should work. Who owns digital? Who owns analytics? What lives in a central organization? What lives in a business unit? Is digital a capability or a department?

In the context of the small company, most of these questions aren’t terribly important. In the large enterprise, they mean a lot. But acknowledging that they mean a lot isn’t to suggest that I can answer them – or at least most of them.

I’m skeptical that there is an answer for most of these questions. At least in the abstract, I doubt there is one right organization for digital or one right degree of centralization. I’ve had many conversations with wise folks who recognize that their organizations seem to be in constant motion – swinging like an enormous pendulum between extremes of centralization followed by extremes of decentralization.

Even this peripatetic motion – which can look so irrational from the inside – may make sense. If we assume that centralization and decentralization have distinct advantages, then not only might it be true that changing circumstances might drive a change in the optimal configuration, but it might even be true that swinging the organization from one pole to the other might help capture the benefits of each.

That seems unlikely, but you never know. There is sometimes more logic in the seemingly irrational movements of the crowd than we might first imagine.

Most questions about digital organization are deeply historical. They depend on what type of company you are, in what of market, with what culture and what strategic imperatives. All of which is, of course, Management 101. Obvious stuff that hardly needs to be stated.

However, there are some aspects of digital about which I am willing to be more directive. First, that some balance between centralization and decentralization is essential in analytics. The imperative for centralization is driven by these factors: the need for comparative metrics of success around digital, the need for consistent data collection, the imperatives of the latest generation of highly-complex IT systems, and the need/desire to address customers across the full spectrum of their engagement with the enterprise. Of these, the first and the last are primary. If you don’t need those two, then you may not care about consistent data collection or centralized data systems (this last is debatable).

On the other hand, there are powerful reasons for decentralization of which the biggest is simply that analytics is best done as close to the decision-making as possible. Before the advent of Hadoop, I would have suggested that the vast majority of analytics resources in the digital space be decentralized. Hadoop makes that much harder. The skills are much rarer, the demands for control and governance much higher, and the need for cross-domain expertise much greater in this new world.

That will change. As the open-source analytics stack matures and the market over-rewards skilled practitioners – drawing in more folks, it will become much easier to decentralize again. This isn’t the first time we’ve been down the IT path that goes from centralization to gradual diffusion as technologies become cheaper, easier, and better supported.

At an even more fundamental level than the question of centralization lives the location and nature of digital. Is digital treated as a thing? Is it part of Marketing? Or Operations? Or does each thing have a digital component?

I know I should have more of an opinion about this, but I’m afraid that the right answers seem to me, once again, to be local and historical. In a digital pure-play, to even speak of digital as a thing seems absurd. It’s the core of the company. In a gas company, on the other hand, digital might best be viewed as a customer service channel. In a manufacturer, digital might be a sub-function of brand marketing or, depending on the nature of the digital investment and its importance to the company, a unit unto-itself.

Obviously, one of the huge disadvantages to thinking of digital as a unit unto-itself is how it can then interact correctly with the non-digital functions that share the same purpose. If you have digital customer servicing and non-digital customer servicing, does it really make sense to have one in a digital department and the other as a customer-service department?

There is a case, however, for incubating digital capabilities within a small compact, standalone entity that can protect and nourish the digital investment with a distinct culture and resourcing model. I get that. Ultimately, though, it seems to me that unless digital OWNS an entire function, separating that function across digital and non-digital lines is arbitrary and likely to be ineffective in an omni-channel world.

But here’s the flip side. If you have a single digital property and it shares marketing and customer support functions, how do you allocate real-estate and who gets to determine key things like site structure? I’ve seen organizations where everything but the homepage is owned by somebody and the home page is like Oliver Twist. “Home page for sale, does anybody want one?”

That’s not optimal.

So the more overlap there needs to be between the functions and your digital properties, the more incentive you have to build a purely digital organization.

No matter what structure you pick, there are some trade-offs you’re going to have to live with. That’s part of why there is no magic answer to the right organization.

But far more important than the precise balance you strike around centralization or even where you put digital is the way you organize the core capabilities that belong to digital. Here, the vast majority of enterprises organize along the same general lines. Digital comprises some rough set of capabilities including:

  • IT
  • Creative
  • Marketing
  • Customer
  • UX
  • Analytics
  • Testing
  • VoC

In almost every company I work with, each of these capabilities is instantiated as a separate team. In most organizations, the IT folks are in a completely different reporting structure all the way up. There is no unification till you hit the C-Suite. Often, Marketing and Creative are unified. In some organizations, all of the research functions are unified (VoC, analytics) – sometimes under Customer, sometimes not. UX and Testing can wind up almost anywhere. They typically live under the Marketing department, but they can also live under a Research or Customer function.

None of this, to me, makes any sense.

To do digital well requires a deep integration of these capabilities. What’s more, it requires that these teams work together on a consistent basis. That’s not the way it’s mostly done.

Almost every enterprise I see not only siloes these capabilities, but puts in place budgetary processes that fund each digital asset as a one-time investment and which requires pass-offs between teams.

That’s probably not entirely clear so let me give some concrete examples.

You want to launch a new website. You hire an agency to design the Website. Then your internal IT team builds it. Now the agency goes away. The folks who designed the website no longer have anything to do with it. What’s more, the folks who built it get rotated onto the next project. Sometimes, that’s all that happens. The website just sits there – unimproved. Sometimes the measurement team will now pick it up. Keep in mind that the measurement team almost never had anything to do with the design of the site in the first place. They are just there to report on it. Still, they measure it and if they find some problem, who do they give it to?

Well, maybe they pass it on to the UX team or the testing team. Those teams, neither of which have ever worked with the website or had anything to do with its design are now responsible for implementing changes on it. And, of course, they will be working with developers who had nothing to do with building it.

Meanwhile, on an entirely separate track, the customer team may be designing a broader experience that involves that website. They enlist the VoC team to survey the site’s users and find out what they don’t like about it. Neither team (of course) had anything to do with designing or building the site.

If they come to some conclusion about what they want the site to do, they work with another(!) team of developers to implement their changes. That these changes may be at cross-purposes to the UX team’s changes or the original design intent is neither here nor there.

Does any of this make sense?

If you take continuous improvement to heart (and you should because it is the key to digital excellence), you need to realize that almost everything about the way your digital organization functions is wrong. You budget wrong and you organize wrong.

[Check out my relatively short (20 min) video on digital transformation and analytics organization – it’s the perfect medium for distributing this message through your enterprise!]

Here’s my simple rule about building digital assets. If it’s worth doing, it’s worth improving. Nothing you build will ever be right the first time. Accept that. Embrace it. That means you budget digital teams to build AND improve something. Those teams don’t go away. They don’t rotate. And they include ALL of the capabilities you need to successfully deliver digital experiences. Your developers don’t rotate off, your designers don’t go away, your VoC folks aren’t living in a parallel universe.

When you do things this way, you embody a commitment to continuous improvement deeply into your core organizational processes. It almost forces you to do it right. All those folks in IT and creative will demand analytics and tests to run or they won’t have anything to do.

That’s a good thing.

This type of vertical integration of digital capabilities is far, far more important than the balance around centralization or even the home for digital. Yet it gets far less attention in most enterprise strategic discussions.

The existence or lack of this vertical integration is the single most important factor in driving analytics into digital. Do it right, and you’ll do it well. Do what everyone else does and…well…it won’t be so good.