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?
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.
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.
On one hand my expectations for excellence in software are alien to my peers who just want to complete a JIRA task by any means possible. Yes, it is possible to deliver superior results for an entire day's effort in about 2 hours provided you aren't framed by all kinds of institutional roadblocks and unnecessary abstractions. I am scared to death to actually communicate my opinions regarding software because people tend to whine about how hard life is. For this reason I have abandoned my JavaScript career.
Then on the military side I have to unlearn the high agreeableness that is so necessary for not getting fired in software. By high agreeableness I mean keeping your opinions to yourself, not voicing concerns, treating everything with kid gloves, and making everything as easy as possible. The military side is a much safer environment that expects brutal honesty. Nobody there believes themselves to be god's gift to the universe and they are always in a learning mode, which means they are coach-able and will not whine about corrections and mentorship.
sounds refreshing but debatable whether an environment of honest brutality can be considered safe
interesting if endeavors with nlp and llm's can help to spread nuance or commodify motivation and control.
I'm calling this work 'human comprehension support'.
On the other hand, the non-squeacky wheel gets to collect their salary for a long long time.
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.
I sometimes wonder what would happen if a company hired 100 software engineers, gave them all the same task to program the entire thing independently on their own, and then paid them as a monotonic function of the ranking of their output against their peers. (Obviously, there are limits on what type of product could be developed here, but I think this still encompasses far more company products than you would suspect.)
It’s creative work, like anything else. 1 is not necessarily always the right size, but 100 certainly isn’t. If you look at musical bands usually a sweet spot is between 1-6. You can add more in eg an orchestra or choir but everyone’s not involved in the creative work.
Then it depends on how well you vibe with people. If you have extremely unique ideas and thoughts, you may be better off alone. If you find peers with similar values, preferences and experiences, you might be fine with 5 people.
Most teams I've been on or managed were at their optimal efficiency with three people. Just enough to keep any one person from making too many poor decisions, but not to many to spend half a day in meetings.
On the topic of Microsoft/Linkedin, aren't they the ones who used to or maybe still assign the same task to multiple teams and let the teams compete for who can deliver? That does sound vaguely like what you propose.
So he asked me to write my own queries as well to see who was right. Lo and behold, my numbers didn’t match either of theirs at all.
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.
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.
We humans can’t effectively communicate with groups larger than about 7 people, but AIs have no such limits. We could all simply talk to one manager that can integrate everything and everyone into a unified whole.
It’s like the ship Minds in the Culture series having hundreds or even thousands of conversations at once.
"Not Just Bikes" has a good few videos, including https://www.youtube.com/watch?v=n94-_yE4IeU and a couple more that talk about problems that larger roads effectively cause more traffic ("induced demand", "traffic generation"). Organizational structures are like roads, and like roads they can get overloaded, which in turn means traffic needs to be reduced. There is even communication jam, and to combat that something like enforced communication reduction (lower information throughput), etc. to keep this manageable. That also causes decision making being done with less and less information the more steps are included in a communication chain (like upwards/downwards in a hierarchy), which in turn means the quality of decision making is severely hampered by it.
This whole mess is also the reason why the agile manifesto puts humans before processes and other such things, in fact it implies you change even the organizational setup to fit the project, not the other way around. But in the space of "managerial feudalism" (David Graeber) this is pretty much impossible to pull off.
Once again, seizing the term AI to mean LLMs and other current generative techniques has poisoned clear thinking. When we think "AI", we are thinking about HAL and Cortana and C3PO, which is not what we actually have.
Casey's example is focused on a (frankly, ridiculously) large organisation but I've seen the same thing in numerous small companies with just 20-30 developers, and it's hard not to imagine that this is universal, which is a pretty depressing thought.
Recently I've been involved in a new project where teams were set up to be 'domain-specific' with the idea that this somehow avoided the issues of Conway's Law, but this just feels like exactly the same problem because team structures and the software that they end up producing is siloed in exactly the same way as the organisation structures that existed at the time.
Casey's point that the final design is inherently limited by the lack of high-bandwidth communication between the groups of people that need it most is also fairly demotivating, personally.
Tangentially, having been writing more Golang recently this made me think of Golang's mantra (or was it Rob Pike's quote) of "Don't communicate by sharing memory; share memory by communicating.". Go/CSPs concurrency and sharing model is interesting, but I wonder if it's a fair analogue to compare sharing memory by communicating as low-bandwidth communication, and communication by sharing memory as the high-bandwidth communication that seems to be needed for effective designs.
I partially disagree. IIRC their search is broken, and their job alerts are pretty lousy at de-duplicating advertised positions.
And IIRC they hijack the back button, which I find pretty offensive.
Literally the opposite of LinkedIn. I’m approximately user 5000 on linkedin, and since I joined almost nothing useful has been added, despite a huge increase in complexity
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.
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!
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.
I learned that the hard way, only the other way around.
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.
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!
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.
I recommend watching the talk! He specifically addresses the very points you bring up. Of course reality is messy and people especially so, but Conway’s law is one of very few theories within CS that has held up in replication studies.
...like ?
I'm not sure how public they've been about all this, but you certainly can teach an old dog new tricks, provided there is management buy-in (which we certainly had - at one point, our teams were moved between GBUs to save us from budget cuts).
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!