12 Secrets of Digital Transformation: Part 11

Secret #11: There is more time than you think to finish — but less time than you think to start

By definition, a crisis is a problem you can't solve with the time or resources you have. Or so you believe. Regarding your company’s technical situation, you may feel you are out of time; there is no hope. But there’s a saying about crisis that I like to keep in mind: “Don’t confuse the end of an illusion with the beginning of a crisis.”

Many times, when we begin a transformation project, we do so in response to a perceived crisis:

• A competitor may announce a transformational or disruptive product
• A 3^rd party company or technology may impinge or seem likely to impinge on your industry;
• A startup develops something customers have previously been asking you for, and begins taking your market share away
• Customer behavior has begun to shift radically and you can’t keep up with the changes.

These are indeed urgent and important situations, but in most cases the root of the problem was already there: it was unmasked by the external situation, not caused by it. In other words, you are witnessing the end of an illusion, not the beginning of a crisis.

My point in saying this, by the way, is not to persuade you that everything is OK, and certainly not to encourage you to stay where you are. If you’re in a transformation situation, you probably do have a real problem and you really do need to act. However, panic or a sense of impending doom is not going to help. The situation you are in was probably years or even decades in the making. If you are a sizable business, it will take you at best months to even begin to alleviate it, and probably one to two years or even longer to truly resolve. Some companies with deep technical debt can take three, four, five years or more to really “fix” their underlying issues, even though incremental releases may allow them to be partially mitigated faster.

I’ve been surprised several times in my career when I thought my company was way behind the competition, only to find that we were in fact first, or one of the first, to deliver. That’s because in many cases you are comparing your own internal reality to someone else’s hype. If your competitors are good at hype, but you are good or become good at delivering products, you can still win, even when it may look like you’re too late. Also, even if you are not first to market, it takes the public a while to accept a new product or business model. You’ll generally be seen as an early entrant even if you are second, third or even later, even if shipping takes months or quarters longer than you’d like.

If your company has strong market or domain presence, a loyal or otherwise “locked-in” customer base, or significant name recognition, you can beat earlier competitors who do not—and compete effectively with many others who do. I remember when I was at Rational and we were working on the Rose 1.0 software design tool—a new product category at that time. Several months before we were ready to ship, a number of tools with similar software architecture drawing capability started to come on the market. They didn’t have all of our capabilities by a long shot (no code generation, for example), but they did do architecture drawings. I talked to one of the product management team and he told me “Don’t worry about it. The best thing that could happen to us is to have a large number of weak competitors. They’ll just create market awareness for us, and we’ll win.” He was right—and we did.

A spectacular example is, of course, Apple. The world had pretty much written off Apple as a viable business by the late 1990’s, saying that it had lost its technology edge and was consigned to a long decline into total market irrelevance. This situation took a while to fix; in fact it took Steve Jobs and his team four years of hard work to turn Apple around technically (counting from the time Job’s re-joined as CEO in 1997 until the time the iPod and OS X shipped, both in 2001). In other words, even after the world had written Apple off as a viable company, they still had four years in which to mount a successful turnaround. And what a spectacular turnaround it was. Granted, even in decline Apple had a lot going for it in terms of brand and customer loyalty, and none of us are Steve Jobs. But the lesson we can take from this is that if our company also has non-technical assets such as consumer loyalty, domain expertise, brand recognition, revenue streams / tangible assets, or other types of assets, there is hope. We may in fact have time to implement our technical transformation, even if we are in a deep hole today.

While shipping later than you want to can sometimes be overcome, starting work too late often cannot. The dirty little truth about software development is that it generally takes longer to develop the product you want than you think it would. Even with great planning, great management, and great processes like Lean and Agile—practices which we follow and strongly endorse—there will always be some bottleneck that takes longer to resolve than you expect. This might be in an area totally unrelated to the software itself—project funding, requirements analysis, regulatory review, external or internal third-party dependencies, etc. Its predictable that something unexpected will happen, and that this will make things take longer than you think.

After fighting it for years, I’ve come to believe unexpected events are simply part of the nature of complex systems—that is, systems and programs with many “moving parts.” Your best strategy is to plan to adapt and respond, in addition to mitigation of known or reasonably foreseeable risks. You can and should work to remove every obstacle you can anticipate, and take advantage of all the efficiencies that modern software development has to offer. We are lucky to be in a time where many things that once were hard and time consuming—for example, setting up the physical hardware infrastructure—have now become much simpler (due to cloud and containerization technologies in this particular case). Many previously difficult and expensive vendor selection alternatives are now addressed by multiple free and widely used open source packages, or cheap open source-derived and cloud-hosted alternatives. But even with all these advantages, people still get sick or quit; natural disasters occur; management, customers and investors still create unexpected opportunities or hurdles to jump over; and, generally, stuff happens that you cannot control.

These are not excuses and all these contingencies can and should be planned for and aggressively worked around—however I can tell you with almost certainty that when you are in a transformation scenario, if you are thinking more than single-digit weeks / a couple of months out, shipping on time will be more of a struggle than you currently think it will. If you have a very near-term goal, you can indeed generally hit it provided your goal seems ridiculously easy at the outset of the work. But it will still be harder than you expect. If you are thinking many months or several quarters out, you will almost certainly be late or not as feature rich as your current plan calls for, due to the cumulative effect of now-unexpected events.

Things are different once you become a well-oiled machine. But even there, experienced companies and teams still plan for uncertainties and generally hedge their externally (customer) committed dates and targets, even in this modern era of Lean / Agile software development. They do this, generally, by prioritizing their objectives (rank ordering and setting “Must, Should, Could, Won’t” cutoffs on the backlog for the release), focusing on the most important items, and staying “Agile” to accommodate the surprises. Their professionalism comes from recognizing the reality of the unexpected, and being able to accommodate it without stress.

Once we have an idea about where we want to end up, choosing precisely where to start becomes another important decision. In large companies, I often recommend that clients choose a project that everyone has wanted to do for a long time but which has never been successfully implemented. Ideally this project should create significant upside for the company if successful—for example, opening up a currently untapped stream of revenue. On the other hand, it should have limited downside risk, in the sense that if the project fails, it won’t tank the company—or negatively impact revenues in a material way. The reason for these conservative criteria is not that you expect the project to fail, but rather that they allow people to feel that it’s safe to take a risk, change their behavior, and to do their best work. These criteria set people up to be heroes if successful, but is not so career- or revenue-critical that people need to fear making mistakes or trying new approaches. In other words: high upside, limited downside is situation where people can do their best, disruptive work.

For some companies, there is no “hedging” or “Plan B”: the company needs to transform or die. While small companies may literally go out of business unless they move fast enough, for a significantly sized company things are rarely that quick. Generally, the worst case for a large company is a long, lingering erosion of market share accompanied by top executive departures, layoffs, and ending in an ignominious acquisition of the remaining assets by a competitor or disrupter wanting to buy market share. That’s bad enough.

In “transform or die” cases, wholesale re-invention is indeed required. Generally, however, your best plan is limit the impact of new initiatives on your current revenue generation activities as much as you can, until you have demonstrated success. Move in parallel to the degree that you can—then go “all in”. Apple, again, is a good role model here: in turnaround mode, they continued shipping and doing active engineering work on their then soon-to-be-obsolete operating system (MacOS) while, in parallel, developing their new operating system (“OS X”) as well as disruptive new products like the iPod. They didn’t start cannibalizing their MacOS revenue stream until its successor, OS X, was well established.

Overall, your best mitigation for uncertainty is to start now, and to prioritize your work so you do the most important and risky things first. That way at any given point in time, you at least have the most important items completed. And if you do encounter a risk, you have maximum time to mitigate it. But this only works if you start. Thinking and planning is great and necessary, but it doesn’t turn into working software until you actually start work on the software!