37. You Can’t Fake IT – The Software Architect Elevator

Chapter 37. You Can’t Fake IT

To Be Digital on the Outside, You First Need to Be Digital on the Inside

Who can spot the dinosaur programmer?

Rapid feedback cycles (Chapter 36) help digital companies understand customer demand and improve the product or service offered. Naturally, this feedback loop works best when the product or service has direct exposure to the end customer or consumer. Corporate IT, in contrast, is relatively far removed from the end customer because it supplies IT services to the business, which in turn is in contact with the customer. Does this imply that corporate IT shouldn’t be the focal point for digital transformation as it’s too far removed from digital customers? Many digital transformation initiatives that are driven “from the top” appear to support this notion: they have special teams engage with customers in focus groups before handing down the specs to IT for implementation.

Laying the Foundation

But just like you cannot build a fancy new house on an old, fragile foundation, you cannot be digital on the outside without transforming the IT engine room: IT must deliver those capabilities to the business that are needed to become Agile and to compete in the digital marketplace. If it takes eight weeks to procure a virtual server based on an email request, the business cannot scale up with demand, unless it stockpiles a huge number of idling servers, which would be the exact opposite of what cloud computing promises. Worse yet, if these servers are set up with an old version of the OS, modern applications may not run on them. On top of all this, necessary manual network changes are guaranteed to break things or slow them down.

Feedback Cycles

Rapidly deploying servers can be achieved with private cloud technologies, but that alone doesn’t make IT “digital.” For corporate IT to credibly offer services to businesses competing in a digital world, it must itself be ready to compete in the digital world of IT service providers, not only from a cost and quality perspective, but also from an engagement model point of view: corporate IT must become customer centric and learn from customers using its products in an infinite loop (Chapter 36).

If the servers that are provisioned aren’t the ones the customer needs, provisioning them faster accomplishes nothing. Moreover, the customer may not want to order servers at all, but prefers to deploy applications on a so-called “serverless” architecture. To understand these trends, IT must engage with their internal customers—the business units—in a rapid feedback loop, just as the business units do with their end customers.

Delivering on Your Promises

Engaging with customers is helpful only if you can deliver on their demands. In the case of IT delivering services to its customers, the business units, it must have the capability and the attitude to deliver digital services rapidly at high quality. An MIT study1 showed that those companies that aligned business and IT without first improving their IT delivery capability actually spent more money on IT but suffered from below-average revenue growth. You can’t fake being digital.

Customer Centricity

Customer centricity is a common phrase incorporated into many a company’s motto or “value statement.” What company wouldn’t want to be customer centric after all? Even institutions whose customers are decreed by law, such as the Internal Revenue Service, have exhibited a good dose of customer awareness in recent years. For many organizations, though, it’s difficult to move beyond the simple slogan and truly become customer centric because it requires fundamental changes to the organizational culture and setup: hierarchical organizations are CEO centered, not customer centered. Operational teams following ITIL processes are process centered, not customer centered. IT run as a cost center is likely cost centered as opposed to customer centered. Running a customer-centric business on top of a process- or CEO-centric IT is bound to generate enormous friction.

Cocreating IT Services

To support a business in digital transformation, it’s no longer enough for IT to develop and push commodity services to their customers, the business units, via governance (Chapter 32). IT must start to behave like a digital business, generating “pull” demand instead of pushing product. This can be done well by developing products jointly with customers, which goes under the fancy moniker of “cocreation.” While many internal customers will welcome the change in mindset and the opportunity to influence a service being built, others may not want to engage unless you present a firm price and service-level agreement. Being digital works only if your customers are digital.

Eat Your Own Dog Food

Some IT departments are relatively far from the end customer, so they wonder how they can get feedback cycles started. They tend to ignore a large, readily available pool of customers that’s very close by: their own employees. Employees are friendly and motivated customers that are usually eager to try out new stuff. Ironically, the common name for this clever practice is dogfooding, assuming people will eat their own dog food. I’d side with an old friend here who determined that it’s unfair that his dog eats dog food while he’s having a tasty dinner. So he decided to share his meal with his dog instead—the vet confirmed the dog is perfectly healthy doing this.


Google is famous for dogfooding its products, meaning its employees get to try alpha or beta versions of new products. While the name doesn’t make it sound too appealing, Google’s “food” includes pretty exciting products, some of which never reach the eyes of the consumer.

Dogfooding is effective because it enables an extremely rapid feedback and learning cycle in a safe and controlled environment. I start all my IT services by offering them first as an internal beta release. Once we better understand customer expectations and work out the kinks, we offer them to external customers.


Google took things a step further and merged employee and customer accounts into a single user-management system, making customers and employees appear identical to most applications, differentiated only by their domain name (google.com) and their access from the corporate network. Merging the previously disparate systems was rather painful, but the effect was hugely liberating as employees were treated as customers.

In contrast, traditional organizations can look at employees and customers very differently, as illustrated by this example:

At a large financial services company, employees weren’t supposed to use Android phones. Without even debating the technical merit, I couldn’t help but wonder how this company can then support customers using Android devices, which make up some 80% of the market. If Android isn’t considered secure enough for the company’s financial services employees, how can it be considered secure enough for its customers?

Rather than trying to control the user base, it’d be more helpful to understand and address potential weaknesses, for example through two-factor authentication, mobile device management, fraud monitoring, or disallowing old versions of the OS, both for customers and employees.

Digital Mindset

Besides starting to use their own products and learning to iterate, one of the biggest hurdles in making corporate IT more digital can be the employees’ mindset. When employees use previous-generation BlackBerry phones and internal processes are handled by emailing spreadsheets based on rules documented in a slide deck, it’s difficult to believe that an organization can act digitally. While it’s a touchy subject, the age distribution in traditional IT can be an additional challenge: the average age in corporate IT is often in the 40s or early 50s, far removed from the digital natives being courted as the new digital customer segment. Bringing younger employees into the mix can help companies become digital as it brings some of your target customer segment in-house.

The good news is that change can happen gradually, starting with small steps. When employees start using LinkedIn to pull photos or resumes instead of emailing resume templates, it’s a step toward becoming digital. Checking Google Maps to find convenient hotels instead of the clunky travel portal is another. Building small internal applications to automate approval processes is a small but very important step: it gets people into a “maker mindset” that motivates them to tackle problems by building solutions, not by referring to outdated rule books. The digital feedback cycle can work only if people can build solutions. This may be the biggest hurdle for corporate IT departments, because they are too afraid of code (Chapter 11). Code is what software innovation is made of, so if you want to be digital, you’d better learn to code!

Opportunities for making small steps toward becoming digital are plentiful. I tend to look for little problems to solve or small things to speed up and automate.


At Google, getting a USB charger cable was a matter of 2.5 minutes: 1 minute to walk to the nearest Tech Stop, 30 seconds to swipe your badge and scan the cable at the self-checkout, and 1 minute to walk back to your desk. To do this in corporate IT, I had to mail someone, who mailed someone, who asked me the type of phone I use and then entered an order, which I had to approve. Elapsed time: about 2 weeks. Speed factor: 14 days × 24 hours/day × 60 minutes/hour / 2.5 minutes = 8064, in the same league as setting up a source code repository (Chapter 35).

Fixing this would make a great miniproject. You don’t see a positive business case? That’s probably because your company isn’t yet set up to develop solutions rapidly. A digital company could likely build this solution in an afternoon, including database and web user interface, and host it in its private cloud basically for free. If you never start building small, rapid solutions, your IT will be paralyzed and likely unable to act in a digital environment.

The Stack Fallacy

As much of corporate IT is focused on infrastructure and operations, becoming software minded (Chapter 14) requires a huge shift. For example, my idea to build an on air sign (Chapter 30) that illuminates when my IP desk phone is off the hook never materialized because the team rolling out the devices didn’t code or deal with software APIs.

The challenge an organization faces when “moving up the stack,” e.g., from infrastructure to application software platform or from software platform to end-user application is well-known and has aptly been labeled the stack fallacy.2 Even successful companies underestimate the challenge and are subject to the fallacy: VMware missed the shift from virtualization software to Docker containers for many years, Cisco has been spending billions in acquisitions to get closer to application delivery, and even mighty Google failed to move from utility software like search and mail to an engaging social network, a market dominated by Facebook.

For most of corporate IT, this means an uphill climb from a focus on operating infrastructure to engaging users with rapidly evolving applications and services. Though challenging, it is doable: internal IT doesn’t need to compete in the open market, giving it the chance to change in small increments.

1 David Shpilberg et al., “Avoiding the Alignment Trap in IT,” MIT Sloan Management Review, October 1, 2007, https://oreil.ly/nK9ph.

2 Anshu Sharma, “Why Big Companies Keep Failing: The Stack Fallacy,” TechCrunch, Jan. 18, 2016, https://oreil.ly/OYCi-.