# Conway's Law Published articles for Conway's Law. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to take incremental steps towards data democratisation DevFeed: [How to take incremental steps towards data democratisation]() Original publisher: [Read original article]() Author: Andy Scotland Published: 2026-08-17T13:09:00Z Content type: article Language: en Sources: [Scott Logic]() Topics: [data](), [trust](), [decision-making](), [Artificial Intelligence]() Tags: [agent-factory](), [ai](), [ai-agents](), [artificial-intelligence](), [compliance](), [conway-s-law](), [data](), [data-democratisation](), [data-engineering](), [data-platform](), [data-products](), [governance](), [incremental](), [trust]() ### AI overview This article explains how organisations can pursue data democratisation incrementally while preserving control, risk management and governance. It describes potential benefits in financial services and discusses how trusted data, data products, platforms and AI agents could support innovation, decision-making and customer service. ### Source excerpt Organisations increasingly recognise the value of making data more accessible, but concerns around control, risk and governance often stand in the way. In this post, I explore why data democratisation doesn't require organisations to sacrifice oversight, and how data products, platforms and agent factories can unlock innovation while maintaining trust, compliance and accountability. ## What is the future of software engineering with Adam Bender, Principal Software Engineer at Google DevFeed: [What is the future of software engineering with Adam Bender, Principal Software Engineer at Google]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-07-02T15:01:06Z Content type: opinion Language: en Sources: [Tech World With Milan Newsletter]() Topics: [future of software](), [Software Engineering](), [AI-assisted coding](), [Testing](), [Integration testing](), [Google]() Tags: [ai](), [ai-coding](), [code-generation](), [conway-s-law](), [future-of-software](), [integration-testing](), [software-engineering]() ### AI overview The article discusses Adam Bender's view that the AI coding debate focuses too narrowly on speed. It argues that faster code generation increases pressure on testing, review, engineering culture, system understanding, and long-term maintainability, with integration testing becoming a particular challenge. ### Source excerpt Most of the AI coding debate is about speed. ## Team Topologies DevFeed: [Team Topologies]() Original publisher: [Read original article]() Author: Tom Published: 2026-04-26T00:00:00Z Content type: opinion Language: en Sources: [Tomasz Gągor]() Topics: [DevOps](), [Architecture & Design](), [Software]() Tags: [architecture](), [business](), [cognitive-load](), [collaboration](), [conway-s-law](), [flow](), [leadership](), [management](), [platform](), [team-topologies](), [technology]() ### AI overview This article summarizes Team Topologies by Matthew Skelton and Manuel Pais, focusing on organizational design for software teams. It explains the four team types, three interaction modes, cognitive load, Conway's Law, the Reverse Conway Maneuver, and the Thinnest Viable Platform. ### Source excerpt Team Topologies Organizing Business and Technology Teams for Fast Flow Authors: Matthew Skelton, Manuel Pais Team Topologies is a must-read for anyone involved in building software at scale. It moves away from the "everyone should talk to everyone" fallacy and introduces a pragmatic, team-first approach to organizational design. By focusing on cognitive load and the flow of value, Skelton and Pais provide a clear vocabulary for discussing team structures and their interactions. ## The 20 Software Engineering Laws DevFeed: [The 20 Software Engineering Laws]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-04-23T15:01:23Z Content type: article Language: en Sources: [Tech World With Milan Newsletter]() Topics: [Software](), [Software Engineering](), [Development](), [engineering-culture](), [CAP theorem]() Tags: [cap-theorem](), [conway-s-law](), [development](), [engineering](), [software](), [software-engineering]() ### AI overview A field guide to twenty software engineering laws, including Gall's Law, KISS, Conway's Law, Hyrum's Law, the CAP Theorem, Brooks's Law, and others. The article explains how these principles describe recurring behavior in software projects, systems, and teams. ### Source excerpt A field guide to why software projects fail, systems rot, and teams slow down. ## Management and Productivity Laws for Decision-Making and Organizational Behavior DevFeed: [Management and Productivity Laws for Decision-Making and Organizational Behavior]() Original publisher: [Read original article]() Author: Tom Published: 2025-08-26T00:00:00Z Content type: opinion Language: en Sources: [Tomasz Gągor]() Topics: [decision-making](), [Agile](), [meetings]() Tags: [business-efficiency](), [communication](), [conway-s-law](), [corporate-best-practices](), [decision-making](), [effectiveness](), [leadership](), [leadership-tips](), [management](), [management-laws](), [murphy-s-law](), [organizational-behavior](), [processes](), [productivity-principles](), [team-management](), [workplace-decision-making]() ### AI overview This opinion article introduces several management and productivity "laws," including Kidlin's Law, Gilbert's Law, Wilson's Law, and Falkland's Law. It explains how clear problem statements, explicit guidance, timely action, and avoiding unnecessary decisions can support workplace decision-making and organizational effectiveness. ### Source excerpt Discover the most influential management and productivity "laws"-from Murphy's Law to Conway's Law-that shape decision-making, leadership, and organizational behavior. Learn practical applications and scientific backgrounds to boost your effectiveness at work. ## Applying the Inverse Conway Manoeuvre to Existing Sociotechnical Systems DevFeed: [Applying the Inverse Conway Manoeuvre to Existing Sociotechnical Systems]() Original publisher: [Read original article]() Author: tobi@techunicorn.builders (Tobias Mende) Published: 2023-04-15T06:00:00Z Content type: article Language: en Sources: [Tobias Mende]() Topics: [systems](), [structure]() Tags: [architecture](), [collaboration-employee-happiness-software-architecture-team-topologies-technical-leadership-eng](), [conway-s-law](), [organizational-design](), [team-topologies]() ### AI overview The article examines whether the Inverse Conway Manoeuvre can change the architecture of existing sociotechnical systems by altering team structures and communication paths. It argues that existing teams, communication paths, and system architectures create significant difficulties for this approach, unlike greenfield environments. ### Source excerpt The Inverse Conway Manoeuvre in Existing Systems - It does not work! In 1968, Melvin E. Conway postulated a law about a connection between organizational design and system structure, which got pretty famous. The paper has the title "How Do Committees Invent?" and the law goes as follows: ## Code ownership conflicts as a signal for structural mismatch DevFeed: [Code ownership conflicts as a signal for structural mismatch]() Original publisher: [Read original article]() Author: tobi@techunicorn.builders (Tobias Mende) Published: 2022-02-19T12:54:00Z Content type: opinion Language: en Sources: [Tobias Mende]() Topics: [Architecture & Design](), [software-architecture](), [Code](), [Software]() Tags: [architecture](), [code](), [components](), [conway-s-law](), [practices-software-development-organizational-design-software-craft](), [software-architecture](), [teams](), [transparency]() ### AI overview This opinion article argues that team-level code ownership can reveal structural mismatches between team organization and software architecture. It explains how unclear ownership, especially in larger systems, can obscure subsystem boundaries and hidden knowledge gaps. Drawing on Conway's law and the Inverse Conway Manoeuvre, it presents aligned team and architectural boundaries as a way to reinforce system structure and surface ownership issues. ### Source excerpt Code ownership conflicts as a signal for structural mismatch In my last article, I explained why I believe that individual code ownership is bad and why weak code ownership on a cross-team level can be highly beneficial. ## Thoughts on Conway's Law and the software stack DevFeed: [Thoughts on Conway's Law and the software stack]() Original publisher: [Read original article]() Published: 2019-03-25T15:09:26Z Content type: opinion Language: en Sources: [Jessie Frazelle]() Topics: [Software](), [Open Source](), [Hardware](), [Cloud](), [cpu](), [Kernel](), [systems]() Tags: [bugs](), [cloud](), [communication](), [complexity](), [conway-s-law](), [cpu](), [design-systems](), [hardware](), [kernel](), [open-source](), [software]() ### AI overview The article applies Conway's Law to the software stack, arguing that insufficient communication between hardware, firmware, kernel, and user-space layers can contribute to security risks, complexity, overlooked bugs, and difficult debugging. It uses cloud multi-tenancy, Spectre and Meltdown, and firmware as examples. ### Source excerpt I've been talking to a lot of people in different layers of the stack during my funemployment. I wanted to share one of the problems I've been thinking about and maybe you can think of some clever solutions to solve it. Conway's Law states "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." If you were to apply Conway's Law to all the layers of the software stack and open source software you'd see a problem: There is not sufficient communication between the various layers of software. Let's dive in a bit to make the problem super clear. I've met a bunch of hardware engineers and I've made a point about asking each of them how they feel about using a single chip for multiple users. This is, of course, the use case of the cloud. All of the hardware engineers either laugh or are horrified and the resounding reaction is "you'd be crazy to think hardware was ever intended to be used for isolating multiple users safely." Spectre and Meltdown proved this was true as well. Speculative execution was a feature intended to make processors faster but was never thought about in terms of the vector of hacking something running multi-tenant compute, like a cloud provider. Seems like the software and hardware layers should better communicate... That's just one example, let's reverse the interaction. I've talked to a bunch of firmware and kernel engineers and they'd all love if the firmware from chip vendors did less complexity. For instance, it seems like a unanimous vote among firmware and kernel engineers that CPU vendors should not include runtime services or SMM with their firmware. Open source firmware and kernel developers would rather handle those problems at their layer of the stack. All the complexity in the firmware leads to overlooked bugs and odd behavior that can't be controlled or debugged from the kernel developers layer and/or user space. Not to mention, a lot of CPU vendors ## Conway's Law and Software Security DevFeed: [Conway's Law and Software Security]() Original publisher: [Read original article]() Author: Adam Published: 2018-06-06T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Security](), [Architecture & Design](), [Software]() Tags: [code](), [conway-s-law](), [developers](), [product-security](), [security](), [software]() ### AI overview The article discusses how Conway's Law relates organizational structure to software security. It cites Steve Lipner's account of shifting responsibility from a small security engineering group to a much larger population of software engineers tasked with creating secure code. ### Source excerpt [no description provided] ## Upday's Journey from Monolithic Backend Components to Microservices DevFeed: [Upday's Journey from Monolithic Backend Components to Microservices]() Original publisher: [Read original article]() Author: María Fernández Pajares (maria@upday.com) Published: 2017-08-22T22:55:55Z Content type: article Language: en Sources: [Upday]() Topics: [Back end](), [Architecture & Design](), [Microservice](), [Java](), [Spring Boot](), [Ruby]() Tags: [architecture](), [backend](), [conway-s-law](), [java](), [microservices](), [ruby](), [spring-boot]() ### AI overview The article describes upday's backend architecture journey, beginning with Java and Spring Boot monolithic components and later moving toward microservices as the company and backend teams grew. It also discusses how architecture and team structure can shape each other. ### Source excerpt I have always wanted to write about our journey through the world of backend architectures. As a developer, you may have been facing problems related to this topic in your team or with your projects. You might even be aware of the magical and trendy solutions out there, but sometimes these don't perfectly fit your current needs. This topic has not been - and it is not yet - an easy one for us either, but after facing many problems we now find ourselves in the world of backend architecture. Therefore I would like to share a few of our experiences and learnings in this area at upday. Conway's Law's reversion In conferences I have attended I have heard references to what could be interpreted from Mel Conway's Law: A backend architecture is a reflection of the team setup. and I totally agree with that but I also think that with time it may become the other way around: the architecture can end up shaping the team instead of the team shaping the architecture. Let me dig more into the challenges we face this time around and how we managed to resolve them: Our firsts architectural steps At upday we started with a small team of developers tasked with creating a robust solution to fulfill our client's requirements of reliability and providing good quality content to our readers. As in most startups, everything started fast and in a rush. The solution we finally came up with consisted of two monolithic components written in Java and Spring Boot. Together they form the core of our system. But they were not the only ones. We also had other smaller components written in Ruby or Java, which took care of minor requirements. When this setup worked properly and was production ready, we went live with it. When our architecture started to have flows When our company started growing, it was impossible to stick to only one big team of backend developers. We started splitting our backend team into feature teams. This was not an optimal setup at that time, given these two big components ha