It sounds reasonable, but I think a key requirement of operating like this would be to have solid leaders that will guide the organization in the correct way.
This is similar to the best blog post I've ever read on organizations by coda hale [1]. His perspective of viewing an organization like a distributed computing system is enlightening and highly pragmatic.
Scaling organizations is hard. To scale well, you need to avoid contention on shared resources and continually work on force multiplier type projects.
Thank you so much for introducing me to that article. It's fantastic! I've made this comparison forever, and used a lot of the same arguments -- I wish I had written this!
Quite cool to see my conclusions on viewing organizations as distributed systems echoed by other people, and, in particular, explained in such beautiful form.
In this model communication has to go up to go across the silo. The "white space" in the organization is filled with poison gas (or strong cultural taboos against "breaking the chain of command"). Before you talk to someone you need to talk to their manager (or your manager must talk to their manager).
It's an interesting thought experiment for organizational design. If you had enough information you could partition the challenges an organization faces into a set of mutually exclusive collectively exhaustive set and assign one team to each challenge. Of course the world does not stand still and your perfect decomposition of teams to problems starts to go obsolete as soon as you announce it.
1. Formal Reporting Hierarchy: manages formal budget and compliance with laws and regulations.
2. Informal Networks: hold social capital and operate in the “white space.”
3. Expertise Networks: hold intellectual capital and procedural knowledge that enables value creation.
This model remove the second and third category of networks as options. I suspect that an organization with only a formal hierarchy would be neither robust or resilient in the face of changes in the outside world (e.g new competitors, new opportunities, changes in customer needs, etc..). Christopher Alexander wrote about the value of multiple overlapping networks and a messy but lively organization in "A City is not a Tree" (See https://www.patternlanguage.com/archive/cityisnotatree.html ). I think his insights also apply to organizations.
I didn't intend to argue against communication or collaboration between silos. When a leader implores the people around them to "break down silos", they're usually not being very explicit about org design or communication design or collaboration design. I argue it's important to be explicit about the collaboration model of teams -- and that can work across silos. For example, you might have a product marketing person (from the marketing silo) who is embedded in a team or a couple of teams and work closely with them. There are many collaboration models you can choose from that effectively allow teams to coordinate their work.
My next post is going to be about the structures you can use between teams and organizations.
You make a really good point about informal and expertise networks. Do you agree that good org design is often about making the value creation networks overlap to whatever degreee possible with the org structure? I enjoyed your blog post!
I think Christopher Alexander's insights into the organic structure of natural cities, what he calls a semi-lattice, is what a long lasting organization needs. It's never optimized at any moment in time but it continues to improvise, adjust, and adapt. Cities live much much longer than companies. I buy into Hayek's hypothesis that you never have enough information or intelligence to centrally plan anything above a very small scale.
I don't quite understand what your concerns are about "silo busting." I have normally seen it applied to teams that have become to locally focused, who don't care about the downstream consequences and second order effects of decisions they are making and outputs that they refuse to adjust.
Happy to chat or work on a joint write-up (contact info in profile). I don't have the sense that we are in agreement but that can establish a common ground to walk around the implications of our different perspectives.
I love the point you're making, and perhaps what I'm trying to say isn't coming through in the piece.
Another way I've talked about this (to myself) in the past is that there is something akin to the cathedral vs the bazaar approach. One is designed, intentional, centralized, and structured. The other is informal, emergent, and distributed. I think this is what you're getting at with the organic structure of natural cities?
I believe the best organizations actually have some attributes of both -- tension between design and emergent structure.
Companies usually lack the right structure to really have emergent properties without bad results (see the excellent Coda Hale article referenced in another comment for some of the math behind this). I believe it takes some design to set things up so that emergent qualities can be successful.
You shouldn't squash things that arise between silos, like new communication pathways and even some collaboration. Those are very necessary and important. But I do think you need to keep an eye on collaboration, because it's often a sign that there are structural problems that will break down without further design.
The best designs, I think, allow for emergent qualities naturally.
I guess I also agree with Hayek's hypothesis, except that I'm not sure it applies here. For example, if your problem is that the go to market organization doesn't understand what is happening within the product development organization, that is a very solvable problem -- you can solve that many different ways -- the two that come to mind are role definition and communication channels.
A lot of what I'm advocating for is design that is compatible with how human beings work together, and sensitive to their limits.
I'm super curious if I'm missing your point or if you'd suggest adding anything to the piece to clarify this point. Thank you for your thoughtful comment!
They're organized functionally, and are one of the only companies in the world that seem to have cracked this at scale. I've always been super curious how that works in practice.
This article argues against functional organization (as in most cases organizing functionally increases your coordination needs within a company).
My understanding is there is considerable activity and communication in the white space of the organization chart at Apple. Strict silo organizations tend to be extremely bureaucratic and slow moving.
perhaps the silos are big enough (like an iphone silo, a macbook silo...) that they don't need to communicate so much between them? Or they got silos, but also effective communication channels?
AFAIR, the original idea of having silos came from Sloan/GM. Originally the groups were organized by function to reduce costs and streamline production. Say motors, wheels, windshields, etc. But this created problems because the end product lines didn't have much power over these groups. Some of these groups even became defiant as they were in high demand so they played the different product lines against each other.
The solution was to integrate vertically from the end product lines. So each of Chevrolet/Pontiac/Cadillac/Buick would have its dedicated teams for all it's neededs. No more delays and innovation was much faster. This turned GM from a mess to beating Ford.
The problem is this was seen as the ultimate organizational structure and Business Schools love magic recipes.
But I've seen the same problems in IT companies with massive Dev, QA, Production teams who end up antagonizing. Prom passive aggression (e.g. delaying approvals) to the occasional openly sabotaging (e.g. approving faulty releases). From experience, QA drifts into being the most political, Dev drifts into carelessness, and Production/Ops ends up over-reacting. This can be solved by integrating vertically.
But there is no silver bullet in organizational structures. There are many factors like culture, what's the product/service, the size of the organization, the geographical distribution of the teams and organization, and what kind of company it is (e.g. lean vs. moonshot).
The article itself says this, but the original idea comes from the military, not GM. Silos aren't functional; they're mission-based. Each unit down to the squad level is capable of operating in an entirely self-sufficient manner, but the scope of mission it can accomplish alone is smaller than higher-level units. This is accomplished in part by having all of the functional specialists you need in the units together with each other, instead of having functional silos. It's the original matrix organization, where you get assigned some functional specialty and your career is managed by that in terms of what you're required to learn and master doctrinally, and it also determines your unit assignments, but your chain of command is orthogonal. Your career manager has no say in what your mission is on any given day.
Somehow, it seems like the military is still the only organization to really get this right, but they of course have at least two pretty serious advantages over private organizations:
1) The personnel can't quit
2) They actually get training budgets and dedicated schools and enough slack in headcount to send people away from their units solely to learn their profession and then go back to the units
I don't think you need a matrix management system, and actually kind of hate matrix management. In general (there are exceptions) I AM arguing for cross-functional teams. More like D&D teams, with Fighters and Wizards and Rogues and Clerics on the same team.
The management structure is a kind of separate topic. You can have cross-functional teams with or without matrix management, and I'd argue it's way better to have it without matrix management. But this is a complex topic and a separate one.
I've got a memory of business organisation being classified into "D" type and "M" type organisations.
Sloan's model of a corporation comprised of largely autonomous divisions, with a central administrative department (legal, bookkeping, taxes, some marketing and the like) was the "new style" business of the 1940s -- 1960s.
The older monolithic structure was the "M" type.
Problem being that I can't find these terms readily (single-character terms tend to be search-averse). Do these ring a bell with anyone?
Say QA dumps a badly tested release which causes a lot of weekend drama for Prod and QA does not own up to management or apologize to Prod (e.g. they did it under pressure from Business or Marketing). In retaliation Prod doesn't approve releases after Wednesdays. I've seen much worse than this.
Prod probably doesn’t even think of this retaliation; they just think they’re acting like the sensible adults in a company that just needs to “become professional” here.
A lot of company red tape was thought to be green tape when implemented.
Edit: to be clear, I'm not saying any delay that isn't caused by high utilisation is attributable to malice. Just saying that if you've narrowed it down to those two, you've done the hard work. Those to are very easy to tell apart.
Collaboration is when people work together to produce an outcome. When teams are collaborating, it means they’re working with other teams to achieve outcomes together. That’s often a sign the team isn’t set up well. Ideally, it should have what it needs to do what it needs without dependencies on other teams.
I think you'd need to be very careful about how you implement that philosophy. It has the potential to be a recipe for every team rolling their own solutions to the same problems over & over again with very little individual knowledge making its way to become institutional knowledge.
Making every team self sufficient, if not done carefully, also has the potential to be wasteful when it comes to skillsets that the team doesn't need on a full-time basis when a few teams could share the same staffer for whatever that skillset happens to be.
This describes exactly what I have seen happen, with the exception of
> if not done carefully
I don't think you can really do it carefully and succeed. It can only work if the teams are naturally independent, i.e. with no overlap in workspace, projectspace and headspace. If you force that independence and separation you break stuff you need.
An under-appreciated element of teams rolling their own solutions is that teams vary in competence and solutions vary in quality. Preference for consistency at the expense of mediocrity is at least as serious a cultural disease in a large organization as the existence of “silos.”
This is a ckickbait title for an article that fails to communicate what it is really about.
OP seems to work in an company that give too much freedom to employees and as a result this is impossible to manage them. This has not a lot to do with collaboration.
I feel like what OP is trying to describe is "highly aligned, loosely coupled"
Companies are like good software: there should be well defined interfaces. Without them, communication as says the article is "many to many". This leaves a lot of leeway for those who use information for their own profit. And this includes management: "are you telling me you are not aware [you should have done this | we work like that | of this email from customer]?"
> A little collaboration is fine, .... Bezos structured Amazon so that teams were as independent as possible.
Maybe too much independent? It looks like AWS had roughly zero collaboration between teams. I wonder how they even get IAM to work with all the services.
> I wonder how they even get IAM to work with all the services.
They don’t “get it to work”. Whether it works is up to the teams, and the teams are allowed to have different views on priorities.
This makes secure adoption difficult for a client trying to build a thing from multiple teams’ products.
That IAM works at all is indication of sufficient values alignment across teams for prioritization of IAM to be good enough that most use cases are 80/20 met.
"The expected benefits of modular programming fall into three classes: (1) managerial -- development time could be shortened because separate groups would work on each module with little need for communication (and little regret afterward that there had not been more communication);"
This assumes pair-wise communication, but if you need to set up n-team cross channels then this can go up factorially (realistically it won’t, but definitely larger exponent than 2). To put it another way, thinking of teams as nodes and communication channels as edges doesn’t capture the possible complexity. It’s also not uncommon, I’ve had to work in cross-team environments where getting multiple teams aligned wasn’t just a series of pair interactions.
Not necessarily, Alice, Bob and Charlie talking together might not be representable through a set of <AB>, <AC>, <BC> interactions, sometimes you really need all three to be talking/listening together. Then the interaction is <ABC>.
This problem also appears in some physical materials where there are strong electron-electron correlations and so you can’t rely just on pair correlations for your calculations.
This is similar to the best blog post I've ever read on organizations by coda hale [1]. His perspective of viewing an organization like a distributed computing system is enlightening and highly pragmatic.
Scaling organizations is hard. To scale well, you need to avoid contention on shared resources and continually work on force multiplier type projects.
[1] https://codahale.com/work-is-work/