The art of leading teams where everyone is smarter than you in something.
You can’t out-expert your experts. So stop trying.
The longer I’ve led multi-disciplinary teams, the more I’ve realized that leadership in technology has almost nothing to do with technical mastery and everything to do with orchestration, creating the conditions where expertise stops competing and starts converging.
At Klika Tech, our projects don’t fit neatly into a single box. On any given day, a sole feature passes through the hands of embedded engineers, cloud developers, QA specialists, DevOps engineers, and front-end developers. Each discipline brings its own language, priorities, and definition of “done.”
When it works, it feels like conducting an orchestra: each section has its own sheet music, but the melody only emerges when everyone listens to each other. When it doesn’t, you can feel the static immediately, missed cues, competing tempos, brilliant solos with no rhythm between them.
The Meeting Where Everything Collided
Every manager has that meeting, the one that starts as a technical discussion and somehow becomes a philosophical standoff.
Ours happened during an integration sprint earlier this year. The embedded team wanted to push a firmware update to enable a new diagnostic feature. The cloud team pushed back: the telemetry pipeline wasn’t ready. QA warned about test coverage gaps. The mobile team reminded everyone that the UI mockups were already approved, and changes would ripple through the app.
It wasn’t a conflict for the sake of ego, it was six versions of “right.”
We spent the first fifteen minutes defending our perspectives. Then one of the front-end developers asked a question that stopped everyone cold:
“What’s the experience we want the user to have when something goes wrong with a charger?”
That eye opening question reframed the entire conversation. It shifted us from “Who’s right?” to “What’s right?”
We ended up redefining the release: firmware and cloud aligned on a minimal viable diagnostic path; mobile delayed a cosmetic feature to support error visibility; QA re-prioritized tests around failure modes. The deliverable changed, but the integrity of the goal didn’t.
That day reminded me that leadership in a multi-disciplinary team isn’t about forcing consensus, it’s about creating the space where the best idea wins, regardless of where it comes from.
Research on diverse teams confirms this: cognitive diversity leads to more innovative solutions, but only when teams have the psychological safety and structural processes to integrate those diverse viewpoints effectively.
Translating Between Worlds
Every discipline speaks its own dialect. Cloud architects speak in terms of latency and scalability. Embedded engineers talk in interrupts and firmware cycles. UI designers speak in interactions and flow. QA speaks in edge cases.
And somewhere in the middle sits the manager, translating, not to simplify, but to connect.
When the embedded lead says, “We need extra time to implement OCPP message queuing,” and the cloud lead hears “over-engineering,” the manager’s role is to bridge intent:
“They’re ensuring charging commands don’t get lost during network drops. Without it, users tap ‘start charging’ and nothing happens, they assume the app is broken.”
Context converts conflict into collaboration.
Patrick Lencioni’s research identifies inattention to results as one of the core dysfunctions that plague teams. When individuals prioritize their domain’s success over collective outcomes, even talented teams underperform. Effective translation creates a shared understanding of how individual contributions serve the broader goal.
When Expertise Becomes a Wall
The hardest moments aren’t when people disagree. They’re when everyone is silently convinced that “the other side just doesn’t get it.”
In these moments, the manager’s job is to translate curiosity into humility. I’ve learned to ask:
“Can you explain it to me as if I know nothing, because I probably don’t know enough?”
That question does two things: it disarms the expert, and it gives permission for others to admit what they don’t know. What follows is usually a small miracle; people start teaching each other.
That’s where alignment actually happens: not in long emails or dashboards, but in the ten minutes when someone sketches a concept on a whiteboard and another person suddenly says, “Ah, now I get why you were insisting on that!”
Amy Edmondson’s work on psychological safety demonstrates that high-performing teams create environments where interpersonal risk-taking is encouraged. When leaders model vulnerability by admitting their own knowledge gaps, they signal that learning is valued more than appearing competent.
The Value of Not Knowing
Early in my career, I thought credibility came from having answers. Now I know it comes from asking better questions.
Some of my best decisions started as questions that made me look uninformed.
Like when I asked a QA engineer why we needed to run a particular test suite for what looked like a trivial UI change. The answer led to discovering a hidden dependency in the data model that could have crashed production.
Or when I asked an embedded developer why a small firmware patch required so much retesting. That conversation revealed our QA scripts weren’t aligned with the new hardware behavior, and that we could automate half the work if both teams collaborated.
Ignorance, used deliberately, becomes insight.
Edgar Schein’s concept of humble inquiry, asking genuine questions driven by curiosity, builds trust and opens channels for authentic dialogue. This approach is particularly powerful in technical environments where the depth of knowledge varies dramatically across domains.
Decisions Without Borders
One of the most common questions I get: “How do you make decisions when every discipline has its own priorities?”
The honest answer, you don’t, at least not alone. You facilitate decisions.
We rely on what we call decision narratives, short, written justifications that capture the trade-offs we’re making. Not just the decision, but why it was made, what alternatives were considered, and what we’ll revisit later.
If an engineer joins six months later and asks why we chose a certain approach, the context is right there, no mythology, no defensive rewriting of history.
More importantly, it shifts authority from hierarchy to reasoning. You maintain authority through clarity, not seniority.
Michael Mankins’ research shows that good decisions made quickly beat perfect decisions made slowly. Decision narratives create the institutional memory that enables both velocity and coherence. Teams move fast because they understand the rationale behind past choices.
The Empathy Engine
Empathy gets a bad reputation in engineering circles, often mistaken for softness. But empathy is the most precise diagnostic tool a leader has.
When you understand why someone defends their position so strongly, you can negotiate with reality, not ego.
A firmware engineer resisting deadline pressure might be protecting device stability. A designer insisting on a color scheme may be defending accessibility. A QA refusing to skip a test might be shielding client trust.
Empathy lets you interpret resistance as information. And once you do, even hard conversations turn productive.
One of our cloud leads put it perfectly:
“When you understand that everyone’s fighting for something valid, collaboration stops being a tug of war and starts being choreography.”
When Non-Experts Change Everything
Breakthroughs rarely come from the deepest expert in the room. They often come from the curious outsider.
One of our best architectural simplifications came from a QA engineer who asked, “Why are we parsing the same JSON twice?” That question led to removing redundant code and saving thousands of API calls per day.
Another time, a front-end developer asked, “Can we just move that configuration logic to the back-end?” That suggestion triggered a redesign that now saves us hours of release overhead.
Expertise drives depth. Curiosity drives integration.
Research on innovation shows that boundary-spanning individuals, those who connect different knowledge domains, are disproportionately responsible for breakthrough ideas. Creating conditions where non-experts feel safe to question assumptions is how leaders unlock latent innovation potential.
Conducting Without a Baton
Every orchestra has a conductor, but the conductor doesn’t play a single instrument. They cue, adjust, balance, and step back.
Leadership across disciplines works the same way. You can’t master every instrument, but you can feel when something’s out of tune. You can hear when one section can’t hear another.
That’s when you pause the music. Not to lecture, but to listen.
You might not know how to play the solo, but you can ensure everyone is playing the same song. That’s technical leadership, less command, more connection.
Karl Weick’s concept of sensemaking describes how leaders help organizations interpret ambiguous situations. In multi-disciplinary environments, this orchestration function is critical, as different domains process information through different frameworks. The leader’s role is to create the interpretive frame that allows all disciplines to align toward a coherent outcome.
Where Harmony Lives
Cross-functional leadership isn’t neat. It’s constant negotiation between clarity and complexity, ego and humility, precision and pragmatism.
But when it works, when firmware stabilizes because QA anticipated edge cases, when cloud auto-scales smoothly because telemetry traffic spiked, when UX feels effortless because backend latency dropped, it’s something else entirely.
You can hear the harmony. You can feel the shared rhythm. And you realize that leadership didn’t direct that performance. It simply enabled it.
That’s what orchestration really means, not leading from above, but connecting from the middle.
Key Principles for Leading Multi-Disciplinary Teams
- Create space for the best idea to win, regardless of which discipline it originates from. Forcing consensus suppresses innovation.
- Translate between domains by reframing intent, not just repeating information. Context converts conflict into collaboration.
- Model humble inquiry by admitting what you don’t know. This creates psychological safety for genuine knowledge transfer.
- Document decision narratives that capture trade-offs and rationale. This shifts authority from hierarchy to reasoning.
- Interpret resistance through empathy to understand underlying concerns. What appears as an obstruction often reveals valid priorities.
- Value curious outsiders alongside deep experts. Boundary-spanning questions surface insights that specialists miss.
- Focus on orchestration rather than expertise. Your role is to ensure all sections hear each other, not to master every instrument.
Related Reading
If you found value in this article, you may also appreciate:
The Leadership Multiplier: Creating a Culture of Ownership Without Micromanagement
A reflection on how empowering autonomy multiplies performance across complex systems, featuring frameworks like OKRs, RACI, and Delegation Levels that transform well-intentioned managers into force multipliers.
Leading Through Priority Changes: Maintaining Alignment When the Map Keeps Redrawing
Lessons on maintaining team direction and morale through turbulent change, drawing on real experiences navigating shifting client priorities, resource constraints, and evolving technical landscapes.
References
- Edmondson, A. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace. Wiley.
- Lencioni, P. (2002). The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass.
- Mankins, M., & Garton, E. (2017). Time, Talent, Energy: Overcome Organizational Drag. Harvard Business Review Press.
- Schein, E.H. (2013). Humble Inquiry: The Gentle Art of Asking Instead of Telling. Berrett-Koehler Publishers.
- Weick, K.E. (1995). Sensemaking in Organizations. SAGE Publications.
- Wiseman, L. (2017). Multipliers: How the Best Leaders Make Everyone Smarter. Harper Business.
By Mohammad Shirazi, Portfolio Manager, Klika Tech