12 ms·

Oh boy, been there. This is Conway’s law in action - they are about to go and create the same code soup again - because the org won’t have changed. Having been

Oh boy, been there. This is Conway’s law in action - they are about to go and create the same code soup again - because the org won’t have changed. Having been in the same boat my lesson is positive engineering initiatives can only come top down - through some very senior champion. You can’t change an organisation from the bottom up - and it’s the organisation that produces the code base.

zer00eyz 3y ago
>> This is Conway’s law in action Not just one layer, look at the stack: Type script is MS's Conways law. API/microsevice everything is more of a google thing (vs FB monolith)... So you have two other major product of Conways Law that your trying to jam into your own org. On top of that a 5 year plan is never going to digestible by (almost) any company. How many people stay in one place for that long? How much has the front end changed in 5 years? Is any choice you make in the JS world relevant in 5 years? Though sell there too!
antupis 3y ago
I think it is more nuanced, you can also change the organization bottom up, but it needs to be new stuff that does not exist or has it infancy. Changing existing stuff is very hard even top-down.
- LightFog 3y ago
  Indeed, and greenfield projects are a great way to move upward in the org - as Jim in the story recognises.
- chii 3y ago
  > new stuff that does not exist or has it infancy. If it was new stuff, then the people doing it must not be very low at the bottom (by virtue of the org being quite shallow - such as a startup). Even new stuff in a big company with lots of layers of management cannot make new stuff with excellence. Eventually, probably sooner rather than later, it gets polluted. Not to mention that in a big org, the people at the bottom do not get rewarded for making excellence in engineering, if the top doesn't appreciate it. SO why go that extra mile, when a mediocre job will earn you the same salary? You'd be more incentivized to move jobs to grow your pay instead, and use this as a stepping stone.
  - klyrs 3y ago
    As somebody who has only ever worked at places small enough for individuals to all roughly understand eachother's impact, could I even get a job at a big org like that? I don't even understand the mindset
    - nercury 3y ago
      Yes of course. You have to demonstrate that you are very skilled at building with the particular bricks they use. Don't mention anything else to show your commitment to particular brick usage.
      - klyrs 3y ago
        Yikes! I didn't want to understand the mindset after all! Thanks :)
    - hef19898 3y ago
      Get one? Sure. Be happy with it? Propably not. I learned that the hard way, only the other way around.
      - klyrs 3y ago
        Sometimes, I daydream about being a nameless drone in a cubefarm, taking home a nice paycheck and leaving my work at work. But, yeah, the dream passes quickly because I know I'd hate it with a burning passion.
        antupis 3y ago
        it is fine the first 6 months then bore out hits and you will be miserable.
        chii 3y ago
        it depends. If you want to seek meaning in your work, then yes, cubicle farms will not give you fulfilment. But if you're just after a steady paycheque, and don't give a damn about the business, your work nor its purpose, then this is fine. And it gives you free time to live outside of work too.
- devjab 3y ago
  Have you changed an organisation from the bottom up? In two decades I’ve never seen it happen in organisations larger than 50 people. You can change something, like how an engineering team works and how an organisation does DevOps and other things that management doesn’t really know anything about and trust their employees on. But moving an organisation into something like team topologies which is a more modern expansion on Conway, is virtually impossible from the bottom up in my experience. Change management in general is very hard both directions, but it’s much harder going upwards because going upwards means you don’t really have the support of management above you. Maybe they’ll humour you but to make an actual impact you’re going to need them onboard. You’ll even have to reach pretty far up top if you want to inflict lasting culture changes as things carried by a single (or few) managers often dies with them. My career has sort of put me in a role where I help non-tech startups transition from that to medium or enterprise size. I solely focus on the tech journey though, as I know I won’t have too much impact on culture or work processes on the grander scale. Often this leads to a semi-team topologies approach as the tech teams divide systems into independent business related services, but as a whole I don’t expect any changes to reach outside of the development departments.
  - _puk 3y ago
    I'm not disagreeing on your overall point, but it can be done (I've done it with 130+, so there's a lot of incumbent process and numerous senior managers to align). The key is having a champion who can tie change in with higher level desires. In these orgs there's often an external (as in stakeholders external to prod eng) perception that "engineering is slow, product doesn't deliver, they're preventing us delivering our OKRs", and that can be used as leverage for change. You can't go dark and stop delivery, but you can usually carve out a 10 - 20% allowance for change (that doesn't sound much, but is 1 - 2 days every 2 weeks, which quickly adds up). Start small, show success in impacting metrics that external stakeholders care about, then next quarter push for more. I've focused myself in a similar area as you, but actually lean into processes and people, whilst still guiding tech - maybe we should chat!
krig 3y ago
If you want to dig into Conway's law and its implications, I can't recommend this video essay by Casey Muratori enough: https://youtu.be/5IUj1EZwpJY?si=dPxsXieBwZsP0PPP https://youtu.be/5IUj1EZwpJY?si=dPxsXieBwZsP0PPP Fair warning though, you'll lose all hope that companies like Microsoft will ever manage to produce anything that they don't then ruin.
- Xelbair 3y ago
  >Fair warning though, you'll lose all hope that companies like Microsoft will ever manage to produce anything that they don't then ruin. you are implying that we still had any hope left in such endeavors.
- jiggawatts 3y ago
  Oh. My. God. This video explains everything I've seen in the enterprise IT of a huge government org that was the result of a long series of back-to-back mergers and splits. It's exactly this! Conway's law, but over time. Dysfunction not just because of the large hierarchy, but also because of the built up layers of history. Some elements still limping along, some essentially amputated and mere phantom limbs of the org tree now, some outright dead and spreading miasma and corruption from their decay. I knew or suspected most of this, but to hear it said out loud so clearly has crystallised my understanding of it.
  - krig 3y ago
    Yeah once it hits, it really explains so much of the issues in large organizations (and explains a lot about small organizations / indie development as well). For example, why is it that mergers and buyouts rarely work out? Conway's law largely explains it! When a product is bought by an organization, the result is an integration over time of both organization org-charts combined. If the companies are both large, this immediately becomes an intractable mess. If the original company was small and the new company is large, it _also_ becomes intractable because now different teams will have to communicate to manage or split components that don't fit the communication patterns of the new organization, and will lead to large refactors and rewrites and in the end the essential qualities of the original software will inevitably change. Even if you know this, there is nothing you can do - you have to organize yourself somehow and how you do that can't be left up to just mirror whatever this piece of software that was brought in happens to be organized - because _that too_ doesn't reflect an actual org chart but is an integration over time of all org charts that have touched it. I don't even know how to think about the implications this has for the use of open source software and how open source is developed, like... I think there are huge opportunities for research into Conway's law and how it relates to software development practices, software quality, etc.
dasil003 3y ago
Top down comes with its own risks. The bottom line is big ideas and big change can only happen with both the champion at the top, as well as good understanding at the bottom, and a critical mass of good alignment and competence throughout the middle layers. Though Conway's Law is immutable, it doesn't necessarily depend on a formal org chart, it can be worked with by simply creating ad-hoc communication structures between the right tech leads and competent managers. A handful of technically weak or empire-building managers in the middle can fuck the whole thing pretty easily though, and depending on the lifecycle of your company it may be a lost cause due to Pournelle's Iron Law of Bureaucracy.
- LightFog 3y ago
  Although it’s not always necessary to go through the middle - you can do the old switcheroo and build a parallel org in your image, emerge from the shadows and duke it out with the old structure.
  - chasd00 3y ago
    If you come at the king you best not miss. Fail at taking down the old structure and those relationships are so destroyed they will come after you. I’ve seen groups of consultants become unemployable across the whole industry by failing to take down the old guard. Word spreads.
- szundi 3y ago
  Very good comment
- nonrandomstring 3y ago
  > as well as good understanding at the bottom, and a critical mass of good alignment and competence throughout the middle layers. How do you hold the middle together? Especially under such turbulence? "Strong" leadership isn't enough. Reflective practice [0] is one way to build that. It's common in medical and some safety-critical civil/military spheres but strangely missing from many corporate structures. I talk about it here with regard to a more mature cybersecurity stance [1]. It intersects with Agile ideas but doesn't make much noise in software engineering project management as much as it should? Anyone have this in their org? [0] https://en.wikipedia.org/wiki/Reflective_practice https://en.wikipedia.org/wiki/Reflective_practice [1] https://cybershow.uk/blog/posts/reflective https://cybershow.uk/blog/posts/reflective
rpastuszak 3y ago
I'm adding "Conway’s Soup" to my vocab as a name for the result of such process.
julik 3y ago
And even then - the senior champion might as well burn out on it, even when they do manage to pass the initiative. Been there too.
austin-cheney 3y ago
That highlights the greatest repeated tragedy to befall software: poor leadership. For some bizarre reason developers almost always think they can fix people problems with better tools. For example if all your developers suck give them a popular framework. It’s just an excuse to avoid dealing with people that provides license for the children to run the daycare. If you want excellence set high standards defined by rules that to hold people accountable and impose ownership (liability/reward). It’s not complicated but it requires not being terrified of assertiveness and confrontation from the top down.
- bsenftner 3y ago
  > It’s not complicated but it requires not being terrified of assertiveness and confrontation from the top down. It requires the professional communication skills that are not taught in a STEM education. That's why this is all so difficult: we are not taught how to communicate effectively with one another, and the entire tech landscape has poor communicators misinforming and misleading one another.
  - geraldhh 3y ago
    Statements of poor communication always make me wonder if the shirky principle might be part of the problem
    - bsenftner 3y ago
      I do not believe so. This lack of communication skills is also due to a lack of recognition of the value good communications engenders. An undergraduate business school education pragmatically touches on professional communications, but only as far as how to motivate and control people, not how to effectively communicate - as in a shared synchronization of understanding, which is what professional communications is all about. Colleges of communications teach professional communications as their foundation, before the various media majors one graduates within. The more I look at the levels of communications in general within society, our civilization has not yet recognized how critical communications are to every aspect of life, not just business and careers. Good communications are like fire, capable of destroying and capable of being the foundation greater things are built, and the lack of this recognition amazes me.
deleted 3y ago
[deleted]
gilbetron 3y ago
Conway's Law isn't a "law" - it is an interesting observation and there are definitely interactions (both ways) between organizational structure and software "design". But people weigh it too heavily. There are plenty of counterexamples of, for instances, fine-grained teams in one company that build a monolith, and the same type of teams in another company building a microservices architecture. Complex software is complex, and once your require more than a handful of people, that complexity requires a complex organization structure to handle the challenges of communication and responsibility. But it isn't a purely deterministic relationship between organizational structure and software structure. More that certain organizational structures are really bad at building complex software, and some are better. It is interesting to think about, but there is this tendency to invoke "Conway's Law" as some simple method of fixing the extraordinary complex problem of developing and evolving complex software over time. Really what it is is that organizations from the 70s, 80s, and 90s were built around building physical things, for the most part. Manufacturing and construction, mostly. And taking those organizations and applying them to software development fundamentally was a terrible match. We had to find new structures that were better suited, and we have gotten a lot better, but we are still working on it. Management was taught by those that managed manual laborers, who's output was easy to measure, and whom you could force to work a certain amount without a significant drop in their output. The same isn't true for knowledge workers. And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago. Read Conway's original paper, it is interesting, but it isn't a physical Law that cannot be violated!
- lolinder 3y ago
  > But people weigh it too heavily. There are plenty of counterexamples of, for instances, fine-grained teams in one company that build a monolith, and the same type of teams in another company building a microservices architecture. These aren't counterexamples because Conway's law makes no comment on how the teams will choose to deploy what they build. It talks about the overall design of the system, the solution space that was explored. Windows is a monolithic application if the alternative is microservices, but anyone who gives it more than a cursory glance can see the org chart (both past and present!) reflected in the disjointed UX. > And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago. I'm not sure why this makes Conway's law not applicable anymore—what you're describing is that new management does a better job of creating communication structures that lend themselves well to creating software. That may well be correct, but the resulting improvements validate Conway's law! If we're getting better at software, it may well be because people are talking about and accounting for the impact that communication structures have on the output.
snotrockets 3y ago
That's the thing that stumped me here: how does a _Senior Staff Engineer_ doesn't understand their job isn't to build software, but to enable the rest of the organization to build software? (Paraphrasing on that old Toyota principle)

zer00eyz 3y ago

>> This is Conway’s law in action Not just one layer, look at the stack: Type script is MS's Conways law. API/microsevice everything is more of a google thing (vs FB monolith)... So you have two other major product of Conways Law that your trying to jam into your own org. On top of that a 5 year plan is never going to digestible by (almost) any company. How many people stay in one place for that long? How much has the front end changed in 5 years? Is any choice you make in the JS world relevant in 5 years? Though sell there too!

antupis 3y ago

I think it is more nuanced, you can also change the organization bottom up, but it needs to be new stuff that does not exist or has it infancy. Changing existing stuff is very hard even top-down.

LightFog 3y ago
Indeed, and greenfield projects are a great way to move upward in the org - as Jim in the story recognises.
chii 3y ago
> new stuff that does not exist or has it infancy. If it was new stuff, then the people doing it must not be very low at the bottom (by virtue of the org being quite shallow - such as a startup). Even new stuff in a big company with lots of layers of management cannot make new stuff with excellence. Eventually, probably sooner rather than later, it gets polluted. Not to mention that in a big org, the people at the bottom do not get rewarded for making excellence in engineering, if the top doesn't appreciate it. SO why go that extra mile, when a mediocre job will earn you the same salary? You'd be more incentivized to move jobs to grow your pay instead, and use this as a stepping stone.
- klyrs 3y ago
  As somebody who has only ever worked at places small enough for individuals to all roughly understand eachother's impact, could I even get a job at a big org like that? I don't even understand the mindset
  - nercury 3y ago
    Yes of course. You have to demonstrate that you are very skilled at building with the particular bricks they use. Don't mention anything else to show your commitment to particular brick usage.
    - klyrs 3y ago
      Yikes! I didn't want to understand the mindset after all! Thanks :)
  - hef19898 3y ago
    Get one? Sure. Be happy with it? Propably not. I learned that the hard way, only the other way around.
    - klyrs 3y ago
      Sometimes, I daydream about being a nameless drone in a cubefarm, taking home a nice paycheck and leaving my work at work. But, yeah, the dream passes quickly because I know I'd hate it with a burning passion.
      - antupis 3y ago
        it is fine the first 6 months then bore out hits and you will be miserable.
      - chii 3y ago
        it depends. If you want to seek meaning in your work, then yes, cubicle farms will not give you fulfilment. But if you're just after a steady paycheque, and don't give a damn about the business, your work nor its purpose, then this is fine. And it gives you free time to live outside of work too.
devjab 3y ago
Have you changed an organisation from the bottom up? In two decades I’ve never seen it happen in organisations larger than 50 people. You can change something, like how an engineering team works and how an organisation does DevOps and other things that management doesn’t really know anything about and trust their employees on. But moving an organisation into something like team topologies which is a more modern expansion on Conway, is virtually impossible from the bottom up in my experience. Change management in general is very hard both directions, but it’s much harder going upwards because going upwards means you don’t really have the support of management above you. Maybe they’ll humour you but to make an actual impact you’re going to need them onboard. You’ll even have to reach pretty far up top if you want to inflict lasting culture changes as things carried by a single (or few) managers often dies with them. My career has sort of put me in a role where I help non-tech startups transition from that to medium or enterprise size. I solely focus on the tech journey though, as I know I won’t have too much impact on culture or work processes on the grander scale. Often this leads to a semi-team topologies approach as the tech teams divide systems into independent business related services, but as a whole I don’t expect any changes to reach outside of the development departments.
- _puk 3y ago
  I'm not disagreeing on your overall point, but it can be done (I've done it with 130+, so there's a lot of incumbent process and numerous senior managers to align). The key is having a champion who can tie change in with higher level desires. In these orgs there's often an external (as in stakeholders external to prod eng) perception that "engineering is slow, product doesn't deliver, they're preventing us delivering our OKRs", and that can be used as leverage for change. You can't go dark and stop delivery, but you can usually carve out a 10 - 20% allowance for change (that doesn't sound much, but is 1 - 2 days every 2 weeks, which quickly adds up). Start small, show success in impacting metrics that external stakeholders care about, then next quarter push for more. I've focused myself in a similar area as you, but actually lean into processes and people, whilst still guiding tech - maybe we should chat!

krig 3y ago

If you want to dig into Conway's law and its implications, I can't recommend this video essay by Casey Muratori enough: https://youtu.be/5IUj1EZwpJY?si=dPxsXieBwZsP0PPP https://youtu.be/5IUj1EZwpJY?si=dPxsXieBwZsP0PPP Fair warning though, you'll lose all hope that companies like Microsoft will ever manage to produce anything that they don't then ruin.

Xelbair 3y ago
>Fair warning though, you'll lose all hope that companies like Microsoft will ever manage to produce anything that they don't then ruin. you are implying that we still had any hope left in such endeavors.
jiggawatts 3y ago
Oh. My. God. This video explains everything I've seen in the enterprise IT of a huge government org that was the result of a long series of back-to-back mergers and splits. It's exactly this! Conway's law, but over time. Dysfunction not just because of the large hierarchy, but also because of the built up layers of history. Some elements still limping along, some essentially amputated and mere phantom limbs of the org tree now, some outright dead and spreading miasma and corruption from their decay. I knew or suspected most of this, but to hear it said out loud so clearly has crystallised my understanding of it.
- krig 3y ago
  Yeah once it hits, it really explains so much of the issues in large organizations (and explains a lot about small organizations / indie development as well). For example, why is it that mergers and buyouts rarely work out? Conway's law largely explains it! When a product is bought by an organization, the result is an integration over time of both organization org-charts combined. If the companies are both large, this immediately becomes an intractable mess. If the original company was small and the new company is large, it _also_ becomes intractable because now different teams will have to communicate to manage or split components that don't fit the communication patterns of the new organization, and will lead to large refactors and rewrites and in the end the essential qualities of the original software will inevitably change. Even if you know this, there is nothing you can do - you have to organize yourself somehow and how you do that can't be left up to just mirror whatever this piece of software that was brought in happens to be organized - because _that too_ doesn't reflect an actual org chart but is an integration over time of all org charts that have touched it. I don't even know how to think about the implications this has for the use of open source software and how open source is developed, like... I think there are huge opportunities for research into Conway's law and how it relates to software development practices, software quality, etc.

dasil003 3y ago

Top down comes with its own risks. The bottom line is big ideas and big change can only happen with both the champion at the top, as well as good understanding at the bottom, and a critical mass of good alignment and competence throughout the middle layers. Though Conway's Law is immutable, it doesn't necessarily depend on a formal org chart, it can be worked with by simply creating ad-hoc communication structures between the right tech leads and competent managers. A handful of technically weak or empire-building managers in the middle can fuck the whole thing pretty easily though, and depending on the lifecycle of your company it may be a lost cause due to Pournelle's Iron Law of Bureaucracy.

LightFog 3y ago
Although it’s not always necessary to go through the middle - you can do the old switcheroo and build a parallel org in your image, emerge from the shadows and duke it out with the old structure.
- chasd00 3y ago
  If you come at the king you best not miss. Fail at taking down the old structure and those relationships are so destroyed they will come after you. I’ve seen groups of consultants become unemployable across the whole industry by failing to take down the old guard. Word spreads.
szundi 3y ago
Very good comment
nonrandomstring 3y ago
> as well as good understanding at the bottom, and a critical mass of good alignment and competence throughout the middle layers. How do you hold the middle together? Especially under such turbulence? "Strong" leadership isn't enough. Reflective practice [0] is one way to build that. It's common in medical and some safety-critical civil/military spheres but strangely missing from many corporate structures. I talk about it here with regard to a more mature cybersecurity stance [1]. It intersects with Agile ideas but doesn't make much noise in software engineering project management as much as it should? Anyone have this in their org? [0] https://en.wikipedia.org/wiki/Reflective_practice https://en.wikipedia.org/wiki/Reflective_practice [1] https://cybershow.uk/blog/posts/reflective https://cybershow.uk/blog/posts/reflective

rpastuszak 3y ago

I'm adding "Conway’s Soup" to my vocab as a name for the result of such process.

julik 3y ago

And even then - the senior champion might as well burn out on it, even when they do manage to pass the initiative. Been there too.

austin-cheney 3y ago

That highlights the greatest repeated tragedy to befall software: poor leadership. For some bizarre reason developers almost always think they can fix people problems with better tools. For example if all your developers suck give them a popular framework. It’s just an excuse to avoid dealing with people that provides license for the children to run the daycare. If you want excellence set high standards defined by rules that to hold people accountable and impose ownership (liability/reward). It’s not complicated but it requires not being terrified of assertiveness and confrontation from the top down.

bsenftner 3y ago
> It’s not complicated but it requires not being terrified of assertiveness and confrontation from the top down. It requires the professional communication skills that are not taught in a STEM education. That's why this is all so difficult: we are not taught how to communicate effectively with one another, and the entire tech landscape has poor communicators misinforming and misleading one another.
- geraldhh 3y ago
  Statements of poor communication always make me wonder if the shirky principle might be part of the problem
  - bsenftner 3y ago
    I do not believe so. This lack of communication skills is also due to a lack of recognition of the value good communications engenders. An undergraduate business school education pragmatically touches on professional communications, but only as far as how to motivate and control people, not how to effectively communicate - as in a shared synchronization of understanding, which is what professional communications is all about. Colleges of communications teach professional communications as their foundation, before the various media majors one graduates within. The more I look at the levels of communications in general within society, our civilization has not yet recognized how critical communications are to every aspect of life, not just business and careers. Good communications are like fire, capable of destroying and capable of being the foundation greater things are built, and the lack of this recognition amazes me.

deleted 3y ago

[deleted]

gilbetron 3y ago

Conway's Law isn't a "law" - it is an interesting observation and there are definitely interactions (both ways) between organizational structure and software "design". But people weigh it too heavily. There are plenty of counterexamples of, for instances, fine-grained teams in one company that build a monolith, and the same type of teams in another company building a microservices architecture. Complex software is complex, and once your require more than a handful of people, that complexity requires a complex organization structure to handle the challenges of communication and responsibility. But it isn't a purely deterministic relationship between organizational structure and software structure. More that certain organizational structures are really bad at building complex software, and some are better. It is interesting to think about, but there is this tendency to invoke "Conway's Law" as some simple method of fixing the extraordinary complex problem of developing and evolving complex software over time. Really what it is is that organizations from the 70s, 80s, and 90s were built around building physical things, for the most part. Manufacturing and construction, mostly. And taking those organizations and applying them to software development fundamentally was a terrible match. We had to find new structures that were better suited, and we have gotten a lot better, but we are still working on it. Management was taught by those that managed manual laborers, who's output was easy to measure, and whom you could force to work a certain amount without a significant drop in their output. The same isn't true for knowledge workers. And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago. Read Conway's original paper, it is interesting, but it isn't a physical Law that cannot be violated!

lolinder 3y ago
> But people weigh it too heavily. There are plenty of counterexamples of, for instances, fine-grained teams in one company that build a monolith, and the same type of teams in another company building a microservices architecture. These aren't counterexamples because Conway's law makes no comment on how the teams will choose to deploy what they build. It talks about the overall design of the system, the solution space that was explored. Windows is a monolithic application if the alternative is microservices, but anyone who gives it more than a cursory glance can see the org chart (both past and present!) reflected in the disjointed UX. > And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago. I'm not sure why this makes Conway's law not applicable anymore—what you're describing is that new management does a better job of creating communication structures that lend themselves well to creating software. That may well be correct, but the resulting improvements validate Conway's law! If we're getting better at software, it may well be because people are talking about and accounting for the impact that communication structures have on the output.

snotrockets 3y ago

That's the thing that stumped me here: how does a _Senior Staff Engineer_ doesn't understand their job isn't to build software, but to enable the rest of the organization to build software? (Paraphrasing on that old Toyota principle)