“What you need is a latticework of mental models in your head. And, with that system, things gradually get to fit together in a way that enhances cognition.”
– Charlie Munger, Vice Chairman Berkshire Hathaway
Dear all,
last week, I worked with two companies to improve their digital capabilities.Both are among the leaders in their respective industries. Both companies have more than a century of successful history in what can be circumscribed as some field of mechanical engineering and manufacturing. As with many companies we work with,digital elements are becoming increasingly critical for their solutions and business.
So they are doing what they believe necessary to emulate successful Tech companies: Ramping up software development capacity and employing (scaling) Agile methodologies. Hiring Agile Coaches and Scrum Masters and developing Product Management functions for their digital solutions.
Still, they struggle to even remotely approach the digital skill and the success of the West Coast behemoths. And our clients are not alone in that; many other industrial-era companies worldwide are in the same situation.
So what sets the Amazons, Apples, Facebook/Metas (etc.) apart in their capabilities?
Reflecting on my observations from my two-plus decades as an executive in tech companies (Apple, …) and more than a decade as a consultant to mostly industrial companies, here is what I think makes the critical difference:
It’s mental models.
Mental models are representations of the world that help us understand and make sense of it. Mental models shape our perception and interaction with the world. They are built from our experiences, knowledge, and beliefs. (The concept of mental models was initially developed in cognitive science in the 1980s.)
The biggest challenge of industrial companies is an underlying mental model that equates software and digital technology development at large with industrial production.
Industrial Corporates: Mental Model „Software Production“
Most industrial companies still treat software development like an industrial process, with components specified, planned, and managed – often in „projects.“
This approach considers software developers (and their time) a production cost factor. Therefore, they are planned for and accounted for like factory workers or robotic production resources.
Outsourcing and even offshoring are standard practices in industrial companies‘ IT and R&D departments (amplified by the general scarcity of programmers and computer scientists in the local labor markets).
The mental model of „software production“ also significantly shapes the structure of organizations and products. Often, teams are formed based on technical expertise rather than the problems to solve. This strategy seeks to optimize capacity utilization by concentrating specialists and spreading them across the development of different components of various products.
The industrial mindset also often involves a specifications-driven „command-and-control“ management approach. Management decides product priorities, implementation strategies, plans, and even specifications with limited engineering participation, reducing engineering teams to order takers.
Mandatory process models like the Scaled Agile Framework (SAFe) support this approach. A survey by “The Pragmatic Engineer” blog shows industrial companies prescribe development methodology more often than big tech.
This approach has consequences: Aligning resources across multiple teams requires complex and usually longer planning cycles. Engineers with a limited understanding of the market, problems, and products may create solutions that fail to satisfy customers, resulting in the need to redo the work. The matrixed specialist team approach requires frequent context switching for developers, which has been shown to reduce implementation speed and increase error rates. Matrixed resources alsoamplify technical dependencies between components and increase development time and project risk.
Tech Companies: Mental Model „Software Unlocks Value„
Typical „Tech“ companies approach software development from a business problem-solving perspective. In their mental model, software is created to solve a business problem or „get a job done“ with the aim of creating more value.
In these environments, a team (or a group of teams) is typically assigned to solve one problem or go after one opportunity. Engineers and developers are encouraged to come up with their own solutions to it within the constraints agreed upon and continuously negotiated with Product Management. To do so effectively, they typically have direct access to „the business“ and its data and metrics. Product Managers and other business staff interact with development teams without intermediaries and vice versa. Engineers from different groups also communicate directly if required. Communication via a management layer is regarded to be unusual.
In tech companies, development teams are usually perceived as assets and are often treated almost like profit centers.
Also, development teams receive the necessary support to focus on their job regarding tooling and infrastructure. In the digital industry, it is common for companies to create an enabling technology and tooling architecture that provides a high level of support for product development. Tech companies even invest in dedicated resources focusing on infrastructure, APIs, and DevOps tools to support product development.
This is often amplified by the presence of strong CTOs who actively shape these digital infrastructures‘ architecture. Amazon’s Werner Vogels, Microsoft Azure’s Mark Russinovich, or Basecamp’s David Heinemeyer-Hansson would immediately come to mind.
Unlike industrial companies, big tech companies usually do not mandate a particular development method. Teams are expected to choose or develop their own way that suits the problem, context, and experience.
As a result, tech companies‘ engineers are typically facing less overhead and, consequently, appear less overloaded and able to focus on their tasks. In fact,some companies actively try to ascertain a certain amount of what was dubbed „headroom“ at, e.g., eBay. Google’s widely quoted 20% rule, leaving engineers effectively one day per week to develop their own ideas, may have been extreme. Still, it highlights the concept of leaving engineers space for problem discovery and problem-solving.
My personal experience underscores this difference: When I was working with a German engineering company that was in dire straits at the time, I went to talk to the head of R&D to find out if he knew of any „skunkworks“ projects or even raw ideas somewhere in engineers‘ drawers that might help us out. His answer was clear: there weren’t any because the engineers had no spare capacity to come up with them. I was shocked. A beer or dinner with an engineering manager at one of the tech companies I worked for always revealed some ideas for product improvements or even half-baked new products.
This results in a measurable difference: in research by MIT/Sloan and Glassdoor, typical tech companies display a significantly higher degree of „business agility,“ (defined as the ability to „…respond quickly and effectively to changes in the marketplace and seize new opportunities“) correlating with if not causing a significant difference in their scores for innovation.
Project Management v Product Management
These mental model and approach differences become even more apparent how projects are organized.
Industrial companies tend to think of software in projects, while tech companies typically manage products.
Projects, by definition, have a beginning and an end. Products continue until they deliver no– or only marginal value and are being „sunset.“
(To get this out of the way: there’s a load of „engineering project management“ going on in Tech, but while sounding similar, I perceive it to play a different role.)
Again, the industrial approach shines through. A project is set up to build or create something. Specifications and requirements are collected and decided upon at the start, and resources, required time, and costs are estimated. The project is then planned and implemented. At the end of the project, often regardless of outcomes, the result is rolled out and moves into a „sustaining“ or „maintenance“ mode where it is expected to see limited improvements or modifications, quite often in the responsibility of a completely different team.
This feels very similar to creating an industrial die-cast part. Dimensions and specs are collected. The casting mold is being made, tested against specification, fixed when necessary, and finalized. The mold moves to production, and parts are cast until the corresponding product is phased out.
This industrial model is also reflected in the typical industrial budgeting approach: there is a project budget for implementation. Maintenance of the project’s result is covered by a „maintenance“ or „run“ budget afterward.
Tech companies primarily create products that solve customer or business problems by leveraging digital technology to unlock value. If Product Management identifies a customer- or business problem as an attractiveopportunity, a product is developed and launched, provided the business benefit outweighs the expected resource requirements and technology risk.
In a competitive marketplace where technology constantly evolves, the product is continuously optimized to maximize customer and business value. This optimization process is a collaborative effort between the Product Manager, who develops and manages business objectives and constraints, the Engineering team who are responsible for technical realization (plus often a Designer optimizing the user experience.)
Product budgets are, therefore, continuous. Depending on strategic importance and business value, they will be adjusted over planning horizons. The constant visibility allows understanding and managing profitability (cost per generated value) and drives the dedicated development effort.
Conclusion
The above is a broad brush description of the differences between the Mental Models of Tech and Industrial enterprises and their impact on software development. The reality of companies obviously is more nuanced.
Working with industrial clients in mechanical engineering, I am also beginning to understand the challenges of integrating software and digital technology into large-scale mechanical engineering projects better. Developing effective working models to address these challenges is crucial. (There will be a WeekendReading that delves deeper into this topic and some of our learnings shortly.)
However, the power and impact of digital and particularly software technologies require a shift in mental models. Mechanical engineering and production are becoming rapidly digitalized. New challengers are approaching traditional industrial products with mental models shaped by the digital industry.
It is crucial that we recognize our mental models and adjust them to utilize the opportunities and the power of digitalization.
I have linked two articles by Gergely Orosz below that provide a more nuanced view of the working models of the digital industry.
What Silicon Valley „Gets“ about Software Engineers that Traditional Companies Do Not
Silicon Valley companiesunderstand some things that their counterparts fail to either understand or implement.
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
The summary and conclusions from Gergely Orosz’ survey of working models.
Big Tech differs in how they approach the execution of tech projects, compared to the rest of the industry.
Enjoy the – long, at least if you work in Germany – weekend!
All the best,
Godehard