In this article, I argue that tech teams’ success depends not only on their technical skills but also on their ability to collectively build and refine theories about their work. Drawing from Peter Naur’s Programming as Theory Building, I will explore how shared understanding, tacit knowledge, and cognitive diversity contribute to resilient teams capable of delivering sustainable solutions.
Many tech teams struggle despite having talented individuals. They deliver initial solutions efficiently but falter when requirements change, key team members leave, or when they need to pivot. These failures often stem not from technical incompetence but from insufficient theory-building—the lack of a shared, evolving understanding that transcends documentation and enables adaptation.
The Theory-Building Nature of Technology Work
When Naur wrote about programming, he argued that the essential activity isn’t producing code but building a theory – a comprehensive understanding of how real-world activities map to computational solutions. This applies broadly across technical disciplines, where teams must:
- Develop a shared understanding of business contexts and user needs
- Translate domain knowledge into technical approaches
- Make countless implicit decisions about implementation and design choices
The most valuable asset a tech team creates isn’t their code or products but their collective theory about the problem space and solution approach. This theory transcends documentation and enables the team to evolve solutions as requirements change.
The Hidden Power of Tacit Knowledge
Much of what makes technical professionals effective can’t be articulated. As Michael Polányi observed, “we know more than we can tell.” In technical work, this tacit knowledge includes:
- Intuition about which approaches might be effective
- Recognition of patterns that suggest specific implementation strategies
- Understanding the limitations and applicability of different technologies
- Awareness of how to interpret unexpected results
This tacit dimension explains why teams with identical technical skills can produce vastly different outcomes. The best teams develop ways to share and build upon tacit knowledge, often through close collaboration rather than formal documentation.
Given that much of a team’s expertise remains tacit, it’s no surprise that multiple valid solutions exist for the same problem. This brings us to a key idea from philosophy of science: the Quine-Duhem thesis.
The Quine-Duhem Thesis in Technical Work
The Quine-Duhem thesis in philosophy of science suggests that data underdetermine theories. Multiple theoretical frameworks can explain the same observations. Similarly, multiple valid solutions can address the same technical requirements.
This underdetermination means:
- Different architectures can satisfy the same functional needs
- Various implementation approaches can achieve similar performance characteristics
- Multiple technical paradigms can solve identical business problems
When a team selects among these equally valid alternatives, they’re not just making technical choices but expanding their collective theory. The choices reflect unstated values, priorities, and mental models that become part of the team’s shared understanding.
These different solution paths highlight why diversity of thought is crucial in technical teams, leading us to the team composition paradox.
The Diversity Paradox
My biggest lesson about building tech teams is that homophily—the tendency to connect with similar people—is powerful and dangerous.
Teams of like-minded people with similar backgrounds communicate effortlessly and move quickly. When team members share similar education, experience, and mental models, they can almost finish each other’s sentences. Development accelerates as shared assumptions don’t need validation.
Yet these same teams can have identical blind spots. Without differing perspectives, critical assumptions go unchallenged. The team’s shared theory might fit their collective worldview perfectly while missing crucial aspects of reality.
The Necessity of Cognitive Diversity
My solution has been surprisingly straightforward: build teams with diverse backgrounds. The most productive teams I’ve worked with have included software engineers and people with backgrounds in sociology, economics, physics, cognitive psychology, biology, etc.
I’ve witnessed this principle in action repeatedly. Once, I worked on an enterprise search problem with exceptionally talented developers. We leveraged everything Solr and its ecosystem could offer to an online shop. But we completely missed that this was when internet traffic was rapidly shifting to mobile devices. What we thought was a sophisticated search problem was an information architecture issue requiring a simple predictive input solution. Our homogeneous expertise blinded us – we had hammers, so everything looked like nails.
In stark contrast, when we needed to pivot our startup, a small team of six people (four technical) with diverse backgrounds could ideate, implement proofs-of-concept, and test ideas within just a few weeks. The cognitive diversity allowed us to see multiple paths forward when change became necessary.
This diversity brings several advantages to theory building:
- Multiple theoretical frameworks that can be integrated or contrasted
- Different approaches to problem decomposition
- Varied tacit knowledge that wouldn’t otherwise be accessible
- Alternative vocabularies that force explicit articulation of concepts
In my data science teams, the friction that results when a physicist approaches a problem differently than an economist or when a sociologist challenges assumptions about user patterns leads to more robust theories and solutions.
Including Stakeholders in Theory Building
Users, clients, and other stakeholders aren’t just sources of requirements or obstacles to overcome. They’re essential participants in the theory-building process.
When stakeholders actively participate, several benefits emerge:
- The team’s theory encompasses the actual business context
- Regular exposure to users tests whether the team’s understanding corresponds to reality
- Stakeholder interaction facilitates tacit knowledge transfer that requirements documents can never capture
- Solutions address genuine needs rather than the team’s interpretation of those needs
Treating stakeholders as collaborators rather than just clients transforms potential friction into productive theory refinement.
The Time Investment for Diversity
One significant trade-off to acknowledge is that diverse teams initially take longer to reach full productivity. There’s a period where the team must:
- Develop a shared vocabulary
- Make tacit knowledge more explicit
- Reconcile different approaches to problem-solving
- Establish communication patterns and trust
This relates directly to Naur’s theory-building process. Constructing a collective theory that incorporates diverse perspectives naturally takes longer than when team members already share mental models.
Long-Term Resilience and Adaptability
However, this investment pays substantial dividends. Diverse teams demonstrate:
- Greater resilience when facing unexpected challenges
- Superior ability to pivot when business contexts change
- More robust solutions that consider broader perspectives from the start
- Continuous theory evolution that keeps pace with changing requirements
While homogeneous teams might deliver initial results more quickly, diverse teams build theories that remain viable longer, especially when facing uncertainty or change.
Isn’t This Just Teamwork with Extra Steps?
Some may wonder whether this theory-building perspective is simply a fancy way of saying teamwork is essential. While teamwork is widely recognized as crucial, theory-building goes beyond collaboration—it involves constructing a shared epistemological framework that allows the team to evolve its solutions over time.
Standard teamwork approaches focus on communication, task allocation, and conflict resolution. Theory-building, by contrast, centers on how knowledge is collectively constructed, held, and evolved. It explains why documentation alone fails to transfer project understanding, why team members leaving can devastate projects despite extensive handovers, and why some teams adapt to change effortlessly while others struggle.
This perspective shifts how we think about team activities:
- Code reviews become opportunities to align theories, not just verify code quality
- Technical documentation serves to trigger knowledge reconstruction, not contain it
- Cross-training becomes essential for theory resilience, not just operational continuity
- Diverse perspectives are valued for epistemological reasons
Conclusion
Building effective tech teams requires balancing immediate delivery pressure with long-term resilience. By viewing teams through Naur’s theory-building lens, we can better understand why diversity produces more robust solutions despite its initial cost in time and communication effort.
The strongest technical teams aren’t those that can implement technologies most efficiently but those that collectively build comprehensive theories that connect business needs, user contexts, and technical possibilities. These theories, built from diverse perspectives and constantly refined through stakeholder engagement, enable teams to create solutions that truly matter.
The best tech teams don’t just build software—they build theories that stand the test of time. The question isn’t just how well your team codes but how well they think together.
Leave a Reply