How AI Is Changing the Way We Structure Engineering Work – and How It Shouldn't
In a Nutshell
AI amplifies existing organizational patterns—good or bad—rather than fundamentally changing team structure principles. Organizations succeeding with AI focus on end-to-end value flow and managing cognitive load, while those treating AI as a code-generation tool will fail and revert to 1990s practices. Team Topologies remains the core framework; AI's real value lies in detecting interaction failures, harvesting shadow innovations, and enabling teams to act as better stewards of their domains.
These notes were generated by AI and may contain inaccuracies.
Blueprint Plus Plus is a webinar series interviewing leading thinkers at the intersection of technology and business. The series focuses on trends in software development and AI, along with best practices helping enterprises achieve better results. This particular webinar was pre-recorded but features live chat interaction for questions.
Mish Evink, VP of Business Development at JetBrains, has spent the last 13 years working with JetBrains to change the lives of software developers.
Matthew Skelton, author of Team Topologies, joins the webinar. The book was first published in 2019, with the second edition released in September 2025. The second edition includes 10 case studies from organizations worldwide applying the ideas successfully.
Team Topologies provides a blueprint and set of principles for organizing capabilities, skills, and technology within organizations in the context of fast flow of value. The patterns emerged from the DevOps movement and software delivery in the 2010s. The ideas evolved between 2013 and 2018 during the book's writing period.
High-velocity software delivery solved problems in organizational operating model space. People building software think about boundaries and interfaces, which apply valuably to organizational operating models. The patterns were initially experimented with in software delivery and have since been applied outside of IT and software delivery.
The framework includes terminology and types of teams, types of team interaction modes, and a mindset for deciding how to use technology to enable value delivery. Team Topologies applies to knowledge work in general.
AI is amplifying existing practices, whether good or bad. A bad approach involves AI generating millions of lines of code that no one understands, then passing it to a separate testing team. This represents a return to 1990s practices and fails to focus on actual value delivery.
A Goldman Sachs report released days before the webinar indicated AI added almost nothing to the US economy in the previous year, serving as a warning sign that AI usage in organizations lacks focus on value and is being used as a "shiny new toy" in some cases.
Good uses of AI align with Team Topologies principles: end-to-end value flow with teams as stewards of that value flow, and managing cognitive load. Organizations thinking about value flow and empowering teams will succeed with AI, while those focused only on generating lots of code will fail.
Cognitive load itself is neither good nor bad. The distinction lies between cognitive load related to the team's mission versus extraneous cognitive load. A banking payments team needs to understand reconciliation and the SWIFT international banking system - this represents valuable cognitive load. They should not need to think about configuring deployment tools or collecting application logs.
AI can help by shortening time to incident understanding for engineers building products, or by handling heavy lifting around refactoring or insights about older codebases. The focus must remain on empowering teams to be good stewards of their domain or product.
The shift from developer productivity to developer experience mirrors AI considerations. Optimizing for lines of code or features delivered leads to developer burnout and unsustainable systems. Developer experience designs the entire system to be sustainable rather than maximizing a single throughput metric.
Most organizations would benefit from writing as little code as possible. More code increases attack surface area and vulnerability risks, while making maintenance, reshaping, validation, and attestation more difficult. This applies particularly to regulated industries.
AI can prototype different scenarios and run them against synthetic users to gather data about what users actually want. This helps organizations focus only on truly valuable features rather than building unnecessary functionality.
JetBrains invests in unifying developer experience within a single IDE (IntelliJ and others), integrating tools, AI agents, and models from different providers. This reduces context switching costs and cognitive load for developers.
Having all development tools integrated inside a single IDE makes sense rather than requiring developers to coordinate multiple small tools. This creates a single space for developers to work, understand, and reason about their work.
Different AI models bring different biases and generate different solutions. Five or six different potential solutions can be generated for a problem, then assessed using additional tooling from multiple perspectives including code base health, coupling, changeability, dependencies, and readability.
This assessment connects code-level decisions to business stakeholders like COOs and CFOs who care about financial and operational aspects of implementation choices.
Two camps exist regarding monoliths: enterprises moving carefully and slowly with AI assistance, versus startups and SMBs favoring complete rewrites from scratch. Domain-driven design concepts from Eric Evans' 2004 blue book remain relevant and become more important when integrating AI systems.
LLM-based AI risks coupling different concepts that look similar in tokens but are actually different, potentially losing domain fidelity. AI can help summarize and detect aspects of codebases that humans might miss, including relationships between code and teams, and coupling patterns.
AI expands what groups of people can accomplish, helping them become better stewards of products or services. However, some organizations are shrinking team sizes because they believe fewer engineers are needed with AI assistance.
This creates danger of losing diversity of perspective and experience, resulting in blinkered solutions. Organizations assuming AI systems provide neutral or diverse perspectives are mistaken, potentially losing innovation capability.
The four team types in Team Topologies are:
- Value stream aligned teams
- Enabling teams (building capabilities for other teams)
- Specialized complicated subsystem teams
- Platform teams (building platforms providing APIs)
AI can be used across all team types, with some organizations already implementing this approach.
AI-enabled tooling can pull together multiple signals across an organization including Slack messages, Teams messages, code repositories, Jira tickets, and ServiceNow data to flag problems much sooner than traditional approaches. These tools can identify when 17 teams are struggling with the same issue, enabling enabling teams to detect problems more rapidly and cluster similar issues together. The systems can perform upfront analysis including sentiment analysis and word clustering to determine that teams are discussing a problem in ways suggesting they don't understand it, allowing enabling teams to target interventions more quickly and precisely.
Platform teams must detect when capabilities that should be consumed as services are no longer functioning that way. When stream-aligned teams repeatedly go back and forth via email, Jira tickets, or Slack messages asking platform teams how things work or why parameters don't function properly, this indicates the interaction has shifted from service consumption to collaboration mode. The team topologies framework emphasizes listening for this signal and making the shift intentional. AI can detect these patterns and suggest flipping into collaboration mode for two or three days to work through issues, after which the service can hopefully be consumed again as intended.
Enabling teams that bring new capabilities to stream-aligned teams are often perceived as disruptive or as know-it-all experts coming to teach others. Significant work is required to integrate enabling teams so they deliver real value and help developers build capabilities. A critical moment occurs when the enabling team departs after capability development is complete, moving on to enable other teams. The industry faces the challenge of creating safe environments for enabling teams to develop capabilities effectively.
People in enabling teams should be experts bringing substantial expertise, but expertise often comes with ego that can feel toxic to stream-aligned teams. Enabling team members need training on how to effectively facilitate and share expertise in ways that get adopted. Success criteria for enabling teams should focus on how rapidly and extensively their ideas are adopted by other teams. If other teams aren't adopting new ideas about cloud scaling, automated compliance, or other capabilities, the enabling team bears responsibility for making their offerings more compelling.
When platform capacity becomes insufficient, stream-aligned or complicated subsystem teams may create their own platforms or purchase external solutions to deliver value faster. This scenario appears problematic in large organizations where multiple initiatives duplicate efforts because teams closer to customers won't wait for central platforms. Banks may have 70 different implementations of something that ideally would have only two or three versions. However, this duplication isn't necessarily problematic at scale, as distributed innovation helps discover good patterns quickly when technology, compliance, and markets change rapidly.
Organizations lack organizational scanning and innovation diffusion capabilities to identify good implementations, spotlight them, help builders share their approaches appealingly, and create friendly FOMO so other parts of the organization adopt superior versions. The harvested innovations can then become platforms. This creates a virtuous cycle with innovation at the edge, harvesting into central platforms, and operationalizing services to make them more consumable and scalable. All innovation doesn't need to originate in platform areas initially—it can happen outside and be brought in, but this requires intentional dynamics that many organizations lack.
The concept involves shadow IT, shadow AI, and shadow innovation, with frameworks needed to elevate successful innovations to become organizational standards. This increases velocity of beneficial practices moving through organizations systematically.
AI doesn't fundamentally change team structure considerations. The core mental model remains how to empower groups of people to be good stewards of value delivery on an ongoing basis. The additional element involves finding outstanding team achievements, promoting them, helping teams tell their stories, and helping others see effective practices. This requires active knowledge diffusion across organizations, which most don't implement. Organizations need active approaches to sharing knowledge and diffusing innovation, being honest about how actively they seek good practices and innovation, share them, and create conditions for other teams to adopt them.
All organizational changes must be designed, including team topology, communication processes, innovation processes, and internal conferences. Evolution happens regardless, but without intentional design, organizations lose control over direction and outcomes. The framework requires structure and interactions between teams plus active knowledge sharing and innovation diffusion across the entire organization.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
