Platform Engineering: Lessons from the Rise and Fall of eBay Velocity

This talk is two stories told against each other. The first is a delivery transformation that, by the speaker's account, doubled engineering productivity for every team the programme touched — a quarter of eBay's roughly 400 product teams while he was there, all of them today — and moved the organization from medium to high performance on the DORA metrics. The second is why that success did not change the company's trajectory, and why the person who led it was fired. Randy Shoup's thesis is that platform engineering executed well is necessary but nowhere near sufficient: delivery capability sits downstream of strategy, planning, and organizational culture, and improving it cannot compensate for dysfunction upstream of it.

Shoup was eBay's chief architect from 2020 to 2022, having previously worked on eBay's search engine from 2004 to 2011, with stints at Google, Stitch Fix, and WeWork in between. The InfoQ page lists the presentation at 49 minutes 17 seconds, files it under the "QCon San Francisco 2025" topic, and carries a publication date of April 14, 2026. Note on sources: these notes are drawn from the InfoQ transcript, which includes a three-question audience Q&A; that material is folded into the sections it belongs to rather than reproduced separately. Passages marked Context are supplementary explanation added for readers unfamiliar with a term or reference, not claims Shoup made.

What You Will Learn

• How to assess a large engineering organization with a value stream map before choosing what to fix, and why Shoup deliberately attacked only two of four lifecycle phases.
• The specific technical and process bottlenecks eBay removed, and the outcome and input metrics used to steer the work.
• The operating model — cross-functional leadership, embedded senior ICs, a cadence of standups and reviews, and quarterly cohorts — that scaled the initiative from 10% of teams to all of them.
• How Shoup converted teams' objections into his own team's backlog, and the psychological-safety conditions that made that possible.
• Shoup's four-part explanation of why the transformation did not change eBay's business outcome, including the mechanics of the innovator's dilemma, the "feature factory" incentive, and Westrum's pathological culture type.
• The lessons he draws about top-down, bottom-up, and "middle-out" change, and what he says he would do differently.

Where eBay Started

Shoup opens by establishing that eBay was not always a laggard. In its first decade from 1995, he lists things eBay invented or co-invented: database sharding, a real-time search engine he says had not been built anywhere before 2003, eventual consistency at large scale as an alternative to large synchronous database transactions, distributed tracing and centralized logging in 2000, feature flags in the early 2000s under a different name, and guaranteed messaging in 2006 that he characterizes as essentially Kafka with a transactional outbox, idempotent consumers, and readback. The list continues with SLO-driven configuration of system software, circuit breakers under a different name, graceful degradation, staged cluster deployment, and automated coordinated multi-cluster rollout. The point of the inventory is to set up the contrast: this was a technically pioneering organization, and the later problems were not a failure of engineering talent.

The business picture is where the contrast lands. Shoup gives eBay's gross merchandise volume — the total value of goods and services transacted — as $50 billion in 2007 and roughly $75 billion today, a 1.5x increase. Over the same period he says U.S. e-commerce grew 8x and inflation ran 56%, which makes the line flat in constant dollars. That flatness is not incidental scene-setting; it becomes the root cause he returns to when explaining organizational behavior later in the talk.

When he returned as chief architect in 2020, the organization consisted of about 3,000 engineers in roughly 400 teams in the core product organization, plus 2,000 engineers in core technology covering system software and infrastructure, including eBay's own data centers. There were 4,500 actively worked applications and services. Deployment frequency averaged once or twice a month per application. Lead time for change — commit to live on the site — was 10 days.

Assessing Before Acting

Shoup's first move was a value stream map of the end-to-end software lifecycle, which he divides into four phases in his own vocabulary: planning (how an idea becomes a project), software development (how a project becomes committed code), software delivery (how committed code becomes a feature customers can use), and post-release iteration (how the feature is changed once live). He could not interview all 5,000 engineers, so he surveyed a cross-section and found problems that recurred consistently.

Context: a value stream map is a Lean technique for drawing the full path work takes from request to delivered value, annotated with time spent and time waiting, so that the constraint is visible rather than assumed. Shoup names the Lean origin but does not define the practice.

Asked whether he should fix all of it at once, his answer is emphatic: absolutely not. They focused on the middle two phases, development and delivery, on the reasoning that improving software delivery makes everything else possible by enabling faster change and reducing the cost of change. He frames the batch-size argument in Nicole Forsgren's terms from the same conference's keynote: iterating monthly gives you twelve bites at the apple in a year, iterating daily gives you 365.

Architecture And Data Flow

The diagram below renders Shoup's four-phase lifecycle and the scope decision he made against it. This is my synthesis of his narrated value stream map, not a reproduction of a slide he showed. The phase names, their definitions, and the choice to focus on the middle two are his; the layout is mine.

flowchart LR
    P[Planning
idea to project] --> D[Software development
project to committed code]
    D --> S[Software delivery
commit to live feature]
    S --> R[Post-release iteration
change the live feature]
    R -.feedback.-> P
    subgraph Focus[Velocity Initiative scope]
        D
        S
    end

The dotted feedback edge reflects his stated goal of rapid feedback on experiment results informing subsequent planning. The gap between that intent and what actually happened at eBay is the subject of the second half of the talk: the delivery loop was closed, and the planning loop was not.

What the Velocity Initiative Achieved

The programme ran from 2020 and, Shoup reports, continues under his former team. He started it in 2020, was let go in 2022, and says the work covered 25% of teams while he was there and 100% now.

The headline outcome is a doubling of flow velocity — the number of features and bug fixes a team ships per unit of time, with the same team, size, and composition. On the DORA metrics, he reports deployment frequency improved 10x, lead time 5x from 10 days to 2 days, and change failure rate and time to recover each improved 3x despite not being targeted. In aggregate, eBay's teams moved from roughly the 35th percentile — solid medium performers, deploying and delivering on a one-week-to-one-month cadence — to roughly the 75th percentile high-performer band.

One transcript detail is worth flagging: when stating the 10x deployment-frequency improvement Shoup says "from 10 days to 1 to 2 days", but his own baseline of once or twice a month per application makes the "10 days" a slip for the lead-time figure he gives in the next sentence.

Shoup is blunt that none of the method was novel: he says he had no original ideas and was executing the standard DevOps, Accelerate, and DORA playbook. Operationally that meant serial bottleneck removal — find the constraint that blocks many teams, release it, then work on the one behind it, which he sums up with the line that once you solve problem number one, problem number two gets a promotion.

The Technical Work

The tangible engineering fell into a few buckets. They substantially reduced build, test, startup, and pull-request validation times. They invested heavily in the reliability and comprehensiveness of the common staging environment. They automated software upgrades, testing, deployment, and site-speed work — site speed here meaning user-experience latency.

Scaling brought a second kind of automation. eBay ran regular deployments for every one of its applications and services, including ones not actively maintained. Shoup's justification is operational readiness: if a bug or a security vulnerability turns up in a dormant service, you need to be able to re-release it safely, and a deployment path that has not been exercised in a year is not a path you can trust in an incident. They built what they called the patch pipeline for changes that should not alter behaviour — security vulnerability fixes, dependency upgrades, and migrations of eBay's many legacy and proprietary APIs — so that individual teams did not have to learn how to perform them.

The Process Work

An equal share of the wins were not technical at all. They streamlined team processes and code reviews, and removed what eBay called partner signoffs. Shoup describes the old rule concretely: if you owned a platform component or service, every upgrade required you to explicitly ask each consuming team to test against the new version and wait for all of them to agree before releasing. The release rate of a shared component was therefore set by its slowest consumer.

Context: the industry alternative Shoup gestures at with his complaint about missing service contracts is consumer-driven contract testing, where each consumer's expectations are captured as an automated test the provider runs in its own pipeline. That converts a synchronous human approval into an asynchronous machine check. He notes eBay was "still struggling to get interface contracts effective" but does not prescribe a specific technique.

The Operating Model

Shoup treats how the work was organized as at least as important as what was built. Leadership was explicitly cross-functional: he led from the platform and infrastructure side and Mark Weinberg led from product engineering, and they ran the programme jointly. Under that sat an embedding model — he hired senior individual contributors, architect and tech-lead calibre, into his team and sent them out to pair with engineers in specific areas of eBay, solving problems directly where they could and carrying the rest back to the central platform team as demand signal. Platform and product teams also worked together on new platform capabilities, with product teams volunteering as alpha testers.

The communication cadence was deliberate and dense:

Measurement was split into two layers. DORA metrics served as outcome metrics — the results they were trying to move. Measures of developer friction served as input metrics: they instrumented the entire end-to-end delivery pipeline with timing and success metrics for every step, giving a global view of where delivery was stalling plus the ability to drill into a specific business unit, team, build, or deployment. The improvement loop itself was Deming's Plan-Do-Check-Act: form an idea, try it, check whether it worked, do more of what worked.

Context: the distinction between outcome and input metrics matters practically. Outcome metrics tell you whether you are winning but are lagging and hard to act on directly; input metrics are leading indicators you can attach to a specific intervention. Shoup uses both terms without defining them.

For at least the first part of his tenure, the programme also had unusually strong executive backing. The CEO repeatedly highlighted the work at company all-hands, Shoup and Weinberg presented to eBay's board of directors, and it was mentioned on quarterly earnings calls. The message coming back down was that this was the most important initiative in the company and that it needed to go faster. His qualifier — "at least for the first part of the time that I was there" — is the only signal in the talk that this sponsorship did not hold, and it is worth reading against his later account of being fired.

Turning Objections Into a Backlog

The most transferable tactic in the talk is how Shoup ran his team meetings. He would arrive as, in his words, your friendly neighbourhood chief architect, observe that a team deployed once a month, and ask them to tell him every reason they could not deploy every day. Teams responded with long lists — one asked whether he wanted the whole list or just the top 150. The shift was in what happened next: where the platform team had previously not acted on those complaints, Shoup treated the list as his own team's backlog. Their impediments became his work items, which he says generated substantial collaboration and partnership from the teams.

Shoup pairs this tactic with a cultural precondition he addresses directly. eBay had what he repeatedly calls a culture of fear, so making it psychologically safe to admit you were struggling mattered. His framing to teams was that deploying once a month does not make you a terrible person, it means you deploy once a month, and the question is whether you can get to twice, three times, ten times. Removing the moral valence from the metric is what makes the honest inventory of impediments possible.

The same partnership logic was applied outward to the functions usually experienced as blockers. Rather than accepting "I could deploy daily except for security" or "except for SOX compliance" or "except for long-running accessibility tests" or "except for localization", he took each constraint to the owning function and worked out where it should be solved — shifting checks left, running them offline, or making them faster.

Culture and Scaling

Shoup emphasises making the work fun, and his mechanism is regular weekly progress on visible metrics, on the theory that winning and making forward progress is a large part of why people become engineers. The team-of-teams forum turned that into peer influence: a team that improved its code review or rollout process would be asked what it did, and would answer with both the ideas and the tooling. Regular team demos were held as part of the same forum, giving teams a standing occasion to celebrate their wins in front of their peers.

The most interesting second-order effect he reports is that product teams stopped being pure consumers of platform tooling. He notes that the traditional split — platform teams automate and write tools, product teams consume them — is not terrible, but product engineers are engineers too. Once the conversation was open, product teams built their own automation around code review, performance and site-speed testing, and accessibility testing, none of which his team touched. He attributes this to inspiration rather than direction.

Scaling was by cohort. They started with pilot teams representing about 10% of engineers — roughly 300 of 3,000, or 40 of 400 teams — and worked with them intensively for the first year. With bottlenecks already removed and the approach proven, they added another 10-15% of teams each quarter, producing what he describes as successive S-curves of adoption maturity.

Context: the S-curve shape is the standard adoption pattern — slow start while a cohort learns, rapid improvement, then a plateau as the easy gains are taken. Staggering cohorts means an experienced group is available to help the next one, and it caps how much change the central team must support at once.

Mobile Modernization

eBay shipped iOS and Android apps very early, around 2005-2006, which Shoup notes meant building its own frameworks because none existed, and consequently accumulating fifteen years of cruft. Modernization meant moving to SwiftUI and Jetpack Compose and remodularizing the architecture, but the change he singles out as most impactful is release cadence: monthly when he arrived in 2020, and now achievable in a day.

The story he tells about getting there is a useful template for changing a sceptic's mind. His mobile release manager was the most sceptical person involved and told him weekly releases could not be done. Shoup's response was to set it as a stretch goal for the end of 2021 and try anyway. Around April they attempted a first bi-weekly release, which went acceptably, and they did several more. By July the team observed that bi-weekly releases were going smoothly precisely because each contained fewer changes, which made diagnosing problems easier — and proposed weekly releases themselves. They shipped the first weekly release seven months in and never reverted. Shoup is careful to credit the team rather than himself, and quotes the release manager's later description of what helped: air cover and rational small tests of the process.

Context: the reason this worked connects back to the batch-size argument from the assessment phase, and the team stated the causal step themselves — two weeks of changes are easier to diagnose than a month of them. The wider observation that the evidence which converted the sceptic was produced by running the change itself is my reading, not a point Shoup makes explicitly.

AI Across the SDLC

Shoup credits this work to his former team after his departure, describing it as introducing AI across the entire lifecycle — starting in CI and expanding both rightward into production and leftward into daily developer workflow. He counts 25 or 30 independent points of integration and points to a 25-minute cdCon talk by his former team member Aravind Kannan for the detail.

The applications he lists fall into three groups. The expected ones are code generation, test generation, test data, legacy code migrations, PR summarization, and automated code review assisting human reviewers. The less obvious set is using AI to manage the CI pipelines themselves: analyzing why a build failed, producing a root-cause analysis when the failure is serious, analyzing test failures, and predictively optimizing pipeline efficiency. The third group runs downstream and sideways — deployment monitoring with automated rollbacks, and LLM-generated developer support documentation and feedback analysis.

Why Velocity Did Not Save the Company

Shoup's honest accounting distinguishes what was achieved from what was intended. Against the target state he set out at the start, he judges that they fairly achieved fast build and test iteration, daily merges and deploys for many applications if not for every engineer, a fully automated test and deploy pipeline through to the site including canary deployments, considerably more production iteration with feature flags, and good progress on end-to-end monitoring. Notably, the planning-phase goals are absent from that list. He offers four reasons the business outcome did not follow.

Strategy and Planning

The first is Clay Christensen's innovator's dilemma: a successful pioneer finds it hard to disrupt itself, and the more successful the business model, the harder it is. He cites Netflix's move from DVDs to streaming as one of the few counterexamples. His sketch of how a competitor disrupts eBay is to not try to be eBay for everything, but to become the eBay of one category — used electronics, used musical instruments, used clothing — and he observes he has just named several real competitors without naming them.

The second is learned helplessness. Everyone who has grown up inside eBay over the last fifteen years has experienced a flat business, and in a flat, unchanging environment the adaptive behaviour is risk aversion. He is careful to frame this as rational adaptation rather than a character flaw.

Third, that risk aversion is well earned, and his explanation of why is the sharpest analytical point in this section. eBay's relationship with its seller community meant user-facing improvements were often met with revolt. Working on search from 2004, he found that improving results for buyers reliably angered sellers. His example is spelling correction: when the engine started correcting misspellings, it destroyed the business of hundreds of people who made a living finding misspelled listings, buying low, and selling high. Improving the ranking function had the same effect on those who profited from digging out good listings buried in poor rankings. His generalization is that eBay is large enough to be an economy in its own right, and every inefficiency in it is an arbitrage opportunity somebody is already exploiting. A platform improvement is therefore never purely an improvement; it is the removal of someone's income.

Fourth, centralized waterfall planning. There is an annual multi-month company-wide planning cycle. An initiative can only happen if the executive team approves it, and it can only reach the executive team if it is big enough to make the list presented to them. Anything smaller than a tens-of-teams project can therefore only survive by attaching itself to a larger project — his analogy is a rider on a congressional bill. Downstream of that, plans are set 12 to 18 months in advance with little real-time autonomy to adjust to market conditions. He notes eBay has a statistically strong experimentation platform, but says it was often used to confirm decisions made 18 months earlier and, in the culture of fear, to prove nothing had broken — which inverts the purpose of experimentation from discovery to defence.

Execution and Delivery

eBay has a history of massive coordinated releases with end-to-end cycle times measured in quarters or years, more than one of which involved 50 or more of its 400 teams. His worked example is eBay managed payments. eBay acquired PayPal in 2002 and separated in 2015, with a separation agreement under which PayPal remained eBay's payment provider for five years. That created a hard 2020 deadline by which eBay had to be able to process credit cards itself. He hedges both inputs himself — he says he does not think the work took the whole five years and that it probably started around the last three — and, with roughly 2,000 people on it, converts three years times 2,000 into about $1.5 billion in personnel costs alone. The outcome for sellers was worse in one respect: PayPal paid out immediately, whereas clearing through the banking system takes a day or three.

The second failure mode he names is the feature factory. In a flat business where you cannot demonstrably drive outcomes, the adaptive strategy for personal success is to hit milestones predictably and be seen to do activity. His illustration is from 2004: a VP told an all-hands of about a thousand people that they should be proud to have delivered 5,000 train seats to the business that quarter, a train seat being two engineer-weeks of work. Restated, that is 10,000 person-weeks, which he prices at around $60 million — and which says nothing at all about whether revenue, profitability, or reliability improved. The measurement is of effort supplied, not value delivered.

Technology Dead-Ends

The same organization that pioneered the techniques in the opening inventory became a laggard in several areas. Shoup lists HTML generated from XML via XSLT, which he says did not age well; service-oriented architecture built on shared databases rather than per-service databases; a custom OpenStack fork that drifted far from mainline, followed by a custom Kubernetes fork that did the same; Hadoop still serving as the data warehouse; a proprietary JavaScript framework called Marko; and proprietary mobile frameworks until the recent SwiftUI and Jetpack Compose migration. He adds that eBay does not use the public cloud, runs its own data centres, is a consumer rather than a notable maintainer of open source, and was late to microservices with isolated databases, continuous delivery, fully automated testing without human involvement, effective interface contracts, automated canary deployment, and GraphQL.

He is explicit that some of these were not wrong when made — in 2006 neither SwiftUI nor Jetpack Compose existed, so building your own mobile framework was the only option.

Context: the recurring shape here is the maintained-fork problem. Forking an open-source platform to meet a real local need is cheap at the moment of forking and expensive forever after, because every upstream release widens the gap you must either re-merge or abandon. Shoup names the OpenStack and Kubernetes forks and their drift; the general characterization of the cost is mine.

Organizational Culture

Shoup treats culture as the driver behind much of the above, and grounds the claim in the research from Accelerate by Nicole Forsgren and colleagues, which he describes as demonstrating that organizational culture predicts software delivery performance and also organizational performance. The book applies the sociologist Ron Westrum's typology of pathological, bureaucratic, and generative cultures, with generative cultures doing well on the DORA metrics, bureaucratic ones middling, and pathological ones struggling.

His assessment of eBay is pathological, and he states repeatedly that he says this because he wants the company to succeed. The symptoms he lists: a culture of fear that makes the organization highly political; acknowledging failure being treated as rude or threatening; executive empire building under a zero-sum scarcity mindset, where maximizing your success means maximizing your span of control and headcount; and a sense of exceptionalism that produces not-invented-here, so that industry-standard approaches are considered after proprietary ones rather than adopted by default. He identifies long tenure as one contributing factor — in his team of 150 he had five people past their 20-year anniversary — while being careful that this is about accumulated organizational monoculture, not about the individuals, whom he calls great people.

The specific event that ended his tenure, which he calls the third rail he touched, was pointing out to a peer that having requirements-gathering sprints, then design sprints, then development sprints, then QA sprints, then rollout sprints is not agile, it is waterfall with sprint labels. He describes that peer's organization as having a culture of terror, with significant empire building, and notes that after earlier quality problems the person had personally approved every deployment their team made for a year. He adds that after he was fired, that person was too.

Trade-offs And Limitations

The talk's own retrospective is the clearest statement of its limits. Shoup's first lesson is about the shape of transformation: it obviously needs to be top-down, with executive and leadership support, and obviously bottom-up, with support from the people doing the work. The thing he says he would do better is middle-out — engaging peer leaders laterally and getting them invested. His tactical corollary is that when you encounter resistance you should route around it the way the internet does, rather than confronting it head-on, and he concedes that his own personality inclines toward confrontation rather than routing. His second lesson is to see the whole board. Technical improvement was necessary and he remains proud of the improvements they made, but the big unfilled gap — one he hopes is filled sometime — was going upstream into planning and making it less waterfall-driven and less top-down. That is the same gap the four-phase diagram makes visible: he deliberately scoped planning out of the initiative, and nothing else he fixed could substitute for it.

An audience member pushed on whether routing around a resistant leader leaves them feeling sidelined and threatened. Shoup's answer refines the tactic rather than defending it. In a culture of fear, he argues, telling someone they could be better is itself perceived as threatening, so the direct offer to help does not land. The fear of missing out that results from being bypassed is, in his view, a feature: over the five years, teams that had opted out saw other teams double their productivity and asked for the same treatment. He describes that as exactly how the mechanism should work. The unstated condition, which the talk does not address, is that this requires visible wins elsewhere to create the pull.

A second questioner observed that the seeds of a company's present problems are usually sown five to ten years earlier, and asked what should have changed around 2015. Shoup declines to answer specifically — he was an individual contributor from 2004 to 2011 and away for nine years, and says he does not know the state of the company in 2015 — while agreeing with the premise that cultures are long-lived and that today's constraints were set years or decades ago. Pressed on what the company should have done, his answer is to resolve the issues in the talk, with yearly planning as the example: having a plan is good, but you must be able to deviate from it. He closes that answer with a plea to the audience — "Please help them make it better. I couldn't."

A third question asked whether a middle-out approach could build a cultural foundation durable enough to survive executive turnover. Shoup's answer is honest but partial: he says executive change was not what affected this programme — the problem was executive non-change — and he does not claim middle-out solves the turnover problem. He characterizes both failure modes with the Anna Karenina principle, noting you want just enough change, a Goldilocks situation, with a new executive arriving with entirely different ideas being as damaging as an incumbent preserving the old way indefinitely.

Two further caveats apply. The productivity, DORA, and percentile figures are his reported internal results from a single organization, not independently published measurements. And his closing observation limits generalization in the other direction: changing a 5,000-engineer organization is much harder than changing a 100-engineer one — he now works at Thrive Market, roughly the latter size, and reports being happy transforming it. The operating model described here was resourced by a dedicated central team with a full-time cross-functional leadership pair, which is not available at every scale.

Practical Takeaways

• Map the full lifecycle before choosing a target, and pick the phase whose improvement unlocks the others. Shoup chose development and delivery because faster, cheaper change is the precondition for everything upstream and downstream of it.
• Ask each team to list every reason they cannot deploy daily, then adopt that list as your platform backlog. This converts a complaint channel into a prioritized work queue and buys collaboration in the process.
• Remove the moral judgment from delivery metrics before you publish them. Teams will not give you an honest impediment list if a low number is treated as a character verdict.
• Instrument every step of the delivery pipeline with timing and success rates, and keep DORA as your outcome layer while friction measures serve as the input layer you act on.
• Take blockers to the owning function rather than routing around them technically. Security, compliance, accessibility, and localization requirements are usually negotiable in where and when they are satisfied, not in whether.
• Scale by staggered cohorts, starting with about 10% of teams for an extended first cycle, so that each wave benefits from bottlenecks already removed.
• Keep the deployment path warm for dormant services. A patch pipeline for behaviour-preserving changes is what makes emergency security releases safe.
• Beat scepticism with a bounded experiment rather than an argument. The mobile team's move to weekly releases came from letting the sceptic run bi-weekly releases and observe that smaller batches were easier to diagnose.
• Cultivate lateral peer leaders as deliberately as you cultivate executive sponsorship, and where a peer is immovable, invest your effort where wins are achievable and let the results create demand.
• Audit for measurement that rewards effort rather than outcome. "Person-weeks delivered" is a cost report presented as an achievement.
• Do not stop at the phases you scoped. Shoup's own verdict is that the delivery improvement was real and insufficient, and that the unfinished work was making planning incremental and adjustable. If you cannot eventually reach the planning phase, set expectations that the business outcome may not move.

Key Terms

• Flow velocity — features and bug fixes shipped per unit of time by a team of constant size and composition; Shoup's headline outcome measure.
• DORA metrics — deployment frequency, lead time for change, change failure rate, and time to restore service, used here as outcome metrics.
• Value stream map — a Lean diagram of the end-to-end path from idea to delivered value, used to locate the constraint.
• Partner signoff — eBay's former requirement that every consumer of a shared component explicitly approve each new version before release.
• Patch pipeline — automation for deploying behaviour-preserving changes such as security fixes and dependency upgrades across many services.
• PDCA — Deming's Plan-Do-Check-Act improvement cycle.
• Innovator's dilemma — Clay Christensen's observation that successful incumbents struggle to disrupt their own profitable business model.
• Feature factory — an organization that measures and rewards volume of delivered work rather than the outcomes that work produces.
• Westrum culture typology — a classification of organizational cultures as pathological, bureaucratic, or generative, used in Accelerate as a predictor of delivery and business performance.
• Middle-out change — Shoup's term for engaging peer leaders laterally, as a complement to top-down sponsorship and bottom-up participation.

Reference: Platform Engineering: Lessons from the Rise and Fall of eBay Velocity