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.
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.
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.
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.
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”.
