Management by Model: Leading at Scale Without Drowning

A mentee recently came to me for advice: they had doubled the size of their team (and even added a layer of management) and were struggling with intense whiplash… bouncing from low-level execution management to coaching junior engineers to high-level architecture to org-wide influence, all in the space of a single day, and somehow being expected to also have time to think deeply and come up with novel strategic solutions to our org’s biggest problems. Oh, and while you’re at it, make sure to provide polished and perfect exec comms and upward management to control the narrative/perception of your team’s work… now across twice as many things. Cool, cool, cool.

The exact numbers don’t really matter, the problem is that as your scope grows there comes a point where it no longer all fits in your head. You can’t keep all the details straight while making sound decisions, commitments start to slip, your personal ETAs go from days to weeks, those “important but not urgent” tasks seem to never happen, and you start to collect regrets: bad decisions, moments where you were a total grouch, or slipped into outright command-and-control leadership. Whether that’s happening to you at 30 reports or 20 or 10, you have to change tactics before you implode.

Managing at scale is being subjected to 12 straight hours of meetings where every 30 minutes is about a totally different topic, with a totally different stakeholder, and every conversation is an active two-way exchange (no boring all-hands you can just tune out while you read emails). Here’s a random Thursday morning (not even a whole day) plucked off my calendar:

• 1:1 with a disgruntled skip report who wants to get promoted.
• H2 Roadmap session with Product.
• Design discussion about a new testing framework.
• HR consultation on a serious case of misconduct.
• Postmortem review from a huge incident we had last week.
• Status readout to VPs to decide if we shitcan an entire project.
• Coaching session on exec communication with one of my directs.
• Negotiating a stand off between the feature and platform teams.
• Emceeing a fun event for my distributed team members (thank god for skribbl.io).
• Deciding on the final set of metrics we’ll use for next quarter’s OKRs.

You no longer have the luxury of carefully preparing talking points for your status updates, good coaching questions for your 1:1, practicing the delivery of some hard feedback, or boning up on some technical details before a complex design review…you just have to walk in with <30s to change gears and nail it, first try, every time, completely cold. Maybe you also noticed there’s no time blocked off in there for deep thinking, writing docs, responding to emails, or any personal TODO’s. Yikes.

We’ve all heard the same, namby-pamby advice that you just need to “delegate more.” God, I’m so tired. Your reports might also be at capacity. You might not have anyone physically able to handle such tasks (i.e. a shallow bench). You might not even be able to concretely articulate the task/deliverable/goal, just a vague sense “something needs to happen.” You don’t see any way to just say no to the request. Whatever, the point is that delegating isn’t always an option.

Now don’t get me wrong, delegation is good (I have a whole post queued up about this topic), but delegating more without changing the way you work is a faux solution to a different problem altogether.

I’m no stranger to this situation: I once went from 5 to 30 direct reports in a matter of weeks, and then managed that group for a whole year as more and more orphaned teams, maintenance-mode systems, and employees were moved under me all without any option to add additional management layers.

I didn’t just double my working hours and do more of what I was already doing…I had to do something completely different. Rather than treating strategy, politics, and execution as three different jobs to juggle, I instead approached them as one integrated flow. The resulting system, dubbed management by model, transforms the 12-hour meeting block from huge time-suck to massively productive, prevents micromanagement, ensures most of your cognitive cycles are spent on high-level strategic interventions rather than tactical minutia, and might just let you reclaim your nights and weekends.

The Management by Model (MbM) Framework

The entire framework rests on one simple assumption: you were given this job for a reason, you’re probably pretty good at Getting Shit Done even if sometimes it doesn’t feel like it (imposter syndrome is a thief of joy). An obvious corollary to this that you Know Things™. Things like…

• …how work needs to be organized and tracked to ensure it actually happens and happens transparently.
• …the different systems/tools you need to build anything useful (and which dependencies to avoid like the plague).
• …how long things roughly take and an ability to create estimates that are more accurate than a PRNG.
• …which teams and stakeholders with which you must communicate when working in any given area.
• …the technical and business experts you can (or should) consult for a variety of different problems.
• …how much wiggle room there is to skirt process, skip steps, cut corners, and take chances.
• …what “high quality” means in your org and the definition of success beyond just “the project is done.”
• …the sorts of things that will make your boss / boss’s boss / boss’ boss’s boss grumpy and how to massage the message.
• …the signs that a project is doomed to fail or group cohesion is disintegrating.

With this knowledge in hand, you can construct in your head a platonic ideal for any given project: the abstract, perfect, conceptual model of how the work should be proceeding if all is well. You can likely do this automatically and without much effort (again, see: “you are good at things, you have this job for a reason”).

Like any model or virtual twin, you must carefully choose which details to include or exclude. When an architect builds a balsa wood model of a skyscraper, they are modeling mass and flow. They need to show where the load-bearing columns are, how the light hits the atrium, and how people move from the lobby to the elevators. They do not model the pattern of the wallpaper in the bathroom or the thread count of the curtains. Including those details doesn’t just waste time; it clutters the model so much you can no longer see the structural flaws. In your management model, you need to see the load-bearing walls (e.g. critical dependencies), not the wallpaper (e.g. code style).

Model in hand, you can continuously check whether work is proceeding in accords with that model, and when diffs are found, concoct a minimal intervention to nudge the system back into compliance or update your model to accommodate this allowable deviation).

By correcting deviations, the execution takes care of itself while you are free to focus on the broader strategic picture and stakeholder management so that the execution engine you build can be directed at the highest leverage opportunities. To implement this in practice, you need to implement new practices across 3 key constituencies.

Part 1: Manage Down with the “Diff” Method

The Trap: you manage by tracking all of the activity on your team and continuously get involved in nearly every discussion, decision, setback, and cross-team negotiation. You feel compelled to ensure everything from the lowest level code structure decision to team-level goal setting is a 10/10 on the quality scale. You think your success will be judged by all of these details and never want to be caught by surprise with a setback or slip.

The Mindset Shift: leaders work on the system not in the system. You need to stop tracking progress and individual activities and start tracking deviations. Teams fuck up, your career won’t end if there’s an occasional outage or a timeline slip (in my experience your “career” won’t be impacted either way, tbf). What matters is that the way the team responds is appropriate and automatic (i.e. does not require you).

The Protocol: form a rigorous mental model of how your system (people + code) should behave. Any time you encounter a diff (like a lack of expected progress, missing conversation, design docs that imply the code works differently than you understand it, etc) then dig in hard. You can use this to buff your understanding of the tech just as much as you can to find+fix team/process/execution problems making it doubly effective.

To effectively detect deviations, you need to set up a series of tripwires, gates that occur naturally throughout the rhythm of work where you can look for deviations. This could be things like…

• A weekly sprint or kanban wherein committed tasks taking longer than expected will stand out.
• Paying attention to the oncall / production chat. Is the team expressing the right amount of curiosity when things break or flake? Do they try to fix problems without being asked?
• Review all postmortems…do they include action items that proactively detect similar events? Prevent them from happening again? Is the root cause conclusive and correct or a giant hand-wave?
• Check the approvers on design docs. Were the right people included? Are key stakeholders and system owners off team appropriately engaged?
• Even the much maligned OKRs can be somewhat useful. Do proposed OKRs describe actions or outcomes? Are those outcomes believable? (no you won’t double the size of your user base in one quarter) When end of quarter rolls around, did the team at least start work on all of their proposed OKRs? If the team pivoted to different goals, did they do so because they learned something or circumstances changed…or was it because something is going haywire with either the planning or execution process?
• Be curious in 1:1s about how people are working together. Are there topics that keep coming up (indicating unresolved issues)? Do people share compliments and kudos about each other unbidden or is it all negative? Ask people “what can I expect to see from you in the next two weeks?” and let them answer without your influence or steering.

These are just examples and none of them are smoking guns which indicate 100% “there is a problem.” These are simply your signs that its time to get curious and dig in…to actually spend some of your own precious energy. The best part is that most of these things cost nothing…they are all checks you can perform passively by reading email / looking at Jira / going to your regular 1:1s and team meetings.

As your team scales (30->50, 1->2 layers of management) the design of your tripwires will have to evolve in sophistication. Most of these examples would apply to a manager of a large 10+ person team or with at most 1 layer of management under them.

Example: we all know that PR throughput is a horrible metric for measuring developer or team performance, but when used through the lens of MbM it has new utility! Each of my teams has a very distinct “flavor” to their work: some do greenfield projects where the expected velocity is high free from the burden of tech debt, some are deep infra groups where careful design and research are key for reliability, others are right in the middle shipping features in legacy codebases where we can expect some setbacks and rework. Every week, I receive an automated email that alerts me when someone has not pushed any code in a long time; the time span varies by team…e.g. 1 week for the greenfield group and 2 weeks for the infra group. These engineers are NOT in trouble! I don’t even tell people I have this data it never gets brought up / written down / shared. This is just my own private nudge to pay extra attention in standup and ask some leading questions in our next 1:1 to understand where the time is going or if something about their approach is off. Many times it’s innocuous…like at the start of quarter when we’re beginning new projects and the TLs might be in multiple weeks of scoping+design with their product counterparts. Other times it uncovers problems that require intervention. Two memorable examples:

• The flagged individual had lots of pending PRs (just nothing actually submitted). It turned out that code reviewers were very slow in responding and almost all these PRs were stuck waiting on 2 key tech leads. This led to establishing team norms around responsiveness in reviews (same-day turnaround), and cross-training to avoid bottlenecks in high-traffic components.
• In another case, it turned out the individual was busily designing a robust, reusable architecture to support a new feature but it had been more than a month and they were still just writing writing writing. However, the feature in question would never need that level of extensibility/modifiability…the entire thing was a one-off customer request and not an area of investment where we’d be continuing to iterate and enhance past the initial launch milestone. A quick and direct solution was the only thing that would be ROI positive; after filling in this important context, the engineer changed their approach and quickly moved onto implementation with a more pragmatic design.

By having an accurate model of how much “non-coding” work my different teams do, PR throughput becomes a marvelously effective tripwire for finding stuck engineers and problematic team behaviors!

Part 2: Manage Up by Solving, Not Inventing

The Trap: you try to impress your leadership with “new” ideas and sophisticated chainlink strategies (often in the form of 20-page visionary documents) that show you can conceive of and execute ideas valuable to the business. You believe it’s key to do something large and strategic that others recognize as your original idea.

The Mindset Shift: success is defined by the velocity at which you solve your boss’s problems. Creating new work unattached to current reality is just creating a whole additional problem (“more work I don’t have the resources to fund, and a report who will be mad if I say no”). In any sufficiently mature organization, the top problems and opportunities are already known and your focus should be on applying your organization to addressing them.

The Protocol: understand deeply the incentives, goals, and desires of your immediate management team. That includes…

• What problems are they worried about? What issues are getting dumped in their lap from higher up?
• How are they personally spending their work time? What meetings and projects do they make time for vs. skip?
• What are their (often secret) hopes and aspirations? Are they trying to get promoted? What will it take to land that promotion? What is the “next job” they want? What are they hoping to put on their resume when the dust settles?
• What public commitments and strong positions have they taken recently? Consistency of message is key in exec circles and they are likely repeating the same 2 or 3 talking points in every meeting. Not only does this establish momentum you can draft behind, but it also tells you what “no-go” positions to avoid…ideas and statements that would contradict or weaken the message they have been trying to send for the last N weeks.

Once in alignment with the boss’s incentives, your job is to create the environment needed for their strategy to unfold successfully. You will do this via resource allocation (e.g. ruthless prioritization), role assignment (e.g. granting authority and auspicious titles to similarly aligned lieutenants), and putting in place constraints/invariants that shape how the work happens (e.g. “all teams are full stack teams by default”).

Example: one of my team’s owned the backend API and frontend libraries that powered ~all feature development in Google Drive. I inherited a multi-year migration to a new API architecture that was intended to vastly improve the feature velocity of the whole org. Midway through the migration, I conducted a round of user interviews with various feature developers across the org and discovered they did not find the new solution developer friendly. While faster than the old thing, it fell far short of our goal of enabling rapid 24-hour iteration cycles with full-stack feature teams making contributions freely to the backend to keep work moving. I could have used that data to push for a large “developer velocity” program to fully land on the original vision, or slowed down the migration to ensure the quality was high, but I didn’t. Why? Zooming out to my boss’s level, nearly 40% of our SWEs were occupied across 3 different multi-year grungy infra migrations with no user-visible impact. In the intervening years, other existential problems were identified that desperately needed attention (i.e. reliability, competitive pressure) and feature work had slowed to trickle from the resulting staffing crunch. Pressure from upper management was high to ship ship ship, and we were slowly losing headcount to other orgs that did a better job of delivering user-visible impact. What my boss most needed in that moment was to get some of these migration projects off the books as fast as possible so she could update priorities to reflect the new opportunities and new problems that needed attention. Locking 100+ SWEs onto projects solving problems identified 3+ years ago killed our ability to be responsive to new information. So instead of making my migration even bigger, I focused on containing the scope and pacesetting: we finished the migration in 18 months (down from a projected 28-36 months). The goodwill I earned from this directly propelled me into a higher leadership position with even more opportunity for impact (oh, and btw, with this increased authority I was able to eventually get that developer velocity work prioritized…you have to play the long game).

The name of the game is resource allocation based on political physics.

Part 3: Manage Out with Shareholder Politics

The Trap: you try to be helpful to absolutely everyone. You constantly field random one-off feature requests from sister teams. When you hear that someone might not agree with what your team is doing or how they are doing it, you go out of your way to address that stakeholder’s issues. When planning time comes around, you have a laundry list of cross-functional requests you try to pack into the team’s quarterly commitments to support your myriad peers. You internalize just how much others depend on your team and what you build, and don’t see any way out of this…when your boss tells you to say “no,” you cannot fathom how that would even play out as there is no alternative.

The Mindset Shift: rather than managing stakeholders you need to manage shareholders. The metaphor to publicly-traded companies is an apt way to realize that some stakeholders just don’t matter, while others can be absolutely existentially critical. A power-interest grid will help you identify the true shareholders in your enterprise:

Someone with a lot of shares (think: voting rights) has high-interest and high-power. Maybe they’re your top internal customer and their success depends on using your platform to ship a product. Or they could be your immediate manager who sees your area/project as key part of their portfolio and career ambitions.

There are also those with a lot of formal authority (think: class A shares) but are content to let things play out without helping or undermining you. Your CTO may be fine letting her VPE’s figure things out without meddling.

Others have a few shares but not enough to really influence anything. That ivory tower architect 4 teams away has strong opinions about what database your team uses but spending any effort appeasing them is going to be a waste.

Finally there’s everyone else with neither power nor interest (think: the general public). They have little reason to interact with you and may occasionally grumble and groan but neither party truly cares enough to do anything about it.

The Protocol: take inventory of the shareholders in your world and chart them on a power-interest grid. Ask yourself questions like “if I overdelivered for this stakeholder, would it matter?”, “who has the ear of senior leadership?”, and “if this stakeholder didn’t like my very much, how much would it matter?”.

• Closely manage and invest in your relationship with high-power, high-interest shareholders. Regular 1:1s and 100% follow-through on every single commitment is key.
• Keep the high-power but low-interest shareholders satisfied. They may require extra attention when things aren’t going well to establish confidence, maintain independence, and/or receive additional support.
• Ensure the high-interest but lower-power shareholders are informed so they don’t suddenly become a source of problems. Consider amortizing the cost of managing this group with Customer Advisory Boards.
• Spend no effort on the low-interest, low-power shareholders.

Example: earlier this year, we tried to ship a UI refresh of our file viewer. As a common component used across hundreds of frontends, the launch would proceed in phases with different parts of the product getting updated over the course of the year. On our 2nd launch, the accessibility lead for our area blocked the launch citing failure to meet modern accessibility standards. This wasn’t a surprise to us: we were refreshing a 10+ year old UI that needed significant updates to become compliant and as such had placed that work out-of-scope as there was limited appetite to increase the size/cost of the project. Despite filing the appropriate exemption paperwork, the accessibility lead was adamant this needed to be addressed. Key to navigating this situation was figuring out where this shareholder fell on the power/interest spectrum. Their interest was ostensibly low (they literally ignored this project for more than a year, which is why this blocker emerged during launch and not at one of the myriad earlier reviews or when we filed the initial exemption paperwork) but power was high…very high. Not only did they own the approval for this launch, but they had the ear of our VP. Ignoring them or forcing our way through the blocker would blow up, made worse by the fact that over the next year we’d need to go through this same review and same fight for every incremental launch month over month! As such we formed a compromise where a few critical surfaces would launch to start collecting real user feedback, and after that we would address all the accessibility issues before proceeding to the remaining long-tail of launches. Our launch was unblocked, user feedback was extremely positive, and everything has proceeded peacefully since.

Putting MbM into Practice

At the heart of Management by Model is a principle of energy conservation. First is personal energy conservation: limiting interventions to systemic problems and only getting into the details enough to understand the system; avoiding overwork by aligning to your boss’s incentives above all else; and removing distractions by filtering out irrelevant shareholders. Second is organizational energy conservation: ensuring work is proceeding in an low-friction and effective way by shaping the environment, constraints, and communication pathways.

The goal is to lower the incremental energy cost (time, people, $$$$) of each unit of progress, and the amount of energetic input you must personally provide to make that happen…without slipping into outright abdication and absenteeism.

Keeping Your Model True to Reality

None of this works if your model of how work gets done is a fiction. Even if you came up on the IC ladder, your model will always drift the longer you stay in management. Model updates don’t come for free like they did when you were hands-on pushing PRs every single day. Consider…

1. Most of the information you receive is at least partially filtered or colored to sound better. Everyone wants to look good in front of their boss.
2. Any information you do gain is free of the texture and intuition that comes from actual lived experience. It’s one thing to hear “feature flag rollouts can be a little toilsome” and another altogether to experience the 3AM debugging session screaming “WHY WON’T THIS BOOLEAN JUST FLIP TO TRUE $#%$#(*%&”

At my core I remain an engineer, so I keep my mental model fresh by picking up the keyboard—but I do it carefully. I target the toil: flaky tests, noisy alerts, and cleanup tasks that sit off the critical path. This is a strategic protection of the team’s time. If an engineer pauses a major deliverable to fix these annoyances, they dilute their portfolio with a smorgasbord of invisible work that is hard to defend in a performance packet. I, however, can absorb that “run the engine” overhead with impunity. Since management impact rolls uphill, I can afford to do the unglamorous work that clears the runway for the team’s visible wins, while gaining valuable insight for updating my management model It’s a win-win-win!

When we have production incidents, I love to dive in and help debug…root causing can be wonderfully illuminating (word of caution, I am a systems engineer by training and have SRE experience so I am actually useful…don’t show up and start asking basic/obvious questions or distracting first responders with crackpot theories).

The same model drift problem occurs with shareholders. The key players will change over time. Being thick as thieves with the EM of your sister team is great, but a reorg could send them far away. A deadline crunch can make even the most helpful partners turn feral and tell you to buzz off. People (and even entire orgs) will fall in and out of favor with executives and other power brokers at completely unpredictable times. That Director of PM you’re spending all your energy appeasing will become a political pariah overnight….you might not know anything has happened/changed! It’s not like your VP is going to pop into the quarterly all-hands and say “oh, by the way, ignore any requests you get from the Platform org…it’s a total shit show and our CTO is not happy with them, we don’t want to be associated with that mess.” The protégé you’ve been mentoring for the last year will have their promo denied and fail to acquire any useful power or influence you can call upon. Womp womp.

To keep your shareholder model up to date, you need to put effort into establishing a network of trusted confidants that have eyes and ears in rooms you can’t access. You need to sow many such relationship seeds because some will fail to sprout, or the plant will wither in a drought.

Joining a New Company

All of this is why joining a new company in a middle or upper management role can be fraught with peril. You have absolutely no model of how work gets done in that environment. Relying on the model from your prior employer is a recipe for misfires ranging from overpromising to not-a-few pissed off employees.

When considering taking a new management role, ask your interviewers and hiring manager what they are looking for in the would-be occupant of this role. Are they looking to import a new way of working or missing experience? Does the company have a culture of curiosity and a commitment to truth? What’s the change budget? Maybe the whole reason they want YOU is to come in and bust things up…if so, fire away, use that legacy model baby!

That said, that probably isn’t reality. Most of the time, the team you inherit probably has some really solid virtues and your job is to tune and optimize without capsizing the entire vessel. Chesterton’s Fence and all that jazz. Some approaches I’ve taken to rapidly naturalizing and building a model of my new workplace include:

• Construct a value stream map.
• Fix a bug (yes, even as a VP).
• Do a round of listening sessions and 1:1s with TLs and key talent that are more than 2 or 3 hops away.
• Set up regular coffee chats with the 2nd-to-last person to join the company whose a little further along finding their feet.
• Identify all the critical roles in your org (specific jobs / titles that must be occupied and performing well or the org fails at its mandate).

I wrote a whole article that elaborates on these and many more tips…check it out!

Succeeding as a Mid-Career Hire

People Bugs

MbM won’t help you if most of your staff are constantly screwing up, your tripwires will go off constantly and you’ll drown in concurrent deep dive interventions.

Hence when it comes to talent management, especially for your top lieutenants, you’ll have to adopt a somewhat brutal “up or out” mentality. If they can’t OODA, address any skill gaps, and adjust their approach to deliver what you need, it’s time to have a frank conversation about alignment and roles that might be a better match. Then you can find someone else whose recent experience means they do what’s needed “off-the-shelf.”

I don’t like giving up on people. Just writing that paragraph above gives me a stomach ache. People can change, they can learn! I literally run a management coaching business after all (hello, welcome). That said, when these senior+ folks are missing the mark, the damage is multiplicative and often long lasting (see: key talent quitting). Time is of the essence. Reprogramming such individuals to meet your standards can be a full-time job on its own…one that doesn’t always pay off because they might still fail or quit from the sustained discomfort. If you need to reprogram multiple people, forget about it, it’s not happening. This is the management equivalent of a build vs. buy decision…but for people. Any time you decide to invest in someone (build) rather than hire a ready-to-go candidate (buy), it has to really be worth it.

Situational Leadership

MbM is not a silver bullet and does not apply in all circumstances.

• Building an entirely new org means starting with a null model. A more hands-on and demonstrative leadership style is needed to ensure the right patterns, behaviors, and systems are put into a place.
• Doomsday crises need a more active command-and-control leader. An existential competitive threat that could delete your business cannot be left to chance; these situations are often too dynamic for a large decentralized organization to handle appropriately…the body needs a brain!
• Once you have 3+ layers of management, your model will be woefully incomplete, your tripwires not sensitive enough, you won’t have enough visibility to know what to do about it, and almost everyone will be trying to manipulate you. At this scale, management turns into governance which requires a different playbook.

Ultimately, MbM assumes you have team that are largely stable and established in their structure, approach to work, shareholders, and goals…at least on the scale of the next 3-6 months.

Go forth and become a Model Manager

The proper response to increased scale isn’t just doing more of what you’re already doing, it’s recognizing you have a different job and your role in the system has shifted to governing how information flows and work gets done…all to maximize productivity (or maybe it’s “minimize wasted energy?”)

Doing this in 40 or so hours is no small feat, but it is doable:

1. Align your org’s incentives with your boss and the broader company’s success. Sift and winnow the existing problems/opportunities rather than creating new work. Prioritize the top #1 most impactful opportunity and swarm everything you have behind making that happen.
2. Create the environment necessary for that strategy to unfold successfully. Use careful process design, architecture principles, and other “work invariants” to shape org-wide behaviors. Carefully manage the high-interest and high-power shareholders to ensure your team has the support it needs.
3. Maintain an up-to-date model for how work actually gets done. Use tripwires like kanban/sprint ceremonies, project lifecycle gates, postmortem reviews, etc to detect deviations. Get curious, dig in, and (sometimes) intervene when you find a diff to keep work on track.

It’s so important I’ll say it again: leaders work on the system not in the system. It’s a bit black a white…but if you don’t then who else is going to do it…? No one. There’s huge opportunity cost to letting your org run through a series of implicit defaults. Get modeling!