I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

Tuesday, February 28, 2017

Our Once and Future Wisdom: Re-acquiring Lost Institutional Knowledge

Last month we looked at the loss of institutional memory and the reasons for it. This month, we look at our options for re-acquiring it.

The erosion of business knowledge is not a recent phenomenon. Management textbooks dating at least as far back as the 1980s included stories of employees performing tasks the reasons for which they didn't really understand. The classic reference case was usually some report people spent hours crafting every month that they distributed to dozens of managers and executives, none of whom read it because they didn't know what it was for. Those execs never put a stop to it because they assumed another exec knew why it was important. Then, during the much-anticipated system replacement, some business analyst tracked down the person who wrote the report specs so long ago; after he was done laughing, that person told the business analyst the crisis that triggered the need for that report ended many years ago, and he couldn't believe they were still wasting time producing that report.

This story always seemed apocryphal - of course that could happen, but people are smart enough that it wouldn't really happen - until I saw it first hand at an investment bank just 6 years ago.

Natural (retirement) and forced attrition (layoffs) have long robbed companies of their knowledge workers. The rise of automation has simply made their loss more acutely painful. Accounting for knowledge hits the income statement in the form of the salaries of experienced and tenured employees; unfortunately, the value of their knowledge has no representation on the balance sheet. Extracting greater cash flows through payroll reduction is value-destructive in ways that accountants cannot (or at any rate, do not) measure.

If we have a business that hasn't yet gone full zombie that we want to pull back from the brink, what can we do to re-build business knowledge? There aren't a lot of high cards we can draw, but playing them in the right combination offers us a strategy. None of these are discreet solutions, but are a collection of non-mutually-exclusive tools that we can use to bridge a knowledge gap.

Tool 1: Dolly the Sheep

Companies that are heavily rule-based - think insurance - eagerly moved their business rules into code. It was easy to move into code; it's just as easy to move it back into human-readable format. Hire some developers fluent in a legacy technology, make sure you have an objective way of auditing their extraction of the rule base, and identify a cadre of employees who can understand those rules well enough to more comprehensively catalog and contextualize them. It's cheap (people paid to document code will be less expensive than people paid to create code) and hygienic (preservation of business information is a good thing) and it makes our business rules accessible to a wide audience spanning business users, managers, business analysts, and quality assurance engineers.

Of course, this is data, not information. A working foundation of facts is better than none, but facts are of limited value without context. And, while it's easy to reverse-engineer facts like rules, it's not so easy to forensically construct the business contexts that encapsulate those rules. A clone of something extinct - our lost business knowledge - runs the risk of suffering severe defects. For example, ghost code - code that is not commented out but will conditionally never be executed - is likely to be confused for real code in a reverse-engineering exercise. The facts are fantastic to have, but facts are not knowledge.

Tool 2: Seek the Jedi Masters

Somebody (well, somebodies) figured out how to automate the business. There are people behind the systems to which we're bound today. Why not put them back on the payroll? If they're still alive (always a good start), local and accessible, and grateful to the company for the income that put food on their table and their children through college, welcome them home. Techniques like value stream mapping bring them back to a business-operations mindset, allowing the business "why" in their heads to be extracted in a structured and coherent manner.

Of course, this isn't as simple as it sounds. Former colleagues won't come cheap. A knowledge worker who was forced out years ago may not feel inclined to share the wealth of their knowledge. The business will have evolved since the time these knowledge workers left. Corporate policies may also interfere with a re-recruitment campaign: one company I worked with forbade engaging contractors for more than 24 months, while another forbade contracting former employees at all.

You could also hire people who work for a primary competitor: In his book The Competitive Advantage of Nations, Michael Porter pointed out how industries tend to form in clusters; so if you're in an industry that isn't post-consolidation there's a good chance you've got a direct competitor nearby, offering a source of business knowledge you can recruit from. Again, this isn't as easy as it sounds. It's hard enough determining whether the people in our own business really understand the business "why" behind the things that they do, or whether they just know the complex motions they go through. It's even harder to do that with people grounded in another company's domain: if our business knowledge is in short supply we won't have the business knowledge to ask the abstract questions to gauge their comprehension of the business; plus, we may speak fundamentally different languages to describe their implementation. If their knowledge is too finely grained - that is, too specific to the context of our competitor - their knowledge won't travel: they're a subject matter expert in our competitor's operations, not in the industry. Plus, if our loss of business fluency was the result of corporate blood-letting, it's highly likely that our competitor up the street has done much the same, and will be no richer in domain expertise than we are.

One final word of caution is that we have to challenge the "why" the experts give us. Ten years ago, I was leading an inception for a company replacing their fleet maintenance systems. Their existing system was a combination of a custom AS/400 based RPG system (that had started life on a System/34), a fat client Visual Basic application, and thin-client Java tools, all of which required manual (operator) steps for data integration with one another. The user got to a step in the workflow in the VB application, then transferred data updates to the AS/400 and resumed there, then transferred data updates to the Java application and resumed there, all over a period of days or even weeks and often going back and forth. Their experts genuinely knew their business, but had grown so accustomed to the data transfer steps that they ended up baked into the initial value stream maps we produced. It took a lot of challenging the "why" on those specific portions of the value stream before they understood how a simple shared database would eliminate lots of no-value-added inventory control steps.

Still, maintaining a connection with the people who were there at the creation helps us identify the things so important for us to know if we're going to evolve or pivot from it. In much the same way as air traffic controllers are taught how to land planes in the event the software fails on them at a critical moment, former knowledge workers can help re-build our knowledge from the ground up.

Tool 3: Buy Before you Try

If you're on your way to becoming a zombie company, why not eat someone else's brain? Re-constructing a lost capability is expensive, so buying a competent operating company - along with its digital assets - is a shortcut. This assumes that you as the buyer can make an informed decision about the competency of the people you're acqui-hiring. It also assumes that the people in the acquired stick around after the acquisition.

A reverse-acquisition can take one company's girth and bloat and wed it to another company's core nimbleness and agility. But M&A is ego-driven: the CEO or board member who wants to do a deal will see the deal through regardless the state of the acquirer or target. A few years ago, I worked with a holding company that had bought two competing firms that collected data about banks and sold it on a subscription basis. As their product was becoming digital, the value of the data they sold was plummeting (as most data tends to do when it becomes digital), so we helped them define a strategy to combine the companies and transform them from providers of data to providers of digital tools. Three days into the inception, we were frustrated that the workshops had ending up with incomplete and unsatisfactory levels of detail. We hypothesized the reason for that was because the experts weren't all that expert. On day 4 we ran a series of experiments in our workshops to test this hypothesis, and in the process confirmed that the activities they performed in the acquisition, curation, publication and distribution of the data they sold were performed for reasons of rote, not reason. The inception was successful in that it exposed am inability to execute on the strategy in the manner they had hoped to do, which led to an entirely different approach to execution.

Buying is a shortcut, and as Murphy's Law teaches us, a shortcut is the longest distance between two points.

More modestly, we can simply license technology to replace major portions of legacy systems, and train or hire experts in that technology. This, though, substitutes solution knowledge for business knowledge, and the prior isn't necessarily a proxy for the latter: even though commercial ERP systems have largely replaced home-grown ones, those commercial solutions are highly customized to the needs of the business.

Tool 4: Play Calvinball

We're barraged by business media to be internal drivers of digital "disruption" because it puts our competitors at a disadvantage, challenging their leadership by forcing them to chase after us. But disruption is also a means of rebuilding lost business knowledge: if we change the rules of the game, we're less restrained by our current assets and procedures. The more we can change, the more we set a new agenda in the competitive landscape. Ideally, we should be playing Calvinball, and make up the rules as we go along.

Disruption is a tool, not a solution. Disruption may be constrained by prevailing legislation and regulation, while regulators tend to look at established firms differently from upstarts - if they look at them at all. In the wake of the 2008 financial crisis, bank lending declined in response to higher capital requirements against risk-weighted assets and tighter lending standards; marketplace lenders skirted balance sheet restrictions and lending regulations simply by not being chartered banks. This allows marketplace lenders to underwrite loans with much more flexibility than a bank. The door to this type of disruption was closed to banks. As with Calvinball, it is the player with the ball who makes the rules, and banks (like many other regulated businesses) aren't the ones holding the ball.

Plus, when we build on existing business rules rather than replace them, we're not moving away from a dependency on fundamental knowledge that we don't have. Re-imagining how an existing offering is packaged, distributed or even consumed doesn't alleviate the need to understand the core characteristics of that offering.

Making the Best of a Bad Hand

Re-gaining lost business knowledge is a slow, sometimes difficult, and usually expensive proposition. Pushing too hard to re-acquire it is like beginning to learn calculus and non-Euclidean geometry the night before a comprehensive final exam: a grade of D- would be a small miracle. But, since strong business knowledge is key to executing any business strategy pursuing growth or evolution, a grade of D- isn't going to cut it.

Worry less about the slow rate of re-acquisition and think instead about where you want your business fluency to be in 6 months, 12 months, and beyond, and how much more effective your organization will be at those times. That guides the extent to which you employ each of the four techniques described in here and how they get you to a greater state of fluency so that you can operationalize the business strategy. For example, contracting legacy language developers to capture encoded logic and hiring in a couple of retired employees for value stream mapping sessions, all in exchange for donuts and a fat payday for a few months, may be an effective and inexpensive precursor to an acquisition, or provide suitable grounding to initiate disruptive change that re-writes the rules of an industry.

This requires us to prioritize organizational learning along side operating performance and delivery goals. The latter two are quantifiably measurable and glare at us from our financial statements; the prior is not and does not. A commitment to learning is an investment that needs board-level visibility and air cover: without the learning there is no execution, and without the execution the strategy is just an elaborate Powerpoint. Board-level patience isn't infinite, so in exchange for an investment in learning, line management will have to commit to strategic execution - even if it has to commit to execution before it has re-learned as much as it would like.

The alternatives are to be acquired (sooner rather than later, at peak value for the book of business the company still commands) or slow obsolescence (and concomitant market irrelevance). Since this gives the people in the company a fighting chance, trading a commitment to learn for a commitment to strategic execution is a fair exchange.