Adapting to AI: Adapting Organizations

I have been writing a series of essays on how the software industry is adapting to AI. My first essay reflected on AI and productivity and I tried to capture some of the uncertain feelings of this liminal time. The second essay focused on challenges in reviewing code, especially in regulated industries or critical infrastructure. The third looked at the impact of AI on software engineering through the lens of Dave Farley’s book on modern software engineering, and the fourth was about the importance of writing things down.

In this essay, I will explore perhaps the most difficult question: How do we adapt organizations to take advantage of AI? AI doesn’t change the fundamentals of organizations—it scales them. If an organization is already struggling with communication, quality, execution, or leadership, adopting AI will magnify these sociotechnical challenges exponentially. On the other hand, organizations built around exceptional systems thinkers and design thinkers—organizations with excellent communication, quick feedback loops, first-principles engineering, and excellence in the social aspects of engineering and operations—will drastically outperform all others.

Product, Program, and Project Management

When the development of software was viewed as a bottleneck, many organizations created roles to support the management of software, including product, program, and project managers, in order to keep software teams focused on development.

When I began my career twenty-five years ago, we didn’t have any of these roles, and neither did our customers.^[1] The engineers worked directly with customers, iterating together on a regular basis. The engineers were responsible for managing projects and the overall success of the products and programs, even for very large initiatives. Many of the most successful engineering and product-driven companies never deviated from this approach.^[2]

With software engineers now spending less time typing code,^[3] I expect software engineers will again be responsible for the management aspects of the work and there will be only a small number of people in dedicated management roles. Those who remain will be exceptional leaders focused on the largest, most complex, and most critical projects, acting as a facilitator, a chief of staff, or a product owner. They will drive important decisions, connect decision makers, solve problems, capture information, facilitate the flow of information, work across teams, work directly with customers, and refine communication.

Feedback Loops

Another way organizations attempted to scale software development was by creating separate teams for testing and operations.^[4] If a software developer hands their work off to quality assurance to write automated tests or run manual tests, and quality assurance hands their work off to an integration testing team to test across components and services and integrate with hardware, and the integration testing team hands their work off to a deployment team to install or update the software, and the deployment team hands their work off to an operations team to run the software, the quality of the product will suffer. Ownership and accountability are diffuse. People won’t even see the opportunities for improvement across the system. In addition, the testing, deployment, and operations teams will end up building their own auxiliary software and processes that would be unnecessary if they were addressed at the source, and CI/CD will be immature because the hand-offs encourage a narrow view of the entire process.

Current AI tools do particularly well when they can “taste the soup” and evaluate their own work. It is impossible to do this when there are many hand-offs between teams, and the feedback loops are indirect and take far too long. We know from the DORA reports that end-to-end ownership with minimal hand-offs leads to faster deployment frequency, shorter lead time for changes reaching production, and faster detection and recovery when problems occur. It is a predictor of overall team performance. Organizations that have tight feedback loops through a combination of CI/CD and a “you build it, you run it” ownership philosophy are far better positioned to take advantage of AI.

Amplifying the Wrong Feedback Loops

I have seen more than a few people get excited about working closely with product managers to quickly turn requirements into code. While I understand the temptation, this is a distraction. Inevitably, a good number of those requirements will be wrong.^[5] What really matters is not the time it takes to write code but the time it takes to reliably get new functionality into the hands of customers, evaluate it, get feedback, and iterate. If you are already struggling with slow or unreliable builds, testing bottlenecks, quality issues, poor abstractions, a lack of metrics and monitoring, unreliable deployments, configuration management, an inability to fix-forward, too many hand-offs among teams, cross-team coordination, bureaucratic approvals, trust between teams, communication issues, data governance, or any of the other common issues that hold organizations back, quickly turning requirements into code with AI is optimizing the wrong part of the process. AI is only going to amplify these organizational dysfunctions. More code isn’t necessarily more value, but it is definitely more liability. If you have any of these challenges, do not invest in creating more code faster, invest in tighter feedback loops, focusing on processes that dominate cycle time, and anything that is impacting reliability.

AI increases the demand for coordination work but doesn’t reduce the costs of coordination work. Watch for coordination challenges to increase in the near future.
—Lorin Hochstein

Systems Thinkers and Conceptual Integrity

To solve sociotechnical challenges, you need systems thinkers who see across the organization, work directly with customers, think holistically about the product and projects, consider the present and the future, maintain a north star, and focus attention on the greatest challenges of the organization.^[6]

With AI making our ability to solve technical challenges easier, Jensen Huang believes this will reshape our definition of smart:

I know what people are thinking. The definition of smart is somebody who’s intelligent, solves problems technically, but I find that’s a commodity now. We’re about to prove that artificial intelligence is able to handle that part easiest...It turns out that definition of smart is very different than most people think. I think long-term, the definition of smart—and my personal definition of smart—is someone who sits at that intersection of being technically astute but having human empathy, and having the ability to infer the unspoken, around corners, the unknowables. People who are able to see around corners are truly, truly smart. And their value is incredible—to be able to preempt problems before they show up just because you feel the vibe. And the vibe came from a combination of data analysis, first-principles thinking, life experience, wisdom, sensing other people. That vibe—I think that’s smart.
—Jensen Huang

Intuitive systems thinkers draw abstractions, they see the whole not just the parts, and they anticipate what is possible beyond what is material. However, intuitive systems thinkers make up a very small percentage of the overall population—on the order of one in ten people.^[7] Most people think much more concretely. Don Norman, in the book The Design of Everyday Things, a book about design and systems thinking, says, “It is the conceptual model that provides the true understanding.” Furthermore, he writes, “The lack of clear communication among the people and organizations constructing parts of a system is perhaps the most common cause of complicated, confusing designs.” Lots of concrete thinking, aided by AI, without systems thinkers to maintain the conceptual model, will erode the integrity of the product and of the human organization itself.^[8]

Systems thinkers—the critical thinkers trying to maintain conceptual integrity by teasing out the right abstractions, weighing trade-offs, building personal relationships, fostering collaboration, writing things down, thinking about the whole system—including the reliability, sustainability, security, scalability, and integrity over time, not just the immediate goals—can seem like some of the hardest people to work with. It is a lot easier to work with someone willing to “turn features into code” with a quick and dirty solution, or to even do this yourself aided by AI.^[9] If you are not a systems thinker, you will not appreciate the difference—the debt the organization is now burdened with, the impact on the product from the erosion of conceptual integrity, the cognitive burden now imposed on support teams and customers,^[10] the waste from a duplication of effort, the regulatory risks from gaps in data governance, and so much more. Don Norman writes, “Designers need to focus their attention on the cases where things go wrong, not just on when things work as planned.”

Engineering Will Be More Social

To achieve an organizational focus on systems thinking, product ownership, feedback loops, and conceptual integrity, it is inevitable that engineering will be a more social enterprise than it has been for many people in the past. Some software organizations valued the introverted programmer who worked alone, disliked social interactions, communicated poorly, and lacked attunement, as long as they produced valuable code—sometimes the most valuable code. But the value of this role will be significantly diminished with AI writing more of the software and the role of the software engineer shifting to put even more emphasis on communicating, collaborating, aligning, strategizing, managing, and working with end-users of the software.

Some people will read this conclusion and realize what is old is simply new again. Many highly effective software teams have embraced this style of working for decades.^[11] Kent Beck popularized Extreme Programming in the 1990s which valued managers, customers, and developers all working as equal partners in a collaborative team. Extreme Programming put an emphasis on communication and quick feedback, including pair programming, test-driven development, refactoring, and iteration directly with the customer. Others extended these ideas to team programming, a collaborative software development approach where the entire team works together on the same task, enhancing teamwork and knowledge sharing, and allowing all members to contribute simultaneously to the design, development, and testing process.

Software engineering is empirical, experimental, iterative, and incremental. Many would argue the social methods of software engineering have always produced the best outcomes.^[12] With AI, I expect this to be the dominant way of working.

Conclusion

We have seen dramatic shifts in organizations before: the industrial revolution, the assembly line, computing, robotics, and the internet all changed the nature of work and how we organize labour. Two hundred years ago, most people were involved in agriculture in one form or another—now very few are. Fifty years ago, almost no one used a computer to do their job—now most people use one as a primary tool every day. What is different with AI is how rapidly this transition is happening. Organizations that excel at systems thinking, value conceptual integrity, demand end-to-end ownership, establish excellent feedback loops, and embrace the social aspects of engineering are poised to take full advantage of AI. For the rest, AI will only amplify existing organizational challenges.