# Opening knowledge across the organization **Opening knowledge across the organization** requires incentives, decision records, and forums that make teaching valuable. Leaders shape whether useful facts travel when they choose promotion evidence, ask who else can operate a system, and fund places where decisions remain findable. Openness is not universal publication. It is authorized access to enough truth for another group to act. ## Incentives decide what people preserve If promotions celebrate private rescue work but ignore the engineer who made rescue repeatable, people learn to protect expert dependence. The hero receives urgent visibility. The teacher spends time on an interface note, a demo, or a review guide and may appear slower. Leadership language has to correct that imbalance. Add evidence of transferred capability to growth expectations. Ask who can now make a decision, operate a service, or explain a constraint because of the person's work. Keep technical depth central. The valued result is expert judgment that reaches more work, not publishing for its own sake. Managers should also inspect assignment patterns. The same patient engineer may answer every cross group question because they are good at it. Without rotation and credit, openness becomes hidden glue work. Treat the load as planned organizational work, not an endless favor. ## Decision records give history an address Architecture records are valuable when they state the choice, relevant constraints, alternatives considered, owner, and conditions for review. They are less valuable when written as ceremonial essays after everyone has moved on. Capture the decision near the moment while disagreement and evidence remain visible. Use ordinary titles and search terms. A record called ADR 1842 may satisfy a numbering system but remain invisible to a product manager searching for payment retry guidance. Include the customer or operating concept people actually use. Link the record from service and product entry points. A decision record should not freeze the organization. State what would trigger reconsideration. New regulation, scale, customer behavior, or platform capability can change the right choice. Visible review conditions encourage challenge without reopening settled work every week. ## Demos need a findable result A company demo can spread awareness, but attendance is not durable access. After the session, preserve the problem, capability, known limit, owner, and link to use. Someone who joins next month should be able to discover the result without replaying an hour of video. Design demos around another group's action. Show how a product team uses a new identity capability, what failure looks like, and where an exception goes. A tour of internal components may impress experts while leaving potential users unable to begin. Invite questions from support, product, security, sales, and operations. Their confusion reveals boundary gaps that close peers may not see. Return good answers to the maintained entry point. Otherwise the demo produces a brief burst of openness followed by another private memory network. ## Organizational mechanisms and outcomes | Mechanism | Useful outcome | Failure sign | | --- | --- | --- | | Promotion language | Teaching receives credit | Only rescues are visible | | Decision record | Reason and owner are findable | Choice lives in a meeting | | Company demo | Another group can begin | Only attendees know | | Skip level | Boundary friction surfaces | Questions stay local | Mechanisms should be judged by what changes. A record system with thousands of pages can still fail if current owners and decisions are unclear. A lively demo series can still favor polished presenters over essential operating knowledge. Ask which group acted differently afterward. Use a small set of recurring tests. Can another authorized team locate the current constraint? Can they identify the owner? Can they take a safe first step? Can they challenge stale guidance? These tests keep organization wide initiatives connected to daily engineering. ## Leaders should ask who else can operate this When leaders review a critical service, they often ask about uptime, cost, and roadmap. Add a capability question: which other authorized people can diagnose, decide, or recover without the usual expert present? This reveals organizational exposure without reducing the discussion to individual absence. The answer may span teams. A platform group can operate the service, security can approve an emergency pattern, product can explain customer effect, and support can identify affected cases. Resilience depends on the path between those roles as much as knowledge inside each one. Avoid demanding universal depth. Not every group should operate production or inspect sensitive data. Define the action each role must perform and provide the matching access. Good organizational transparency is specific about authority. ## Use skip level questions to expose boundaries Skip level conversations can reveal where official knowledge and practical knowledge differ. Ask which answer requires knowing the right person, which approval changes by reviewer, and which customer question repeatedly returns to engineering. Invite concrete cases rather than broad complaints about communication. Protect people who surface friction. If leaders immediately route every comment to the named team as a performance issue, employees will stop sharing. Look for system patterns, verify with recipients and sources, and involve both sides in repair. The aim is a healthier boundary, not a list of culprits. Close the loop. Tell participants which route, record, or ownership decision changed. Visible response shows that raising a boundary problem is useful work. Silence teaches people to keep relying on private workarounds. ## Open knowledge in a deliberate sequence - Choose one costly organizational boundary. - Define the action another group must perform. - Locate the fact and decision owner. - Separate sensitive evidence from usable guidance. - Create a findable entry point. - Reward the people who test and maintain it. - Review whether independent action increased. A sequence limits the urge to launch a company wide documentation campaign. Begin where delay, customer harm, or operating risk is visible. Learn which mechanisms work in your organization, then repeat with evidence. Local success creates credible examples for leaders and teams. Include maintenance from the start. Organization wide material decays quickly as structures and products change. Tie review to service ownership, policy change, and incidents. A central program cannot keep every technical truth current without accountable local owners. ## Separate real security from status secrecy Real security can explain the protected asset, authorized audience, access rule, and safe guidance. Status secrecy says only a few important people may understand, often without a specific threat. Leaders should challenge the second pattern while strengthening the first. Ask for layered records. A broad audience may see the approved pattern and business consequence. A smaller authorized group may inspect threat detail. A very limited group may hold credentials or active response data. Layering avoids the false choice between exposing everything and sharing nothing. Audit exceptions. If the same senior people bypass the stated route through private contacts, the organization teaches that access follows status. Make urgent routes explicit, record decisions, and review whether ordinary teams can reach fair answers through the designed process. ## Change recognition and review language Thank public answers when they convert a repeated private question into shared capability. In reviews, describe who could act and what risk or delay decreased. Avoid praising visibility alone. A flashy presentation that leaves no usable trail should not outweigh quiet work that changes how several groups operate. Recognize receiving teams too. Testing guidance, naming confusion, and contributing examples are part of opening knowledge. If all credit goes to the source, recipients become passive consumers and quality suffers. Strong boundaries are built jointly. Report organizational progress with cases, not slogans. One example might show that a product team now chooses an identity pattern from approved guidance. Another might show support explaining a payment constraint without escalation. Repeated independent action is credible evidence that knowledge is traveling. ## Govern the routes without centralizing every answer A central team can define simple expectations for ownership, discovery, sensitive access, and review. It should not become the approval point for every technical note. Local teams understand the changing facts and need authority to maintain their interfaces. Central support is most useful when it removes tool friction and compares patterns across boundaries. Choose a few shared locations and clear purposes. Decision records hold why a choice was made. Service entry points hold current supported action. Incident records hold impact and learning. When every tool can contain every kind of truth, search produces several plausible answers and people return to personal networks. Make retirement visible. Mark replaced records, point to the current source, and remove stale links from common entry points. Keeping history can be valuable, but history must not look like current operating guidance. Readers need to distinguish what happened from what they should do now. Ask organization leaders to sponsor one boundary they depend on. Their role is to clarify priority and authority, not write the material. When a decision spans product, platform, security, and support, a sponsor can settle ownership that no documentation tool can resolve. Review access during reorganizations. Teams change names, services move, and old channels remain visible. Before closing the change, test whether a person outside the move can still find the current owner and operating guidance without relying on personal memory and guesswork. Organization charts describe reporting, but they rarely provide the whole route from a customer question to an engineering decision. ## What are common questions? ### How do promotion systems encourage knowledge silos? They encourage silos when private rescue work receives credit while teaching, durable answers, and transferred capability remain invisible. ### What should an architecture decision record contain? Capture the choice, relevant constraints, alternatives, owner, and conditions that should trigger another review. ### Are company demos enough to spread knowledge? No. Preserve a findable result with the capability, limit, owner, and route to use after the live session. ### How can leaders test organizational transparency? Ask whether another authorized group can find the current constraint, identify the owner, and take a safe first step. ### How should sensitive knowledge be opened? Layer access so broad groups receive usable guidance while smaller authorized groups can inspect sensitive evidence and controls. Related: [opening knowledge silos between teams](https://isilta.com/blog/knowledge-silos-between-teams/), [what a knowledge silo between teams looks like](https://isilta.com/blog/what-a-knowledge-silo-between-teams-looks-like/), [sharing knowledge with your customers](https://isilta.com/blog/sharing-knowledge-with-your-customers/).