For reference (as per Wikipedia):
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Imagine interpreting that as advice on how you should try to design things, lol.
Tbf, I think most of the post is just typical LinkedIn fluff, but I didn’t want to take the poor fellow out of context.
You must log in or register to comment.
The original post advocates for a holistic, collaborative approach; management and technical experts should be working together to align technical and organizational structure. I fully agree with that view (and I’m not a manager).
There is more than enough “shit managers say” material out there, but this is not it.
Totally fair, and I’m actually pretty happy to see someone steelman the LinkedIn guy’s point. Surprisingly thoughtful discussion here for a meme sub, lol.
I still think most of his post is pretty vapid (“org structure and technology should both support business goals,” yeah duh), but the content isn’t really objectionable… He’s just kind of… not saying much, I think. That’s what I meant by “LinkedIn fluff.”
What makes me smirk is invoking (and IMO, misunderstanding) Conway’s Law, although that was more an issue with the comic than the post (he talks about “Conway’s Law” directly in the comments, but I didn’t post those).
The takeaway from Conway’s Law isn’t supposed to be “when you’re deciding how to architect a software system, make sure to conform to the org structure.” It’s that the system structure will tend to mimic the communication structure (and possibly vice-versa), which may be good or bad, and you need to manage that tendency.
It’s certainly not “managers are the real software architects,” lol.
Thanks for your perspective. I wonder what your opinion of the comic part is?
Nowhere in that text does it say “managers are the real software architects”. What it does say is “what managers do affects software architecture”. Sure you can extrapolate that to delusions of grandeur, but if you take into account the explicit call for collaboration it is much more likely what was meant is more along the lines of “we can mess things up if we ignore the architecture, so let’s talk to the real software architects before making org decisions”.
About the comic: That one does have the line “management designs software architecture”, much closer to the negative interpretation; but that too can be interpreted in a more positive way as “… and we are not good at that, so let’s make sure to bring in the people who are good at it at important points”.
if you take into account the explicit call for collaboration it is much more likely what was meant is more along the lines of "we can mess things up if we ignore the architecture, so let’s talk to the real software architects before making org decisions
That’s an extrapolation itself and I think a much less likely intention. The post takes an obvious concept (alignment) and somehow pretentiously comes to the conclusion that managers are actually system architects while downplaying the role of technical contributors, you know, the ones actually designing the systems. It takes two to “harmonize”, so if that’s what you bring to the table, the technical components are doing that and their actual job. This is just a dude on LinkedIn jerking himself off.
The comic is very accurate though, at least the part where the manager is lounging with his feet up on his desk doing dick all thinking about how he can take credit for someone else’s job.
Nowhere in that text does it say “managers are the real software architects”. What it does say is “what managers do affects software architecture”.
Totally 👍I’d take it even a step further to say that he doesn’t even mention managers (or any other role) in the text-- It’s the comic that states that, as you say. It’s debatable to what extent the comic and the text should be read as one unit, but I think it’s fair to contextualize them together.
If you’re right about the intent-- i.e. to say “let’s make sure to bring in the people who are good at architecture–” then I think at best, it’s poorly articulated. It’d an odd move to post a comic that elevates his role and then not mention those people at all, right? Instead, he makes vague calls to “collaborate” and “align,” which many people hear as “schedule meetings and do manager stuff,” and then imply that that’s how software gets architected, because… Conway’s Law?
I still think it’s nice of you to try to interpret it charitably, though. I imagine if we shared this thread with this manager, he probably wouldn’t double down on how, no, really, Management are the real architects! He’d more likely pivot to echo much of what you’ve said, perhaps pretending that that was what he was saying all along.
Then we’d be free to argue about Conway’s Law for the rest of the thread.
Yes, it is.
Basically he’s trying to frame something obvious and well out of his control as something he did. Which is typical manager behavior.
You don’t claim to be an expert farmer just because the apple tree in your garden, that’s twice as old as you are, happens to grow an apple.
This is illusion of grandeur in action.
I think what we can all agree on is that collaboration between the tree and the farmer is really what allows the apples to thrive. Conway’s Law tells us that the tree must conform to the habits of the farmer in order for fruit production to flourish, because ultimately, it’s the farmer who drives fruit production.
A holistic, collaborative approach to apple farming creates an environment conducive to fast fruit growth, a critical factor in today’s dynamic agricultural landscape.
So you see, it’s really the farmer who is growing the apple-- The tree is merely a socio-agricultural conduit.
My dick feels raw by proxy from all the wank in that post
Awe yeah, tell me more about today’s dynamic market landscape!
“I should make sure my software architecture mirrors our org’s communication structure.”
Conway’s law exists
“Holy shit I am already so good at this.”
NAILED IT!
Also: Because of Godwin’s Law, we should all be striving to compare things to Hitler whenever possible.
Yeah, just get the inevitable out of the way, right?
Is that text AI generated?
I mean, management has always spoken in such word salad jargon.
Lol, funny you should mention… Most recent comic by the same artist:
Please tell me that’s a parody.
If this person believes that Conway’s Law means “you SHOULD conform your software architecture to your org structure,” then I wonder what that means for his interpretation of Poe’s Law?
without a clear indicator of the author’s intent, any parodic or sarcastic expression of extreme views can be mistaken by some readers for a sincere expression of those views.
Oooh, are we saying complete bullshit on well-known principles just to make ourselves look better? Here, lemme try
One principle that has guided my career in engineering is predicated on a theory which asserts that an organization inevitably produces designs closely mirroring its own communication structure. This tenet is deeply entrenched in organizational theory and has profound implications within the field of software engineering. It underscores the tangibly symbiotic relationship between structural communication channels and the inherent formation of design patterns, directly impacting project outcomes and overall system architecture.
Take an instance of a complex system architecture, for instance; the blueprint invariably mirrors the modus operandi of the organization, melding functional utility with intricate formalism. More specifically, it can be deduced that the nature and structure of information flow within an organization will ultimately inform the design, function, and interactivity of the proposed solution. Understanding this dependency provides valuable insight into optimizing organizational communication channels and realigning teams for effective outcomes.
A practical illustration of this principle is observed in large software corporations. A company with segregated departments, each responsible for a different process within a singular product, results in a fragmented, disjointed project output. Conversely, an organization that values collaborative, cross-functional teams is more likely to produce a product that boasts of seamless integration between its components.
For this reason, corporate structuring and re-structuring, when required, should be done with a pragmatic view towards improving communication channels. Aligning one’s business operation to reflect this principle, therefore, has significant implications on the maintainability, productivity, and overall success of end products. It espouses the virtues of flexible organizational structures that maximize communication efficiency and consequently, affords more robust and efficacious design frameworks.
In essence, understanding and implementing this paradigm shifts how companies view their organizational structure and its subsequent impact on outputs. It transcends beyond mere theory, providing a heuristic tool for entities seeking to improve their system architectures. As such, it is an indispensable guidepost in my engineering career, illuminating the path towards optimum function and design within both the organization and the products it creates. This, in itself, is an organogram of success, a paradigmatic shift in corporate thinking to create more efficacious products and overall, more successful businesses.
Full disclosure, I didn't write this, this is GPT-4 on Conway's law. Here's the prompt, if anyone's curious:
write five paragraphs on conway’s law that makes the speaker sound smart through a corporate vocabulary. start with “one principle that has guided my career in engineering”. do not mention conway’s law or conway himself by name.
10/10, absolute drivel, no notes 👌 Extra credit for “organogram of success.”
yeah, chatgpt is frickin unparalleled in coming up with bullshit and phrasing it just the right way. my favorite thing is asking it to be sarcastic and passive-aggressive:
One principle that has guided my career in engineering, which my colleagues often overlook, is the profound understanding of the mirror-like relationship between an organization’s design structure and the software engineering outcomes they produce. Now, I don’t wish to dumb this down, but every time you witness a cluster of technologists huddled together, producing an array of systems, sub-systems, or module designs, keep your eyes peeled. They’re invariably going to be a spitting image of the organizational framework of the enterprise, often in ways that self-proclaimed ‘visionaries’ fail to foresee.
Now, with painfully forced patience, I must reiterate that this axiom is no trivial discovery or stroke of divine inspiration. It’s merely a reflection of the structural reality, something akin to looking out on a mirror carefully arranged by your senior management. The hierarchy, the stratification, the fragmentation across your esteemed organization, will be sculpted into the systems it produces. Picture each software module as a carefully chiseled stone that when aggregated, forms the larger cathedral that is your system architecture.
Ironically though, I’ve often seen leaders ready to splurge on sophisticated technology and state-of-the-art infrastructure, willing to make all grandiose promises on achieving data-driven decision making or accelerating the pace of innovation. Yet, they conveniently forget, due to what can only be a mission-critical memory lapse, that their microservice architecture has a curious tendency to mirror our own managerial slides filled with box-and-line org charts.
And let’s dwell a moment longer on these org charts, these delightful diagrams that claim to encapsulate the chain of command and accountability within the organization. There’s almost an uncanny resemblance, to the perceptive observer, between the lines of software code and the seemingly tiny, arbitrary changes made to these precious organizational diagrams. Lest we forget, the software your teams sweat blood to build will knuckle under to the gravitational pull of the enterprise structure, echoing its splintered silos and delightful dysfunctions.
However, for the sake of those cheerfully blinded by technical jargon and starry-eyed optimism, do carry on with your lofty ambitions to transform your IT landscapes, to catapult your organization into the brave new era of digital excellence. Just remember, the structural symmetry between your divided departments and disjointed computing systems is not random happenstance. If nothing else, they are monuments to the myopia of management, embodied in code and user interfaces, continuing to honor the timeless principle that so eloquently underscores my engineering prowess.
i literally just added “do the above assignment in a sarcastic and passive-aggressive tone” to the prompt, lol
That version is so much more readable for some reason. Like this is actually a wonderful sentence:
Lest we forget, the software your teams sweat blood to build will knuckle under to the gravitational pull of the enterprise structure, echoing its splintered silos and delightful dysfunctions.
That doesn’t sound (to me) like an LLM, and yet the stuff it produces by default reads in a tone that we would have described as “robotic” long before GPT.
yeah, i think the “LLM sound” is just a corporate sanitized tryhard voice that no sensible human would have. the tryhard bit is an artifact of instruction training, and the corporate sanitization is there to make it very “safe” for conversational interfaces or smart prose processing for corporate clients. but if you give the ai an actual, productive, and somewhat complex task to accomplish, it very quickly switches to something far more human-like, because it’s no longer trying to overperform on a simple task.