Technology Transformation isBullShit
The long game — organization and culture change
The Technology Transformation isBullShit people are the carbon of transformations blog post addressed technology transformation anti-patterns focused on people and process. I dismissed organizational and culture change as things to do later. Well, later has arrived.
What works for organizational and culture change? It is not easy, most attempts fail because a politically charged methodical, cautious, and timid approach is taken. Invoking the ‘easy button’ (avoiding process, organization, and culture change) will inevitably lead to resistance, sabotage, subversion, and inaction. The remedy includes exterminating sacred cows, firing leaders, dismantling internal fiefdoms, simplifying standard operating practices, letting go of people unwilling to change, and eliminating the ingrained ways of doing business. The action-orientated path needs to be rapid, ruthless, and offensive; a willingness to offend some people, and show no quarter when it comes to establishing new ways of doing business.
During a successful transformation, peoples’ pride, security blankets, livelihoods, and egos will be irreparably damaged, and replaced with a new way of thinking, existing, and working. Below are the top ten unequivocal prescriptive guidance imperatives for organizational change, organizational design, and culture change. If you know of better ones, let me know; the top ten organizational change and culture imperatives are mutable.
- People change — The only way to institute organization and culture change is though people change. Changing people begins with KPIs that are aligned to the outcomes of the transformation. The second imperative is to define and publish new roles. Lastly, you must communicate verbally, in writing, and one-on-one the principals of the transformation. Manifestos (will be discussed soon), KPIs, and role adaptation are the three pillars of changing people behavior. Twenty-five percent of people will embrace the change. They are typically the most productive, ambitious, and unorthodox individuals. They have been frustrated with the lack of accountability, leadership risk mitigation, and inaction. They have been waiting for a new direction, and the technology transformation will emboldened and elate them. You have now activated the most important individuals in your company. This twenty-five percent will contribute 90% of the effort during the transformation. Thirty-five percent will reluctantly change. This individuals will adapt — eventually. They will require enormous hand holding in the form of up-skilling, constant communication, reassurance, and copious one-on-one meetings to discuss concerns. The leader’s responsibility is to balance empathy with challenging and stretching the limits of the individuals to unlearn what they have learned. The remaining 30% need to be fired — immediately. These individuals are most likely non-regretted attrition. Delaying the inevitable will only reduce the morale of the organization, consume most of your time, and squander budget for resources that will help you succeed. The bottom 30% will engage in active subversion of your transformation efforts.
- Flatten the organization — Institutions evolve from lean to corpulent — they are no exceptions. Universities, technology companies, federal governments, hospitals, primary schools, car companies, police departments, non-profits, and city governments all inexorably move from a structure of doers with limited leadership to top heavy organizations with very few doers. The Institutional Structure isBullShit isBullShit blog post discusses how institutions only survive if they evolve, adapt, and constantly reinvent themselves. Companies naturally evolve from being comprised of pioneers, to settlers, and finally to town planners as coined in the book Accidental Empires. Town planners are proficient at operational efficiencies, and stewards of a money making commodity offering. The problem becomes when town planners become the majority at an institution. This leads to hierarchy, bureaucracy, over analysis, and inaction. The first action to take when town planners stifle progress and subvert change is to demote or promote all “team leaders” and managers with less than six direct reports . I believe that no manager should have less than 10 direct reports. Team leaders is one of “canaries in the coal mine” of a Day 2 company. To do change management, sometimes you have to change management. This isBullShit blog post explores the disease of middle management.
- Redefine incentives for people — Incentives drive behavior so establishing new KPIs is crucial to a successful transformation. As companies grow, the KPIs grow and they become input based (activities not results). During the pioneering and settler phase, the KPIs are limited and focused on customer outcomes. An early stage company will have a goal such as five production workloads from customer workshops, or publish a white paper that has ten thousand downloads. A late stage company will have a goal such as twenty customer workshops, or publish five white papers. An obvious difference is outcome vs output, and quantity vs quality. It is much easier to manipulate and massage input based KPIs. Would you rather have an employee write 5k lines of code, or write an application with 500 lines of code that produces $500K in revenue for the company?
- Change hiring practices — Culture change starts with “new blood”, and the right “blood”. A company can not expect all change to happen from within, and they can not expect the same job descriptions and hiring criteria to impact transformation positively. Cloud and digital transformation starts with transforming HR and recruiting practices to hire qualified staff, and to educate existing employees so they can become part of the learning cycle. The recruiting and HR needs to revise candidate responsibilities, qualifications, and experiences required to reflect the new organizational design, culture, and technology aptitude.
- Change promotion practices — Leaders that are smart, self-aware, confident, possess marketable skills, and perhaps have some “f*** you money” make objective decisions regarding promotions. A company that is permeated with imposter syndrome C and D players suffers from a highly politicized promotion process. Typically, and ironically, the more rigorous and defined a promotion process is, the more it falls victim to favoritism, subjectivity, and likeability. The promotion process should be based upon outcomes and customer results. Companies need to streamline the promotion process to place an outsized weight on customer feedback, outcomes, and empirical data from external stakeholders. Feedback from internal allies, cohorts, and others seeking promotion is easy to get and highly subjective, and therefore should have less weight on a promotion.
- Not just training, but on the job practical experience — Certifications prove a moderate threshold of competence, and provide companies reassurance that an individual possesses textbook expertise. I was able to pass six of the AWS certification exams (I am making no claim of brilliance or high IQ), including two professional level certifications, in six weeks with limited hands-on experience. I give credit to the Braincert.com. The online training consists of test taking from a diverse and abundant set of questions. Certifications involve a high proportion of learning how to eliminate answers, and ability to quickly, effectively, and efficiently determine the answer to a question. These test exams go into extreme detail on why the correct answer is true, and why the other answers are incorrect. Certifications prove you can pass tests, and have “textbook” knowledge. Hands-on experience imbues individuals with practical skills. AWS utilizes a workshop titled Experienced Based Accelerators (EBAs) to infuse cloud neophytes with the technical skills to successfully complete a cloud migration. The five day workshop groups the attendees into two pizza teams led by an AWS cloud guru. The teams re-host an application, or several simple applications, to AWS during the course of the week — learning by doing. I conceived, designed, and delivered a comparable migration workshop during my tenure at Oracle. The five day competitive database migration workshop (I did not have a glamorous moniker for the workshop) consisted of a half-day of presentations, and four and half days of actually migrating production databases and applications. Attendees found the workshop rewarding, fulfilling, and real as they were responsible for getting an application running on a new database in just a few days. Learning with real data and applications is so much more educational than attending a class, or passing a certification exam.
- Communicate, define, and document the transformation principals, and communicate, communicate and then communicate some more — The transformation strategy and tenets, modernization approach, and operating model need to be codified. A cloud manifesto is an approach to codifying tenets, approach, priorities, and communicating an outline of a plan. The manifesto provides a prescriptive approach to all the dimensions of a technology transformation. A manifesto consolidates, synthesizes, and disseminates an agreed-upon approach from the entire company’s senior leadership team. Sections include: operating model, skills, Training & Talent Development, organizational design, organizational change, and technology direction (AI, cloud, data, and product focus for example).
- Get some wins — Success does breed more success. Identify greenfield migration projects that will utilize DevOps, two-pizza teams, working backwards from customer objectives, CI/CD, new tools, and automation. Utilize EBAs, or a similar concept, to complete simple migrations. What constitutes a simple migration? This Accelerating Migrations — Prescriptive Guidance for Cloud Migrations white paper provides the characteristics of simple, medium, complex, and very complex applications. The tools, approach, and resources used for the first migrations can be expanded across the company.
- Innovation/R&D team — Establish an innovation or research and development team that has its own budget, processes, culture, and building. The team should not be constrained by the rigid, cumbersome, hierarchical structure, and paternal nature of the company. It should not have to make a return on investment for three to five years. This organization is responsible for developing and implementing greenfield solutions developed using the latest technologies instead of the traditional tools and software utilized by the company. Infiltrate the rest of the company with the new operating model and best practices for technology and process change learned from the new innovation/R&D team once it has successfully implemented production solutions. This organization will be despised by many at the company. They will be perceived as the privileged and elitists, that can be successful because they don’t have to play by the rules. This group will be adored by A players, customers, partners, and analysts, The organization will attract young, smart, ambitious individuals that will catapult the company on a new technology trajectory. Throughout my career I sought out these teams and companies. First when I worked for EDS, and the technology preference for customers was shifting from mainframe to client/server. I moved from a mainframe group to a team that was implementing distributed computing based solutions on Sun Sparc computers, TCP/IP networks, Sybase databases, Computer-aided Software Engineering (CASE) tools, and the C programming language. This team used the precursor to Agile and MVP — Joint Application Design (JAD) and Rapid Application Development (RAD). EDS failed to embrace the movement to client/server, Agile, and MVP until it was too late. The second occurrence of seeking to be part of the ‘cool kids’ group was during the transition from client/server to the Internet. In the late 1990’s, I was a Solution Architecture in the Oracle Partner Technical team mostly engaged in Oracle database work. The Partner Technical team established an Internet Computing team that everyone want to be a part of. The Internet Computing team was engaged with application server engagements, Java coding, and Web front end design. I joined this team which lead to more opportunities, higher compensation, and better job security. Companies need innovation and R&D teams to benefit from the cost savings, productivity, efficiencies, and flexibility of the next technology wave. Innovation and R&D teams will infuse talent into the organization as they attract the best and brightest individuals. The mavericks, cowboys, and rebels in these innovation/R&D teams will be instrumental to the success of a transformation journey.
- Edicts work — Instead of allowing middle management to be an impediment, executives have proclaimed mandates. There is a distinct proclivity to attempt 50 applications in 50 days. The first company to institute a 50 in 50 decree was a Fortune 500 bank in 2014. Folklore indicates the CEO said to his leaders that he was no longer waiting for the company to start their migration to cloud. The bank would migrate 50 applications in 50 days starting immediately. No more debate, discussion, strategy, planning, excuses, building consensus, or delay. The outcome was 30 applications in 50 days. A Fortune 500 industrial automation company set out to move 50 applications in 50 days, and succeeded. AWS Managed Services was used to reduce the necessity of establishing a cloud landing zone and implementing operations in the cloud. National Australian Bank achieved 30 applications in 50 days.
The obvious buzzwords are missing from the top ten imperatives — Agile, Scrum, Site Reliability Engineering (SRE), Product-centric organizations, lean, two pizza teams, DevOps, and other acronyms, fashion statements, and memes. The reason is simple. People make two pizza teams, DevOps, SRE, and other frameworks work. Caveat emptor applies when it comes to two pizza teams, DevOps, and SRE. These organizational mechanisms create redundancies and duplication of effort. However, the benefits of two-pizza teams and DevOps creating a high-frequency, lean organization typically outweigh these deficiencies. Typically is the operative word. At a bloated company, two-pizza teams and DevOps can add to the complex and cost, and lead to inefficiencies, duplication of effort, and add wait time to workflows . This “Frankenstein” presentation is a montage of culture and organizational change mechanisms and frameworks. It contains details regarding the common implementation methods of Agile, Scrum, SRE, product-centric organization, lean, two pizza teams, and DevOps.
The other obvious exclusion in my top ten list is the perceived failure to mention a Cloud Center of Excellence (CCoE), Cloud Adoption Office, or a managed services team. A CCoE/CAO plays a role in creating standards, developing and deploying reference architectures, and ensuring a common set of security, operations, migration, application, and data best practices. This CCoE white paper I authored delves into the purpose, components, attributes, anti-patterns, and positive characters of a CCoE. The reason a CCoE is not listed in my ten in this blog post, is that it is a mechanism to achieve success and not a top ten organizational change and culture imperative.
I have witnessed many technology modernization, digital transformation, and cloud transformation efforts fail or stall because companies attempt to change an organization and its culture by moving to DevOps, Agile or two pizza teams. 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. I believe (and have seen in action) the success of technology and process change to influence organizational and cultural change. For example, implement a CI/CD pipeline for a new project. This change will force changes to tooling, technology, and processes, which will force organizational structure and culture to change. It took Amazon over 10+ years to fully change their organizational structure and architecture/technology to move to cloud. Amazon did not have as much legacy technical debt, had a defined culture of innovation (Leadership Principales, two and one way doors decision framework, and other lean mechanisms). Amazon was only a 6+ year old company when it started its journey; benefiting from not having an embedded culture, processes, or organizational structure. The disconcerting aspect of the Amazon.com story is if Amazon took that long, how long is it going to take John Deere, Capital One, or some other multinational behemoth?
The world is in the midst of the biggest evolution of mankind — technology revolution enabled by cloud and AI. The industrial revolution automated and obviated a majority of human and animal physical toil. The technology revolution (led by AI/ML, and now the fashion of the day GenAI) is disrupting cognitive work (aka mundane, repeatable intellectual tasks). Anecdotally, it appears as though companies outside of the software realm, or those that have existed for more than 20 years, are not that equipped from a technology, organizational structure, culture, governance, or process perspective to take advantage of the ‘supernova’ called cloud and AI. This is because their processes (aka mechanisms), organizational structure, culture, and technology is permeated with ‘debt’.
Ignore the glossies, case studies, and the one hundred page “boilerplate” binders from analysts, vendors, business process consulting companies, and change management gurus. First, internalize the anti-patterns I stated in the Technology Transformation isBullShit — People are the carbon of transformation blog post. Second, implement the ten patterns of success above after you are successfully running five percent, or 50 applications on the new technology, and have changed processes. Third, Venmo me an amount commensurate with the egregious saving you made through internal operational efficiencies gained, and the money you did not spend on over priced business consulting firms. Be like water in how you operate, govern, and adapt your company — constantly adapt, look to automate first, implement continuous improvement, realign teams as processes and technology change, listen to customers (don’t just talk to them), use AI (a chatbot is not digital transformation), learn through trial and error, and be open to criticism.
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.
