Tag Archives: digital organization

How to Drive Digital Transformation when You’re Not a Digital Expert : Addressing the Reverse Hierarchy of Understanding

In my last post I described some of the biggest challenges to a traditional enterprise trying to drive digital transformation. This isn’t just the usual “this stuff is hard” blather – there are real hurdles for the traditional large enterprise trying to do digital well. The pace of change and frictionless competition drive organizations used to winning through “weight of metal” not agility, crazy. The need for customer-centricity penalizes organizations setup in careful siloes. And these very real hurdles are exacerbated by the way digital often creates poor decision-making in otherwise skilled organizations because of what I termed the reverse hierarchy of understanding.

The reverse hierarchy of understanding is a pretty simple concept. Organizations work best when the most senior folks know the most about the business. When, in other words, knowledge and seniority track. For the most part (and despite a penchant for folks lower down in the organization to always think otherwise), I think they do track rather well in most companies. That, at least, has been my fairly consistent experience.

There are, of course, many pockets of specialized knowledge in a large company where knowledge and seniority don’t track. The CFO may not be able to drive TM1. The CTO probably doesn’t know Swift. That’s not a problem. However, when something is both strategic and core to the business, it’s critical that knowledge and seniority track appropriately. If they don’t, then it’s hard for the enterprise to make good decisions. The people who are usually empowered to make decisions aren’t as qualified as they typically are, and the folks who have the specific knowledge probably don’t have either the strategic skills or business understanding to fill-in. And, of course, they probably don’t have the power either.

Digital can create exactly this inversion in the appropriate hierarchy of decision-making in the traditional enterprise, and it does so at many levels in the organization. Digital has become strategic and core far more rapidly than most large organizations can adapt, creating reverse hierarchies of understanding that can cripple efforts to do digital better.

So if you want to transform a traditional business and you know your organization has a reverse hierarchy of understanding (or maybe just a complete lack of understanding at every level), what do you do?

There’s not one answer of course. No magic key to unlocking the secret to digital transformation. And I’ve written plenty of stuff previously on ways to do digital better – all of which still applies. But here are some strategies that I think might help – strategies geared toward tackling the specific problem created by reverse hierarchies of understanding.

 

Incubation

I’m sensitive to the many draw-backs to incubating digital inside a larger organization. If incubation succeeds, then it creates long-term integration challenges. It potentially retards the growth of digital expertise in the main business and it may even cannibalize what digital knowledge there is in the organization. These are all real negatives. Despite that, I’ve seen incubation work fairly effectively as a strategy. Incubation creates a protected pocket in the organization that can be staffed and setup in a way that creates the desired knowledge hierarchy through most levels.  Would I always recommend incubation? Absolutely not. In many organizations, years of at least partial learning and transfusions of outside talent have created enough digital savvy so that incubation is unnecessary and probably undesirable. If digital knowledge in your organization is still nascent and particularly if you have layers of management still skeptical or negative to digital, then incubation is a strategy to consider.

 

Transfusion

And speaking of talent transfusions, the role of appropriate hiring in effectively transforming the organization can hardly be overstated. The best, simplest and most impactful way to address the reverse hierarchy of understanding is to…fix the problem. And the easiest way to fix the problem is by hiring folks with deep digital understanding at multiple levels of the organization. In some cases, of course, this means hiring someone to run digital. If you’re a traditional enterprise looking to hire a chief digital officer, the natural place to look is to organization’s that are great in digital – especially the companies that dominate the Web and that we all, rightly, admire. I tell my clients that’s a mistake. It’s not that those folks aren’t really good at digital; they are. What they aren’t good at is digital transformation. If you’ve grown up managing digital platforms and marketing for a digital pure-play, chances are you’re going to be massively frustrated trying to change a traditional enterprise. To drive transformation, you have to be a great coach. That isn’t at all the same as being a great player. In fact, not only isn’t it the same, it’s negatively correlated. The best coaches are almost NEVER the best players.

Getting the right person to lead digital isn’t the place where most organizations go wrong though. If you’re committed to digital transformation, you need to look for digital savvy in every hiring decision that is at all related to your digital enterprise. You need digital savvy in HR, in accounting, analytics, in customer, in supply chain, in branding and corporate communication. Etc. Etc. This is the long game, but it’s ultimately the most important game you’ll play in digital transformation – especially when you’re trying to drive transformation outside of massive disruption. In my last post, I mentioned FDR’s many efforts to prepare the U.S. for WWII before there was any political consensus for war. Every leader is constrained by the realities on the ground. Great leaders find ways to at least lay the essential groundwork for transformation BEFORE – not after – disaster strikes. You need to make sure that digital savvy becomes a basic qualifier for a wide range of positions in your organization.

 

Analytics

Dare I say that analytics has the potential to play a decisive role in solving the reverse hierarchy of understanding? Well, at the very least, it can be a powerful tool. In a normal hierarchy of understanding, seniority comes pre-loaded with better intuitions. Intuitions born of both experience and selection. And those intuitions, naturally, drive to better decisions. It’s darn hard to replace those intuitions, but analytics is a great leveler. A good analyst may not be quite the decision-maker that an experienced expert is – but at the very least a good analyst equipped with relevant data will come much closer to that level of competent decisioning than would otherwise be possible.

Thankfully, this works both ways. Where senior decision-makers can’t rely on their experience and knowledge, they, too, benefit from analytics to close the gap. An executive willing to look at analytics and learn may not be quite in the league of an experienced digital expert, but they can come surprisingly close.

This works all up and down the organization.

So how do you get your team using analytics? I addressed this in depth in a series of posts on building analytic culture. Read this and this. It’s good stuff. But here’s a simple management technique that can help drive your whole team to start using analytics. Every time there’s an argument over something, instead of voicing an opinion, ask for the numbers. If your team is debating whether to deliver Feature X or Feature Y in digital, ask questions like “What do our customers say is more important?” or “Which do high-value customers say they’ll use more?”

Ask questions about what gets used more. About whether people like an experience. About whether people who do something are actually more likely to convert. If you keep asking questions, eventually people are going to start getting used to thinking this way and will start asking (and answering) the questions themselves.

Way back in the early days of Semphonic, I often had junior programmers ask me how to do some coding task. At the time, I was still a pretty solid programmer with years of experience writing commercial software in C++. But since I wasn’t actively programming and my memory tends to be a bit short-term, I almost never just knew the answer. Instead, I’d ask Google. Almost always, I could find some code that solved the problem with only a few minutes’ search. Usually, we’d do this together staring at my screen. Eventually, they got the message and bypassed me by looking for code directly on Google.

That’s a win.

Nowadays, programmers do this automatically. But back in the aughts, I had to teach programmers that the easiest way to solve most coding problems is to find examples on Google. In ten years, looking at digital analytics and voice of customer will be second-nature throughout your organization.  But for right now, if you can make your team do the analytics work to answer the types of questions I’ve outlined above, you’ll have dramatically raised the level of digital sophistication in your organization. This isn’t as foreign to most good enterprise leaders as I used to think. Sure, folks at the top of most companies are used to offering their opinions. But they’re also pretty experienced at having to make decisions in areas where they aren’t that expert and they know that asking questions is a powerful tool for pushing people to demonstrate (or arrive at) understanding. The key is knowing the right questions to ask. In digital, that usually means asking customer-focused questions like the one’s I enumerated above.

 

Consulting

I’m probably too deeply involved in the sausage-making to give good advice on how organizations should use consulting to drive transformation. But here’s a few pointers that I think are worth bearing in mind. Consulting is a tempting way to solve a reverse hierarchy of understanding. You can bring in hired guns to build a digital strategy or drive specific digital initiatives. And if you’re lucky or choose wisely, there’s no reason why consultants can’t provide real benefits – helping speed up digital initiatives and supplement your organizational expertise. I genuinely believe we do this on a pretty consistent basis. Nevertheless, consultants don’t fix the problems created by a reverse hierarchy of understanding; they are, at best, a band aid. Not only is it too expensive to pay consultants to make your decisions on a continuing basis, it just doesn’t work very well. There are so many reasons why it doesn’t work well that I can attempt only a very partial enumeration: outside of a specific project, your consultant’s KPIs are almost never well aligned with your KPIs (we’re measured by how much stuff we sell), it’s difficult to integrate consultants into a chain of command and often damaging if you try too hard to do so, consultants can become a crutch for weaker managers, and consultants rarely understand your business well enough to make detailed tactical decisions.

Don’t get me wrong. Building talent internally takes time and there aren’t many traditional enterprises where I wouldn’t honestly recommend the thoughtful use of consulting services to help drive digital transformation. Just don’t lose sight of the fact that most of the work is always going to be yours.

 

That last sentence probably rings true across every kind of problem! And while digital transformation is legitimately hard and some of the challenges digital presents ARE different, it’s good to keep in mind that in many respects it is just another problem.

I’ve never believed in one “right” organization, and when it comes to digital transformation there are strong arguments both for and against incubation. I think a decision around incubation ultimately comes down to whether digital needs protection or just expertise. If the former, incubation is probably necessary. If the latter, it may not be. Similarly, we’re all used to the idea that if we need new expertise in an organization we probably have to hire it. But digital introduces two twists. First, the best candidate to lead a digital transformation isn’t necessarily the best digital candidate. Second, real digital transformation doesn’t just come from having a leader or a digital organization. You should bake digital qualifications into hiring at almost every level of your organization. It’s the long game, but it will make a huge difference. And when it comes to leveling the playing field when faced with a reverse hierarchy of knowledge, remember that analytics is your friend. Teaching the organization to use analytics doesn’t require you to be an analytics wizard. It mostly demands that you ask the right questions. Over and over. Finally, and this really is no different in digital transformation than anywhere else, consulting is kind of like a cold medicine – it fixes symptoms but it doesn’t cure the disease. That doesn’t mean I don’t want my bottle of Nyquil handy when I have a cold! It just means I know I won’t wake up all better. The mere fact of a reverse hierarchy of understanding can make over-reliance on consulting a temptation. When you’re used to knowing better than everyone, it’s kind of scary when you don’t. Make sure your digital strategy includes thought about the way to use and not abuse your consulting partners (and no, don’t expect that to come from even the best consultants).

Keep these four lessons in mind, and you’re at least half-way to a real strategy for transformation.

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.