I grew several grassroots software projects in a 5-digit size company. The last had least 10-15 direct contributors and tens of others involved. It grew so large the CTO organized a summit to get the main IT organization along with everyone else involved on the same page and it came out as the "winner".
I did all this as an individual contributor. We called them "internal open development" and had developed an entire model around it. You can basically create "parallel" hierarchies within organizations. It's not that different from the "build something people want" idea, but it actually makes those people part of it.
> The challenge is that these communication networks are informal, fluid, and nearly impossible to map. I bet most large tech companies could have a fairly accurate map of the network in less than a week if they really wanted it. Simply look at every email and chat reply between two people and build a graph whose nodes are people and with edges whose strength is the number of those interactions. Done. Of course, ther…
Organizational Network Analysis (ONA) Tools. Google that and you will find many out of the box tools that tap into email, calendars, Slack, Teams, Google Workspace, et al.
> The challenge is that these communication networks are informal, fluid, and nearly impossible to map. I bet most large tech companies could have a fairly accurate map of the network in less than a week if they really wanted it. Simply look at every email and chat reply between two people and build a graph whose nodes are people and with edges whose strength is the number of those interactions. Done. Of course, ther…
I know someone who was building a product like this that they intended to sell for the purposes of improving M&A efficiency. You feed it slack, zoom, etc. info and then get a sense for "who needs to be in the room" at various levels, see where duplicated management effort is, and so on. Not sure where it went, but this was around 10 years ago.
> The challenge is that these communication networks are informal, fluid, and nearly impossible to map. I bet most large tech companies could have a fairly accurate map of the network in less than a week if they really wanted it. Simply look at every email and chat reply between two people and build a graph whose nodes are people and with edges whose strength is the number of those interactions. Done. Of course, ther…
I was in a non-tech org of about 100 people and they had this. The data is so accessible to admins that it’s almost hard not to do it.
Anyone who has worked in disaster recover and business continuity planning knows how to map an organizations processes and people.
There is always 2 different orgs: the organization that is formally stated for legal/insurance reasons, and the REAL organization that is messy and ad-hoq.
> The challenge is that these communication networks are informal, fluid, and nearly impossible to map. I bet most large tech companies could have a fairly accurate map of the network in less than a week if they really wanted it. Simply look at every email and chat reply between two people and build a graph whose nodes are people and with edges whose strength is the number of those interactions. Done. Of course, ther…
I was in a non-tech org of about 100 people and they had this. The data is so accessible to admins that it’s almost hard not to do it.
This would be a better article if the term "organic" was defined.
I don't think it's hard to infer from the context and example.
An organic team is a group of individuals that forms spontaneously within an organization based on informal communication networks and interpersonal relationships rather than formal directives or predefined structures. Such teams typically emerge in response to a specific need or opportunity and are composed of members from various departments who collaborate based on shared goals and complementary skills. Unlike traditional teams, their existence is not documented in official organizational charts, and their composition can be fluid.
Isn't this effectively a core operating principle of DAOs? Members self-organize and declare their roles and accountabilities. Tooling has been built specifically around structuring, visualizing, governing, and incentivizing this emergent organic structure. Traditional orgs could learn a lot from what's been happening there.
I find the automate csv shuffling example interesting. I have never worked in a place that was this organic. You can’t just find some idea and do things. There are road maps and promises made to manager and product. What incentivises your manager to just agree to let you work on your own projects?
> What incentivises your manager to just agree to let you work on your own projects?
I've seen it work in a few ways; these are not mutually exclusive: * You have someone whose job or as part of their job is to it is to discover these kinds of internal organizational efficiencies and automate them. Something that organically comes up like this gets assigned to that person. * Managers are not incentivized to stick to a rigid schedule or metrics based on an inflexible roadmap. * Flexibility and autonom…
These sound like good ideas. I guess I just don’t work in such companies and I think this is the norm unfortunately. There are strict timelines that span months if not years, often optimised to a large extent. There is little room for spontaneity and organic projects to come up.
I've worked at companies where this sort of thing is encouraged, and others where I'd be afraid to even ask about the possibility of doing such a thing. Naturally it's a spectrum.
(Although, there is also the company that claims to encourage it, and then buries you in bureaucracy...)