Are You Leading a Team, or Just a Group of Experts?
We all want a team of rockstars.
We spend months recruiting principal engineers, hoping that bringing top-tier talent into the same room will automatically translate into outlier results.
But there is a trap here that many engineering leaders fall into: we confuse a group of brilliant individuals with an actual, functioning team.
If you have a strong group of experts who merely act as individual task forces—working in silos and focusing solely on delivering their own tickets—you are leaving immense potential on the table.
A true team doesn’t just deliver individual outputs; they amplify each other, challenge one another, and solve cross-domain problems fluidly.
The hardest part? The biggest bottleneck preventing this transformation is often the leader.
The True Full Stack: A Recipe for Imposter Syndrome
A year ago, I took on a new challenge: leading Platform Engineering. I inherited a 40-50-person organization split across four very distinct domains with almost zero overlap:
Frontend Infrastructure: Micro frontends, design systems, maintaining React and Node versions, and E2E testing.
Backend Infrastructure: Auth and user domains, notification pipelines, Java templates, internal libraries, file processing and other backend-platform solutions.
DevOps: Cloud infrastructure, observability, cost management, CI/CD, and the service catalog.
Orchestration: Connecting services into groups and controlling the complex flow of information between them.
Managing that was quite a challenge. It is simply impossible to hand down tasks, orders, and requirements to such a wide, specialized group.
While I felt deeply knowledgeable in the frontend space, whenever I sat down to plan DevOps or backend infrastructure, I hit a wall of imposter syndrome again and again.
I was drowning in endless tasks and clashing priorities until I had a crucial realization: my job wasn’t to manage these teams independently.
The engineers already knew their domains vastly better than I did. But what I had, which they didn’t, was the big picture.
My work wasn’t to dictate their individual steps; it was to combine their expertise.
Finding the Connecting Tissue
We started simple. I introduced a weekly 30-minute “infra leadership” catch-up for my domain leads to talk about what was happening in their respective areas.
For the first few weeks, I essentially acted as a router, actively facilitating the connections.
I would point out overlaps: “Look, we are working on something similar from different sides. Backend infra is reworking authorization, frontend infra is migrating the sign-up UI from Angular to React, and DevOps is managing a separate instance of the observability platform just for auth-related events.”
Over time, something clicked.
Today, while each of our teams still has domain-specific challenges, at least half of our active initiatives are cross-cutting objectives. The silos have broken down, leading to incredible synergies that I could never have tied together alone:
Frontend engineers are providing infrastructure for backend devs, enabling them to create back-office UIs independently.
DevOps is building scaffolds for backend and frontend templates, with the definitions driven directly by the front-end/back-end engineers.
The backend team is working directly with DevOps to build alerts-as-code infrastructure.
Frontend and DevOps are collaborating to build hosting capabilities for vibe-coded apps.
These projects weren’t dictated from the top down. They were initiated by the infra leadership group we established just a few months prior.
We don’t manage individual tasks anymore; we manage high-level initiatives and objectives that are no longer limited by domain boundaries.
The “Missing Leader” Test
How do you know if you have successfully transformed your domain experts into a cohesive unit?
Try running your leadership team through this simple self-assessment:
The Two-Person Test: If you ask two of your domain leaders/engineers to collaborate on a problem, do they talk freely and figure it out? Or do you need to be in the room to moderate the discussion and connect them?
The Prioritization Test: When priorities clash between two domains, do they negotiate a solution together, or do they escalate it to you, expecting you to act as the ultimate judge?
The Absence Test: If you missed your weekly team meeting, would they still connect, share context, and unblock each other? Or would the conversation fall apart and the meeting be canceled?
Make Yourself Obsolete
If your team relies on you simply to communicate with one another, they aren’t a team yet—and you have more work to do.
Our primary goal shouldn’t be to insert ourselves into every decision or to act as the ultimate taskmaster for deeply specialized experts.
The goal of an engineering leader is to build a team so cohesive, resilient, and aligned that, eventually, you become completely unnecessary to their day-to-day operations. Only then can you step back and focus on the future.
Supplemental reads
Here are the top frameworks and materials to help you build team out of strong individuals: