Technology Transformation isBullShit

People are the carbon of transformation

Culture eats strategy for breakfast, and people devour culture, organizational change, and strategy during a transformation feast. Individuals motives, desires, aspirations, ego, talent (or lack there of), id, performance metrics, peer pressure, and ulterior motives are what form people’s values and beliefs, and drive people’s behavior. People’s values, beliefs, and behaviors control the destiny of a companies organizational structure and culture during a technology transformation.

A technology transformation is a confluence of people, process, technology, governance, business, culture, and organizational disruption. It is a painful, multi-dimensional rubik’s cube of infinity permutations. Move one people panel, and the technology, governance, business, culture, and organization change profoundly. Move a culture panel, and the people, governance, business, and organization mutate in unanticipated ways.

The journey will eventually lead to business value creation, and organizational and culture change. Eventually is the operative word as the typical journey involves two to three unsuccessful attempts, failed organizational restructuring, swapping in and out of system integrators (never be the first system integrator in the door), hiring and firing of CTOs, CIOs, and VPs, and blame being distributed freely by the powers that be. This blog post will tell you the shit that does not work during a technology transformation. These we anti-patterns are systemic and ubiquitous because the path of least resistance is so alluring, yet so fatal.

Before we delve into people, best practices, and lesson learned, let’s define, understand, and examine culture, and organizational design and change. The definition of culture I adhere to is from this book — Cloud Adoption Playbook. The book is written by IBM Transformation Advisors. Chapter 4 Culture and Organization. “An organizational culture is the combination of the shared values, beliefs, and social norms in an organization, resulting in behaviors, practices, and customs that the members of the organization follow.”.

The same definition is in the book You are now less dumb, which contains a more verbose explanation of societal culture. The definition is salient as it utilizes a technology metaphor. This book states, “As the philosopher Terence McKenna liked to say, cultures are operating systems for brains. To continue the metaphor — the shared beliefs, values, and norms of your society are the software running on the hardware in your head. Beliefs are the things most people believe to be true. Values are the interpretation of what is right and wrong, important and silly, ethical and unethical. Norms, though, have the most influence on your actions and thoughts. Norms are the rules of behavior within a culture that determine what is and is not acceptable from one circumstance to the next.”.

The book goes on to say that norms are the hardest to change, and are the most ambiguous as they are typically not codified in laws, procedures, or statutes. Norms are just understood, and blindly and rigorously adhered to by employees. Norms are the unspoken assumptions that determine how things get done at a company.

What does not work ? This is the first question leaders ask when embarking on change. Leaders can find a multitude of transformation best practices. There is a dearth of information regarding what not to do. The ten anti-patterns below have been distilled and codified from experience engaging in hundreds of technology transformation across all industries, sizes of companies, and toiling in decades of technology evolution and disruption. I have participated in conversions, transformations, and modernization from pre-mainframe to mainframe, mainframe to mid-range, mid-range systems to distributed computing (aka client/server), client/server to internet, and internet to cloud. I am starting to witness the next mass migration of cloud to AI. The people, process, organizational, and culture change challenges remain the same. The technology changes involve new technologies, which fundamentally remain stagnate and common. There will always be compute, security, storage, databases, networking, applications, and operations. The same questions repeat as well. How do I migrate my database? Should I re-host, re-architecture, replace, re-platform, or re-write? How do I stand up my network, security, and identity management? The song does remain the same, and people will remain the lowest common denominator. Let’s send it…

1. Starting with organizational and culture change — Start with people, process, and platform. Organizational structure is entrenched, and nearly as emotional and dogmatic as culture. Don’t talk religion and politics at dinner parties, and don’t attempt culture and organizational change at an institution without being prepared for visceral reactions and ubiquitous, fierce decent — much like proudly announcing you are an atheist at a dinner party in Birmingham, Ala.

Organizational change is typically done by moving the same leaders into different roles, and/or moving from a horizontal organization to an industry/vertical orientation or vice versa. Two years later nothing has improved including cash flow, cost of goods sold, technology, processes, profits, revenue, margins, or company moral. The company then embarks on another shifting of executive chairs without changing the thing that real matters — the nephophobia, status quo leaders.

Although organizational change is one of the exponential multipliers of Amazon innovation formula, cloud modernization, digital transformation, and cloud transformation efforts often fail or stall because a company attempts to change a organization or the culture. Move to DevOps, embrace Agile, or implement two pizza teams (culture + organizational change) is often the refrain of technology vendors, leaders, IT mavens, and business consulting firms.

The reality is organizational change is difficult and disruptive, and cultural change (culture is essentially the unwritten, inexplicable way people make decisions, interact with each other, and interface with partners and customers) is infeasible, or at least a 10+ year effort involving colossal people change. The success of technology and process change influences organizational and cultural change — don’t start with organizational change. For example, implement a CI/CD pipeline. This change will force changes to tooling, architecture/platform, technology, and processes, which will organically force organizational structure and culture to change.

It took Amazon over 10+ years to fully change organizational structure and architecture/technology to move to cloud. Amazon did not have as much legacy technical debt as most companies, it had a defined culture of innovation (LPs, two-way and one-way doors etc), and was only a 6+ year old company when they started — less history to undo and fight against. The disconcerting aspect of the Amazon.com story is if took Amazon.com that long, how long is it going to take John Deere, Capital One, or some other 50+ year old company?

“Company cultures are like country cultures. Never try to change one. Try, instead, to work with what you’ve got.” — Peter Drucker

2. Expecting middle management to embrace the change — Middle management is adverse to change, and intent on protecting ‘empires’. More so than talent mismatch (aka people skills), the biggest blocker to change, and therefore cloud adoption, is middle management and tenured entrenched leaders one level down from executives — career politicians and bureaucrats. It is the fear of ‘losing an empire’ that individuals have spent years building and 10+ years protecting, and not doing much work in those years. These individuals have expensive mortgages to maintain, a life style they are accustomed too.

I engaged with a Fortune 1000 company that struggled for close to 3 years to get (beyond the innovation group) any cloud migrations of significance to complete successfully. It was not until a number of entrenched VPs ‘retired’ (forced out), new leaders introduced, and middle management was restructured, and downsized, that momentum changed. Keep in mind that decisions being made during a cloud transformation are (including what to migrate first) are done so because of personal and political reasons, not because of business outcomes, the ‘right’ technology, or the greater good (aka well being of the individual contributors or the company). Understanding how people are motivated, incentivized, and what inspires them is the key to being successful at business and technology transformation — read more here.

I will never forget the time a CIO of Fortune 500 company told me, “Tom, I agree with everything you are saying regarding the financial, technical, operational efficiencies, people productivity, and agility benefits of moving off of mainframe technologies to open systems and internet based solutions. However, I am two years away from retirement. Why would I want to work that hard to complete this transformation? Why would I take on even a small amount of risk of failure? I just want to coast to retirement without the annoyance of learning something new, working long hours, and taking on unnecessary risk. This sentiment is real, and permeates all leadership ranks within all companies I have engaged with. This blog post explores the maxim that middle management is a disease.

“There is an enormous number of managers who have retired on the job.”
— Peter Drucker

3. Slow, burdensome decision making — Two frequent mistakes with decision making: 1) Taking too long to get it right 2) Classifying two way door decisions as one-way door decisions. Leaders primarily exist to make decisions. The irony is most leaders avoid or delay making decisions. A primary tactic of decision delay is to over analyze, and imbued oneself in analysis paralysis. Even well intended mechanisms can be exploited by leaders to prolong decision making.

Amazon utilizes a mechanism of narratives (6 page documents) to make one way door decisions. A one way door decision is one that has significant, and often, irrevocable consequences. The original intent of the narrative was to avoid the mistake of making decisions with limited data (empirical and anecdotal) and avoid collusion among leaders. It is perplexing that companies continue to make billion dollar decisions using Powerpoint and behind the closed doors with a few cunning and conniving leaders. The narratives abate this HiPPO decision making process based upon aesthetics, charisma, popularity, plotting, scheming, and likeability. Even a well intended mechanism can be exploited and sabotaged. Narratives can be used by leaders as a decision stall tactic. It is possible for leaders to require narratives for trivial two way door decisions, or as method to avoid the decision by requiring an inordinate effort, six pages, to justify a mundane decision. The beat goes on and the beat repeats — people are the carbon of an organization.

The 80/20 rule applies in earnest regarding decision making. Most decisions, even one way door ones, can be made with 80 percent of the data. It takes 80% of work to complete the last 20% of information gathering, collating facts, and deciphering the consequences of this data. The delay can be catastrophic to a company’s well-being. Decisions can easily fall victim to being, including what to migrate first becoming a laborious, elaborate process, made because of political and personal reasons, to the determent of positive business outcomes. Seeking perfection is fatal. Decisions require a dose of ‘gut feel’. Data can be misinterpreted, bent to satisfy a bias hypothesis, and spurious. Gut feel is not unpredictable and random, it adds an element of experience, intuition, foresight, macro conditions, and humanity that data is devoid of.

“More is lost by indecision than wrong decision. Indecision is the thief of opportunity. It will steal you blind.” — Marcus Tullius Cicero

4. Consensus building — Leaders that don’t want to offend someone or are reluctant to make a decision will use terms such as, “We need to build consensus”, “we need to establish a study group”, “we need to make sure everyone is onboard”, or “let’s form a committee”. The indecisive leader will advocate for forming a committee, a study group, or hire a prestigious consulting firm staffed with eager, inexperienced ivy league MBAs. These are all excuses for the real reason — leaders are afraid to make difficult decisions. I can guarantee that study groups and consulting firms will come to the same conclusion that your employees, customers, or partner could have provided for zero cost and less time — pick up the damn phone and talk with an employee or customer that is a truth seeker and teller, and then actually listen.

One of my favorite quotes is from Ross Perot, “If you see a snake, just kill it — don’t appoint a committee on snakes.” I had the pleasure of working at EDS when it was considered the preeminent technology company to work for. Oh, how times have changed. I would argue that EDS was the first cloud company. I digress…

“Consensus is the process of abandoning all beliefs, principles, values and policies in search of something in which no one believes, but to which no one objects.” — Margaret Thatcher.”

5. Lack of, the wrong, or changing KPIs — Behavior is determined by the goals and KPIs of an organization. Behavior drives an organization’s culture, processes, decision making, motivates, and morale. KPIs are essential to the health and prosperity of a company. However, I have witnessed all three categories of failed KPIs — non-existent, ill-conceived, and amorphic. The most frequent category is changing KPIs — amorphic. KPIs change because they are no longer relevant (strategy was wrong), and/or under performing on the KPIs will reflect poorly on a leader or favored individual contributor.

When done right (correct number, good intent, and outcome based), KPIs lead to positive results. The KPIs for each team member of a technology transformation need to be established before one workload is migrated. The other seemingly obvious, but often missing, characteristic is that KPIs for all leaders need to aligned. I have often witnessed incongruence between the CPO, CIO, CDO, CTO, VP of Infrastructure, CISO, and head of engineering. The VP of Infrastructure measured on the number of production deployments in co-location facilities, and the CTO measure on the number of production deployments in the cloud. These two individuals are destine to not get along.

“An employee’s KPIs drive their behavior and the decisions they make every day. “. — Declan Morris

6. Aligning to company goals and objectives — Yes, I am advocating the top priority should be to satisfy decision makers, leaders, and influencers personal objectives instead of the companies goals and objectives. The first reason is because individual goals may or may not be aligned with the company goals. Secondly, most decisions are made by leaders to maximize personal gain, minimize personal lose, and survival.

You have to make it personal in order to successfully complete a technology transformation. First determine what are the decision makers overt and unspoken motivations. Then shamelessly align all conversations and communications to promote, enhance, and invoke the individuals personal motives and whimsical needs of the current situation. This blog post delves into the levers, KPIs, goals, and priorities of an executive personas at work — how to satiate their work persona. Individuals have multiple personas beyond work. They traditionally consisted of home Tom, work Tom, and friend Tom. Now we have social media Tom, and soon AI Tom. No wonder people are confused with who they are. These personas often have different and conflicting desires and motives, just as the CxO personas are divergent and unique.

“The mass of mankind is ruled not by its intermittent moral sensations, still less by self-interest, but by the needs of the moment.” — John Gray

7. Keep the same processes — Developers, operations, system administrators, application developers, and DBAs are interested in keeping the same tools. Project managers, auditors, risk and compliance, and governance teams desire to keep the same processes in place. It is the role of the a leader to educate these individuals that without process change, and new tooling, the full benefit of the cloud will not be utilized. The cloud consists of new pricing models, on-demand compute vs fixed compute, APIs instead of scripts and one off code, ephemeral and immutable architectures, agility, flexibility, and global expansion.

Part of this education is mapping current ITIL-based processes to new cloud friendly capabilities and processes. The argument made for keeping the identical tools and processes is that AWS, ‘is just another co-lo facility”. I have told more than one Fortune 1000 executive that if your posture is cloud is just another data center, “You should not move to the cloud…full stop.”. This attitude will stifle the process, cultural, and organizational change that will an enable a transformation from an on-premises operating model to a Cloud Operating Model. An organization intent on maintaining the same processes should not entertain a technology transformation.

“One should never underestimate resistance to change and innovation in large and successful enterprise that have ‘done things this way’ for a long time.” — Greoge Hope

8. Build it and they will come — The consumers of cloud are the customer, and they are the ultimate decider of success. Internally, the consumers of the cloud are the line of business owners, product owners, finance, and marketing. Understand their needs and provide the services and tools that support those needs. Building the perfect AWS landing zone does not insure lines of business will move to the cloud. Developing a sophisticated cloud monitoring platform does not mean lines of business or operations will embrace this new, new thing.

A Fortune 1000 IT organization I was engaged with developed an AWS monitoring platform. The IT team went to roll out this platform to lines of business, and discovered that one of the lines of business had developed their own monitoring platform that was similar. The line of business, of course, chose to continuing using the one they developed.

A prominent member of the Oracle product management organization once told me, “Product Managers at IT vendors are ‘turd polishers’.”. The IT vendor engineering teams develop what they consider to be a cool, innovate new product with limited customer input, and limited understanding of market dynamics. The engineering team hands the product over to the product management organization to create marketecture that will entice customers into buying the product.

“People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.”- Theodore Levitt

9. Being agnostic and getting all clouds ‘right’ — The root cause of cloud agnostic nirvana syndrome is the fear of vendor lockin. A multi-cloud approach is framed as a means to lower cost, mitigate risk, and ensure reliability. It is perceived as a mechanism to ‘keep vendors honest’ (aka enhance negotiating power). A cloud agnostic doctrine actually increases costs, makes a simple situation complicated, duplicates resources (people, tools, software, operations), and leads to building instead of buying tools. The mitigation of risk is minimal, and the rewards (I can switch cloud providers at any time) are suspect.

Oracle utilizes PL/SQL to achieve vendor lockin. The mantra of keeping your business logic close to your data using PL/SQL has proven highly successful for Oracle. There must be a benefit to customers as well, as customers, partners, and ISVs continue to utilize PL/SQL.

‘Vendor lockin’ endows customers with hefty discount rates via Private Pricing Agreements (PPAs) and Enterprise Licensing Agreements (EDPs). ‘Vendor lockin’ products (cloud managed services) and features improve performance, scalability, reliability, and security. Vendor lockin is a means to reduce cost of development and management, increase performance and reliability, and significantly reduce cost of acquisition.

Cloud agnostic ideology turns a simple or complicated transformation into a complex, convoluted, and chaotic situation. There are a plethora of best practices, frameworks, and blueprints that can be deployed if the situation is kept simple — one cloud. The complex and chaotic realm (multi-cloud) lacks established patterns, standards, and templates, as every multi-cloud environment is a unicorn.

The vendor lockin dilemma has exited since the inception of technology. The conversation should be re-framed as a cost of switching dialogue. Here is a great article regarding switching costs and vendor lockin.

The approach when new to cloud should be to get one cloud right. It is challenging enough to do this. Pick one cloud, and just do it. I have heard this guidance espoused by executives at every major cloud provider. Even the cloud providers are advising against a non-committal approach to cloud — perhaps you should listen.

“Most people fail, not because of lack of desire, but, because of lack of commitment.” — Vince Lombardi

10. Confusing TCO (cost of acquisition) with ROI — This may seem obvious, but people make this mistake every day. Humans buy a car, a home, and even settle divorces only considering TCO — ‘what will my monthly payment (or check) be’. ROI considers all costs of ownership and the duration of the hold period. TCO is what will it cost me day one. TCO is a point in time; a stagnant perspective. Never call at TCO is a business case. A TCO for a cloud transformation is the infrastructure cost of acquisition.

A business case includes runtime costs, migration costs, buying and configuring new tools and ISV solutions, instantiation of CCoE, training / up-skilling investments, hiring and firing expenditures, changes to software licenses, and running systems in parallel during migration. Here are other attributes that are contained in an ROI, but generally not considered in a TCO:

1. Application instead of workload migration plan.
2. Expected annual growth rate of each application.
3. Change of application disposition (eg re-host to re-architecture, re-host to replace) over the course of 5 years.
4. Cost of run/operating in parallel during transition.
5. Production, QA, development, staging, integration, and disaster recovery.
6. Impact of moving from CAPEX to OPEX.

“Price is what you pay. Value is what you get.” Warren Buffett.

The lack of any mention of compliance, governance, and audit — the three horsemen of internal operational efficiency, is quit obvious. Governance encompasses decision-making, rule-setting, and enforcement mechanisms to guide the functioning of an organization. Compliance is the state of being in accordance with established guidelines or specifications, or the process of becoming so. Technical audit (TA) is an audit performed by an auditor, engineer or subject-matter expert evaluates deficiencies or areas of improvement in a process, system or proposal. They are codified, rigid standards and operating procedures. All three ensure operational rigor and conformity across organizations. They also assume a stead state has been achieved. Because of these attributes, the applicably to a transformation, that is inherently unstable, malleable, and transient, is limited.

Compliance, governance, and audit are used to catch errors, improve decision making, establish rules, and enforce standard operating procedures. Compliance, governance and audit are superfluous if you hire and promote the right people (A players), maintain a flat organization, drive decision making down in the organization, and maintain a culture of ownership, learning, innovation, change, and collaboration.

The magic in avoiding errors, better decision making, and improving operational efficiency is hiring and retaining the best people, and letting them do their thing. Why should the potion of a successful technology transformation be any different?

About the author : Tom Laszewski is the founder of the AWS Enterprise Technologist team (2018), and the AWS Private Equity Transformation Advisor program (2021). Tom is currently the Global Account Strategist (GAS) for Blackstone.

The AWS Transformation Advisor (TA) program is an engagement that provides support and guidance for executives leading complex cloud and digital transformations at the corporate level. The Transformation Advisor functions as a ‘cloud whisperer’, ‘cloud therapist’, and trusted advisor to the CxO as they develop the company’s cloud and/or digital transformation strategy, plan, and execution model.

The scope of the TA program includes development of the business case, documenting KPIs, cultural impact assessment, people upskilling plans, organizational change recommendations, launching a cloud adoption office, and establishing a cloud operating model. The program does not follow a rigid curriculum. It is tailored to the specific needs, business outcomes, risks, organizational goals, personal desires, and culture impediments identified by the executive.

Tom is the founder and curator of the isBullShit brand.