Culture Through Tension: Leading Interdisciplinary Teams with Nick Gillian

What's New

Nick Gillian, co-founder and CTO of Archetype, recently appeared on the InfoQ Engineering Culture Podcast to discuss his approach to leading interdisciplinary teams. Gillian, who spent nearly a decade at Google leading machine learning teams and solving on-device sensing problems, now applies these lessons to building physical AI systems. His core thesis is that the most innovative teams don't avoid friction—they cultivate it.

Why It Matters

For engineering leaders building complex systems that span hardware, software, and AI, the traditional siloed approach often fails. Gillian argues that the gap between research and production, or between hardware and software specifications, is where most innovative projects die. By designing teams that embrace these tensions from the start, organizations can ship products that are both technically novel and commercially viable.

The interview reveals a practical framework for scaling engineering culture that moves beyond mission statements. Gillian defines culture as "the behaviors you amplify and the behaviors you tolerate," providing a concrete mechanism for maintaining alignment as teams grow from 20 to 100 people.

How to Use It: Building Teams Through Productive Tension

1. Start with Interdisciplinary Composition

Gillian's teams at Archetype deliberately mix disciplines: machine learning researchers, hardware engineers, designers, and software engineers work in the same sub-team. This contrasts with the typical waterfall approach where hardware teams spec and hand off to software teams, who then hand off to design.

Why this works: Different disciplines approach problems from fundamentally different angles. A hardware engineer thinks about physical constraints and manufacturing. A designer considers user interaction and communication. An ML researcher focuses on model capabilities and data requirements. When these perspectives collide in the same room, the solution space emerges from the intersection.

Practical implementation: Start with the smallest possible cross-functional unit—often 3-4 people representing each critical discipline. This allows rapid iteration through the "fog of war" where the product's true form is discovered through building, not planning.

2. Navigate Scaling Barriers with Process Evolution

Teams naturally hit communication barriers at specific size thresholds:

• ~20 people: Direct communication breaks down. You need lightweight processes—daily standups, clear sprint goals, and basic documentation.
• ~50 people: The 20-person process fails. You need more structure: dedicated Slack channels, formal review gates, and clearer role definitions.
• ~100 people: The 50-person structure breaks. Requires significant rigor: independent teams, architectural review boards, and formalized communication protocols.

Key insight: Each scaling barrier requires a step function in process, not incremental improvement. At each threshold, you must consciously redesign how information flows and decisions are made.

3. Implement the "Steel Cable" Architecture Approach

For managing ambiguity in product development, Gillian recommends a technique he used at Google and now uses at Archetype: building a "steel cable" through the system.

The metaphor: When building a bridge across a river, you first install the major pillars (API definitions, function signatures). Then you thread a steel cable through these pillars. This cable becomes the backbone that allows you to move materials and build the bridge around it.

Technical implementation:

1. Define the major components (3-5 key areas) and their interfaces
2. Mock each component so they can pass data—even garbage data—through the system
3. Allow parallel development where different team members work on different components
4. Iterate daily to remove ambiguity and refine the system

Example: For a multimodal AI system, you might define:

• Component A: Client input (camera/microphone data)
• Component B: Preprocessing pipeline
• Component C: Model inference
• Component D: Output generation (audio/visual)
• Component E: Response delivery

Each team can work on their component independently, knowing the input/output specifications. The "steel cable" is the data flow through these defined interfaces.

4. Guide Career Progression Through Four Stages

Gillian identifies a clear progression for individual contributors:

1. Doing good work: Executing assigned tasks well
2. Achieving results: Owning projects and delivering specific outcomes
3. Creating impact: Translating results into business value (e.g., "reduced GPU costs by 10X")
4. Wielding influence: Motivating teams without direct authority to pursue a vision

Common pitfalls: Engineers often get stuck between stages 2 and 3. They deliver technically excellent results but fail to communicate the business impact. The transition from results to impact requires strong soft skills: stakeholder communication, cross-team collaboration, and translating technical achievements into business language.

5. Amplify Behaviors, Tolerate None That Violate Culture

Culture isn't defined by slide decks but by daily behaviors. Gillian's framework:

• Amplify: Behaviors that drive innovation, risk-taking, and cross-disciplinary collaboration
• Tolerate: Nothing that violates core values

Practical technique: When someone oversteps, address it immediately but constructively. Instead of "Person X didn't do this," frame it as "We as a company aren't great at X. Wouldn't it be better if we tried Y?" This maintains psychological safety while correcting course.

Handling Ambiguity: Two Complementary Approaches

Team Composition Strategy

Interdisciplinary teams naturally handle ambiguity better because they bring multiple lenses to the same problem. The solution emerges from finding the intersection between:

• Engineering feasibility (how far can we push the system?)
• Design constraints (what user interaction is acceptable?)
• Research possibilities (what can the model actually do?)

The sweet spot is where these constraints meet. This requires designers and engineers to co-design from day one, not hand off specifications.

Architectural Abstraction Strategy

The "steel cable" approach provides structural clarity. By defining clear interfaces early, you:

• Decouple dependencies between team members
• Enable parallel development
• Create a framework for iterative refinement
• Reduce cognitive load by allowing teams to focus on their component

This works because ambiguity decreases as you build. The only way to understand what's possible with a new multimodal AI model, for example, is to build prototypes and observe emergent capabilities.

Trade-offs and Considerations

Pros of interdisciplinary teams:

• Better innovation through diverse perspectives
• Faster iteration with reduced handoff delays
• Higher product quality with integrated design and engineering

Cons:

• Requires individuals with T-shaped skills (deep expertise + broad communication)
• Can be slower initially as teams learn to communicate across disciplines
• Needs strong facilitation to manage conflicting priorities

When to use: Best for zero-to-one innovation, complex system integration, and products requiring tight hardware-software coordination. Less suitable for incremental improvements or highly specialized, narrow problems.

Real-World Application at Archetype

Archetype builds physical AI systems that fuse sensor data (cameras, microphones, radar, LIDAR) to perceive, reason, and act. Their team structure reflects Gillian's philosophy:

• Full-stack founding team: ML expert, sensing specialist, designer, and operations lead
• Interdisciplinary sub-teams: Each project team includes representatives from all disciplines
• Steel cable development: They mock system components early to explore capabilities
• Iterative discovery: They build prototypes to understand what's possible before defining the product

This approach allows them to navigate the ambiguity inherent in physical AI, where the intersection of sensor capabilities, model performance, and user interaction is often unknown until explored.

Key Takeaways for Engineering Leaders

1. Design for tension: Don't avoid friction between disciplines—structure teams to harness it
2. Plan for scaling barriers: Recognize that communication breaks down at ~20, ~50, and ~100 people
3. Use architectural patterns for team organization: The "steel cable" approach works for both systems and teams
4. Guide career progression explicitly: Help engineers understand the jump from results to impact to influence
5. Define culture through behaviors: Amplify what you want, tolerate nothing that violates core values

Resources

• Nick Gillian on LinkedIn
• Archetype - Physical AI company
• InfoQ Engineering Culture Podcast

Conclusion

Building innovative teams requires intentional design. By embracing productive tension between disciplines, implementing structural approaches to manage ambiguity, and guiding career progression explicitly, engineering leaders can create environments where complex problems get solved and products actually ship. The key is recognizing that culture is built daily through the behaviors you amplify and tolerate, not through mission statements on slides.

This article is based on the InfoQ podcast interview with Nick Gillian, co-founder and CTO of Archetype. Listen to the full conversation for additional insights and examples.