Executive Summary
Nicki Todd argues that AI is shifting competitive advantage from possessing technical knowledge to exercising judgment, and that engineering organizations need both deep specialists and adaptive integrators to remain resilient. Drawing on nearly three decades of technology leadership and graduate research on distributed teams, she offers CTOs four diagnostic questions for evaluating their team composition.
Early in my career, I worked in customer service and was tapped to perform user acceptance testing for the migration of a green-screen application to the web. I knew the existing system well, what worked and didn’t, and where users had learned to compensate for its limitations.
The process operated with a 24-hour data lag. Rejected transactions were handled offline, so representatives had to collect extensive customer information upfront in case they needed to reestablish contact. Each morning brought what we called the “Reject Report Delivery,” someone walking through the department distributing the previous day’s failed transactions for follow-up. It was a daily walk of shame made necessary by the technology.
The engineering team could have recreated that process in a browser. Instead, our collaboration began with a different question: if we could access and validate information in real time, what would we no longer need to do?
That question changed the solution. We redesigned the workflow around confirmation rather than collection. Representatives could validate information while the customer remained on the phone, and the system retrieved additional data only when needed rather than loading everything in advance. We also resisted the temptation to reproduce every green-screen field and workflow. The primary interface contained only what every call required, with additional information available as the conversation demanded it.
The result was a less complex, uncluttered application that was easier to operate and teach. Customer-service feedback improved, escalations declined, and the Reject Report Delivery disappeared.
I was not an engineer at the time. I was a confident user who understood the work and was willing to imagine it differently. The engineering leader saw potential in that perspective and offered me a place in an upcoming Java bootcamp. Yes, that was a thing. Saying yes changed the next 30 years. I spent ten of them as an engineer, building and maintaining applications alongside the team whose customer I had once been.
That experience taught me something I have seen repeatedly throughout my career. Deep technical expertise is essential, but the strongest outcomes happen when specialists work alongside people who can cross boundaries, translate context, question inherited assumptions, and recognize when a new capability has changed the problem itself.
In the teams I have built and led since, I have come to think of these people as adaptive integrators. They are not generalists. They are people whose value comes from connecting what specialists know to what the organization needs to do.
AI makes that combination more important.
When Expertise Becomes an Assumption
Nearly three decades later, I encountered the same underlying challenge at a much larger scale. Our division needed a modern operating platform built around shared, production-grade capabilities, cloud-native infrastructure, and a workflow engine flexible enough to accommodate different client implementations.
Years of acquisitions had left us with overlapping, monolithic systems that were expensive to operate and difficult to secure. We needed to improve the company’s risk posture without jeopardizing critical business operations. Three previous modernization attempts had failed. Each treated the environment as an indivisible whole, assuming that because the applications were monolithic, the transformation had to be too.
We challenged that assumption.
Instead of beginning with the applications, we looked for the capabilities hidden inside them. Using a strangler-fig architecture, we separated common services, released them independently, and retired legacy applications one by one as their replacements proved themselves in production.
Over eighteen months, we:
- Retired five applications, with a path to retire seven more
- Completed more than 100 individual client migrations
- Expanded product capabilities through the new platform
- Maintained ongoing operations throughout
The objective was modernization without asking clients to absorb the risk of another all-or-nothing conversion. That required both the right technical architecture and the right team architecture. Engineers worked alongside product leaders, quality engineers, operations, and program managers, with roles expanding or receding as the work changed. We used dedicated engineering teams for burst capacity during the most demanding phases rather than permanently sizing the organization around a temporary transformation.
After three failed attempts, skepticism was reasonable. Confidence did not come from a more persuasive presentation or a larger transformation plan. It came from watching individual services reach production, clients migrate successfully, and legacy applications shut down. We delivered confidence in increments, just as we delivered the platform.
When Complexity Becomes a Conclusion
This is where expert consensus can become a risk. The experts correctly understood the complexity of the existing systems. The mistake was allowing that complexity to dictate the shape of the transformation. Knowledge of the monoliths had hardened into a conclusion about what could not be changed.
Experience told the organization that another modernization attempt would fail. Curiosity allowed the team to ask whether the previous attempts had failed because the problem was impossible, or because the approach had repeatedly concentrated too much risk into a single event.
Expertise helps a team identify constraints. Adaptability gives the team permission to test whether those constraints are still binding.
What My 2013 Research on Distributed Teams Still Reveals
That pattern, where expertise becomes difficult to question even when conditions change, is not unique to one transformation. It is a structural tendency in technical organizations.
In 2013, my graduate research examined communication within globally distributed technology teams. These were technically sophisticated teams with established development processes and collaboration tools. Yet significant failures still occurred because people operated with different assumptions, communication norms, cultural contexts, and interpretations of supposedly shared information.
Organizations had extensive practices for developing and releasing technology, but far fewer for creating shared meaning. Greater access to information did not necessarily produce greater understanding.
The research also examined the Mum Effect, the tendency to withhold or soften bad news because of hierarchy, cultural expectations, group harmony, or perceived consequences. That risk becomes particularly important when professional identity and organizational status are tied to expertise.
Who challenges the established expert? Who says the team does not know enough yet? Who recognizes that an architecture that worked for ten years may no longer fit the environment?
AI has made those questions more relevant. A recommendation can sound technically sophisticated while resting on the wrong assumptions. The risk is not only insufficient expertise, but an environment where expertise, human or AI-generated, becomes difficult to question.
This is partly a cultural challenge. But it is also a talent-composition question. If everyone on the team derives their authority from the same type of expertise, the organization has fewer people positioned to ask whether that expertise still applies.
AI Accelerates Capability but Not Understanding
An engineer can use tools like Cursor or Claude to convert code from .NET to Python faster than that engineer could independently become proficient in Python. AI changes the economics of technical knowledge and can shorten parts of the traditional learning curve.
As AI software development reshapes how teams access and apply technical knowledge, the competitive advantage shifts from what people already know to how quickly they can learn, adapt, and exercise judgment.
But it does not automatically make someone willing to use AI. It does not:
- Address legitimate concerns about quality, accountability, or job security
- Give a newly assembled team shared context about the business, the domain, or one another
In 2013, I wrote about the importance of giving teams time to form. Team members built trust, established shared language, understood one another’s strengths, and developed ways of working together. Those practices were not incidental to delivery. They created the conditions for it.
Today, team composition changes more frequently while AI creates an expectation that people should be able to get up to speed almost immediately. Instead of working through context together, we send someone a collection of documentation and expect that person to understand not only the work, but the assumptions, history, and relationships behind it.
AI makes information easier to transfer. That is not the same as transferring understanding.
What Shared Learning Actually Looks Like
I saw this distinction firsthand while leading teams through agentic product development. We brought remote engineers, quality professionals, and product leaders together, some meeting in person for the first time. The purpose was not only to teach new tools. It was to help people learn a new way of working with one another while every discipline’s role was changing.
The teams experimented together, made mistakes together, established guardrails, and became comfortable being vulnerable during a difficult transition. At first, we saw more experiments, more pull requests, more learning, and more mistakes. Over time, that activity translated into business outcomes, including faster remediation of technical debt and new tools that shortened the distance between technical work and realized business value.
We also had individuals and teams who did not participate in that shared experience. Although they had access to the same AI capabilities, their adoption and results did not progress at the same rate. This was not a controlled experiment, and I would not attribute every difference to bringing people together. But the pattern reinforced the earlier research. Tools can accelerate what people produce, but they do not independently create the trust, context, and shared meaning that allow a team to adapt together.
When Identity Shapes Adoption
The same tools can produce very different responses depending on how people define their value. Employees whose professional identity is closely aligned with a particular role or technology may experience AI as a threat to expertise they spent years building. Others, whose sense of contribution is less confined to a specific tool or title, may see AI as an expansion of what they can accomplish. Leaders must be prepared to support both responses while remaining clear that the work itself is changing.
Building the Right Talent Composition
The answer is not to replace specialists with generalists. Deep specialists provide technical mastery, pattern recognition, and domain expertise. They understand systems well enough to recognize when something is wrong and why a seemingly simple change may carry hidden consequences.
Strong technology organizations complement that depth with adaptive integrators, people who move between technical and business contexts, connect disciplines, translate meaning, surface assumptions, and learn quickly enough to remain useful as the environment changes. They may be engineers, product leaders, quality professionals, architects, operators, or people who entered technology through an unconventional route. What distinguishes them is how they create value across boundaries.
For CTOs and engineering leaders, four questions can reveal whether that balance exists:
- Depth. Do we have people who understand the technology deeply enough to recognize when something is wrong, including when an AI-generated answer only appears correct?
- Translation. Do we have people who can carry meaning among engineering, product, operations, business, risk, and customer contexts without reducing one discipline’s needs to another’s vocabulary?
- Adaptability. Do we have people whose organizational value is not entirely attached to the technologies, tools, or roles they already know?
- Challenge. Have we created enough intellectual and psychological safety for someone to question an expert, interrupt a consensus, or say that the assumptions have changed?
These capabilities are part of the organization’s technical resilience. AI lowers the cost of accessing expertise. It does not lower the cost of judgment. When answers become easier to produce, the ability to frame the problem, test assumptions, and ask a better question becomes more valuable.
The defining talent question for the AI era is not whether a team needs specialists or adaptable people. It needs both, deliberately composed and given the conditions to learn from one another.
If a major part of your technology strategy changed tomorrow, who on your team would help you master the new technology, and who would help you recognize that the problem itself had changed?
The resilience of your organization may depend on whether those are the same people, different people, or people you have not yet thought to invite into the room.
Key Takeaways
- Engineering teams built exclusively around deep specialization become fragile when conditions change.
- Strong organizations deliberately combine deep specialists with adaptive integrators who cross boundaries, translate context, and question assumptions.
- AI lowers the cost of accessing expertise but does not lower the cost of judgment.
- Tools can accelerate what people produce, but they do not independently create the trust, context, and shared meaning that allow a team to adapt together.
- The defining talent question for CTOs is whether their teams can recognize when the problem itself has changed, not just solve the problem as currently understood.
