Internal Tools as a Product (The Crying Octopus)
Run your dev-productivity team like a product team: monthly surveys, hard metrics, and one-click paper cuts.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 92%
Stripe's developer productivity team runs exactly the same product development process on internal engineers that Stripe's product teams run on external users: know your users, talk to them constantly, measure everything, and make reporting friction frictionless. The signature mechanism is a crying-octopus button embedded in every internal developer tool — one click, type what went wrong, and the dev productivity team reads them all and prioritises from them. These are called paper cuts.
Origin
David Singleton, CTO of Stripe. Singleton names the crying-octopus paper-cut button as the most profound of the 'relatively minor' changes Stripe has made to its product development process.
Core principles
- 01Your engineers are users; the internal-tools team should run the identical loop you run for paying customers.
- 02Friction in reporting friction is the tax that hides most internal pain — remove it entirely.
- 03Triangulate free-text complaints against hard measurement; the combination shows where investment pays.
- 04Sample statistically rather than surveying everyone constantly — at scale a monthly ping to a subset gives a significant sample without survey fatigue.
- 05Very small productivity changes compound; deliberately hunting them pays like optimising a checkout flow.
- 06Enabling engineers to do the best work of their careers is a retention strategy, not just an efficiency one.
How to run it
- 1
Staff a developer productivity team and give it a real product loop
Stand up a team that owns dev tools and runs the same product development process used for external users — understand your users deeply, talk to them a lot, and prioritise from what you learn.
- 2
Run a statistically-sampled monthly survey
Ask engineers directly what experience they're having. At sufficient scale you can ping a subset monthly, get a statistically significant sample of the whole organisation, and only need any individual to respond about every six months.
Pro tip Ask very directly ('what's the experience you're having?') rather than a satisfaction score — free responses are what pair with the metrics.
Watch out Surveying everyone every month at scale produces fatigue and declining response quality, which corrupts your prioritisation input.
- 3
Measure everything so you know where people get stuck
Instrument the developer pipeline. Compare the quantitative data against the free-text survey responses — the overlap tells you where investment makes the most people more productive.
- 4
Put a one-click paper-cut button in every internal tool
Stripe embeds a crying-octopus emoji button in every single developer tool. Click it, type what went wrong, done. The developer productivity team reads all of them and uses them to prioritise their roadmap.
Pro tip Make the report channel amusing and instantly recognisable — a crying octopus is memorable in a way a 'Feedback' link is not.
Watch out If reporting a paper cut requires filing a ticket in a system with required fields, engineers will simply absorb the pain and you will never learn about it.
- 5
Hunt the compounding micro-wins
Deliberately look for single-step removals in the engineering flow, the same way you'd hunt a click or a millisecond out of a checkout. Stripe's examples: auto-deploy (removing the deploy babysitter) and an auto-merge checkbox on pull requests so the system takes over the moment the reviewer approves.
Pro tip Each of these looks trivially small in isolation; that is exactly why nobody prioritises them and why doing so is an edge.
- 6
Trial new tooling rigorously before rolling it out broadly
Stripe ran a fairly rigorous trial of GitHub Copilot to assess its actual impact on code written and code quality before making it available across engineering.
Pro tip Copilot's clearest early win at Stripe was generating the substantial boilerplate in test cases, letting engineers spend their reasoning on whether the test tests the right thing.
In the wild
Stripe put a small button — an emoji of a crying octopus — in every single developer tool. Clicking it lets an engineer type what went wrong in seconds. The developer productivity team reads all of them and uses them to prioritise what they work on. Stripe calls these reports paper cuts.
→ Asked what relatively minor change had the most tremendous impact on Stripe's ability to execute, Singleton named this frictionless problem reporting as probably the most profound.
About eight months before the interview, Stripe added a tick box on the pull request in its GitHub Enterprise-based review tooling: auto-merge. Once the reviewer approves, the system takes over — the author never has to come back and manually merge.
→ Cutting out that one human distraction step laddered up to a big change in engineering productivity — Singleton's illustration that small changes compound the same way checkout optimisations do.
Common mistakes
Treating internal tools as a cost centre
Internal tooling built without a user research loop optimises for what the tools team finds interesting, not for where engineers actually lose hours. Stripe's fix is to run the identical product process internally.
Making feedback expensive to give
Every unit of friction in the reporting mechanism filters out proportionally more reports. Most internal pain is individually too small to justify a ticket, which is exactly why it never gets fixed.
Only chasing the big wins
Dev productivity roadmaps skew toward large re-platforming projects while ignoring the one-click removals that compound. The auto-merge checkbox looked trivial and produced a big change.
Is it for you?
Best for
Engineering leaders at companies past ~100 engineers where developer productivity has become a real bottleneck but is still managed by anecdote.
Not ideal for
Small engineering teams where the leader already feels every paper cut personally and a dedicated productivity team would be premature.
From the transcript
“run exactly the same product development process that I just described for our external users internally.”
“We also measure everything. And so we know where people are getting stuck.”
“we put a little button in every single developer tool at Stripe. It is an emoji of an octopus that is crying.”
“we have our developer productivity team read all of those and use them to prioritize what they're up to”
From the episode
Building a culture of excellence
David Singleton (CTO of Stripe)