Updated: Category: Transformation
Not many people switch straight from a Silicon Valley powerhouse to a global insurance firm based in Germany. Now I am not sure whether that makes me brave or foolish, but it gives me a rare perspective on the life of architects at two far ends of the spectrum. Most employees of traditional companies only know the other side from what I call “digital travel brochures”, which show the digital equivalent of endless, isolated, clean beaches accentuated by constant sunshine and turquoise blue water.
And then there’s the opposite reaction, where new working styles are dismissed by unsubstantiated logic of “digital companies can do this because they aren’t regulated / follow the law / care about their quality”. As the gap between perception and reality of traditional and so-called digital companies appears rather large—in both directions—let’s put a reality check behind the rosy (and negative) pictures that many traditional companies have of the digital darlings, and vice versa. We’ll find that before you compare your grass to the neighbors’, you should first make sure that it’s actually grass.
What is traditional?
When describing the differences between banks, manufacturing, or energy companies on one side, and the Googles, Metas, Netflixs, and Amazons on the other, it’s not easy to find suitable labels for the two categories, which is required as per my rule that architecture options must have meaningful names. If the one side is “digital”, is the other “analog”? That may work for watches and music, but not for enterprises, which do very little in analog these days.
Ultimately, I settled on “traditional” because tradition is a good thing, and many of these traditional companies are doing very well. The insurance company that I worked for is also a powerhouse: it holds some $2.5 trillion in assets, roughly equivalent to the market capitalization of Google or Amazon. When they hired me, they were also on the cusp of a major transformation journey to the tune of 1 Billion Euros. Perhaps they ignored my (not-yet-published) advice to not hire a digital hitman, but I did my best and, looking back, believe that we made good progress in this well-funded, global organization, heavily invested into its digital strategy.
Digital Travel Brochures
The insurance firm had ambitions to become more nimble, agile, and ultimately successful in an environment that is governed by economies of speed rather than scale. As most traditional companies would, it looked at the so-called “digital darlings” for inspiration. And rightly so: most of the tech that we employed at Google was so ahead of its time that it didn’t even have proper names: big data, developer platforms, devops, containers, to name a few. To us, they were individually known as Bigtable, Blaze, Borg, Stubby, Chubby et al, and collectively as “this is how we work”. If you want to understand how to succeed in Economies of Speed, Google & co are indeed a good place to look.
But looking and transforming are two very different things. Traditional companies generally know about the environments they aspire to (technically and culturally) only from conference talks and books–exactly those travel brochures. And, as you’d guess, not all that is being advertised is necessarily daily reality. Many of us will remember when the Spotify Model, which had served as the de-facto ideal of modern delivery organizations, was revealed to be as much ambition as reality. And even though Amazonians do recite the leadership principles (minus number 15 and 16) in nearly every meeting, the idiosyncratic ways presented in the slides don’t quite reflect the average work day.
Whenever AWS staff presented the Culture of Innovation pitch to customers I cringed because I was well aware of the not-so-small gap between marketing and reality. The many “Day 2” posts on social media hint that this gap is growing, not shrinking.
So, as you’d expect, traditional organizations have loads of misconceptions about how digital companies really work. It’s a bit like the folks who “know” all foreign countries from television documentaries, but have never been. To be fair, not all presented practices are wrong, but sometimes the costs or preconditions of implementing them aren’t revealed.
The Amazon writing culture is real, but it also carries a huge cost. Teams spend weeks collecting data and fine-tuning a document, just to be told by the VP after a 10-minute “doc read” that they didn’t explore enough viable alternatives (the VP is usually right). The practice works well for Amazon’s scale and decision hierarchy, but it may not work for you.
As stated so often, you can’t copy these approaches without understanding the context in which they take place. That’s the typical Cargo Cult trap that so may organizations fall into.
Traditional Obituaries
The opposite is also true. Digitals hold many misconceptions about the traditional companies that they are looking to disrupt. However, they don’t look at travel brochures (no one except me appears eager to move to the other side), but at imaginary obituaries. Most impressions of digital companies about traditional organizations mimic a replay of the Titanic disaster: rich folks drinking champagne on a rapidly sinking ship (even the Software Architect Elevator has a drawing depicting that).
To correct that misconception, the very insurance firm that I worked for posted another record operating profit and forecasts some EUR 17 Bn for the 2025 fiscal year. It’s no surprise, then, that in 5 years their market cap doubled while Amazon eked out about 50% (the AMZN figure is dampened by the pandemic boost of 2020, which hadn’t completely worn off by 2021, but such is digital life).
How much greener is the grass really over there?
The biggest danger when looking at other organizations comes from projecting your constraints and assumptions. For example, it’s common for traditional organizations to achieve quality and compliance through lengthy review and approval processes. Such organizations equate these aspects with slow speed, to the point where they justify being slow by the need to be compliant. When they see a digital company move very fast, their conclusion is that those guys must be non-compliant and deliver shoddy software. And they are entirely wrong!
If you evaluate other organizations under your constraints, you will be wrong. They don’t operate under your constraints.
If you don’t realize that other organizations don’t operate under your constraints, you can’t understand the essence of the transformation. Digital organizations have high levels of automation and transparency, aren’t organized into silos that work against each other, and work in rapid iterations. Digitals have legal and compliance teams, but they don’t pride themselves in saying “no” to everything, as is often the case in traditional organizations. This makes them fast and compliant, something that doesn’t fit in traditional companies’ one-dimensional mental model.
The core point of transformation is that you cannot achieve your ambitions with existing methods and mental models. That’d be called optimization. No matter how much you fertilize your grass, it’ll never be as green as the digitals’, for a simple reason:
Digitals don’t have greener grass. They don’t grow grass.
Traditional organizations must understand that they need to leave old assumptions behind and imagine a world with fewer constraints.
Digital Misconceptions
Let’s make a “wrong answers only” list of views that traditional companies have about their digital counterparts—after all, such lists get a lot of attention on social media. As hinted, the same can be done in the other direction, but we’ll leave that’ll be material for another post.
Young and Small
The first fundamental misconception is that all digital companies are young. Microsoft is a semi-centennial, having been founded in 1975 and having gone public in 1986 (yes, we all wish we had bought those $21 shares that are now worth around $130,000). Google is coming up to 30 years and so is Netflix. Even Facebook aks Meta has passed the 20 year mark. Many of them have over 100,000 employees and tens of thousands of technical staff. There is no eternal youth for organizations: no, it’s not always “Day 1”.
Void of Problems
The perception of youth is closely associated with the second misconception that digital companies don’t suffer from the problems that hinder large, traditional organizations. After all, they are the role models, right? As you’d expect, digital companies, despite all their achievements, aren’t void of problems. They have legacy, coordination issues across teams, fiefdoms, and all the other dysfunctions that one would expect at their scale and size.
The laws of physics still apply in modern organizations.
The difference lies in them detecting and correcting quickly. When Google started to sense tensions between managers and technical staff, they launched an extensive data gathering and research initiative that became re:Work. When they saw too much local optimization and duplication, they introduced the role of the Area Tech Lead (ATL). Their critical capability is not to magically avoid all problems, but to resolve them swiftly.
No Legacy
One problem that is often perceived to not exist in digital organizations is legacy. Legacy does slow organizations down because everyone is afraid to touch it. That is true for digitals and traditionals alike. Digitals actually face a bigger challenge:
If you build faster, you also create legacy faster.
Rapid growth makes systems obsolete faster. I often challenge clients that justify system replacements with 2x customer growth—Google’s systems had to handle 200x or 2000x growth! That’s why Google rewrote most of their core systems multiple times, something that corporate IT dreads more tha internal audit. In 1995 the entire world-wide-web ran on about 75,000 web servers, which meant that crawling the entire internet in a batch job was feasible. As you’d expect, that architecture become obsolete very fast.
My favorite data point on legacy is when I invited Mike Feathers to give a talk at Google on his book Working Effectively with Legacy Systems around 2006. The room was packed.
Low Discipline
Traditionals believe (and have proof in their context) that “doing things properly” requires lengthy review processes that slow things down and stifle innovation. So, when others pump out new ideas at record pace, they fall into the trap of projecting their constraints, which leads them to conclude that the other folks do whatever they feel like on any given day.
In reality, though, digitals don’t speed things up by doing manual tasks faster—they automate them. The result isn’t just faster speed but also improved quality and repeatability. You can’t move fast when you have low discipline: you’ll crash and burn before you know it. So, against popular believe, digital companies have higher discipline across many aspects:
- They use highly automated and quality-driven processes to build and deploy software.
- They make decisions based on hard data, not opinions pasted into PowerPoint slides.
- If something isn’t working, they fix it or stop it. They don’t throw good money after bad.
- They track project success not by the budget spent, but by the impact delivered.
In my experience, it’s the traditionals who tend to be sloppy and lack rigor. For every process there’s two exceptions, and decisions are made on beliefs and career ambitions rather than data, which leads them into a lying contest. Because they move slowly, they don’t perceive this lack of discipline and live in the illusion of order and careful planning, a phenomenon that inspired the following chapter in The Software Architect Elevator:
Slow chaos is not order.
Loose Governance
Similarly, when traditionals observe the high rate of innovation on the other side of the digital divide, they quickly attribute it to lack governance. The (false) conclusion stems from the fact that their own governance—incarnated as an endless sequence of governance boards and sign-offs—is slow and rigid. So, they reckon that the only way to innovate rapidly is by shunning governance.
Ironically, the direct opposite is true: Google’s production deployment and operational processes are extremely tightly governed. When I built software, I used standard libraries (e.g. Stubby), deployed onto one kind of operating system (Linux), via one kind of packaging and deployment mechanism (Borg) and wrote automation scripts in the one language (BCL). I’d then monitor via a common time-series database (Borgmon) and analyze logs via the standard processor (Sawzall). For crunching large chunks of data, we’d use MapReduce / Flume and store data in Bigtable. It’s the level of harmonization that most traditional IT shops can only dream of.
In the digital world, harmonization speeds you up instead of slowing you down.
The contrast lies in the effect that these tools had on developer productivity: they enabled developers to do things that they otherwise could not (the open-source derivatives of Hadoop, Kubernetes, Istio, and Spark didn’t exist at that time). The “governance” (a word we never used) assured solid uptimes, rapid deployment, and out-of-this-world scalability.
The digitals use developer platforms in their true sense: highly harmonized and automated, allowing high-velocity creativity and innovation on top. That’s far away from the governance frameworks and infrastructure services commonly pitched as platforms by enterprise IT.
Digitals are also mostly immune to vendors pitching yet-another-tool for the same purpose or acquiring commercial software that comes with yet-another tech stack. Instead, they gravitate towards open-source and in-house solutions, which are easier to harmonize. In enterprises, my old joke sadly holds true:
How do enterprises get to have all possible technologies under the sun? One project at a time.
Living in a Lawless Zone
As you almost guess by now, the notion that digitals “can do what they want because they don’t need to be compliant” is entirely wrong. My work on mobile ad services involved PII (Personally Identifiable Information), such as location data. We built a base station that tracked store visits by customers tapping their phone on an NFC-enabled device. Without legal approval I could not launch, so I flew from Tokyo to Mountain View for a 3-hour working session with the legal team.
I remember my meeting with the legal team very well. They had read the design document and asked: so, you track the phone ID? Yes. You capture the station ID? Yes. You map the station ID to location? Yes. Problem!
Because the stations’s unique ID mapped to a location, the phone’s location history could be easily reconstructed when combined with the phone’s unique identifier, which has legal and reputational implications. The legal team explained that we could get subpoena’d to reveal this data, for example because the phone was used in a crime or an accident. And for reputational reasons, our preferred answer is “sorry, we cannot”.
So, nothing lawless here. The guidelines even extended beyond just legal considerations. And no approval, no launch. The big difference lied in how the legal team worked:
- The legal team was dedicated to geo-commerce applications. They were deeply familiar with both the legal aspects, reputational risks, and technical capabilities. They had read my design document.
- They mapped the legal and reputational requirements directly to the solution at hand, not through an amorphous “framework” that’s meant to cover all possible scenarios.
- Their role was to launch the product—within the legal framework and our own guidelines, of course. Just saying “no” would not achieve their targets.
- They were solution-oriented. We met the legal guidelines through double anonymization, one-way hashing, and limiting data retention. The legal team was well familiar with such concepts and signed off on them.
This stands in stark contrast with typical corporate GRC functions, Governance Risk and Compliance. Lengthy frameworks are written in the absence of specific use cases, deferring to an ominous regulator as their raison d’être. Legal reviews become a rite of passage, where someone passing is considered a weakness among the legal team. After all, their job is to stop projects, not to enable them with solutions.
Unlimited Funds
“Google can do it because they have so much money” say the companies who post double-digit billion operating profits, hand-wash executive’s company cars daily, and eat lunch served by white-gloved waiters in executive dining rooms. The reality is that nobody operates without constraints. Even if you had infinite money, you couldn’t hire infinitely many people and find infinitely much office space for them, leave alone having to coordinate across all of them.
Instead of unlimited funds, digitals tend to have stronger focus. Their opportunity cost is high, so they don’t like to be distracted. They are willing to invest heavily in strategic initiatives or in experiments that give them valuable insights. But if a project doesn’t deliver the anticipated benefits, they fix it fast or cancel it. Traditional companies often lack such discipline: how many business cases are really being revisited after 3 years?
When someone once posited that we need a “failure culture”, I reminded them that we already embraced it by continuing to burn loads of money on a doomed project.
Digitals pay their developers well, but not because they have money to give away. They enable their developers to be extremely productive and conduct strict performance management, so they carry little dead weight. What they don’t do is fund 3-year programs run by hordes of external consultants.
Excessive Risk Taking
A frequent retort to digital transformation—especially in financial services organizations—is the claim that digitals are the Dukes of Hazard gone digital: relentless risk takers who have nothing to lose. The misconception stems from traditional organizations equating change to risk. which is why they “never touch a running system”. Digitals who apparently do, are then considered risk takers.
Digitals decouple change from risk.
Digital companies don’t want to go out of business more than anyone else. Yes, they have billionaire founders who can afford to push the limits, but everyone else likes to see the next paycheck or—much better—an IPO or acquisition. So, they move fast at low risk, made possible by automated quality and compliance tests, solid in-house platforms, short feedback cycles, and data-driven decision making.
Interestingly, digitals also consider traditional companies to be excessive risk takers:
Running an 18-month program purely based on vision and promises seems crazy risky to digital companies.
This odd situation results from traditional companies focusing on the execution risk, the risk of a missing feature or something breaking during deploy, whereas digital companies focus on the impact risk, the risk that the solution won’t deliver the promised benefits. So, in a strange way, each side considers the other as reckless risk takers. It’s another reminder that digital transformation means fundamentally changing your way of thinking.
Shiny New Tech
Equally misguided is the notion that everything being built at digital companies comes straight from the future. In reality, developers have to churn through major refactorings, keep their tests suite up-to-date, and wait for slow builds. I did most of my development on standard Java and Python, which would have been available to any enterprise. Admittedly we had a very modern build system.
I spent a lot of work refactoring towards a domain layer after my project hit the limits of ever-growing domain complexity and a database whose schema was defined by the operational needs of the back-end (yes, Shared Database!). I was also active in the Testing Grouplet, which, as you’d guess, worked on establishing unit testing as a new practice into the organization. Many other teams were working down bug and feature backlogs on top of large, existing code bases. No, it’s not all as glorious as it may appear from the outside.
Easy Life
The last major misconception is that life in digital organizations equates to short pants, dogs and cats at work, baristas, and free gourmet food. We did not follow a 996 schedule, but we worked pretty hard to get our stuff done. I did not track hours, but in Tokyo we largely worked from 9:00-19:00 with very occasional weekend stints.
Even though the hours weren’t crazy, pressure was consistently high. When something worked well, there was no time to sit back—we immediately looked for the next goal. And the “no excuses” cultures meant that when stuff wasn’t done, we had nowhere else to point. I actually wish more traditional companies embraced that stance:
Have you seen those traditional companies where every team is perfect but is held back by the other teams? It’s like traffic with all those other bad drivers!
The food at Google was awesome, but after eating in the cafeterias of many so-called traditional companies in Europe, I can attest that their food is at the same level: freshly prepared, healthy, with vegetarian options. Perhaps this is the one area where the transformation of traditional companies has actually taken hold.
From Travel Brochure to Reality
It’s easy to develop misconceptions when you look at organizations from the outside. It’s even worse when these misconceptions translate into excuses for not changing. I often summarize this danger in a simple observation:
The company logo is on the outside of the building
On the inside things are likely different.
Grow Your Impact as an Architect
The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe
