Growing Your Own Context — Three Practices for Individual Engineers

• Intended readers: Mid-career engineers worn down by context-starved organizations; junior-to-senior engineers working with customers who can’t produce requirements; anyone burning out trying to change the organization from below
• Prerequisites: General software development experience; the basics of the five-layer context model
• Reading time: about 20-22 minutes / skim for key points: about 8 minutes

Overview

“I wrote an ADR and nobody read it.” “I proposed running a postmortem and got ‘no time’ as the reply.” “I keep asking the customer for requirements and they keep telling me to figure it out on my side.” Most engineers have lived through some version of these exchanges.

Discussions of organizational context engineering describe how an organization should actively supply context to the people doing the work. The trouble is, very few organizations are actually designed that way. In most places, context doesn’t come out when you ask for it, and when someone from below proposes “let’s organize this differently,” the proposal is ignored. Morrison and Milliken (2000), in their seminal paper on Organizational Silence, argued that organizations are broadly intolerant of dissent and that employees routinely hold back on naming problems¹. In Asch’s classic conformity experiments, even with an objectively obvious answer, 75% of subjects conformed to the group’s wrong answer at least once². A meta-analysis by Thomas, Whitman, and Viswesvaran (2010) of voice behavior and performance found correlations of only r=.13 to .34, meaning that speaking up does not reliably translate into being recognized³.

The structure is identical for customers who never articulate their requirements. Almost no one can fully verbalize their own work. Polanyi’s classic line — “We can know more than we can tell” — captures the fact that most knowledge stays tacit inside the person who holds it⁴. Context holders inside your organization and external customers face the same structural problem: they have it, but they don’t (or can’t) put it out.

So the realistic strategy for an individual engineer isn’t “supplement what the organization supplies.” It’s “assume nothing will be supplied, and assemble your own decision resources accordingly.” This article lays out three survival strategies for engineers in context-starved environments — (1) reconstruct from traces, (2) write assuming no one will read, (3) supplement from outside — with evidence for each, concrete practices, and criteria for when to exit. Protecting your own context assets opens up more long-term career options than burning out trying to fix the organization. This article confines itself to the reality of context-starved environments; for the opposite future — how AI redraws role boundaries — see the sister article The PdM Obsolescence Debate and the Rise of FDE.

Why “Just Ask for the Context” Doesn’t Work

Organizational context engineering describes an ideal: leadership broadcasts strategy, middle management documents decisions, frontline teams record the history, and one-on-ones reinforce the background. In that world, an engineer just goes and gets what they need. Real organizations run in the opposite direction.

Context Doesn’t Flow Down

Even in the innermost technical layer, design decisions that aren’t written down evaporate — Jansen and Bosch (2005) coined the term knowledge vaporization for exactly this phenomenon⁵. Falessi et al. (2013) showed in a controlled experiment that without recorded design rationale, impact analysis and redesign become measurably harder⁶. If this happens at the technical layer, it’s much worse for business, organizational, and market layers.

“If you don’t know, just ask” only goes so far either. LaToza, Venolia, and DeLine’s 2006 ICSE paper documented that developers spend significant effort on code exploration and interrupting teammates simply to maintain their mental models⁷. The time of people you can ask is a scarce resource — both sides pay a friction cost. The set of “people who’ll actually answer when I ask” tops out at three or four, and everything outside that bubble stays empty forever.

Proposals Get Ignored

“If there’s no documentation, I’ll write some myself.” “Let’s start taking meeting minutes.” Someone always tries to drive things from below. But in some organizations, the structure crushes these proposals by design.

Morrison and Milliken (2000) describe organizational silence as a self-reinforcing pattern: organizations tend to be intolerant of dissent, so employees stop voicing problems¹. Noelle-Neumann’s spiral of silence theory describes how minority opinions, once suppressed, make the majority sound louder, which suppresses the minority further⁸. Inside a company, the person saying “let’s start writing ADRs” or “let’s run postmortems” easily becomes the minority — and gets pulled into the spiral when no one responds.

Gallup’s 2026 State of the Global Workplace report puts global employee engagement at 20%, with Japan at 6%⁹. In an organization where the bulk of people prefer the status quo, an improvement proposal registers as “noise demanding change.” Bond and Smith’s (1996) meta-analysis of conformity studies built on Asch’s paradigm confirmed that collectivist cultures (Japan included) show higher conformity pressure¹⁰ — the norm of “if no one else is doing it, I don’t have to either” hollows out proposals before they take root.

The People Most Engaged Get Pushed Out

The worst pattern is when the individual who keeps pushing for improvement gets treated as a foreign object and eventually pushed out of the organization. Edmondson’s program of work on psychological safety has repeatedly shown that without institutional protection for voice, the behavior of speaking up itself disappears¹¹. Gallup’s drop in manager engagement (30% to 27% in 2025) is a side indicator: the people who are supposed to surface frontline voices are themselves the first to burn out¹².

The result is a stable equilibrium where the organization neither articulates context nor accepts proposals to do so. Nobody is acting in bad faith — the structure has just made it individually rational to behave that way. That’s what wears down the individual trying to “change the organization.”

Customers Who Can’t Articulate Requirements: The Same Structure

The relationship with external customers has the same shape. “The customer won’t tell us what they want.” “The buyer can’t explain their own process.” This is a daily complaint in development organizations. PMI’s 2014 global survey identified inaccurate requirements gathering as the primary driver in 37% of project failures¹³. Iqbal et al. (2020) report that 48% of all software development errors trace back to requirements engineering¹⁴.

This isn’t because customers are incompetent. As Polanyi pointed out, most knowledge stays tacit in the holder⁴. The customer “does” their work but can’t necessarily “explain” it. The same goes for context holders inside the company — if the cost of verbalizing tacit knowledge is too high, even when you ask, they can’t answer.

So internal organizational context and external customer requirements are the same structural problem: the holder has it but it doesn’t come out. The engineer’s job is shifting toward practices that don’t depend on “getting it out of them” from either direction.

Strategy 1: Reconstruct from Traces

If context isn’t supplied as documentation, work backward from the traces that remain. This isn’t a specialized skill — many senior engineers already do this at the technical layer.

Technical Layer: History and Data Speak

• Git history and commit messages — git log --all --follow traces the evolution of specific files. Even with terrible commit messages, the timing, author, and scope of each change survive as facts.
• PR and code review comment history — Sometimes the discussion of why an implementation took its shape is still there. GitHub/GitLab threads are a strong source.
• Slack threads and tickets from past incidents — Even without a postmortem, the conversation logs from the time are searchable.
• Test failure history and CI logs — Why a particular conditional exists may be erased from the code itself but preserved in the tests.
• Archaeology of deleted code — git log -S "deleted-symbol" finds prior existence; git show reveals why it was removed.

This is the research area known as Software Mining / Mining Software Repositories, with established techniques for extracting design decisions and quality attributes from repositories¹⁵. For everyday individual use, git log and search are usually enough.

Business Layer: How the Numbers Moved Tells You What Mattered

• KPI dashboard history — Quarter-over-quarter movement of the numbers shows what got prioritized.
• OKR changes year over year — When the KPI itself changes, that’s the signal of a strategic shift.
• Revenue reports and IR materials (for public companies) — Public disclosures preserve the words leadership chose.
• Product roadmap history — The list of “planned but never shipped” features tells you what the organization gave up on.

Organizational Layer: Diffs in HR and the Org Chart

• Org chart diffs — Comparing six months, one year, and three years ago shows shifts in internal power dynamics.
• LinkedIn histories of people who left — Who left when, and where they went next, reflects the internal state of the organization.
• Hiring class concentration — A cohort hired in the same period embodies the leadership decisions of that moment.
• The gap between official and actual approval flows — The difference between formal sign-off paths and how things really get decided shows where real authority sits.

Customer Work: Pulling Requirements from Traces

The same reconstruction logic works for customers who can’t produce requirements:

• The systems, forms, and spreadsheets the customer is currently using — Evidence of how the work actually runs.
• Past support tickets and inquiry logs — Pain points the holder can’t self-report show up as traces.
• Industry regulations and compliance requirements — Constraints the customer can’t articulate are written down in industry documents.
• Equivalent features at competitors — Requirements that are tacitly treated as “industry common sense” become visible by comparison.

Limits of Trace Reconstruction

Reconstruction from traces has a hard limit: where no trace exists, nothing can be filled in. History transmitted only orally, meetings with no notes or minutes, tacit agreements — none of these can be reconstructed in principle. That’s why the next strategy is needed.

Strategy 2: Write Assuming No One Will Read

If proposals don’t get received, is there any point in writing? Yes — but redirect the audience from “the organization” to “your future self.” This is a small shift in perspective with a fundamentally different strategic basis.

Why Write: As Your Own Decision Resource

The act of writing is a training exercise for verbalizing your own context. Nonaka and Takeuchi’s SECI model places the conversion from tacit to explicit knowledge (externalization) at the core of knowledge creation¹⁶. When you write an ADR, even if the organization’s knowledge base gains nothing, your own judgment capacity is strengthened.

Grant and Ashford’s (2008) research on proactive behavior shows that proactive action produces better outcomes than passive waiting in ambiguous and complex environments¹⁷. The crucial point is that the effect of proactive behavior does not depend on the other party’s response — the person acting builds their own relationship, resource, and situational-awareness capacities regardless. Even if the proposal isn’t accepted, the proposer’s capability has gone up.

Don’t Circulate: Write as a Personal Note

Don’t post what you wrote on the company wiki and call it done. The moment it lands on the company wiki, it gets labeled “part of the organizational record,” and the futility of being ignored bites harder. Instead:

• Accumulate in a personal note system (Obsidian, Notion, plain text files) — close it as your own decision resource.
• Keep it portable for when you leave — managed under a personal account, with confidential information excluded, captured as abstracted lessons.
• Write it as a letter to your future self — imagine “if I came back to this project three years from now, what would I want to know?”

This is close to what Tiago Forte systematized as Building a Second Brain, but the difference in this context is that you’re not expecting any organizational contribution¹⁸. It’s strictly a personal decision resource, and not circulating it is a feature, not a bug.

Exceptions Where Circulation Works

A small number of organizations do receive what you write. You can usually tell ahead of time:

• There’s a specific reader (a successor, a new hire, the lead of the next team over) → likely to be received.
• Document built around quantitative discussion (KPI trend analysis, A/B test results) → becomes a target for argument.
• Postmortem immediately after an incident (memory fresh, impact visible) → gets short-term attention.

When these conditions apply, circulate. Otherwise, keep it in your personal note — that’s the operating rule for “write assuming no one will read.”

Designing for Your Future Self as the Reader

• Lead with the question — open with “why this design?” or “why this decision?” Your future self re-enters more easily through the question than through the answer.
• Topic-based, not chronological — “Payment feature design decisions” is more searchable later than “Meeting on 2026-05-12.”
• Record failures — not just what worked, but proposals that failed, were ignored, or were abandoned. These hold the largest lessons.

Strategy 3: Supplement From Outside

When the internal well is dry, supplement from outside. This is a strategy for filling internal context gaps with external resources while remaining employed (distinct from side jobs or job-hopping).

Industry and Domain Knowledge from External Sources

• Specialist books and academic papers — Business and market layers can be filled in with industry reports and academic research. With AI assistance, the cost of finding and summarizing papers has dropped dramatically.
• Industry conferences and meetups — Hearing other companies’ cases calibrates your sense of how abnormal or normal your own situation is.
• Communities (Slack, Discord, technical forums, external meetups) — Engineers from peer companies will relativize whatever your own organization treats as normal.
• Former colleagues and ex-coworkers — Once-departed relationships keep an independent perspective.

Cross and Sproull’s 2004 paper documented that professionals draw five types of knowledge from informal networks: solutions, meta-knowledge, problem reformulation, validation, and legitimation¹⁹. External networks can meaningfully substitute for missing internal context, and there’s research to back it up.

Use Interview Reverse-Questions as a Cultural Litmus Test

Job hunting is the single biggest window into other organizations. Beyond choosing your next role, it works as a periodic check-up that relativizes how abnormal your current company is. Use reverse-questions in interviews to measure context supply:

• “Do you use ADRs? Where are they stored?”
• “Can I see the postmortem for your most recent incident?”
• “How is onboarding documentation for new hires organized?”
• “Do meeting minutes from leadership decisions reach the engineering teams?”

An organization that can’t answer these — or immediately says “we don’t” — is at or below your current company’s context supply. Conversely, one that shows you actual documents has structural channels for context to circulate.

Networks of Former Coworkers

Former coworkers are a valuable resource because they listen to stories about your current organization with an independent outside perspective. Most ex-employees carry a mixed love-hate view of their previous employer and have higher tolerance for organizational criticism. Connecting on LinkedIn and exchanging updates once or twice a year is a long-term context asset.

That said, asking former coworkers for confidential information from their tenure is off-limits. Keep the relationship within “industry trends,” “other companies’ cases,” and “career decision input.”

A Minimum Bar for Community Participation

There are too many external communities to follow them all. As a minimum:

• Participate deeply in one community — depth over breadth.
• Publish once a month (blog, meetup talk, social media) — once you’re producing, the relationship stops being one-way.
• Attend a conference twice a year — opportunities to meet people outside your usual community.

Even this much establishes a context channel that doesn’t depend on internal supply.

Diagnostic Tool: The 5-Layer × 3-Channel Matrix

Diagnose quantitatively how much your organization is a “non-supplying” one. The point isn’t to measure against an ideal — it’s a tool to look at reality directly.

The Matrix

Cross the five layers defined in the five-layer context article (technical, user, business, organizational, market/social) with three absorption channels (read, ask, observe) to get a 15-cell grid that scores your company’s supply level:

Layer \ Channel	Read	Ask	Observe
Technical	ADRs, commit history, incident postmortems	Ask seniors about design decisions	Sit in on code and design reviews
User	Support tickets, usage logs	Conversations with customer support	Ride along on sales calls, site visits
Business	KPI dashboards, IR materials	Conversations with leadership and PMs	Attend executive meetings, quarterly reviews
Organizational	Org chart diffs, HR announcements	One-on-ones, diagonal conversations	Cross-functional meetings, all-hands
Market/Social	Industry reports, regulatory trends	Conversations at industry conferences	Customer events, trade shows

For each of the 15 cells, ask yourself: does this work in my company? Some examples:

• Technical × Read: Can you actually follow ADRs, commit messages, and incident postmortems?
• Technical × Ask: When you ask a senior about a design decision, do you get a real answer?
• Technical × Observe: Can you sit in on code and design review discussions?
• Business × Read: Can you access executive meeting minutes and KPI dashboards?
• Organizational × Ask: Does anyone tell you why Director A and Director B don’t get along?

In most organizations, at best 5 to 6 of the 15 cells actually function. That fact is the starting point of this article.

Responses by Diagnostic Result

• 10+ cells functioning: A fairly healthy organization. Lean on the organization’s supply and supplement with personal routines.
• 5–9 cells functioning: A standard organization. You need the three strategies in this article in serious operation.
• Fewer than 5: Low-supply organization. Start thinking about exit.

The numbers aren’t sharp thresholds. But just looking directly at the fact that your organization isn’t designed to circulate context is itself a defense against burnout.

When to Exit

If you’ve read this far and become convinced “my organization really is broken,” here are criteria for deciding to exit (internal transfer or job change).

Signs of Structural Problems

• After a year, three or more of the five layers are still blank — the territory unreachable by individual effort is too large.
• ADRs and memos you’ve written have gotten no response for six months or more — the dismissive culture toward context is entrenched.
• “Let’s take meeting minutes” has been shot down three or more times — the structure that refuses to receive improvement proposals is fixed.
• Departing employees give similar complaints — the structural problem is chronic, not transient.

When these line up, you’re past the limit of individual effort. The problem is on the organization’s side, not in your capability.

Signs of Your Own Erosion

The cost of trying to change the organization for too long shows up as your own capabilities eroding:

• The habit of seeking gets lost — “it won’t come out anyway” dulls the skill of active absorption.
• The habit of writing gets lost — “no one reads it anyway” dulls your verbalization ability.
• The habit of asking gets lost — “they won’t answer anyway” dulls your dialog skills.

Long-term tenure in a context-absent organization dulls your own sensitivity to context as an individual. This kind of erosion takes time to recover from after a job change.

Exit as a Strategic Choice

“Trying to make the organization better” is treated as a virtue, but whether the organization deserves the effort is a separate question. Of Hirschman’s three famous options — Exit, Voice, and Loyalty — when Voice doesn’t function, Exit becomes the rational choice²⁰. The pattern where the sponsor backing a reform initiative gets transferred or quits, and the in-flight effort collapses overnight, is a textbook example of Voice’s limits (see the sister piece Sponsor Loss Risk: How Change Initiatives Collapse).

Exit isn’t running away. It’s a strategic decision to protect your personal context assets. Moving to an organization that does circulate context is, itself, a form of capability development that opens up long-term career options.

Summary

Organizational context engineering describes an ideal. The number of organizations that actually meet that ideal is small. In most places, context doesn’t come out when you ask, and proposals get ignored. The relationship with customers who can’t articulate requirements has the same structure — the holder has it but it doesn’t come out.

Given that premise, individual engineers have three things they can do:

1. Reconstruct from traces — Work backward from Git history, KPI trends, org chart diffs, and customer operation logs to undocumented context.
2. Write assuming no one will read — Redirect the audience from “the organization” to “your future self.” Close it inside personal notes, expect no circulation, keep it portable for when you leave.
3. Supplement from outside — Fill internal gaps through communities, academic literature, ex-coworker networks, and interview reverse-questions.

These are individual strategies for keeping your contextual judgment independent of the organization’s state. The objective is different from organizational reform. Protecting your assets while preparing your next options is stronger long-term than burning out trying to change the organization.

And when structural limits become clear, exit is a fair choice. Where Voice doesn’t function, Exit is the rational call. Organizations that do circulate context exist. Finding one and moving there is a form of capability development.

Waiting for organizational reform takes too long. Starting from what an individual can do is reliably faster.

If you’re interested in how organizations should be designed to supply context, see the sister article: Organization Context Engineering First. This piece is its companion — the individual-survival edition.

For the “opposite future” — what happens when AI redraws role boundaries — see the follow-up: The PdM Obsolescence Debate and the Rise of FDE. The argument there: those who have internalized the survival practices in this article are the ones best positioned to thrive when FDE-style roles become the norm.

Related Articles

• The Five Layers of Context IT Engineers Should Recognize — The five-layer framework this article builds on
• Organization Context Engineering First — The ideal form: how organizations should be designed
• 1on1 Question Library — Context supply designed from the manager’s side
• The Last Asset a Senior Can Hand to a Junior — Context transfer between peers
• Why “Not Thinking” Becomes Rational — How organizational silence stabilizes as an equilibrium
• Sponsor Loss Risk: How Change Initiatives Collapse — How even organizations where Voice seemed to work can come apart

References

References are numbered to match the citation numbers in the text.

1. Organizational Silence: A Barrier to Change and Development in a Pluralistic World - Morrison, E. W., & Milliken, F. J. (2000). Academy of Management Review, 25(4), 706-725. [Reliability: High] ↩︎ ↩︎²

2. Studies of independence and conformity: I. A minority of one against a unanimous majority - Asch, S. E. (1956). Psychological Monographs, 70(9), 1-70. [Reliability: High] ↩︎

3. Employee proactivity in organizations: A comparative meta-analysis of emergent proactive constructs - Thomas, J. P., Whitman, D. S., & Viswesvaran, C. (2010). Journal of Occupational and Organizational Psychology, 83(2), 275-300. [Reliability: High] ↩︎

4. The Tacit Dimension - Polanyi, M. (1966). University of Chicago Press. [Reliability: High] (classic, bibliographic reference) ↩︎ ↩︎²

5. Software Architecture as a Set of Architectural Design Decisions - Jansen, A., & Bosch, J. (2005). 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05). [Reliability: High] ↩︎

6. Value-Based Design Decision Rationale Documentation - Falessi, D., Cantone, G., Kazman, R., & Kruchten, P. (2013). ACM Transactions on Software Engineering and Methodology, 22(2), Article 12. [Reliability: High] ↩︎

7. Maintaining mental models: a study of developer work habits - LaToza, T. D., Venolia, G., & DeLine, R. (2006). ICSE ‘06: 28th International Conference on Software Engineering. [Reliability: High] ↩︎

8. The Spiral of Silence: A Theory of Public Opinion - Noelle-Neumann, E. (1974). Journal of Communication, 24(2), 43-51. [Reliability: High] ↩︎

9. State of the Global Workplace 2026 Report - Gallup (2026). [Reliability: Medium-High] (industry survey) ↩︎

10. Culture and conformity: A meta-analysis of studies using Asch’s line judgment task - Bond, R., & Smith, P. B. (1996). Psychological Bulletin, 119(1), 111-137. [Reliability: High] ↩︎

11. Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct - Edmondson, A. C., & Lei, Z. (2014). Annual Review of Organizational Psychology and Organizational Behavior, 1, 23-43. [Reliability: High] ↩︎

12. Managers’ engagement is on the decline - HR Dive (2025). [Reliability: Medium] Secondary reporting of Gallup’s manager engagement figures (30% → 27%). ↩︎

13. Pulse of the Profession 2014: The High Cost of Low Performance - Project Management Institute (2014). [Reliability: Medium-High] ↩︎

14. Requirements engineering issues causing software development outsourcing failure - Iqbal, J., Ahmad, R. B., Khan, M., Fazal-E-Amin, Alyahya, S., Nizam Nasir, M. H., Akhunzada, A., & Shoaib, M. (2020). PLOS ONE, 15(4). [Reliability: Medium-High] ↩︎

15. Mining Software Repositories - Hassan, A. E., & Holt, R. C. (2004). International Workshop on Mining Software Repositories. [Reliability: High] ↩︎

16. The Knowledge-Creating Company - Nonaka, I., & Takeuchi, H. (1995). Oxford University Press. [Reliability: High] (classic, bibliographic reference) ↩︎

17. The dynamics of proactivity at work - Grant, A. M., & Ashford, S. J. (2008). Research in Organizational Behavior, 28, 3-34. [Reliability: High] ↩︎

18. Building a Second Brain - Forte, T. (2022). Atria Books. [Reliability: Medium] (bibliographic reference, practitioner book) ↩︎

19. More Than an Answer: Information Relationships for Actionable Knowledge - Cross, R., & Sproull, L. (2004). Organization Science, 15(4), 446-462. [Reliability: High] ↩︎

20. Exit, Voice, and Loyalty: Responses to Decline in Firms, Organizations, and States - Hirschman, A. O. (1970). Harvard University Press. [Reliability: High] (classic) ↩︎