Building Software at Scale in the AI & Cloud Era

← the whole book on one page

Chapter 6: The Internal Platform as a Product — Paths, Adoption, and Developer Experience

“Get users on the system quickly, work with them closely, and let their needs and problems drive the design.” — T. A. Dolotta, R. C. Haight and J. R. Mashey, 1978

Every software company of any size ends up building a second product whose customers are on its own payroll. The product is the collection of templates, pipelines, credentials, runtimes and documents through which its engineers turn an idea into a running service, and the customers are those engineers. Chapter 1 called this the system that builds the system. This chapter asks how that product should be built: how to learn what its customers need, how to build the smallest thing that meets the need, how to persuade 40 teams to use it and move off what they had before, and how to know whether any of it made their work better. These are product questions, and the uncomfortable discovery of the last decade is that most internal platforms were never asked them. They were built as infrastructure and announced as policy, and many of them stand half-used, a portal with a fine front page and a small fraction of the company behind it.

The Architecture book has already argued why a company at Encore’s scale needs a platform and what one contains, and the Resilience book has argued how a platform is run. We will not argue either again. What neither book could show, because both were about the platform as a thing, is the method by which a platform group finds its next piece of work and gets it adopted. That method has a surprisingly long history. Its clearest early instance is a machine at Bell Labs in the 1970s that served a thousand programmers whose real targets were other computers, and whose builders wrote down how they ran it in words that read today like a platform team’s charter.

Encore’s platform group has nine teams and 40 people, about a tenth of engineering, and early in year nine it did something it had never done before: it hired a product manager and began interviewing its users. Verified Resale is the first large new service to be built since then, and the Resale team’s journey from an empty repository to its first production deploy became the group’s first serious piece of research. The Resale service was created from the template on its first day, yet its first production deploy took 23 working days, and 15 of them were spent waiting. That wait is why the platform group built the two roads it showed to be missing: a way to issue partner credentials without a ticket, and a shared way to deliver webhooks to partners, which three teams had each built for themselves. This chapter follows the platform group as it builds both, migrates the three home-grown senders onto the shared one, and measures whether the next partner-facing service ships faster.

6.1 Why Platforms, Again

The Programmer’s Workbench

In 1973 UNIX was still a small research system in Bell Labs’ Computing Science Research Center, running on a handful of PDP-11 minicomputers. Elsewhere in Bell Labs, much larger groups of programmers wrote the business software that ran the Bell System, and that software did not run on PDP-11s at all. It ran on big batch machines. The installation that later became famous served programmers whose targets were two IBM 370/168s, two UNIVAC 1100-series systems and an XDS Sigma 5, each with its own job-control language, editors and habits. A programmer working for one of those machines wrote code on it, submitted jobs to it and waited for it, and carried around decks of punched cards in the meantime. Evan Ivie suggested, in the middle of 1973, a different arrangement: as much of the development as possible should be done on a computer dedicated to that task, and only the finished work sent to the target. Rudd Canaday, one of the designers of the original UNIX file system, led the department that built it, and the first PDP-11/45 was installed late that year. They called it the Programmer’s Workbench, or PWB.

The workbench was a collection of small tools aimed at the friction of a programmer’s day. A Remote Job Entry subsystem sent jobs from the workbench to the target machines and brought their output back. John Mashey wrote the PWB shell, which came before the Bourne shell, and Dick Haight wrote find, cpio and expr. Marc Rochkind’s Source Code Control System (SCCS), the first version-control system to run on UNIX, became one of its tools: Rochkind had begun SCCS in 1972 on an IBM System/370 and rewrote it in C for UNIX in 1973, and it first shipped publicly with the workbench. PWB/UNIX 1.0 was released on 1 July 1977, and much of it later flowed into the UNIX that the rest of the industry used. Ivie described the principle in Communications of the ACM that October, and in 1978 Ted Dolotta, Haight and Mashey described the system and how it had been run in the Bell System Technical Journal. Figure 6.1 draws the arrangement and its dates.

Figure 6.1 — The Programmer’s Workbench as a schematic: programmers on machines dedicated to development, small tools on top, and Remote Job Entry carrying finished work to the batch machines that had once received their card decks.

That second paper is the reason PWB belongs at the head of this chapter. Its authors set out their approach in a handful of sentences. Get users on the system quickly, work with them closely, and let their needs and problems drive the design. They “forcefully nurtured a close, continuing dialogue” with their users. They chose to follow the UNIX habit of building small, independent tools rather than large, interrelated ones, and they changed UNIX itself only “after much deliberation, and only when major gains can be made.” That last rule is a limit the team placed on its own surface, which is what the Resilience book means by thinness. The users, the paper records, were at first “a bit wary of what then seemed like a radical idea.” Then “as word about the system spread, demand for service grew rapidly, almost always outrunning the supply.” By the end of 1977 the main installation ran seven PDP-11s for about 1,100 people, which the authors called the largest known UNIX installation in the world, and most of those users had “thrown away their decks of cards.”

One phrase in the paper seems at first to argue against this chapter’s title. The team aimed “to provide to our users tools, rather than products.” Read in context, the contrast is between small composable tools and large packaged systems that do everything one way, and the team’s practice was exactly what we now call treating a platform as a product: users as customers, their problems as the backlog, their continued use as the test. We should also be careful about what the sources do not say. Nothing in them tells us whether Bell Labs’ programmers were free to ignore the workbench, and it would be easy to retell PWB as a platform nobody mandated. What the paper does record is pull: demand outran supply, and the authors credited the system’s qualities with making users “want to use our system.” That is the measure this chapter will apply to every capability Encore builds. A platform succeeds when the people it serves come to it because their day is easier there, and the work of building it consists mostly of finding out what would make their day easier.

What is already settled

A good deal of the ground has been covered, in this book and in the others, and it saves pages to say where. Figure 6.2 is the map. Each row is an idea this chapter will use without arguing for it again, with the place where it is argued and the team at Encore that owns the corresponding machinery today.

Figure 6.2 — What this chapter assumes, where it is argued, and who at Encore owns it.

What remains is the method. The Architecture book says a platform must be built as a product and must win its users; it does not, for reasons of space, show how a platform group discovers what to build, writes it down, builds it so it stays current, gets it adopted, retires what it replaces and measures the result. That is this chapter’s work.

The platform paradox

A platform speeds teams up by taking choices away from them, and this is less of a contradiction than it sounds. Gregor Hohpe, in Platform Strategy (2024), states it as a dichotomy that platforms dissolve: “Platforms break through the perceived dichotomy between harmonization and innovation.” A team that need not choose a database, a broker, a deployment tool and a signing scheme for each new service has more attention left for the thing it was formed to build. One of the section headings in that chapter makes the point with paper: A4 does not stifle creativity. The German standard DIN 476 fixed the A series of paper sizes in 1922, and a century of writers, printers and office-equipment makers has built freely on top of it, precisely because nobody has to negotiate the size of a sheet any more.

The practical question is which choices to remove. Camille Fournier and Ian Nowland, in Platform Engineering (2024), frame it as limiting primitives while minimizing overhead: a platform should narrow the set of building blocks teams assemble services from, without adding so much process around those blocks that teams route around it. A large music festival offers a working picture. Most festivals provide a shared backline, the drum kit, amplifiers and keyboards that stay on stage all weekend, so that one band can follow another after a changeover of minutes. A band that insists on its own amplifier may bring it, with notice and at its own cost. The shared backline is why a festival can put 12 acts on one stage in a day, and nobody thinks the bands less creative for using it. The picture breaks where software’s time scales differ. The backline serves for one weekend and goes back to the rental company. A platform’s primitives stay in service for years, and every service built on them inherits their limits for as long as it lives, so the choice of what to standardize carries much more weight than a festival’s choice of drum kit.

Encore’s rule is written down and short. New services choose from one managed relational database family and publish events on the existing event backbone. The rule applies to new services only. Seat Inventory’s event-sourced store predates it and sits in the exception ledger as a recorded, permanent exception with a named owner, as the Architecture book’s Section 15.3 requires, and any other team that needs something different may leave the road on the same terms. The rule’s rationale is recorded beside it: two families of database and two brokers would double what the Runtime and Event Backbone teams must patch, upgrade and support at three in the morning, and nothing Encore’s teams have asked for in three years needed a second of either.

Platform or service desk?

Not everything a platform group offers is a platform. Hohpe’s sharpest chapter title puts it as “IT Platform and IT Services Are Antonyms”, and his test is self-service: “Self-service is the default mechanism through which IT platforms assure low friction,” and “instead of filing a ticket, teams directly provision a virtual machine.” A capability that a team can use only by asking a person is a service desk, however good the people at the desk may be. The distinction has evidence behind it. DORA’s (DevOps Research and Assessment) Accelerate State of DevOps Report 2024 measured developer independence, defined as developers’ ability to perform their tasks for the entire application lifecycle without relying on an enabling team, and found a 5% improvement in productivity where platform users could complete their tasks without involving one.

The method that follows from the test is unglamorous. Take a quarter’s worth of the requests that reached the platform group, by ticket, chat message or email, and classify them by kind. The Operations book’s Section 3.1 measured toil in the same spirit; here the aim is narrower. Each kind of request that recurs is a candidate for a self-service interface, and the counts say which candidates matter. Encore’s platform group ran this audit over the quarter before the Resale team formed. About 1,100 requests had arrived. The most common kind was a grant of database access, the second was setting up a new repository and pipeline by hand where the template did not fit, and the third was partner credentials. Since the Rowmate key leak told in the Resilience book’s Section 7.2, every partner client has used 15-minute tokens bound to a client certificate, and every such client identity was being issued by a person on the Security Engineering team in answer to a ticket. The security model had improved; obtaining an identity under it still meant waiting for a person.

The audit taught the group something else, about its own front door. Requests arrived through four channels, and some never arrived at all, because teams had stopped asking. DORA 2024 found that the commonest ways platform teams hear from users are informal conversations and issue trackers, and that not collecting feedback at all hurts. So the group gave itself a single public request channel, a published response target for each kind of request, weekly office hours and a support rotation, which is ordinary service practice and is what makes the next audit’s data worth counting.

Swamps and shadow platforms

Fournier and Nowland give a name to the condition a platform exists to prevent: the over-general swamp. It arrives in two steps. First the choice of building blocks explodes, as every cloud provider and open-source project offers another way to do each thing. Then the operational demands on each service rise, for security, observability and compliance. Product teams end up writing and maintaining a great deal of glue between the blocks they chose and the demands they must meet, and each team’s glue is a little different. The swamp is a form of accidental complexity in the sense the Architecture book borrows from Brooks, multiplied by the number of teams.

Where the platform is missing, teams build their own, and these shadow platforms are the best evidence a platform group has of unmet need. Fournier and Nowland give the management of shadow platforms a section of its own; the useful stance is to treat each one as a finding rather than a transgression, and then to decide deliberately whether to adopt it as the platform’s own, absorb its users into something better, or leave it alone because it serves one team well. Chapter 1 recorded the finding that started this chapter: Encore’s developer survey named three home-grown webhook senders. Partner APIs sent inventory and listing events to partners, Venue Integrations sent sales events to venues’ own systems, and Billing & Payouts sent payout notices to organizers’ finance tools. Each signed its payloads differently, each retried on its own schedule, and one did not retry at all. All three worked. None was anyone’s job to improve, and every partner integrating with Encore had to learn three dialects.

A capability’s life

A capability’s relation to its users changes as it matures, and the platform group plans that change on purpose. The interaction modes of Team Topologies (collaboration, X-as-a-Service and facilitating) belong to team design, and Section 9.2 treats them there; for a platform capability they read as a life cycle. A new capability starts in collaboration with the first team that needs it, because nobody yet knows its right shape, and moves to a self-service interface once the shape settles. Encore’s Security Engineering team and the Resale team collaborated on partner credentials for one quarter, from the Resale team’s formation in month 4, and agreed at the outset on the date when the collaboration would end and the self-service interface would become the only way in: the first day of month 8. Fixing the date in advance protected both sides. Without it, collaboration tends to persist because it is pleasant, and the platform team becomes a permanent extension of its first customer.

Recap. The Programmer’s Workbench shows that the method is old: a dedicated machine for developers, small tools aimed at daily friction, a close conversation with users, and growth by demand. A platform narrows its users’ choices to speed them up, so the decisions about what to standardize, and the open exceptions to it, deserve to be written down. A capability is a platform only if teams can use it without asking someone, and both the requests that still reach the platform group and the shadow platforms teams build for themselves show where it falls short.

Exercise 6.1. Classify the last 50 requests your platform or operations team received, by kind. Which kind would you turn into a self-service interface first, and why that one? If it is not the most frequent kind, say what made it outrank the others.

6.2 Discovering What Developers Need

Interviewing colleagues

Developers are users, and the established way to learn what users need is to ask them about what actually happened. The Products book’s Section 3.1 teaches story-based interviewing in full, following Teresa Torres’s Continuous Discovery Habits (2021): ask about a specific recent episode, follow it step by step, and listen for where it went wrong, because people describe their past behavior far more accurately than they predict their future wishes. A developer asked what the platform should build next will name a tool they read about last week. A developer asked to walk through the last time they set up a new service will name the three days they spent waiting for a firewall rule, often without realizing it is the answer.

Interviewing colleagues differs from interviewing customers in two ways, and both help. The interviewer and the interviewee share an employer, so politeness runs in both directions: an engineer may soften a complaint about a team they will need favors from next quarter. And the interviewer can check what they hear. A customer’s account of their week cannot be compared with their keyboard, but a developer’s account of their last deploy can be compared with the repository history, the pipeline logs and the ticket timestamps. Encore’s platform group does exactly that after each interview, and the comparison is often more revealing than the interview itself: people remember the wait that annoyed them and forget the one they had grown used to.

Someone has to own this work, and it is not naturally anyone’s. Fournier and Nowland describe four pillars of platform engineering, product, development, breadth and operations, and product is the pillar a group of infrastructure engineers is least likely to staff by instinct. Encore’s group hired its first product manager, Hana, in month 2, two months after the Verified Resale memo. In her first six weeks she and a tech lead from the Developer Portal team interviewed five teams about the last new service each had built, and the Resale team, then forming, became the sixth, interviewed as its journey happened.

Mapping the journey

Interviews produce stories, and to compare stories the group needs a map. Section 1.1 introduced the method, value-stream mapping, which grew out of Toyota’s material-and-information-flow diagrams and makes waiting visible as a quantity. It transfers to software with little change, because a change moving toward production is, like a part moving through a factory, mostly waiting.

A developer journey map works best when it follows one journey at a time, such as from idea to first production deploy for a new service, and marks every handoff. Figure 6.3 is the map of the Resale team’s first deploy, built from the interviews and checked against timestamps. Read the shaded bars first.

Figure 6.3 — The Resale team’s journey to its first production deploy. Two-thirds of the 23 working days were waiting, nine for partner credentials and six for a security review of a sender the team should not have had to write; all of it was for two capabilities the platform did not offer.

The map changes the conversation. Before it, the Resale team’s complaint was that “getting started is slow”, which is true of every new service at every company and suggests no particular remedy. After it, the complaint has a shape: nine days spent waiting for credentials, and six waiting for a review of code the team should never have had to write. The fourth webhook sender is the more telling of the two. The Resale team was not careless in writing it; there was simply nowhere else to go, so it copied the nearest one and inherited that sender’s quirks along with its code.

Once several journeys are mapped, the frictions they share can be ranked. Encore ranks them by working days lost multiplied by the number of teams affected in the last two quarters. That rule is Encore’s own heuristic, with no validation behind it, and it has a known blind spot: a friction that strikes rarely but badly, such as a migration that blocks a team for a month once a year, scores lower than its pain deserves. The group therefore reads the ranking as the start of a discussion, and keeps a short list of rare, severe frictions beside it.

Desire paths as data

The Architecture book’s Section 15.1 introduced desire paths as a metaphor, and noted where it breaks: grass records footsteps without being asked, and a platform team has to go looking. Here is how to look. Most organizations already have three instruments that can show where teams have worn their own tracks.

The first is code search. Copied pipeline definitions, vendored scripts and near-identical helper modules show up as clusters of similar text across repositories, and each cluster is a workaround someone found worth copying. The second is the dependency graph: when three internal libraries do the same job and each has its own set of importers, the duplication is visible without reading any code. The third is the wiki’s own analytics. The pages everyone bookmarks, and the ones edited most often by people outside the team that wrote them, mark the places where a document is doing the work a tool should do. None of these instruments has published evidence of its yield behind it; they are technique, and their findings still need an interview to say why the track was worn.

Encore found its webhook senders the simple way. Every webhook from Encore carries a signature header, X-Encore-Signature, so that receivers can check where the call came from, and a code search for the header’s name returned the three senders, the Resale team’s new fourth, and one more surprise: a fifth caller, which Section 6.4 will meet. Spotify has published a larger version of the same technique. In a 2026 post on dataset migrations, its engineers describe using lineage data in Backstage together with code search to find which repositories needed a change, before handing those repositories to Fleetshift, its tool for running a change across many repositories as automated pull requests.

The thinnest increment

Discovery always finds more than a platform group can build, so the next step is to choose, and the thinnest viable platform of Team Topologies is the principle. A platform group should build the smallest thing that removes real pain, and only then the next. Encore scores each candidate on four questions: how many teams it affects, how much time it saves them, what risk it removes or adds, and what it costs to build and run. The scoring is Encore’s own rubric. It is deliberately crude, because its job is to make the group argue about the same four things, and a number to the decimal place would add nothing to that argument.

Before building anything that scores well, the group asks one more question, borrowed from Simon Wardley’s mapping: how evolved is this capability in the industry? The Architecture book’s Chapter 13 places capabilities on Wardley’s evolution axis, from genesis through custom-built and product to commodity, and the rule that follows is to adopt or buy what has become a product or commodity and build only what is particular to the business. Certificate authorities and token exchange are commodities, and Encore buys and adopts them. What is particular to Encore is the policy: which scopes a partner may hold, how its identity is bound to its contract, how quickly it can be revoked. That is what the platform group builds.

The rubric chose two increments in the first half of year nine: self-service partner credentials and shared webhook delivery. The loudest request in the same period, a new visual theme for the internal portal with a dark mode, scored near the bottom. It affected every team and saved none of them a minute. The group published the ranking with its reasons, which turned out to matter as much as the choice, because the teams who had asked for the theme could see that their request had been weighed.

There is published testimony that this order of work is the one that succeeds. In 2023 Helen Greul, Spotify’s head of engineering for Backstage, told The New Stack that among organizations that had installed Backstage, “the average Backstage adoption rate is stuck at 10%.” Her explanation was that adopters “fail to understand the challenges developers are facing and build the thinnest viable platform around solving those first.” It is practitioner testimony and not a study, but it comes from the people with the widest view of internal portals, and it describes a failure that Encore’s audit had just shown it how to avoid.

The path brief

Before a line of a new path is built, Encore writes it a one-page brief. The format is borrowed from product discipline: it is a cousin of the briefs in the Products book and of the pitches in Basecamp’s Shape Up, cut down to what a platform needs. It names the user, the job the path does for them, what “done” means, what is out of scope, and how adoption will be measured.

The term “golden path” has a history worth knowing before writing one. Spotify’s engineers described their golden paths in 2020 as “the ‘opinionated and supported’ path to ‘build something’”, and they built them to cure what they called “rumour-driven development”, a fragmented ecosystem in which engineers learned how to build things by asking whoever sat nearby. Spotify’s first golden paths were tutorials: one per engineering discipline, seven at the time, each owned by the teams of that discipline. The first began as a Hack Week project. So the original golden path was a document before it was a template, and that is a useful corrective to read beside the Architecture book’s four-part anatomy. A path is first an opinion about how something should be built, written down and supported. Templates, workflows and scorecards come later, as ways of making the opinion cheap to follow.

Encore’s brief for its partner-facing path reads as follows.

Path: partner-facing service                 Owner: Web & API Paths, Security Engineering
User: a stream-aligned team whose service is called by, or calls, a partner
Job: from `exposure: partner` in the manifest to a first production call
     with a partner's sandbox, without opening a ticket
Done when: credentials and webhook delivery are self-service; docs and
     sample code are in the template; the first two teams have shipped on it
Out of scope: partner onboarding and certification (Partner APIs);
     the public API's style rules (Public API); new signing algorithms
Adoption measure: share of `exposure: partner` services on the path,
     six months after each first deploy
Outcome measure: working days from repository creation to first
     production deploy, for new partner-facing services

The brief’s most useful line is the one about scope. Each item in it is something a team will ask for in the first month, and the brief records in advance that the answer is “not on this path”, along with who owns the question instead.

Recap. Interview developers about recent concrete episodes and check what they say against repositories and logs. Map one journey at a time with value stream mapping, so that waiting becomes a number, and rank frictions knowing the ranking’s blind spots. Code search, dependency graphs and wiki analytics show where teams have built their own tracks. Choose the thinnest increment, build only what is particular to the business, and write each path a one-page brief before building it.

Exercise 6.2. Map one developer journey in your organization from idea to first production deploy, recording for each step its working days, its waiting and what the wait was for, as Figure 6.3 does, and checking each step against timestamps. Mark the three longest waits and say which of them a self-service interface could remove.

6.3 Building the Platform

The manifest as an API

A platform needs to know what each service is before it can do anything for it. The Architecture book’s Section 15.2 described the registry entry; the next step is to treat the file that feeds the registry as the platform’s main interface. A service manifest is a declarative file kept in each service’s repository that records what the platform needs to know about the service: its owner, its tier, its dependencies, how it is exposed and what classes of data it holds. The idea is widely practised. Backstage’s catalog descriptor, catalog-info.yaml, records a component’s owner, life cycle, system and dependencies, and Score, a platform-agnostic workload specification, was accepted as a sandbox project of the Cloud Native Computing Foundation (CNCF) in July 2024.

Encore goes one step further than recording. Its platform reads each manifest and acts on it: the registry entry, the catalog page, the alert rules, the access policies and the provisioning requests are all rendered from the manifest and reconciled continuously, by the kind of loop the Resilience book’s Section 3.1 describes. Few companies go this far, and it is Encore’s choice. Its cost is that the manifest’s schema becomes the most depended-on interface Encore has, read by every platform capability and written by every team. For Verified Resale, the schema gained one value, exposure: partner, and that value is what switches on the two new capabilities.

# service.yaml — read by the platform; edits go through review like code
schema: encore.service/v4
name: resale
owner: team-resale
tier: 1                       # purchase-path tier: on-sale freeze applies
exposure: partner             # internal | partner | public
dependsOn: [seat-inventory, orders, bot-screening]
data: [fan-pii, payment-reference]
partner:
  scopes: [listings:read, resale:write]
  webhooks:
    events: [resale_listing_created, resale_ticket_reissued]
    retry: {profile: standard}  # per-partner overrides allowed

Because the manifest is an interface, Encore governs its schema the way the Architecture book’s Section 7.2 governs a public API, turned inward. Fields may be added, and an existing field’s meaning does not change. A new optional field is a minor version, and a removed or renamed one is a major version with a migration and a date. The platform reads at least two major versions at once, so that teams can move in their own sprint. And the schema has a changelog, because the people who read it are the same ones who will be surprised if it changes without one.

Templates that keep up

A template that generates a new service once, and then forgets it, starts to go out of date the day after it is used. The pipeline it produced, the base image it pinned, the alert rules and the logging setup all stay as they were, while the platform moves on. A year later the company has a hundred services, each frozen at the version of the template that happened to be current when its team began, and every improvement to the template reaches only the services not yet written. This drift is the platform’s view of the version skew that Section 2.5 deals with in code.

It matters which tools can fix this, because some popular ones cannot. Backstage’s software templates are scaffolders: they run once, on demand, and changing a template does not touch any component it already created. Two other approaches can carry a newer template into an existing repository. Copier records the answers given when a project was generated, in a .copier-answers.yml file, and copier update re-applies a newer tagged version of the template using those answers, surfacing merge conflicts where the project has diverged; cruft does the same for cookiecutter templates. The second approach works at fleet scale: dependency bots such as Renovate and Dependabot, and change runners such as Spotify’s Fleetshift, open automated pull requests across many repositories at once.

Encore uses both. Its templates are versioned and published with changelogs, and a bot opens an update pull request in each repository when a new template version is released. The platform group watches one number, the count of services more than two template versions behind. When it first measured that number, in year nine, it was 74. The count is a measure of the platform’s own work, and it says nothing against the teams whose services lag: a pull request that a team cannot merge without a day of conflict resolution is a sign the template change was badly made.

Self-service instead of tickets

Each recurring kind of request from the audit in Section 6.1 is a candidate for a declarative request with a reconciler behind it: the team states what it wants, in the manifest or through an API, and the platform makes it so and keeps it so. The machinery of reconciliation belongs to the Resilience book’s Section 3.1, and the Architecture book’s Section 15.2 names the tools, Crossplane and Kratix among them. What this chapter adds is a warning about the shape of what gets built.

Hohpe calls it the grim wrapper. A platform team, meaning well, wraps a cloud service in its own simplified interface, and at first the wrapper is a kindness. Then the cloud service gains features the wrapper does not expose, the wrapper’s simplicity turns out to have been easiness that hides necessary choices, the documentation and community knowledge for the underlying service no longer apply, and the platform team finds itself operating a homemade abstraction indefinitely. Two of his other chapter titles point to the remedy: “Build Abstractions Not Illusions” and “Failure Doesn’t Respect Abstraction”. An abstraction is honest when, if the thing underneath breaks, its user can still understand what broke.

Encore’s partner-credential API is built to that standard. A team with exposure: partner in its manifest calls one endpoint to issue a sandbox client identity for a named partner, bound to the partner’s certificate and limited to the scopes the manifest declares; production identities follow automatically once Partner APIs records the partner’s certification. The API’s error responses are written for the failures that actually happen, and they name them plainly: the partner’s certificate expires in nine days; this client was revoked at a stated time by a named person; the token-exchange service is degraded and existing tokens will keep working until they expire. Each of those conditions is something a product team would otherwise discover from a partner’s angry email, and the API’s job is to make sure the team hears first and understands what it heard.

Documentation is part of the path, and it is built with the same care. Every path’s guide lives beside the code it describes, rendered into the portal from the repository in the docs-as-code style that Backstage’s TechDocs supports, and a path’s release is not finished until its guide has changed with it. Spotify’s experience is the reason for the rule. Its golden paths began as tutorials and were refined by the feedback of new hires, the readers least able to fill a gap from memory.

The portal comes last

An internal developer portal shows the catalog of services, their documentation and owners, and the paths a team can start from. The Architecture book names the products, Backstage, Port and Cortex, and there is nothing wrong with any of them. The risk lies in the order of work. A portal built before the paths exist is a front door that opens onto an empty room, and practitioners describe this as a common way for platform programs to fail. In the same 2023 interview, Greul described organizations stalling at the proof-of-concept stage, faced with more than 70 steps and 100 plug-ins before they could begin. That is testimony, with no measurement behind it, and it agrees with Encore’s own history: its portal predates this chapter by several years, and it has always been the most visible part of the platform while doing the least to remove waiting.

So Encore builds each capability as an API first, then as a command-line interface (CLI) that teams can script, and then as a page in the portal. The order matters for a reason beyond economy. An API forces the platform group to decide exactly what the capability does, while a portal form can hide an unfinished capability behind a pleasant layout. The catalog follows the same principle: every catalog entry is rendered from the service’s manifest and never edited by hand, so that the catalog cannot drift from the services it describes. Machine interfaces matter for a newer reason too. As the Architecture book’s Section 15.4 describes, coding agents reach golden paths through the platform’s APIs and Model Context Protocol (MCP) tools; that practice is young, and it is one more argument for building the API first.

Releasing the platform itself

A platform capability is software that other teams depend on, so it is released the way the best of Encore’s own APIs are released. It has a version. It is tested against its consumers, using the consumer-driven contract tests of Section 3.3, so that a change that would break a team’s integration fails in the platform’s pipeline and never in the team’s. It moves through stages with stated criteria. And it publishes release notes written for the people who use it, which means saying what changes for them and what they must do, if anything, before saying what the platform team found interesting about the work. Fournier and Nowland give planning and delivery a chapter of their own, and the reason is plain enough: a platform’s release discipline is how it earns the trust that its users extend every time they build on it.

Encore’s shared webhook delivery followed this course. It went into beta in month 7 with one consumer, the Resale team, under a written agreement that the interface could still change. It reached general availability in month 9, once three criteria were met: two teams in production, the contract tests of both consumers passing on every platform change, and a service level objective (SLO) of its own, under the Resilience book’s Section 3.5, that 99.5% of webhook events reach a healthy partner endpoint within 60 s over 28 days. Before general availability, any team adopting it accepted the risk of change in writing. After it, the interface fell under the same deprecation rules as everything else the platform offers, and changes to its delivery logic rolled out progressively, as the Resilience book’s Chapter 4 describes for any platform change.

Recap. The service manifest is the platform’s main interface, so its schema is versioned and changed with the care of a public API. Templates need a way to reach the services they already generated, which one-shot scaffolders cannot provide and update tools and fleet-wide pull requests can. Self-service interfaces should be honest abstractions that name their failures plainly, documentation is part of each path, the portal is built last, and the platform’s own capabilities are versioned, tested against their consumers and released in stages.

Exercise 6.3. Write the manifest fields your organization’s next service would need. Mark which fields the platform could act on automatically today, which it could act on with work, and which are only recorded.

6.4 Adoption and Migration

The easy road

A platform capability is adopted the way any innovation is, gradually and unevenly, and it helps to see adoption as a sequence of stages. The sociologist Everett Rogers, in Diffusion of Innovations (1962), described the decision to adopt as a process that runs from knowledge through persuasion, decision and implementation to confirmation, and his most lasting point was that people abandon innovations at every stage, including after adopting them. Encore measures each path with a funnel of four stages of its own, shaped by Rogers’s process: a team is aware of the path, has tried it, has adopted it for a production service, and is still using it six months later. The funnel is Encore’s own instrument, and its last stage is the one that matters, because a path that teams try and then quietly leave has failed in a way that a launch-day count would never show.

Figure 6.4 shows the funnel for shared webhook delivery across the 14 services whose manifests declared exposure: partner by month 11.

Figure 6.4 — The adoption funnel for shared webhook delivery. At month 9 seven services had tried it and two had adopted it; the stall between “tried” and “adopted” lasted until retries became configurable per partner. No count yet exists for the six-month stage.

The stall at “tried” was the most useful thing the funnel showed. Teams tried the shared delivery in their sandboxes, liked it, and did not move production traffic onto it, and interviews found out why within a week. The service retried every failed delivery on one fixed schedule, and Rowmate’s endpoint rate-limited Encore’s calls during large on-sales, so a fixed schedule would have hammered Rowmate at exactly the wrong moment. Partner APIs’ own sender had a hand-tuned backoff for Rowmate. Moving to the shared service would have meant losing it. Once retry profiles became configurable per partner, in the manifest, the stall cleared.

A path wins when it is the default and costs less effort than any detour, and both conditions can be engineered. The default is the template: a new service whose manifest says exposure: partner gets the shared delivery and the credential API without anyone asking. The cost of a detour is set by the exception path of the Architecture book’s Section 15.3, which lets a team leave the road provided it carries the cost, records the exception, names an owner and accepts an expiry date. What Encore deliberately does not do is mandate. DORA 2024 found that platforms were associated with lower throughput and stability particularly when they were mandated for the entire application lifecycle, which supports the stance the Resilience book’s Section 3.5 takes: the road must keep earning its traffic.

Opt-outs are data. Each exception in the ledger is a team saying the path does not fit its work, and the platform group reads the ledger every month as part of discovery. When the same kind of exception appears for the third time, the group treats it as a missing path and opens an interview, which is how per-partner retries would have been found even without the funnel.

Lighthouse teams

The first team on a new path does more than use it. Its experience becomes the story every other team hears, and so the order in which a platform takes on its users shapes how fast trust in it grows. Fournier and Nowland put this as optimizing growth in trust by ordering use cases. The first users should have a real need, so that the path is tested against real work, and their success should be visible to others, so that it persuades. The same idea, applied to external customers, is the design-partner program in the Products book’s Section 3.3.

Verified Resale was the obvious lighthouse for the partner-facing path, and the platform group chose it deliberately. Its need was real and urgent, since the team was already writing a fourth webhook sender. Its success would be seen by everyone, since the whole company was watching the bet. And it was a demanding first user, which is worth more than it sounds: a path that survives a demanding first team has fewer surprises left for the second. The choice carried a risk the group named in advance. A failure on so visible a service would be remembered for years, so the platform group staffed the collaboration fully for its quarter and put the Resale team’s go-live dates on its own plan.

Migration campaigns

New services can be steered onto a path by the template. Existing services must be migrated, and migrations are where platforms most often fail their users. Each one costs the teams that must move a little of their attention, every team receives several at once, and none of them was in the team’s plan. Fournier and Nowland give migrations and sunsetting a chapter of their own, and the published accounts agree on the principle: the platform should carry the cost, doing as much of the work as possible itself, so that each product team spends as little as possible. The Resilience book’s Section 3.5 adds Encore’s rule that the platform team performs the first three migrations itself before writing the self-service guide, and the Architecture book’s Section 15.3 lists the parts of a deprecation campaign. What is left to describe is how a campaign is run.

The best published account is Spotify’s. In “Tech Migrations, the Spotify Way” (2020), Saunak Chakrabarti and Jenni Lee describe a company of about 300 squads that, by 2017, was sending its engineers a steady stream of uncoordinated deprecation emails. Spotify’s response was to treat migrations as a portfolio. A single prioritized migrations map was negotiated with its technical architecture group, and each migration was costed before it went on the map. “Each migration is owned by a PM,” with alpha and beta groups trying it before everyone else, and with automated pull requests doing the mechanical work. Progress was tracked by squad on a page in Backstage, and each migration was driven “until it’s 100% complete.” The stated aim was to “remove the need to expose our engineering teams to 99% of migrations.” For the mechanics of changing thousands of files, Section 2.5 has already described Google’s tooling for large-scale changes, which shards one logical change into many reviewable pieces by ownership; a campaign is the layer of planning and persuasion that sits above that tooling.

Encore’s campaign to retire the three home-grown webhook senders ran for one quarter, from month 9 to the end of month 11, and its plan fitted on one page.

Campaign: retire home-grown webhook senders      Owner: Hana (platform PM)
Inventory: Partner APIs, Venue Integrations, Billing & Payouts senders;
           callers found by code search for `X-Encore-Signature`
Done by platform: migrations 1–3 by hand (Web & API Paths); then a
           codemod plus an automated pull request per remaining caller
Support: office hours Tue/Thu; one named engineer per migrating team
Tracking: campaign dashboard of callers remaining, by owning team
Brownouts: two, announced four weeks ahead; never within 48 h of an on-sale
End date: last day of month 11; old senders removed, code deleted

The order inside the campaign followed the same reasoning as the lighthouse. Partner APIs went first, because its sender was the largest and its team had been overloaded since Verified Resale was announced, as Section 9.2 recounts; taking the work off its hands was the campaign’s best advertisement. Billing & Payouts went last, because payout notices are seen by organizers’ finance departments and the team wanted a month of the shared service’s track record before trusting it with them.

Deprecation that finishes

Migrations stall in their last few percent. The inventory says three callers remain, and nobody can say who owns two of them; the dashboard has been at 94% for six weeks; the old system costs little to keep running, so it keeps running. Hyrum’s Law, which the Architecture book’s Section 7.2 and Section 2.5 both discuss, explains why the tail is so long: with enough users, every observable behavior of a system is depended on by somebody, including users nobody knows about. Software Engineering at Google’s chapter on deprecation adds the organizational half: without an explicit owner, a deprecation is unlikely to make meaningful progress. I spent a decade maintaining a widely used open-source library, and every removal in that time taught the same lesson: the callers nobody has found usually announce themselves on the day the thing they used is removed.

Brownouts are the established way to find them first. A brownout is a scheduled, announced and temporary shutdown of a deprecated capability, short enough to do no lasting harm and long enough to make its hidden dependents fail visibly while the old path can still be restored. GitHub’s retirement of password authentication for its API is the clearest published case. GitHub announced the deprecation on 14 February 2020, explaining that “during a brownout, password authentication will temporarily fail.” It ran brownouts on 30 September and 28 October 2020, each in two windows, from 07:00 to 10:00 and from 16:00 to 19:00 UTC, and from 13 November 2020 at 16:00 UTC password authentication to the API returned an error for good. Each brownout turned an unknown number of forgotten scripts into a known list of failures with owners attached, at a time of GitHub’s choosing.

Encore ran two brownouts of its old senders, in month 10 and early in month 11, each for two hours on a Tuesday morning, scheduled through the on-sale calendar so that neither fell near a large sale. The first found nothing new. The second found the fifth caller that code search had already shown and nobody had claimed: a nightly batch job in the Box Office team, written years earlier, which imported Venue Integrations’ sender library to notify one venue’s finance system of the day’s in-venue sales. The job’s author had moved teams. The brownout failed it at the next run, the venue noticed by morning, and the job was moved to the shared service within the week. Without the brownout, the same failure would have arrived on the day the old library was deleted, with no way back. The senders were removed and their code deleted on the last day of month 11, on the date the campaign had announced.

Removal has one more step that is easy to forget: preventing new uses. Google’s deprecation chapter describes tooling that stops new callers from appearing while old ones are migrated, and Encore’s equivalent is a lint rule in the pipeline that rejects any new code setting the X-Encore-Signature header outside the shared service. The rule exists because the fourth sender was written by a careful team with nowhere else to go, and the next team would have been in the same position.

Telling forty teams

A message sent once to 40 teams is received by a handful. People read announcements when they are relevant to the work in front of them, and for most teams, most of the time, a platform change is not. So the platform group says each thing several times, in several places, in the terms of each audience. Spotify’s migration account makes the same point: after the email flood of 2017, it consolidated its communications and explained each migration’s value separately to engineers, managers and leadership. The Architecture book’s Section 15.5 covers the argument to leadership for funding a platform; here the audience is the engineers who must change their code.

Encore’s mechanisms are ordinary and kept up. Each path has a changelog. Each release gets a short demonstration at the monthly engineering forum. And the platform newsletter, sent every two weeks, reports each path’s adoption funnel in the form of Figure 6.4, so that teams can see where their colleagues stand and the platform group is held publicly to the numbers it chose.

Recap. Adoption is a funnel with leaks at every stage, and the stage after adoption, continued use, is the one that counts; stalls are found by asking the teams stuck at them. A path wins by being the default and the cheapest route, with a priced exception path for teams that leave it, and the exception ledger feeds discovery. Order the first users for trust, run migrations as campaigns with an owner, a plan and an end date, find hidden dependents with announced brownouts, and block new uses of what is being removed.

Exercise 6.4. Draft the campaign for one migration your organization owes, in the form of Encore’s one-page plan: inventory, the work the platform will do itself, support, tracking, brownout dates and the end date.

6.5 Measuring Developer Experience

Three lenses

There are three well-established ways to look at developers’ work, and they answer different questions. DORA’s delivery metrics, set out by Nicole Forsgren, Jez Humble and Gene Kim in Accelerate (2018) and extended since, measure the outcomes of software delivery: how often a team deploys, how long a change takes to reach production, how often changes fail, and how quickly service is restored. SPACE, from Forsgren, Margaret-Anne Storey and colleagues in 2021, is a menu of five dimensions of developer productivity, satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow, with the advice to measure several at once and never one alone. DevEx, from Abi Noda, Storey, Forsgren and Michaela Greiler in 2023, names three dimensions of the developer’s own experience: feedback loops, cognitive load and flow state.

The choice among them depends on the question. If we want to know whether the organization delivers well, DORA’s metrics are the instrument, and Chapter 10’s Section 10.5 uses them for exactly that. If we want to know whether a platform made developers’ work better, DevEx is the closer fit, because a platform’s purpose, in the Architecture book’s terms, is to reduce cognitive load and shorten feedback loops, and those are two of DevEx’s three dimensions. SPACE is the check against measuring too narrowly. This section measures the platform’s effect, and leaves delivery at large to Chapter 10.

Surveys done properly

Developers’ own reports are the place to begin, for two reasons. They are quick to collect, and they see what systems cannot: no log records that an engineer spent a morning confused by a template, or gave up on a path and wrote their own. Accelerate devotes two chapters to the case for surveys and to psychometrics, the discipline of building questions whose answers can be trusted, and the Operations book’s Section 7.4 uses Westrum’s validated items in the same tradition. A survey earns trust when its items are tested, its cadence is stable and its response rate is published alongside its results, because a survey answered by a third of engineers describes a third of engineers.

The harder discipline is tying each question to a decision. Software Engineering at Google’s chapter on measuring engineering productivity, by Ciera Jaspan, gives the method its name: Goals–Signals–Metrics (GSM). “A goal is a desired end result.” “A signal is how you might know that you’ve achieved the end result.” “A metric is proxy for a signal.” The chapter adds that Google tries “to triangulate on the truth using mixed methods”, setting survey answers beside logs. LinkedIn published a reusable framework built on the same method in 2023, its Developer Productivity and Happiness Framework, and it is a good starting point for anyone writing their own. Figure 6.5 shows GSM applied to Encore’s partner-facing path.

Figure 6.5 — Goals–Signals–Metrics for the partner-facing path. Every metric names the decision it exists to inform.

Encore runs a quarterly developer experience survey with ten core items that never change, so that one quarter can be compared with the next. Among them: “In the last quarter, I could get a change to production without waiting on another team.” “I understand how to use the platform capabilities my service needs.” “When something on the platform fails, I can tell why.” Each path may add a few items of its own for a quarter or two. In the quarter after the path reached general availability, 71% of engineers answered, and that figure is printed at the top of every result.

System metrics beside the survey

Surveys tell us how the work felt. System metrics tell us what happened, and the two are most useful side by side, which is the combination the DevEx paper recommends. For a platform, the system metrics worth having are few and concrete: time to first production deploy for a new service; the feedback time of build and test, which Chapter 4 owns and which a platform affects through its templates; time to a new engineer’s first merged change; and the time teams spend waiting for anything to be provisioned. Each needs a written definition before anyone builds a dashboard for it. “Time to first deploy” can start at the first commit, the creation of the repository or the approval of the work, and the three choices give very different numbers; a team that changes the definition halfway through a year has two half-years of data instead of one.

Encore defines time to first deploy as working days from repository creation to the first production deploy that serves real traffic, and measures it for every new service. The Resale team’s was 23. The second partner-facing service to start after shared webhook delivery reached general availability was the Festivals team’s festival feed, which sends event and pass updates to the festival app, and it was created early in month 11. Its time to first production deploy was four working days. One service is not a trend, and the group says so in the newsletter. But the four days decompose cleanly: no credential tickets, no security review of a sender, and two days of the team’s own work. Those are the steps the path was built to remove.

Adoption, satisfaction, outcomes

For each path, the platform group reports three things: who uses it, how they rate it and what changed for them. Adoption comes from the funnel, satisfaction from the survey’s path items, and outcomes from the system metrics. Each alone misleads. A path can be widely adopted because it is the default and still be disliked; it can be loved by its two users and irrelevant to the other 38 teams; it can be adopted and liked and change nothing measurable, because the friction it removed was not the one that mattered.

Encore expects the numbers to be mixed at first, and the evidence says it should. DORA 2024 found that users of internal platforms reported 8% higher individual productivity and 10% higher team performance, with organizational performance 6% higher. It also found that throughput fell 8% and change stability fell 14%, figures the Architecture book’s Section 15.5 has already discussed. DORA described the pattern over time as a J-curve: initial gains, followed by a decrease and then recovery as the platform ages and matures. A platform group should therefore report its numbers over several quarters before drawing conclusions. To see where time saved by a platform actually went, Encore uses Mik Kersten’s flow distribution, which Chapter 10’s Sections 10.4 and 10.5 explain: if the Resale team’s saved days went into features, the distribution shows it, and if they were lost to waiting somewhere else, it shows that too.

Scorecards that do not rank

Every measure in this section can be turned into a league table, and doing so would destroy it. Goodhart’s Law, which Chapter 10’s Section 10.5 develops with its real case, is the general reason: a measure that becomes a target stops measuring. DORA’s own guidance on its metrics is specific about the form the damage takes. The metrics “are meant to be applied at the application or service level,” and “the goal is to improve your team’s performance over time, not to compete against other teams or organizations.” A team ranked against others learns to improve its rank, which it can do faster by changing what it reports than by changing how it works.

Encore’s rule settles a wording question between this book and the Architecture book. The Architecture book’s Section 15.3 says each service’s scorecard is visible to both the team and its leadership. Both remain true, and the rule says how. A team sees its own scorecard in full. Leadership sees trends over time and the distribution across all teams, and uses them to find where the platform is failing its users. Nobody sees a ranking, there are no league tables, and no scorecard number enters anyone’s performance review.

Campaign tracking needs a careful line, because Spotify’s published practice crosses it on purpose. Its migration pages showed progress by squad, explicitly to make completion something of a game, and Spotify reports that this worked. Encore allows the same thing within narrow limits: a dashboard showing which teams still call the old webhook senders is campaign tracking, finite and dated, and it disappears when the campaign ends. It shows who has work left, never who is good at their job, and it is never used in performance reviews. Continuous quality measures are not shown that way at all. The difference is that a campaign has an end and every team can reach it, while a ranking on a continuous measure guarantees that someone is always at the bottom.

AI assistance raises the question of whether these measures need to change. Encore’s answer so far has been to add two survey items about AI-assisted work and change no targets. The evidence, including what DORA sees at the team level, is in Section 5.1, and the organization’s delivery measures are in Section 10.5.

Recap. Choose a lens by the question: DORA for delivery, DevEx for the developer’s experience of a platform, SPACE as the check against measuring one thing. Begin with a stable, validated survey and tie every question to a decision with Goals–Signals–Metrics, then set defined system metrics beside it. Report adoption, satisfaction and outcomes together, expect a J-curve, show teams their own scorecards and leadership the trends, and rank nobody.

Exercise 6.5. For one golden path in your organization, write five survey items and two system metrics with precise definitions. Beside each, write the decision it would inform, and delete any item for which you cannot name one.

Kata: The Portal Nobody Visits

Your brief: “Copperline.” Copperline rents cars and vans from about 600 branches in four EU countries, booked through its own website and app and through travel partners, with 250 engineers in 28 teams. Two years ago its 14-person platform team built an internal developer portal, with a catalog, a dozen service templates and a scorecard page, and launched it with a company-wide announcement. Today only 9% of Copperline’s services were created from its templates, the scorecard page is opened mainly by the platform team, and the catalog lists about a third of the services in production. Product teams describe the platform as “the place you file tickets.” Each quarter the platform group receives about 900 requests, most of them for database access, network rules and service accounts, and the median wait is six working days. A new service takes a median of 31 working days to reach production. Three teams run their own deployment pipelines, two of them copied from each other, and the rental-agreements team maintains a document-signing library that five other teams import. The CTO has given the platform group two quarters to show that it is worth its budget.

Deliverables:

1. Discovery findings — A plan for interviewing six teams about recent concrete episodes, an audit of one quarter’s requests classified by kind, and a desire-path search for copied pipelines and duplicated libraries. State what each finding would change.
2. A journey map — One journey, from idea to first production deploy, in the form of Figure 6.3, with each step checked against timestamps and the waits ranked.
3. The thinnest increment — The one or two capabilities you will build first, chosen with a stated rubric and a check on each capability’s evolution stage, with a one-page path brief for each. Say what you will decline, including anything the portal’s users have asked for.
4. One migration campaign — A one-page plan for moving the three home-grown pipelines, or the signing library’s importers, onto the platform: inventory, the work the platform does itself, support, tracking, brownouts and an end date.
5. The measures — Five survey items and two system metrics with written definitions, tied to decisions by Goals–Signals–Metrics, and the adoption funnel you will report each month.
6. The portal’s future — A short decision on what to do with the existing portal while the paths are built, and how its catalog will stop drifting from production.

Rubric:

Where you now stand

You can now treat an internal platform as a product with colleagues for customers: find what they need by interviewing them and mapping their journeys, choose the thinnest increment and write it a brief, build it as an honest self-service interface behind a versioned manifest, bring teams onto it with defaults, lighthouses and campaigns that finish, and measure whether it helped without ranking anyone. The partner-facing path is the first piece of Encore’s platform whose users reach beyond Encore’s engineers, since its credentials and webhooks are what partners touch. Chapter 7 turns to the platform whose users are all outside: Encore SaaS, sold to venues, where onboarding, identity, entitlements and the life of a tenant are product questions of the same kind, asked of customers who can leave.

References

• T. A. Dolotta, R. C. Haight, J. R. Mashey — UNIX Time-Sharing System: The Programmer’s Workbench. Bell System Technical Journal 57(6), 1978 — free online.
• Camille Fournier, Ian Nowland — Platform Engineering: A Guide for Technical, Product, and People Leaders. O’Reilly, 2024.
• Gregor Hohpe — Platform Strategy: Innovation Through Harmonization. Leanpub, 2024.
• DORA — Accelerate State of DevOps Report 2024. Google Cloud, 2024 — free online.
• Saunak Chakrabarti, Jenni Lee — Tech Migrations, the Spotify Way. Spotify Engineering, 2020 — free online.
• Gary Niemen — How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem. Spotify Engineering, 2020 — free online.
• Titus Winters, Tom Manshreck, Hyrum Wright (eds.) — Software Engineering at Google. O’Reilly, 2020 — free online.
• Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler — DevEx: What Actually Drives Productivity. ACM Queue 21(2), 2023 — free online.
• Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler — The SPACE of Developer Productivity. ACM Queue 19(1), 2021 — free online.
• GitHub — Deprecating password authentication. GitHub developer changelog, 2020 — free online.
• Matthew Skelton, Manuel Pais — Team Topologies, 2nd ed.. IT Revolution, 2025.
• Nicole Forsgren, Jez Humble, Gene Kim — Accelerate. IT Revolution, 2018.
• Evan L. Ivie — The Programmer’s Workbench — A Machine for Software Development. Communications of the ACM 20(10), 1977.
• Mike Rother, John Shook — Learning to See. Lean Enterprise Institute, 1998.
• Copier — Updating a project. Copier documentation — free online.