The need to record With collecting comes the need to record. A specimen without a label is simply a (sometimes) pretty object. Without its associated data it is scientifically worthless. Roger Kitching, A Reflection of the Truth informationorganization
Political chains of influence In Chicago, formal chains of influence and authority are entirely overshadowed by the ad hoc lines of control which arise naturally as each new city problem presents itself. These ad hoc lines depend on who is interested in the matter, who has what at stake, who has what favors to trade to whom. This structure, which is informal, working within the framework of the first, is what really controls public action. It varies from week to week, even from hour to hour, as one problem replaces another. Nobody’s sphere of influence is entirely under the control of any one superior; each person is under different influences as the problems change. Although the organization chart in the Mayor’s office is a tree, the actual control and exercise of authority is semilattice-like. Christopher Alexander, A City Is Not a Tree politicsteamworkorganization
The pie has been made "In today's world, boundaries are fixed, and most significant facts have been generated. Gentleman, the heroic frontier now lies in the ordering and deployment of those facts. Classification, organization, presentation. To put it another way, the pie has been made—the contest is now in the slicing." David Foster Wallace, The Pale King informationorganization
Rewarding Curation An Article by Wesley Aptekar-Cassels notebook.wesleyac.com Something interesting about the design of Twitter is that it doesn’t have much of a way of rewarding curation, only authorship. ...I’m inclined to think that the mechanisms of distribution of information are very important, and I think figuring out ways to reward good curation is probably an important thing. ...I don’t really know what the solution is here, but I do think that finding and curating good links and bits of information is useful, and something that should be rewarded more than it currently is. organizationcollectionscontent
Two types of work An Article by Jorge Arango jarango.com There are two types of work: growth work and maintenance work. Growth work involves making new things. It can be something big or small. In either case, growth work often follows a loose process. Maintenance work is different. Maintenance work involves caring for the resources and instruments that make growth work possible. This includes tools, but also body and mind. Maintenance is ultimately in service to growth. But effective growth can’t happen without maintenance. As with so many things, the ideal is a healthy balance — and it doesn’t come without struggle. organizationinformationmakingwork
Collaborative Information Architecture at Scale An Article by Brandon Dorn www.viget.com Here I describe an approach for defining new information architectures for large organizational websites managed by many stakeholder groups. Broadly speaking, there are four general phases to the approach: Auditing. Begin by immersing yourself in existing content and encourage stakeholders to adopt a critical, audience-minded perspective of their content. Diagramming. Work with stakeholders to develop new conceptual categories that better serve audiences and organizational direction. Elaborating. Think through content in detail and test new categories against specific instances and edge cases. Producing. Prepare content teams for production using a shared database of new sitemap pages and editorial considerations that you’ve developed incrementally. Half of design is facilitation The Ladder of AbstractionA Pattern Language decisionsorganizationpatternsanalytics
Figma's Engineering Values: Craftsmanship An Article www.figma.com Craftsmanship is about thoughtfulness and care in the work we do. It means being deliberate about what we build and how possible it will be to maintain and extend in the future. A solution that will require revisiting in a month — because it’s not scaling, because it has a ton of bugs, because it doesn’t support all the use cases it needs to — is not useful to us and ultimately will generate pain for our users. What we trade off by living this value is (sometimes) day-to-day speed. It’s easy to imagine an engineering team that emphasizes moving fast over keeping things stable and bug-free -- like a team building a product that isn’t responsible for important user data and doesn’t support anyone’s livelihood. But given the role the Figma product plays in the lives of our users, we feel it’s worth it to ensure we hold a high quality bar for them. And in the long run, being thoughtful about how we build often reduces the complexity of ongoing development and new features regardless. craftsoftwarequality