How to Scale Yourself Down — Not Up — as a Leader
Management

How to Scale Yourself Down — Not Up — as a Leader

After a four-decade career of toggling back and forth between big and small, Lightspark SVP of Engineering James Everingham shares his playbook for scaling down your leadership as you go from an org of hundreds or thousands to a handful of direct reports.

In March 2022, James Everingham left Meta, capping off a nearly eight-year run where he headed up engineering at Instagram and helped shape the cryptocurrency experiment that was Diem (fka Libra). After steering large orgs (we’re talking thousands of engineers), he signed up for a challenge of a completely different sort — co-founding a new venture and leading an engineering team that you could count on one hand.

“I’ve done this shift a few times now in my career, but I'm rediscovering how challenging it can be,” Everingham says. “Back at Netscape, we went from 100 to 3000 people in a year. At Instagram, we scaled from 100 to 600 engineers in four years. With Libra, we started with a handful and got up to about 1400 by the time I left. Now at Lightspark, my engineering team is back down to 12 people.”

Going from leading big teams to a small startup is like driving a manual transmission. You're cruising around the freeway in fifth gear and then you dump the clutch in first. You have to scale yourself down — not up. It's a very different job.

This framing caught our eye here on The Review for a couple of reasons. One, Everingham has been a long-standing favorite of ours on all things engineering leadership, so if he’s flagging a challenge, it’s time to pay attention. (His classic articles on quantum team management and boosting transparency are well worth revisiting.) Two, there’s tons of advice out there about how leaders can scale up as their team gets bigger — but much less on how to throw it into reverse.

And it’s not an easy transition to navigate. Joining an early-stage startup means that resources are scarce, process is non-existent, and goals shift by the day. And tried-and-true playbooks will only go so far, as what works in a big company doesn’t always easily port over to a small startup setting. So while leaders might have proven they can run large organizations, it’s not a sure bet that they can revert back to running a small one. That’s why many early-stage founders steer clear of “BigCo” candidates altogether, out of fears that leaders won’t be able to “roll up their sleeves” or “wear lots of hats” (or any other clothing-based metaphor of your choosing).

In this exclusive interview, Everingham open sources his guide for scaling down as a leader, with tactical advice and specific examples from his own experiences navigating this transition. He unpacks the major differences you may not notice as you’re busy shifting gears, and outlines the tools every leader needs to stay the course. From the roadblocks that will stand in your way, to simple, but powerful questions to help you shift from scale to scrappy, there’s tons in here for leaders of every function, not just the eng org. Let’s dig in.

SHIFTING GEARS: MAKE THESE MINDSET ADJUSTMENTS AS YOU GO FROM BIG TO SMALL

“Going between big companies and small startups in my career has taught me that this transition exercises very different muscles,” Everingham says. He ticks through some of the reasons below:

“At a big company, you need to be great at delegation and communicating with nuance. You have to be calm and learn how to influence leadership. It’s your job to hold the line on values alignment with your organization. In addition to understanding how to structure teams, you have to be fairly good at hiring leaders — and really good at career growth for your team,” he says. “But ultimately, leadership at a big company requires you to be an excellent coach. You have to build your team's capability through coaching rather than doing.”

While many of those traits are, of course, valuable in a smaller team setting as well, leaders need to spike in different directions. “If I'm managing a large engineering team, like I was at Instagram, I'm almost a specialist. Leading a small team, I'm wearing a bunch of different hats, so I have to be comfortable doing tons of different jobs, from a one-man recruiting shop to the janitor restocking bathrooms. And communication is still important, but in a different way,” he says. “You have to facilitate a lot of inter-team communication as opposed to broadcast communication out to your entire org.”

But the most defining difference? “At a big company you're trying to reduce risk. At a startup, you have to be a risk taker. You have to be super comfortable with ambiguity. You have to be impatient with shipping, but patient with your career,” says Everingham.

At a big company, you're trained to get it right and get it out. You can’t risk experimenting on your customer base. When you're at a small company, you don't have any product-market fit, so you have to get it out, then get it right.

Frugality also stands out on the small startup leader’s list of must-have traits. “In a large company, you have access to — and come to rely on — a lot of resources, but you have very little control. In a small company, it’s the opposite,” he says.

“That’s why you need to be able to ignore the hierarchy — because there isn’t one. You have a lot more latitude with decision-making at a startup. So you need to get comfortable with quickly making decisions that your boss’ boss’ boss would’ve made at your last company,” he says.

“For example, David Marcus was my boss at Meta, and he’s still my boss at Lightspark today. We were in the office a couple of months ago, and I just pulled him aside and said, ‘Hey, I think we should make this change at the senior staff level,’ And he said, ‘Let's just do it.’ After we agreed, he looked at me and says, ‘You know, that would have taken over a year at Meta.’”

Photo of James Everingham seated
James Everingham, SVP of Engineering at Lightspark

DODGING POTHOLES: COMMON MANAGEMENT MISTAKES TO KEEP AN EYE OUT FOR

With those differences laid out, Everingham runs through some of the traps that folks frequently face as they attempt to scale down their leadership:

Mistake #1: Planning too much for success

Many struggle to switch their mindset from risk-reduction to risk-taking, Everingham says. “Some leaders don’t make the shift from ‘get it right and get it out’ to ‘get it out and get it right.’ They can't. Building solid, well-crafted infrastructure is so ingrained in the way they operate. They’re so focused on seeing around every corner, and anticipating all the complications they’ll run into when it scales. They’ll build a load-balanced sharded database architecture designed to handle millions of users — before any even show up.”

At a startup, planning too much for success can get in the way of success. You're putting all of this energy into building something “correctly” that may not work, rather than into quick experimentation and iteration to get product-market fit.

Separate finding product-market fit from building the product. As a leader coming from a big company, you’ve been focused on driving the latter, not the former. They’re completely different challenges — scaling the product requires an entirely different set of tactics. Acknowledge that,” he says. “Constantly remind yourself that you need to shift gears. You can, of course, anticipate what you’ll need to change and what will need to scale differently, but you can’t be caught up in that level of polish right now.”

Mistake #2: Not striking the right process balance

“People tend to use process as a tool in a big company, thinking it can solve every problem. But in reality, you should be very thoughtful about where and how much process gets put in early on,” says Everingham. “If a process that you were used to having doesn’t exist at your new startup, hit pause before you rush to recreate it. Look for patterns that will increase over time, and address those ones early.”

Take product planning as an example. “In a large company, this is a complicated task, often involving collaboration between numerous teams and stakeholders, careful allocation of a vast array of resources to designated projects, and advanced strategic planning which can extend years into the future, with details stretching down to individual features,” he says.

“In contrast, startups are resource-limited, and their main aim is to discover product-market fit. The final product is uncertain even three months out, let alone a year. Implementing an in-depth product planning strategy would not only be impractical but could potentially be detrimental. It may divert attention to less critical aspects of the product at the expense of agility and adaptability, which are essential for quick responses to a dynamic market.”

Avoid process out of practice. Leaders who are successful in a startup are the ones who naturally reinvent their own toolboxes, and question what the process is trying to accomplish before establishing something that might be too heavyweight.

However, process is a double-sided coin. “There’s often an overcorrection when leaders move from big companies to small startups. Folks want to shake off that big company feeling and run hard in the other direction. And while the idea of no process sounds fantastic, issues emerge if you don't start adding at least a little bit of it early on,” he says.

“For example, I advise a lot of startups and the most common challenges founders bring to me is, ‘We’re about 100 engineers and we don’t have any job levels or performance review process, and now we have to put all of that in.’ Trying to build those muscles all at once is going to hurt,” says Everingham. “Starting slowly in the beginning is much easier than cold-adopting a more robust system. Keep it super simple by kicking off a review process that is functional and a good placeholder so you can evolve the process as you scale.”

Loving process is a problem — but hating it is one too.

Mistake #3: Overhiring

“So many startups overhire — particularly the well-funded ones. ‘If I have more people, I could do more things,’ seems to be common wisdom among many managers. Particularly at a big company, it’s easy to get caught up in an arms race of adding more and more headcount to your team. And when you land at a small startup, there are a million things you want to tackle, so it can be hard to shake that ‘let’s add someone to go faster’ impulse,” he says.

In big companies that’s an expensive mistake — but in small companies it can be a fatal one. Predicting the future is hard in a startup since things change so fast, so trying to ‘get ahead of hiring’ can be inefficient and build the wrong culture,” says Everingham. “Plus, when you don't know exactly what you want yet, you want innovation. Resource constraints force out-of-the-box thinking. It also requires ruthless prioritization and makes teams focus on what's most important.”

Here are two mantras to keep in mind as you’re contemplating hiring while scaling down your leadership:

  • Hire for a purpose, not for a resume. Opportunistic hiring can lead to an imbalanced team,” says Everingham. “You'll end up having engineers without meaningful areas of ownership and without clear work to do.”
  • Hire only when there is pain. “At large companies you’ll often hear phrases like, ‘I'm going to want to grow to 100 headcount next year.’ But at Lightspark, we’re not going to try to anticipate hiring ahead of time. It’s a trailing versus forward approach,” he says. “Monthly, we take a look at everyone’s workload, which is changing constantly at a startup. Who's drowning? Is there enough work there to hire somebody? Or can other people on the team take it? You're constantly load balancing against your team and you're waiting for someone to be like, ‘I need help now. I can’t keep up with the work.’ And even then, you have to think through if it’s long-term or temporary, and if you can just get a contractor.”
Hire the folks you need to get the job done today — not for future work that may (or may not) be coming. It should be clear that adding someone makes life easier, not harder, for your current team.

TOOLS FOR MAKING THE TRANSITION SMOOTHER

“Managing a large team can feel like running a government — managers make rules, establish guard rails, and hire leaders to enforce them. Small teams need fewer rules and more operational and tactical support,” he says.

Here are the tools Everingham leans on to calibrate the right level of support as a leader:

Tool #1: Anchor decision-making in principles.

“One small piece of the process that helps you scale smoothly is coming up with the right principles early on. It’s probably also one of the few elements that doesn’t really need to change as you scale,” he says.

“Decision-making is a mental muscle that teams have to build. When a problem comes up, your natural instinct is to say, ‘What’s the solution?’ But if you’re trying to build scalable teams, you have to insert this step of ‘How should we think about solving this problem? And then how can we systemize that so it can be used later?’”

Whether it's a big company or a small company, it's important that the team understands how decisions are made — not just what decisions were made.

Decision principles are the seeds that can grow into supporting more complicated decisions in the future. They make decisions consistent, repeatable and scalable. They’re mini-frameworks that everyone agrees upon, the algorithms that you use to make the decision. You’re able to move much faster because you can tell your team, ‘When you see this pattern or this comes along, here's the algorithm. You can go make that decision yourself, as long as it fits within that.’”

The key is to start simple, Everingham says. “Don't go overboard building pages of principles. Come up with your first three to five that are most important to you and your business execution.” Next, focus on evangelizing the principles across the team, making them an everyday part of how you operate.

It takes some practice to hold others accountable, but “What principles were used to make that decision?” should become part of your daily syntax.

To bring decision principles to life, Everingham shares an example of one his team is currently using at Lightspark: We solve customer problems first. “This was beaten into my head by Kevin Systrom at Instagram, and I love it. He would constantly ask: Are you solving a customer problem or a company problem?” says Everingham. “You’ll always hear ideas like, ‘If we do X, or build Y feature, we’ll make a lot more money.’ But ‘How do we make money?’ is solving a company problem — and it’s a question that can kill a company if asked too early or too late. If we don't focus on the customer problem first, we're not going to even have those opportunities later on.”

For Everingham, establishing principles isn’t just about making decisions — it's making decisions that are well made. “To me, a well-made decision is one that you can explain how and why it was made. Ingraining this in the culture early on will support transparency as the company grows, promote consistency, and reduce politics. In essence, ‘don’t blame me, blame the framework,’” he says.

“For example at Instagram, we had offices all over the globe with engineering resources. We needed to hire from locations outside of Silicon Valley because we simply exhausted the hiring pipeline locally after hiring thousands of engineers a year,” says Everingham. “But how do you decide where to go? I didn’t want to be the decider, so as a group we thought through what makes a team successful. We ended up with a set of mini-principles that managers could use to decide for themselves where to put a team:

  • Adjacencies with the local talent pool
  • Adjacencies with Meta teams
  • Be able to grow to a large pillar with career growth (Director-level scope minimum)
  • All individual contributors to have a local manager
  • Have a cultural ambassador transfer to the location to help seed the culture

“I had a manager come to me who wanted to stand up a mobile web team in New York. And so we went through the principles. And together we agreed that it wouldn’t ever be more than 20 people, and that there wasn’t a lot of front-end talent in New York, and so on. It didn't actually hit any of the principles. So I said, ‘What do you think about New York now?’ and he said, ‘I guess I shouldn't do it there.’ But without those principles that would have gotten political.”

Read more on how Everingham applied principles (and other decision-making frameworks) at Instagram.

Tool #2: Progress > polish

“A lot of great engineering talent from big tech companies comes into a small startup and says some version of, ‘We need to do it this way because it needs to scale.’ But we don't even know if that's the right solution for the customer yet. You want to put in the least amount of work to find out what’s going to work for the customer,” says Everingham.

Do everything you can to reduce the amount of throw-away work while proving out your thesis.

His shortcut for getting the team there is one simple question: What’s the hack? “When my team is designing and architecting, or suggesting a way that we might be able to do something, I always ask, ‘What's the simplest thing we can do to prove this thesis?’ It almost gamifies it. It’s a chance to exercise their creativity and sidestep that premature ‘But will it scale?’ discussion.”

He shares an example in action: “Back at Luminate, my startup before I joined Instagram, we were building monetization to enable people to buy stuff right on an image. From a big company background, my immediate instinct was, ‘Okay, we need to take credit cards, so we should integrate a payment processor and build all of this stuff to make sure we can take payments.’” he says.

“But the ‘What’s the hack?’ exercise forced me to realize that I need first to find out if folks were going to use it. So we ended up throwing up a UI that just looked like a flow to order and enter your credit card. But when you hit enter, we didn't send it to a payment processor. We didn't keep the credit card. We didn't do anything but increment a counter. After we saw that people were using it, we still didn’t want to build credit card infrastructure, so we literally got a dot matrix printer, and our next phase was manually running these credit cards until it was so painful we needed to automate it. We made sure to stay within the rules, but we just didn't spend the time on building something until we knew we needed it.”

It’s up to you to reinforce this mentality on your team. “Staying focused on the simplest thing you can do to prove a thesis, acknowledging bugs are okay and rewarding your team for quick iteration is critical when you’re moving from a big company to a startup. You need to make sure they know that the ‘win’ is getting more versions out quicker with very different designs to see what works,” says Everingham.

In the search for product-market fit, you can't polish your way into existence. So if something isn’t working, tweaks aren’t the answer. If you want to get dramatically different results, you have to do dramatically different things.

Another helpful tactic in this area? Order of magnitude thought experiments. “Let's say you're tracking at $1 million ARR currently. What do you have to do to finish this year at $5 million? That’s a big jump, but it probably just requires more of the same. But what if you had an extra year to get to a $100 million run rate? That’s revolutionary versus evolutionary — and it leads you to very different places.”

Tool #3: Create narratives as a goal-setting tool.

“Managing a large team is a very detail-oriented exercise. You’re looking at headcount and schedules on a long runway, and that’s impossible in a startup setting. But too many early-stage teams opt to skip over planning and goal-setting altogether. Teams that don’t set goals underperform teams that do. It’s just a fact. So you need to do it,” says Everingham.

But it’s critical to keep goals very high level and not get overly detailed, he says. To not lose sight of the broad brushstrokes, Everingham takes a storytelling driven approach: “I focus on the outcomes and not the specifics when I’m goal-setting at a startup. It’s management by narrative,” he says.

“Instead of drilling straight down into specific KPIs and targets, start by trying to tell a story. Have a thesis, such as ‘This is what we're going to do this year.’ Break that narrative up into chapters, almost like titles. The flow is, ‘First we're going to do this, then we're going to do this, and then by chapter three we’ll have done this, and chapter four is the end, where we have product-market fit and we're scaling,’” says Everingham.

“But here’s the key for an early-stage startup: As we’re building our plans, we only focus on those first three months, that first chapter. So we break that down into monthly high-level goals, and that's what I hold the team accountable for,” he says. “Don’t try to get detailed for longer than a few weeks out. At a startup, it’s almost assuredly wrong past that. All you can do is make sure everyone knows the story, the short-term outcomes you're looking for and that they're doing work that maps up to support that.”

As managers, our jobs are simple: Get people to say what they're going to do, get them to do what they said, and make sure they understand how what they're doing maps up to making the company win.

Take this example from Lightspark. “Chapter one back in January was, ‘We’ve kicked off our larger projects that need as much testing as possible, as well as our Mobile SDK product and demos.’ And then the next chapter was ‘Completed the simplified user interface and got all of our mobile prototypes working in demo.’ And then the third chapter is, ‘We’ve completed all our MVP features and we’re starting aggressive end-to-end testing.’ I have more detail under each of those but just in bullets. My rule of thumb is only one month of high-resolution planning at a time.”

Template for planning by narrative, with blocks for 12 month narrative, quarterly theme, monthly objective and weekly plans
James Everingham's template for management by narrative

Pruning is the next step. “Small teams are creative, and they want to build a lot of stuff. But when you don’t have product-market fit you have to focus. Ruthless prioritization is super important at a startup — more so than it is in a big company — so it’s a skill you need to sharpen as you’re scaling down,” he says.

Here’s how Everingham practices:

I like to go through every single thing the team is doing and ask: If this one thing weren't done, would we not be able ship the product? And if the answer is, ‘No, it would still ship,’ then it's off the list.

FOR FOUNDERS: HOW TO FIND THE LEADERS WHO CAN SCALE DOWN

There are lessons in here for founders as well, not just for the leaders making the transition from big to small. “Don’t not hire a candidate from a big company because you fear they might bring in process, politics, and bureaucracy. Getting someone who knows what management looks like on a larger scale is invaluable,” says Everingham.

Big company people can be a real asset. If you want to have a big company, hiring people that understand firsthand what it takes is pretty essential.

“They often understand what infrastructure and resources it takes to support a large customer base. Whether it’s A/B testing systems, how to do internationalization, standing up data science or scaling security, they’ve solved problems that you're going to have to solve down the line,” he says. “The key is that you're looking for someone who respects process, but knows how to plant the seeds and scale it over time but can also operate with ambiguity. They lay down the map of directions but don’t insist on using the GPS to get there.”

If you’re a founder looking to spot the difference, here are a few of the interview questions Everingham leans on:

  • How have you adapted your management style to different team sizes? What challenges did you face and how did you overcome them?
  • Startups often require employees to wear many hats. Can you provide examples of situations where you have stepped out of your formal job role to help your team or company succeed?
  • Startups often require a 'roll up your sleeves' attitude. Are there instances in your career where you had to dive deep into technical issues, despite having a managerial role?
  • Startups often have to build processes from scratch. Can you share your experience with building and improving processes in your team or organization? How did you ensure it was flexible enough to adapt to changing circumstances?
  • Can you provide an example of a time when adhering strictly to a process caused a problem? How did you handle it?

A flag to watch for? “Be more careful hiring executives who have been in their roles for a very long time. If they haven’t moved companies in years and years, or you don’t see that they’ve ascended the ranks quickly, that’s probably a sign. I look for people who’ve moved up the ladder fast — that shows that they were making decisions, delegating and giving away their Legos, which is a good sign.”