Pace Layering: The Slow Executive Wins the Race

How companies learn and what happens after they are built

You can’t go 5 minutes without finding some thinkpiece breathlessly exhorting you to go faster: ship faster, learn faster, change faster, work faster, decide faster. This isn’t exactly new—if it isn’t the AI perverts of twenties, then it’s the Web 2.0 “Move Fast and Break Things” freaks of the teens, or the Agile zealots of the aughts. Lack of originality aside, no one can refute that GenAI has dramatically increased the temperature at work.

I’m here to give you the exact opposite message: slow the fuck down.

Don’t react too quickly to any single event. Think before you speak. Dispense mandates, principles, and strategies with parsimony. Inject latency between conversation and alignment, alignment and action.

I’m not saying this for exclusively humanistic, it-doesn’t-have-to-be-crazy-at-work reasons (although, it really doesn’t). Outright AI psychosis aside, I too salivate over shipping faster. Eric Ries’ Lean Startup is a prized possession. Though I am trapped within the belly of the beast (Corporate America), I relish decapitating bullshit ceremony and obstreperous process wonks. My bloodlust knows no bounds.

There are purely practical reasons to slow your roll.

When speed sabotages your organization

I have always prided myself on my ability to translate direction into action. Give me a hill to conquer and I can draw up a battle plan, organize the troops, and march in a matter of hours. It usually only takes me a few minutes to grok what my manager is saying, decide if it’s a good idea, and commit. Naturally, this has made me a perennial favorite and worked in my favor as an engineer, then tech lead, manager, and beyond.

Now as an executive it’s become a liability.

Our senior leadership had big ideas for the future structure of our teams. Larger spans of control, middle managers that owned tangible areas with concrete goals+strategies, fewer contractors and more FTEs, geo-aligned teams to encourage realtime collaboration. No one was losing their job (yay), just fixing the structure (double yay). All good stuff that effectively addressed very real problems observed over the past few months. I was bought in nearly instantly so when the mandate arrived to start implementing, I got to work.

Within 72 hours I had…

1. Designed the destination org structure.

2. Secured buy-in and excitement from my Directors.

3. Conducted a round a Nemawashi with all 15 of my product management counterparts (yes, you read right, one-five. Every Friday I take 15 shots in salute to the joy that is matrixed organizations…I then wake up and it’s Monday again…what gives!?)

4. Aligned on impacted projects and roadmap reprioritization.

5. Constructed an exhaustive run-of-show.

6. Began implementation.

Disaster struck after we had finished abut 25% of the reorg, cancelled a couple projects, reassigned about a dozen contractors, and gotten managers comfortable with their new scopes. The reorg mandate would change substantially. Parts that we were previously free to defer to later suddenly had deadlines just weeks out. Span of control targets went from suggestions to strict requirements. Contractor targets went from “you can keep a few as needed” to “you can keep none.”

The result was chaos:

• Product partners did not see this as a 2nd, separate change but rather Engineering changing the terms of the deal after it had been inked, blowing up their roadmaps.

• Managers who were previously told “nothing would change” were suddenly being told they needed to switch into entirely different roles in different orgs.

• Changes originally sequenced around graceful cutover points in project schedules now required development pauses and roadmap slips.

The resulting escalations would consume about a month of my life and we’re still dealing with the fallout of this months later.

The craziest part? Had I literally just done nothing and basically ignored my boss, all of this could have been avoided. We would have communicated a single, consistent change to everyone involved. There would still be heartburn but most of the turmoil was caused by the rug pull, not the change in and of itself.

Situations like this aren’t limited to organizational changes either.

A couple years ago, we were working on enabling Gemini to take action within Google Drive (think: move+rename files, organize folders, upload files, etc). Our tech lead at the time wanted a separate microservice for these APIs for a variety of reasons: they were highly privileged internal-only endpoints that needed different semantics from our public API, they would be used as part of long-running background tasks and needed different runtime management characteristics, general separation of responsibilities, and a tighter/faster SDLC to meet the demands of these super-P0 AI projects.

As 2nd chair, I mobilized the team. We grabbed our 2 best and brightest engineers and sold them hard on this exciting opportunity to build an entirely new server from scratch and earn major clout and career uplift contributing to Drive’s top OKR. They completed the POC in record time (I think it took like…2 weeks…to get into production, something unheard of at Google).

It was at this point that the truth surfaced. Our tech lead hadn’t actually built any real consensus for this direction and was just trying to force things through, coming into direct conflict with our senior leadership team in the process. The POC didn’t help convince anyone like he had hoped so the SLT declared the project dead and that we were going in a different direction.

I then had to go back to these superstar engineers, break the news, and ask them to help me clean up and delete everything. It was a really soul-crushing and discouraging experience for these folks who, by the end, had burned an entire quarter on this boondoggle. I would spend the next ~6 months going out of my way to retain these 2 with special assignments, growth opportunities, and extra attention.

Once again, had I just done nothing and let the natural architecture review process chew up and spit out my tech lead’s scheme all of this could have been avoided.

Organizational Rug Burn

Upper management moves at the speed of light.

Please, pick your jaw up off the floor. Don’t believe me?

What do you think we’re doing in all those meetings all day long? Back rubs and celebratory ass slaps? OK well there are definitely a few drum circles and networking events (shoot me with a gun). No, there’s a reason your 1:1 is rescheduled over and over for urgent meetings until a month later you finally have a 15-minute sync that can only be described as “disappointing.” The reason is that I am a Terrible Boss, but also that my calendar is wall-to-wall knife fights whose outcome will impact the lives of O(100)’s. An executive is a machine that turns alcohol coffee into decisions. Now multiply this by the 3…or 4…or 5 (fuck) layers of VPs at your company.

If every single one of those “decisions” turned into action (immediately or ever), nothing would ever get done. Teams would just be changing gears from one mandate to the next. The company’s PPO premiums would skyrocket from the intense whiplash and emotional exhaustion.

In their infancy, decisions are in constant flux, flip-flopping as the news traverses the org, backchannels open, and executives scurry between offices like a really bad episode of Scooby Doo. Even when there is seemingly alignment, one hand doesn’t know what the other one is doing leading to clashing directives. In one poignant example, we got our whole org to rally around a goal to ship all binaries twice-a-week, just for our C-Suite to sponsor a similar initiative from the other side of the company which instead said the target was P90 merge-to-deploy <24 hours. Our teams came to us asking “well, WTF is the actual goal?” Naturally, we played it off like this was all by design, that there was no conflict here, and nothing stupid just happened. lmao.

This is all to say you need time¹ for the World’s Shittiest Version of Paxos to reach stable consensus or your teams will experience reversals and conflicting demands. Your personal credibility will be left holding the bag because, well, from the perspective of the team you are the living incarnate of The Company. Good luck ever convincing your team to do anything after two or three instances of “opps, nevermind.”

The Neuroscience of Change

The core issue here is that of change budgets. There is a fixed physical and emotional capacity for the human beings in your organization to deal with change. Multiple biological systems conspire to enable the mind to cope with change but also make us initially resist change.

• Amygdala: wired to all major sensory nerves (optical, aural, olfactory, etc) and hypersensitive to change as a potential source of threat. The Amygdala triggers the famous fight/flight/freeze response and can even be triggered by social cues such as others around you experiencing fear.

• Entorhinal Cortex: maintains the mind’s mental map inclusive of both physical space and social networks including power relationships (hierarchy, dominance, competence) and affinity (trustworthiness, love, intimacy).

• Basal Ganglia: turns repeated behaviors into habit loops composed of cues, routines, and rewards. Habits take less mental energy to engage than novel behaviors.

• Habenula: restricts the flow of serotonin and dopamine (“feel good chemicals”) to discourage behaviors that tend to lead to punishment, suppressing both motivation and even physical body movement. In effect, it’s the chemical implementation of “fear of failure.”

Our brains are made to adapt to novel situations so we can change but it takes time and the expenditure of physical energy to suppress amygdala hijacking, form new mental maps in the entorhinal cortex, rewrite habits in the basal ganglia, and overcome learned helplessness in the Hebernula.

The combined effect of this biological machinery is change curve:

Britt Andreatta, Wired to Resist (2017)

The speed by which an individual moves through this curve is both context dependent and highly personal (see the Change Style Indicator if you are a fellow psychometric-enjoyer).

Because of the acclimation time, concomitant change is the norm not the exception. Most leaders (myself included) vastly underestimate the number of overlapping change curves playing out in their organization. Over the years I have made remarks to my myriad bosses about “lots of changes overwhelming the team” and 100% of the time received a reply to the effect of “WTF are you talking about?” This speaks to the very different personality profiles of executives who, as a cohort, tend to be high in openness to experience, low in neuroticism (Big 5), and thereby more comfortable with risk/uncertainty leading to a certain amount of change blindness. The reality is little more overwhelming than anyone realizes…how many of you are dealing with one or more of the following?

• A new job or role.

• A new manager.

• A switch to a different work station or workplace.

• A new leader of your function or organization.

• A change on your team (losing or gaining coworkers)

• A change in another department or team that affects you.

• A shift in process, policy, or procedure.

• An implementation of new or different technology.

• A drive to capture a new client or market.

• A move into a new regional or global territory with different cultures, laws, customs, or perhaps languages.

• A merger or acquisition.

• A geopolitical shift that affects the common market.

Not to mention personal changes occurring at home (births and kids growing up, aging parents, partner or friend drama, even just mundane crap like remodeling projects).

The human body cannot sustain never-ending change—it’s just too exhausting—so people begin to make choices: opting into some changes and opting out of others. Worse, your staff will learn to “perform” embracing change while in reality doing nothing because they assume (know) the change won’t stick. Half of the time I am just pretending to give-a-shit at work and it has always worked in my favor 🤷‍♂️

Think this isn’t happening in your org? Think again. A 2015 cross-sectional study of 513 middle managers found change fatigue prevalent in 47% of study participants.

When you thrash your team around by mobilizing changes too quickly, you create the conditions for change fatigue. Once you’re unable to mobilize your team, the death spiral has begun.

Pace Layer Violations

Beyond the human hardware upon which your decisions are realized, there are also structural and systemic reasons to slow down—what I think of as an “organizational speed limit.”

There is a natural tension that exists between stability and adaptability. Companies, organizations, teams, products, and infrastructure are all examples of persistent systems that must continuously absorb and even incorporate shocks.

• A company that fails to respond to a significant shift in consumer preferences will cease to exist.

• A team that cannot retool and incorporate new technology and professional methods will be replaced with one that can.

• A product which cannot be modified or extended to adapt to emergent customer problems will be outcompeted.

• A piece of infrastructure which cannot support the team’s productivity or product’s agenda will be deprecated.

These different components of a software enterprise form “layers” each with different scales, different rates of change. Fast-adapting layers act as buffers to help absorb change, only letting changes filter down to lower layers if they stand the test of time and scale. Slow-adapting layers provide a stable foundation enabling the continuity of everything above.

For example, your core infrastructure should provide a highly reliable, predictable set of platform primitives. If your core database engine changes in response to every single new product feature, your enterprise will quickly be subsumed by surprise outages, performance degradation, and development delays.

When I worked on Google Drive, there was an increasingly large need for complex async, eventually consistent processing (e.g. what happens when you share a deeply nested folder hierarchy with hundreds of users simultaneously?). We kept bolting on hacked up nightmares to our storage layer to support new features (DLP rules, labels, expansive ACL propagation, ownership transfers, etc) but eventually the system became unusable with async propagations taking days or silently failing. Our SLO dropped below 99.9% and enterprise customers were screaming.

Eventually, we built an async processing platform with a small set of core primitives including guaranteed processing semantics and multi-level priority queues. The processing engine changes almost never and most product needs are met by combining existing, stable primitives. Since then it’s been smooth sailing with >99.99% availability and rapid convergence on even the largest accounts.

Consider another common axis of change: team structures. Teams that successfully make it through the Tuckman Cycle become well-oiled machines. Shared performance standards, mutual accountability, codependence, and common goals unite workgroups and make them more than the sum of their parts. Thanks to effects like Transactive Memory (effectively, groups learn who knows what and how/when to call upon each other in the course of Getting Shit Done), a fully bonded team of 10 will produce more effective output then a random sampling of 10 SWEs.

Hence team structures should be only somewhat adaptable, reconstituting new teams only when strictly necessary (i.e. wrong skills for a major shift in direction). Instead, leaders should bring new problems to existing teams rather than forming new teams altogether.

This will lead to the appearance of strange bugs—back to Drive, we had a “Search” team and a “Sharing” team that for years worked on neither search nor sharing—but the consistently elevated productivity from keeping teams together will speak for itself.

I’m not quite sure what layers precisely exist in our domain, or even if the answer is universal, but it looks something like this:

While each layer is somewhat independent from the others, each layer influences and responds to the layers closest to it.

Markets evolve in response to mercurial and shifting consumer preferences (“fashion”). Company executives attempt to grapple with the evolving structure of Markets and translate that into coherent direction and product offerings. Teams are structured to optimally(?) implement said products. Infrastructure is built or bought which enables the many possible futures of the business.

All durable dynamic systems have this sort of structure—from ecology to business to markets to cities. It is what makes them adaptable and robust. Pace Layers first appeared as “shearing layers” in How Buildings Learn: What Happens After They are Built (1994) and was generalized to all persistent systems in The Clock of the Long Now (1999).

Reduce Speed: School Zone Ahead

Back to our parable: executives and middle managers who are too responsive to the layers above them, who move too quickly relative to the layers beneath them (products, teams, infrastructure) create a shearing effect. The slower layers cannot adapt quickly enough to absorb the shock of change and the enterprise effectively rips itself in half.

When I rushed to implement my boss’s ideas for organizational design and product direction, the slower layers were only halfway through grappling with those changes before different marching orders arrived.

Some wiseass will comment that change is inevitable, going too slow is more dangerous, and this is all working as intended. But that is absolutely the wrong takeaway. The job of management is implement human judgment within a moral context to integrate social activities. When you just passthrough any and all changes/shocks occurring above you, there is absolutely zero judgment being applied. It’s outright abdication of responsibility dressed up as urgency.

In response to new information, a discerning executive will develop a principled opinion, pressure test assumptions, probe and assess their team’s readiness for change, and implement a measured and methodical change management strategy. You’re paid to engineer, not gamble. Your actions affect the lives and livelihoods of real humans, you have a moral imperative to think carefully.

At an absolute minimum, leaders should understand the consensus dynamics of their organization.

• Who are the real power brokers that need to sign-off on something for it to become “real?”

• What exigencies and environmental factors could reverse this decision unexpectedly?

• How long does it take for rough consensus to form and who has a tendency to jump the gun?

• Historically, has there been tangible benefits to being on the bleeding edge?

• Who is sponsoring this decision and how much political capital do they have?

This will allow you to implement an effective filter and avoid organizational fads.²

So, does AI actually change anything?

Unfortunately, yes…I’m no luddite. Let’s use Pace Layers to understand the effects:

• Fashion: the amount of Business Fiction being published about AI is staggering. Need I say more? People will not shut the fuck up.

• Markets: new competitors have emerged that are moving 2-5x faster with much lower cost bases (2-3 SWEs instead of 20-30 for the same offering).

• Products: customer demand has visibly shifted. Some product categories now have AI features as outright must-haves even if the actual usage/adoption is nonexistent. RFPs are a bitch.

• Teams: coding is no longer the bottleneck and what used to require teams of specialist roles (SWE, PM, UXD, GTM) collaborating via structured artifacts (design docs, PRDs, crits, playbooks) are now being replaced with hybrid roles or even monocultures of amorphous “builders” who do a little bit of everything.

The “speed limit” of the slower layers (teams, products) is increasing and with it the pace at which executives need to translate ideas to action is also going up. In short, you cannot just operate business-as-usual.

Personally, I remain a bit uneasy about all of this. Notice anything missing above? Infrastructure hasn’t really experienced a tangible “speed up.” No, the armies of startups slinging slop and hyperscalers lining their Clouds with niche offerings (that conspicuously never exit beta/preview 👀) do not count. Agentic development may have solved coding but is decidedly dog shit at systems architecture: leaky abstractions, sky-high coupling, and incoherent ontologies.

But that’s not even really the issue. It’s not that platform development needs to speed up, but rather, are the current platform primitives and abstractions the ideal substrate for a product development ecosystem that is moving so much faster? We’re driving Ferrari’s down dirt roads. Someone needs to invent asphalt and start paving roads ASAP or we’re going to keep crashing our shiny new supercars.

A few of my long-time readers are working on “the platform primitives of the future” but it hasn’t really made it much further than theory. The companies actually building this stuff are largely flailing and just pushing narratives that dress up incremental improvements as breakthroughs. So far the towering intellects of Silicon Valley have contrived such genius ideas as:

• GitHub but what if it had at least one 9 of availability?

• Firebase but what if it barely worked and regularly loses your data?

• Step 1: Wrap everything in an MCP CLI; Step 2: ????; Step 3: Profit!

• Fuck object stores, filesystems are back baby!

• Generate a metric ton of Markdown, err no HTML. But wait, what if we call all those Markdown files a Wiki!?

• Run everything on the Edge for…reasons?

• Yikes, GPUs are expensive, never mind put it back in the datacenter.

• Get a 2nd mortgage to give your CI/CD provider even more money.

The only proof you need that we’re completely out of ideas: for some reason Docker and Kubernetes have survived the AI apocalypse relatively unscathed.

At the end of the day, platforms still need to be, well, platforms—I always go to Ian Nowland and Camille Fournier’s 4 traits of a platform: discerning product taste, software leverage that abstracts complexity, multitenancy, and operational excellence. We have strayed far from the light.

There is no happy ending to this rant. We need to rethink both our SDLC’s and platform primitives so that the infrastructure layer can keep pace with everything above it. Until then, we’re all going to be flying by the seat of our pants which just underscores my original point: slow the fuck down.

Your job as an executive is to be extremely discerning in what changes you unleash on the layers below you and to not assume Claude has somehow overnight obsoleted the decades of hard-won lessons and accumulated datapoints for what makes an organization thrive.

1. This isn’t exactly universal. There are plenty of stories of medium-large companies that have been able to turn on a dime without “consensus latency.” In most cases, they are outright lying about the amount of commitment actually achieved (looking at you Meta, Block, Cloudflare). In rare cases it’s a real honest-to-god masterclass in choreography and transformational leadership. You are probably not in such an organization. Most senior leaders are utterly spineless, avoid the most painful yet catalytic changes required, and instead enact some sort of perverse change theatre. Even when they don’t fall into this trap, most have unintentionally hired orgs replete with toxic malcontents who will manipulate any and all mandates to serve their career over the collective good. Sometimes the only answer is to spin out a new venture and start over with a clean slate.

2. A word of warning: at some point some asshat will tell you to “disagree and commit” as if quoting a piece of pop-management advice constitutes an actual argument. I’m as much a fan of Amazon’s leadership principles as anyone else, but 99% of the time this phrase is bandied about in bad faith. You’ll have to decide for yourself whether it’s worth the fight to push back or actually disagree-and-commit…or my personal favorite: pretend to go along and then do nothing.