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