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.
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.
So I don’t wholly disagree with your point, but even if I take that context at face value it still comes off as “ hey if your orgs are designed in perfect harmony w/ your objectives, your product will meet those objectives”.
Sure that’s logical as far as it goes, but it’s pretty much never the case in practice that you have a context that’s actually optimized to needs like that.
I feel like the subtext the post doesn’t say explicitly is that most management structure are not setup this way and thus software projects end up with a non-optimal design.
That is pretty much a given. Why else write about it at all?
I read it similar, but also kind of from the other side: If your organization is set up in a way that ignores the technical requirements of the product, your are going to have a bad time.
And yes, of course this is more often on the bad side than on the good side in practice. If everything was already fine most of the time, there would be no point in discussing this topic.
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.
And this is how you end up with five different parts of the company building pretty much the same thing, because if there was a central team creating shared components, they wouldn’t bring in any profit to justify their existence. But hey, at least there are no dependencies. And competition between teams drives innovation, right?
So tired of this line. The first thing I do in any team I’m on is start building bridges, sharing information, and collaborating on shared components that have the features that all the teams need, so we’re not all wasting everyone’s time building ten crappy, buggy versions of something we all need with slight variation. And instead build a single, well designed and well tested version that suits us all. But it’s always an uphill battle. Experienced engineers are always hesitant to trust, even if it’s exactly what they all want. They get burned or even punished by management policy for collaboration.
Unfortunately, it can make sense to the business (in a way) to not properly collaborate.
I’m currently at a company that essentially does projects for various customers, that are all relatively similar. From what I’ve seen, my department could easily fit 60-80% of all projects into one customizable product. Instead, each project reinvents the wheel and starts from scratch. Why? Because it currently doesn’t matter. The market is full of demand and if we can charge 1000 dev days to start from scratch instead of 500 to use an existing base, then that looks better on someone’s paper.
Yeah. I get it if it was a market where things change quickly, so all you need is a quick and dirty product to get your foot in the door with customers. And sometimes it’s easier to build something that is more targeted rather than collaborating to make a more generic solution.
I don’t work in that kind of industry, really. And the kinds of things I’m talking about aren’t things that take years to develop. For example, just in the last two months I built a solution that will make literally hundreds of small upcoming projects spread across four teams take a single two week sprint to implement for one to two people depending on complexity. Previously each of these were taking 3 to 4 people 2-3 months to implement. Plus tying down people from working on maintaining the existing system, so they were going to need to ramp up on engineers pretty quickly.
Plus this solution doesn’t require code deployments to onboard new customers, only to implement the new functionality that each of these small projects are adding. The old solution would have meant possibly having to wait months for a window to deploy code just to onboard a new customer because so many things were hard coded. Our system is extremely high volume and downtime can mean not just losing money, but fines from not meeting timeliness regulations, so deployments are heavily controlled.
And of the two months I spent on this it only was about a week of research and development. The rest was winning the trust of the other tech leads, gathering their requirements, and getting them all to agree on things like naming conventions. Both because they’d been burned too many times and because I’ve only been there for 2 years and wasn’t even a tech lead of my team yet when I started this, though I was about to be because the lead was moving to a newly formed team. And sure, if you had joined one of those meetings in that first week or two, it might have seemed like a waste of time with the bickering and nitpicking. But that’s just because they didn’t believe it was possible to collaborate and get things done, too.
The company was happily going to hire a bunch of contractors to build these things in order to maintain the silos and “competition”. It’s only because of a new manager, that I built trust with over the last year, that no one interfered when I started pulling people together and “wasting time” to collaborate. It’s not even that the middle management is doing these things maliciously in most of the places I’ve worked. They’ve just been brainwashed to believe that making people compete makes them more productive than making them collaborate. But it’s only the worst engineers that need that threat of losing. And only the worst ones that will stick around to play the game since good engineers just want to build stuff.
Funny thing is, this is essentially the same here for me - I just don’t have the standing right now to push such an effort through.
We’re not in a “fast changing” market at all, it’s dog slow actually. But our customers are currently shitting money and often just want to get things done. We don’t even have to “get a foot in the door”, they’re holding the doors open for us - and some have years of contracts already.
Currently, our revenue is limited by the amount of developers, or rather the amount of developer output (however you want to meter that). The problem is, essentially our revenue is made by renting out devs by the hour. Our proposals (and contracts) usually say “We’ll buid this thing within 1000 dev days at 1000€/day”, as long as our rates and time estimates are competitive, we can charge full market price.
Now comes the bummer: If we would build a common platform/product/library, we would need to invest a certain amount of dev time and then roll that investment over to the external costs. So we might say only 500 dev days for this project, but each dev now costs 1500€/day. The sum total is much lower, but our clients will argue, that 1500€/day is totally unreasonable. We also might choose a license model, were we license our own software, but many clients don’t want to buy licenses, unless it’s something like MS, Oracle, etc.
It’s infuriating.
I’m currently trying to convince some managers, that we could at least build some of the more general components in a way that would allow us to build a small toolbox or library, so that we at least have something like common starting point, but even that gets opposition, because some of the project leads are totally convinced that a) their absolute vanilla project is super special and b) the existing of a toolbox means use of that toolbox is enforced by threat of violence.
Yeah, and contracting is weird, too. I worked for a company that built a product to regression test that upgrades to major components that our systems integrated with didn’t change some functionality that would cause incorrect pricing or other issues. The testers at the companies that bought it loved it, but it was an annual fee and they couldn’t justify the cost without a specific upgrade planned in advance. Instead, they all went back to spending up to 100x as much hiring contractors to manually create test data and analyze the results. Worst part is the divisions of the companies that purchased the software could easily have convinced the other divisions to use the software and there would have been plenty of projects every year even if one division only had one project every two years or so.
But nope. Can’t collaborate and share expenses or they’ll lose their funding. Better to have big spikes in spending so that they could look like they were saving money all the rest of the time. Otherwise, they would lose all of their permanent staff to budget cuts.
My dick feels raw by proxy from all the wank in that post
Awe yeah, tell me more about today’s dynamic market landscape!
Management should not exist
No software project should have more than 3 contributors
GUIs should not exist either
The internet was a mistake as well
Many people believe that creating the universe was also a bad move.
But how far away is the chemist’s?
No software project should have more than 3 contributors
RIP Linux
We can all agree on the last point
Point two can be argued about if we say “no software project should have more than three responsible people.” Anyone can contribute, but there are at most three people deciding how the code should be and keeping an overview over everything.
Sound strange? How would we have ever landed on the moon with this? Answer: develop the whole system as a set of libraries that form a nice dependency tree all the way up to the one library that executes rocket launch on button press.
Each library does one thing very well, and each library is designed with the passion and thoughtfulness of someone’s hobby open source project.
There’s another way to see it: If a project has more than three contributors it’s not doing one thing, and one thing well, and should be split up.
“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?
I was thinking it is parody. The whole thing is management consultant speak. But honestly, I can’t tell any more. So much that would have been obvious parody in the 80s and 90s, are in fact serious today. Regardless, software architecture is really not that different from hard engineering. There are designs that work, and designs that don’t, business culture be damned.
This comes across as more of “fuck you, build it the way we feel it should be built” even though they have no fucking clue of the difference between a singleton and strategy, or SOLID and DRY. It is like a senator telling a Pratt and Whitney engineer the F-35 must be able to take a 90 degree turn at mach 3. Totally fucking ludicrous!
“fuck you, build it the way we feel it should be built”
Not really sufficient on its own, you have to fit the organisation and communication structure to the code. That even applies to small teams, even to having a single coding partner, heck it even applies to a solo project you have to get the communication between your idiot and genius self right.
Hum, management does drive your software’s architecture.
This is a well known and documented fact. I don’t see your problem with it. Is it that you don’t like it?
This also means that they share the responsibility for your shitty code. They often have almost all of it. That cartoon is saying this.
They share responsibility in reality, but they will get promotions and bonuses while you will get fired.
Hum, management does drive your software’s architecture.
In what sense? I might agree with you, but it hinges alot in what you mean by “drive.”
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:
Sure, show me the manager who wants to subordinate their own career and status to the good of the users, and has the managerial competence to design a team accordingly. (Okay, Meredith Whittaker might be one. Name another.)
Otherwise, y’all still best off drawing projects out of the noisy nonsense anarchy of open source.
Thanks for introducing me to Meredith Whittaker - what a remarkable woman.
I feel like you’re probably making a very good point but I can’t quite tell what it is.
Managers typically have local incentives that lead away from doing good things with their control of organizational architecture.
Oh-- Yeah that IS a good point. I’m not an anti-manager person, but I do think that many managers are incentivized to perturb their orgs superstitiously, with almost obligate overconfidence.
deleted by creator
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.
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.
I hate project managers like this so fucking much. You won’t know what you’re talking about and your trying to force unrelated shit into design discussions…. Because they don’t know what the fuck they’re talking about.
A good PM will empower the team but this shit is the exact opposite and I see it all the fucking time. Fuck people like this so much
