Engineering practices for cross‑team work
Senior engineers on social are advocating that product and ops teams adopt engineering‑style practices — versioned repos, PRs and searchable decision records — so non‑engineering work compounds context and reduces coordination friction. The idea is to treat decisions and operational knowledge as first‑class, searchable artifacts that scale with the organisation rather than relying on tribal memory. (x.com/i/status/2042060345200590974, x.com/aakashgupta/status/2042888202407801073)
A lot of company work still disappears into chat messages, meeting notes, and somebody’s memory, which is why the same pricing rule, launch checklist, or customer exception gets argued again three months later. Senior engineers are now pushing a simple fix: treat product and operations decisions the way software teams treat code, with version history, review, and a permanent record. (aws.amazon.com) Software teams already solved a version of this problem years ago. A pull request is just a proposed change with comments, approvals, and a diff showing exactly what changed before it becomes the new default. (docs.aws.amazon.com) The missing piece outside engineering is usually the “why.” Architecture decision records were created to capture one important choice, the context behind it, the alternatives rejected, and the consequences that follow from it. (github.com, learn.microsoft.com) That same pattern works for non-code work. A product team can write down why it chose annual billing over monthly billing, and an operations team can record why refunds over a certain dollar amount require manual review, instead of burying both choices in a slide deck. (learn.microsoft.com, docs.cloud.google.com) The argument spreading on social is not “make product managers learn to program.” It is “put business changes in a place with history,” so anyone can see who changed a policy on March 3, what the previous version said on February 10, and what discussion led to the change. (x.com, x.com) Once decisions live in a repository, they stop behaving like gossip. Search works, onboarding gets faster, and teams in sales, support, finance, and operations can look up the current rule instead of asking the one person who “just knows how it works.” (aws.amazon.com, adr.github.io) Large engineering groups use decision records because coordination gets expensive as headcount rises. Amazon Web Services says teams can spend 20 to 30 percent of their time coordinating across teams when decisions are not documented clearly, which is exactly the kind of drag product and ops teams complain about too. (aws.amazon.com) The practical version is boring on purpose. Put launch checklists, policy changes, pricing rules, incident runbooks, and recurring decisions in plain text files, review them with lightweight approvals, and keep every edit in the same system instead of scattering them across chat, docs, and decks. (docs.aws.amazon.com, docs.cloud.google.com) This does not turn every business choice into a committee. Good decision records are short, dated, and specific, which is why Microsoft’s guidance says to start the record at the beginning of a workload and maintain it over time rather than trying to reconstruct history later. (learn.microsoft.com) The reason this idea keeps resurfacing is that modern companies already run on written systems, but most of those systems are hard to search and easy to lose. Engineering-style practices turn operating knowledge into an artifact that survives reorgs, new hires, and the person who finally takes a two-week vacation. (adr.github.io, aws.amazon.com)
