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.
In "organize for Complexity" (https://www.amazon.com/gp/product/B010CL1X66/) Niels Pfaegling suggests every organization has three kinds of networks:
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 blogged about Pflaeging's insights in https://www.skmurphy.com/blog/2018/10/24/7-sets-of-insights-...
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 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.
This article argues against functional organization (as in most cases organizing functionally increases your coordination needs within a company).
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).
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.
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?
How do you tell the difference between malice and having a high task load?
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.
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.
Definitely recommend reading parent's quoted article.
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.
> 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.
Isn't this a power set thing? The cardinality of a power set doesn't increase factorially.
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"
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.
* Basic things like how you call pagination fields is f%cked up. https://gist.github.com/ilyash/f845d050df5c7c0805183790b28ac... . That precludes straightforward implementation of wrappers and what not.
* Code being published of quality which says (99% sure) it was never reviewed (at least not by someone proficient in programming and the language).
* CloudFormation lags supporting new features of other 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.
-- D. L. Parnas, ON THE CRITERIA TO BE USED IN DECOMPOSING SYSTEMS INTO MODULES, 1971, https://prl.ccs.neu.edu/img/p-tr-1971.pdf
