Leading 200 Teams Without Managing a Single One
I have never had a single direct report on most of the largest programs I have led.
No hiring authority. No performance review leverage. No org chart that says anyone owes me anything. And yet, over the past several years, I have led programs spanning 200+ engineering teams, touching thousands of production services, and delivering outcomes measured in hundreds of millions of dollars.
I am a Technical Program Manager. My job is to drive execution across organizations where nobody reports to me, priorities constantly compete, and the work is too complex for any single team to own end to end.
If you are a staff engineer, a tech lead, or an engineering manager trying to influence beyond your immediate team, the lessons I have learned might save you years of frustration.
The myth of authority
Early in my career, I believed that leadership required authority. To get 200 teams moving in the same direction, someone with a big enough title had to tell them to do it. I was wrong.
I learned this the hard way on my first truly large-scale program. We were driving a company-wide operational transformation that required every engineering team to change how they owned and operated their services. The executive sponsor kicked it off with a clear mandate. Within three weeks, adoption had stalled. Teams nodded in meetings and then went back to their backlogs. The mandate had created compliance theater, not real change.
What turned things around was not more authority. It was making the work make sense to each team on their own terms. That required something harder than issuing directives. It required understanding 200 different contexts well enough to show each team why the change mattered to them specifically.
Start with the incentive map, not the project plan
Before I build a single roadmap or milestone tracker, I build what I call an incentive map. For every major stakeholder group, I answer three questions:
- What do they care about most right now?
- What is making their life painful today?
- How does this program either help with that pain or risk making it worse?
On a recent infrastructure program that required migrating hundreds of services to a new regional deployment, the platform teams cared about automation coverage. The product teams cared about not getting paged during the migration. Leadership cared about the timeline. The SRE teams cared about not being the bottleneck. Each of these groups needed a different message, a different entry point, and a different definition of success. The program plan was the same. The pitch was different every time. If you walk into a room with 200 teams and deliver one message, you will get 200 different interpretations. If you walk in with a message tailored to what each group actually needs, you get alignment.
Metrics are your authority
When you do not have positional power, you need something else that creates accountability. For me, that something is metrics.
On every large program I lead, I establish a small set of measurable indicators that are visible to everyone, from the engineers doing the work to the VPs funding it. Not vanity dashboards. Real operational metrics that expose whether the program is working.
During one reliability transformation, we tracked four numbers: time to detect incidents, time to mitigate them, percentage of services meeting their reliability targets, and the rate of incidents caused by insufficient validation. Every two weeks, those numbers were shared across the entire engineering organization. No one had to be told to improve. The numbers made the gaps obvious, and the teams that were behind could see it themselves.
This is the real power of metrics in a program without authority. They replace the need for someone to point fingers. They create a shared scoreboard that makes progress (and lack of progress) visible without anyone feeling singled out. Teams that were behind often reached out to ask for help before I had to escalate. The key is choosing metrics that teams can actually act on. If your metrics only move when five teams coordinate perfectly, no single team feels ownership. Pick indicators where each team can see their individual contribution to the larger outcome.
Build the coalition before you need it
The biggest mistake I see program leaders make is waiting until they need help to start building relationships. By then, you are negotiating from a position of need rather than trust. On every major program, I spend the first few weeks doing something that looks unproductive from the outside: I talk to people. I meet with the tech leads, the engineering managers, the senior ICs who actually know where the bodies are buried. I ask them what worries them. I ask what has failed before. I ask what they wish leadership understood about their systems.
This is not small talk. This is intelligence gathering. By the time I present a program plan, I have already pressure-tested it against the reality of the people who will execute it. And those people feel heard, which means they are more likely to engage when I need them to move.
On a program that required coordinating a new data center built across 200+ teams, I identified eight senior engineers whose systems were the most complex to migrate. I met with each of them individually before the program kicked off. Three of them raised risks that would have derailed us if we had discovered them mid-execution. Two of them became informal champions who helped me drive adoption within their organizations far more effectively than any top-down mandate could have.
Make the first move embarrassingly easy
Resistance to large programs is rarely about disagreement with the goal. It is about the perceived cost of getting started. Teams look at a massive cross-org initiative and think: "This is going to eat my
quarter."
The fix is to make the entry point so small that saying no feels harder than saying yes.
On one program, we needed every team to onboard their services to a standardized set of operational health indicators. Instead of asking teams to do a full integration, we gave them a self-serve tool that
auto-generated 80% of the configuration from existing metadata. The first step took 15 minutes. Once teams completed that first step and saw their services show up on the shared dashboard, most of them
voluntarily completed the remaining 20% within weeks.
I have used this pattern repeatedly. Build the on-ramp. Reduce the activation energy. Let momentum do the rest. The teams that are already motivated will move fast. The teams that are skeptical will see their
peers moving and follow. The teams that are genuinely blocked will surface real issues you need to solve anyway.
Escalation is a tool, not a failure
There is a misconception among program leaders without authority that escalating to leadership is an admission of failure. That if you were good enough at influence, you would never need to pull that lever.
This is wrong and counterproductive.
Escalation, used well, is a precision tool. It is for situations where two organizations have genuinely conflicting priorities and no amount of creative framing will resolve the tradeoff. Someone with authority
needs to make a call, and your job is to frame that decision clearly so it can be made quickly.
The key is how you escalate. I never escalate a problem. I escalate a decision. I present the tradeoff, the options, the consequences of each path, and my recommendation. Leadership makes the call. The team that
did not get their preferred outcome and understood why, because the reasoning was transparent.
Over the course of a 200-team program, I might escalate three or four times. But those three or four decisions, made quickly and cleanly, prevent weeks of stalling and passive resistance.
The real skill is making yourself unnecessary
The best measure of a program leader is not whether the program succeeds while you are driving it. It is whether the systems, habits, and accountability structures you built continue to work after you move on.
On every program I lead, I am deliberately building toward my own irrelevance. The dashboards, the operating rhythms, the runbooks, the escalation paths, the stakeholder relationships. All of it should survive
without me. If a program falls apart the moment I step away, I have not led it. I have just been holding it together.
The most rewarding moment in my career was not shipping a major milestone. It was watching a program I had led for over a year continue to execute flawlessly after I transitioned to a new charter. The teams knew
the metrics. They knew the operating rhythm. They knew who to call when something was stuck. The system worked because it was designed to work without a single person at the center.
What I would tell my younger self
If you are trying to lead without authority, here is what I wish someone had told me earlier:
- Stop trying to convince everyone. Find the 10% who are already motivated and make them successful. The rest will follow.
- Invest more in listening than presenting. The information you gather in the first two weeks will determine whether your program succeeds or stalls.
- Measure what matters and make it visible. Transparency creates more accountability than any mandate.
- Frame every ask in terms of what the other team gets, not what your program needs.
- Escalate decisions, not problems. Make it easy for leadership to help you.
Leading 200 teams without managing a single one is not about charisma or political savvy. It is about building systems of clarity, accountability, and trust that make large groups of people want to move in the
same direction. The authority is never yours. The outcome can be.
Leading 200 Teams Without Managing a Single One
Here is something nobody tells you about leading a massive cross-org program: the first month feels like you are shouting into a void.
I remember kicking off what was supposed to be a company-wide operational transformation. Executive sponsorship, clear mandate, the whole thing. Within three weeks it was basically dead. Teams showed up to the
meetings, said the right things, and then went back to whatever was already on their plate. I sat in my apartment one evening staring at a tracker full of yellow and red cells thinking, "I have zero authority
over any of these people. What exactly am I doing here?"
That was maybe six years ago. Since then I have led programs that spanned over 200 engineering teams, touched thousands of production services, and moved numbers that showed up in board-level conversations. I
still have zero direct reports on most of them. I am a Technical Program Manager, and the job is basically to get large groups of engineers to do something they did not plan on doing this quarter, without being
their boss.
I am not going to pretend I have a perfect framework for this. But I have learned a few things the hard way that might be useful if you are a staff engineer, tech lead, or EM trying to influence beyond your own
corner of the org.
Nobody cares about your program
I mean that literally. When you are running a 200-team initiative, you think about it all day. You dream about the milestone tracker. You have opinions about the shade of red on the status dashboard. Meanwhile, the average team lead on your program thinks about it for maybe 20 minutes a week, sandwiched between their own sprint planning and a production incident from last night. This was the hardest thing for me to internalize. Your program is not their priority. Their team's roadmap is their priority. Their promo case is their priority. The thing that is going to get them paged at 2am is their priority.
So I stopped leading with "here is what the program needs from you" and started leading with "here is what is going to make your life worse if we do not fix it." Different conversation entirely. On one
infrastructure migration, the platform teams cared about automation coverage, the product teams cared about not getting paged during cutover, and the SRE teams mostly just wanted to stop being the bottleneck for
everything. Same program, completely different pitch depending on who I was talking to.
I actually keep a messy spreadsheet for this. For every stakeholder group I write down: what they care about right now, what is causing them pain, and whether my program helps with that pain or makes it worse.
It is not sophisticated. But it forces me to think about the program from 15 different angles before I walk into a room and start asking for things.
The dashboard trick
I figured this out almost by accident. On an early program, I built a simple dashboard that showed each team's progress against a few operational health metrics. I built it mostly for myself, so I could stop
manually chasing people for status updates every week. But something unexpected happened. Teams started checking the dashboard on their own. The ones that were behind could see it. More importantly, they could
see that other teams were ahead of them.
Nobody likes being the red dot on a dashboard that the VP is looking at.
I have leaned into this on every program since. Pick a small number of metrics that are actually meaningful, not activity metrics like "number of tickets closed" but outcome metrics like "time to detect an
incident" or "percentage of services meeting their reliability target." Make them visible to everyone. Update them on a regular cadence. And then, honestly, get out of the way.
What happens is that the metrics do the accountability work for you. Instead of me sending awkward "hey, just checking in on your migration status" messages, the numbers speak for themselves. Teams that are
behind often reach out to ask for help before I even have to say anything. It is not magic. It is just that people do not like being visibly behind when the scoreboard is public.
The thing I got wrong initially was picking metrics that required five teams to coordinate before any single team could move the number. That kills ownership. Each team needs to see their own contribution. If
the metric only moves when everything comes together perfectly, nobody feels like it is their problem.
Talk to the skeptics first
This one is counterintuitive and I resisted it for a long time. When you are ramping up a big program, your instinct is to go find the enthusiastic teams, get some early wins, build momentum. And you should do
that. But do not skip the skeptics.
On a data center migration program, I identified about eight senior engineers whose systems were the most complex and whose teams were the most likely to push back. My initial plan was to get the easy teams
onboarded first and then use that momentum to pressure the harder ones. A mentor told me that was backwards. "Go talk to the hard ones first," she said. "They know things the easy ones don't."
She was right. I met with each of those eight engineers individually. Three of them raised risks that would have completely derailed us if we had discovered them in month four instead of month one. One of them
had tried a similar migration two years earlier and it had failed because of a dependency nobody had documented. Another one pointed out that our proposed cutover window conflicted with a peak traffic period
that only his team knew about because they were the only ones who had run load tests at that scale.
Two of those skeptics eventually became my strongest advocates. Not because I convinced them the program was great, but because I listened to their concerns early enough that I could actually do something about
them. People support what they help build. That is not a platitude. I have watched it play out a dozen times.
Make the first step stupidly small
Most resistance to big programs is not philosophical. People do not disagree with the goal. They look at the size of the ask and think, "I cannot afford to spend three weeks on this right now." And they are
usually right. They cannot.
So I have gotten almost obsessive about reducing the initial ask. On one program where we needed every team to onboard their services to a standardized monitoring setup, we built a self-serve tool that
auto-generated about 80% of the configuration from metadata that already existed. First step took maybe 15 minutes. That is it. Fifteen minutes and your service shows up on the shared dashboard.
What I did not expect was how much that tiny first step changed the psychology. Once a team could see their service on the board, most of them voluntarily went and finished the remaining configuration within a
couple weeks. Nobody asked them to. They just did it because the hard part (getting started) was already behind them.
I think about this a lot when I see program leaders send out these massive onboarding documents with 47 steps and a three-week timeline. You have already lost half your teams before they finish reading page one.
Give them something they can do in one sitting. Momentum is a real thing.
About escalation
There is this weird culture among TPMs and program leaders where escalating feels like admitting defeat. Like if you were really good at influence and alignment, you would never need to involve leadership.
I used to think this too and it cost me months on a program where two organizations had a genuine resource conflict that no amount of creative framing was going to resolve. I kept trying to find the win-win.
There was no win-win. Someone needed to make a call about which initiative got priority, and that someone was not me.
Now I escalate maybe three or four times over the course of a big program. But I am very deliberate about how I do it. I never bring a problem. I bring a decision. Here are the two options, here are the
tradeoffs, here is what I recommend, here is what happens if we do nothing. Leadership makes the call in five minutes instead of five weeks, and the team that did not get their preferred outcome at least
understands why.
The thing is, those three or four escalations, handled cleanly, prevent weeks of passive resistance and back-channel politicking. It is a net positive for everyone involved, including the teams that did not get
what they wanted.
The part nobody talks about
The loneliest part of running a 200-team program is that your success is invisible when things go well. When the migration lands on time, the teams that did the work get the credit. When the reliability metrics
improve, the engineering managers present the results at the all-hands. That is how it should be. Seriously. If you need personal recognition to feel motivated, this kind of role will eat you alive.
But I will admit there is a specific kind of satisfaction that is hard to describe. About a year into one program, I transitioned to a different charter. I was nervous about it. This thing had been my entire
professional identity for a year. What if it falls apart?
It did not fall apart. The operating rhythm kept going. The dashboards kept getting updated. Teams kept hitting milestones. The escalation paths I had set up kept working. Nobody called me asking what to do
next, because the system did not depend on me being in the room.
That felt better than any launch I have ever been part of. Building something that runs without you is, I think, the whole point. If a program collapses the moment you step away, you were not leading it. You
were just holding it together with force of will, and that does not scale.
I do not have a tidy conclusion for this. Leading without authority is messy and slow and full of conversations that feel unproductive until suddenly they are not. But if you can get comfortable with the
ambiguity, with the fact that your name will rarely be on the win, and with the reality that influence is built one relationship at a time, it is genuinely some of the most impactful work you can do in a large
engineering organization.
And you do not need a single direct report to do it.
Okay, I’m trying to write a blog in which it is very important that my original language and the way I think and my words are written as compared to it looks like it comes from an AI. I’m giving you information about one of the programs that I run from my actual personal experience. So I ran one of the largest cultural shift at LinkedIn where we were trying to shift the way we do site reliability at LinkedIn. When I joined LinkedIn in 2022, the company was heavily oriented towards having SREs, one of the models that came from Google early in the years. The company had site reliability engineers embedded across the company for every product and service. So basically the way the model worked is the product teams and the engineering teams, they will build products and the platforms and the site liability engineers, site reliability engineers, they were responsible for managing the support of this product. Like if there are any on-call issues, there are incidents or to make the platform scalable or set up the CI/CD pipeline, devops system, things like those fall under SRE buckets. Now, the challenge in this model is, there are two challenges primarily. One, is the scalability part and the operational side of things. I’m working on something, beta. My office. Can you go? So the scalability side of thing, like the team was totally disjointed from the people who are building the product. Ideally, the scalability and the observability and operability should be built within the product itself from the get-go. And if it is done as an afterthought, like it’s done in this scenario, then your products are not scalable and you’ll have a hard time managing that product. So the idea was basically we want to get out of that model and we wanted to set a model where product teams own the reliability of their own products. And we wanted, this was a major cultural shift because we no longer would have any site reliability teams who would be focused on these efforts. And ideally, the products will build their own product and the reliability organization, which was a huge organization at LinkedIn, will actually transform into also a platform organization, which will build the reliability products that are important for reliability. So that was the main idea. Now I was hired as a TPM. When I joined, the major, the most major challenge that I faced in this program was that the lack of clarity around for everyone to understand, even myself, that how are we going to achieve this and what are we actually achieving, not how, it’s majorly around what are we doing. Only the few people, center, core part of the core team understood what they were doing and they spent like six months trying to set up a structure where they created some documents and guidance for every team to shift and how this will operate. And when I joined the updates were very manual, like every week some director will ping some teams, hey, what’s your update? And they will give some verbal updates and they will say, oh yeah, we are progressing and whatnot, but there was no way to tie those updates and see if they are making progress week over week. And another thing that I noticed in the program was the leadership would say, oh, don’t worry about it because they were afraid of the idea that the teams will go away and people will be afraid of their jobs and whatnot. They were afraid of the idea that people will see this as a challenge to keep their jobs, so they wanted to keep it such, and they would say, oh, don’t worry, this is a 5-year-old program or 10-year-old long program, it will take a long time. It’s not gonna happen. And as a TPM, I do not work in these kind of environments. Like I like fast-paced things. If you want to do something, you just do it. You do not wait for five years to execute a program. You find the right opportunity, put the pedal on the metal, and then hit it. So what I found in this program was this program basically meant a culture shift for the whole company. So you are not only changing the site or liability engineer, which were, let’s say, about 60 teams or so, 50, 60 teams, you’re actually changing whole company because now every software engineer and every team need to learn how to manage their own platform. So these teams, and that was a huge scope because now we are talking about 200 or 300 plus teams that need to manage their own products going forward. So, and that was the job for me. So I ran this program and I want to write a blog about this program, how I managed this program across 200 plus teams. I don’t want you to rewrite it into your own words. All I want you to do is just give the text that I gave to you back to me so I can give it to some AI tool and then that AI tool can, whichever tool I’m using, can actually generate this blog for me. So just verbatim whatever I gave you, just copy paste it for me. So, let’s continue. So, the biggest problem in this program that I thought I could solve was if I can give observability to everyone that what is happening on ground. So, I divided this program into three sections. One was like basically I studied the program and basically understood every team need to work into three things. One is a transition, and then transformation, and then execution. Basically, they need to transition their role into some other role. Then they need to do the transformation. Basically, they need to learn how to become a software engineer, and then they need to do whatever the third one was. But I think that’s not the main thing. I converted this manual verbal update model into an actual execution engine. And how I did that is basically I created a new structure, and it was a normal Google Sheet, which was extensive and super amazingly loaded, where every team can track the progress, every SRE organization can track the progress of all the software engineer teams they are trying to transform, basically. So these are the software team they support, and they are going to transition these software engineering teams. So what I did is I created a simple tracker for every org. We used to have five or four or five orgs. For each org, like that was represented by a director, I created a tracker. And all the teams, software engineering teams supported by that director were inside that org. Now, I asked each SRE team, that define a set of activities that you do today and then add one role for each activity and that eventually software engineers would start doing for you. And then do the training and once they are trained on this and are transitioned just in the sheet market has done. And let’s say you had 50 tasks that you identified that you do today that you need to transition, then basically I will track your progress against those 50. So those 50 tasks now became my metrics. So that way, instead of waiting on manual updates, somebody can say, oh, I did XYZ thing today. And then somebody tomorrow can say, I did ABC thing tomorrow. How would I know how are you progressing towards end goal? So what I did is I didn’t challenge them on what they were providing me update on. I changed the whole game around and made it metric driven. So now they have no way to run from this program and update. All they need to do is they just provide how many activities they have identified and then they just need to track their progress against those activities. And if there are more activities added later, that will add to their backlog list. If the number of activities are reduced, that’s okay too. Because the day they say they are 100% done, I will just take away, I will tell the software engineering team, hey, your support is gone because your SRE is saying you no longer need him and he has 100% transition. So that way, I remove myself and the execution committee from the status update and state tracking gathering. And another beautiful thing this centralized tracker did is, It made everything visible. Now a director can open the tracker and see, oh, your team has only transitioned this much. Another VP…
