Instead of calling it Secret Santa, can we not call it Nondisclosure Claus?

Eoin

How to develop High Agency

• 🚀 Defining High Agency — High Agency is essentially the ability to find a way to get what you want, regardless of the conditions. It is a mindset where you feel a strong sense of control over your life. Instead of waiting for permission or perfect circumstances, High Agency individuals “force” things to happen through sheer will and resourcefulness.
• ↔️ ** The Core Difference** — The article distinguishes between two mindsets. Low Agency is characterized by passivity and excuses (e.g., “I can’t do X because of Y”). High Agency is characterized by action and questioning limits (e.g., “How can I achieve X despite Y?”). It is the shift from being a non-player character (NPC) to the protagonist of your own life.
• 🚪 The “Third Door” Analogy — A powerful metaphor cited is Alex Banayan’s concept of the “Third Door.” Life is like a nightclub: The First Door is where 99% of people wait in line. The Second Door is for the privileged and billionaires. High Agency people find the Third Door — they jump the fence, crack open a window, or sneak through the kitchen to get inside.
• 📞 The Steve Jobs Example — The post references a story about a 12-year-old Steve Jobs calling Bill Hewlett (co-founder of HP) simply because he found his number in the phone book. He asked for spare parts for a frequency counter. Hewlett gave him the parts and a summer job. The lesson: “Most people never pick up the phone and call. Most people never ask.”
• 🏆 The Ultimate Career Differentiator — In software engineering and business, technical skills are the baseline, but High Agency is what separates top performers. These are the people who don’t accept “we are blocked” as an answer. They act as an “unstoppable force” that clears obstacles, making them invaluable to any organization.

Things I Currently Believe About AI and Tech Employment

• 📉 The market slump isn’t just AI — While many fear AI is taking jobs, Fournier argues the current tech employment crisis is primarily driven by macroeconomic factors. The end of the ZIRP (Zero Interest Rate Policy) era, high interest rates, and specific tax changes (Section 174) regarding software R&D amortization are the real reasons companies are hiring fewer engineers right now.
• 👶 The “Junior Gap” danger — AI tools act as powerful accelerators for senior engineers who know how to verify the output and skip tedious syntax work. However, they pose a risk to juniors. If AI does all the “easy” tasks, junior engineers miss out on the crucial learning through struggle that is necessary to become senior engineers.
• 🗣️ The “Translation” barrier — The most difficult part of software engineering is not writing code, but translating ambiguous human desires and business requirements into strict logic. AI is currently poor at managing ambiguity. Therefore, the role of the engineer as a translator who defines what to build remains safe for the foreseeable future.
• 🌊 Infinite code, infinite maintenance — AI lowers the cost of generating code to near zero, which may lead to a flood of “mediocre code” entering codebases. This creates a maintenance nightmare. Fournier predicts we may need more senior engineers just to review, verify, and manage the massive volume of machine-generated software.
• 🏗️ The shifting engineering role — The definition of a software engineer is evolving. Instead of just being “typists” of code, engineers will likely move closer to the role of an Architect or Product Manager — focusing on system design, verification of AI outputs, and solving high-level business problems rather than implementation details.

Frameworks

• 🧠 Reducing Cognitive Load — The primary value of a framework is that it acts as a mental shortcut. Fisher argues that frameworks allow leaders to process complex information quickly without starting from scratch every time. They provide a “basic structure underlying a system” that helps you navigate ambiguity with less mental effort.
• 🗣️ Creating a Shared Language — Frameworks are essential for alignment. When a team uses a specific framework (like RAPID for decision-making or SWOT for strategy), they instantly share a common vocabulary. This eliminates confusion about how a decision is being made, allowing the team to focus entirely on what decision needs to be made.
• 🛠️ Tools, Not Religions — A critical observation is that frameworks should serve you, not the other way around. Fisher warns against becoming dogmatic. If a framework doesn’t fit the specific context or problem, you should modify it or discard it rather than forcing the situation to fit the model.
• ⚡ Decision Velocity — Using established models (like Amazon’s “One-way vs. Two-way doors”) increases the speed of execution. By categorizing problems into pre-solved buckets, organizations can avoid “analysis paralysis” and move forward faster with higher confidence.
• 📚 The Three Categories — The article suggests that while there are hundreds of frameworks, the most useful ones for engineering leaders usually fall into three buckets: Strategy (where are we going?), Prioritization (what do we do first?), and Decision Making (who decides and how?). Mastering a few in each category is better than knowing them all superficially.

Going direct

• 🗣️ Hierarchy ≠ Communication — A crucial distinction is made between reporting lines and communication lines. While the org chart defines who reports to whom for accountability and HR purposes, it should never dictate who is allowed to talk to whom. Using the chain of command as a communication flow is a recipe for slowness.
• 📉 The “Telephone Game” Effect — The article warns about the dangers of passing messages through intermediaries. Like the children's game, every layer of management a message passes through causes signal degradation. By the time information goes up one silo and down another, the context, nuance, and urgency are often lost.
• ⚡ Efficiency over Protocol — To move fast, you must cut out the middleman. If you need an answer from an engineer in another department or a decision from a stakeholder, you should go directly to them. This creates a culture of high velocity where problems are solved by the people closest to the work.
• 🕸️ The “Shadow” Org Chart — Real work rarely happens strictly according to the official hierarchy. It happens via the organization’s informal network—the web of social connections and trust between individuals. Effective leaders recognize this and encourage their teams to build lateral bridges rather than relying on managers to carry messages.
• 🛡️ Inform, Don’t Ask — Going direct does not mean undermining authority or being secretive. The professional protocol is to “go direct” to solve the problem, but ensure you keep the relevant managers in the loop. The dynamic shifts from asking for permission (“Can I speak to X?”) to providing context (“I spoke to X, and here is what we decided”).

Small Bets

• 🎲 Product Development is Poker, not Chess — Fisher argues that building software is probabilistic, not deterministic. In Chess, all information is visible; in Poker (and product), you make decisions with imperfect information. Therefore, leaders should treat initiatives as “bets” rather than guaranteed deliverables.
• 📉 The Danger of the “Big Bet” — The traditional waterfall approach relies on placing huge wagers (months of time and resources) on a single hypothesis. The risk here is catastrophic: if you are wrong, you lose everything. Furthermore, the “sunk cost fallacy” often traps teams into finishing bad projects simply because they have already spent so much time on them.
• 🔬 Optimizing for Learning Velocity — The core value of a Small Bet is speed. By breaking a large idea down into its smallest testable component, you reduce the time to feedback. The goal is to validate or invalidate a hypothesis as cheaply as possible so you can pivot before investing heavily.
• 💰 The Portfolio Approach — Engineering and Product leaders should think like venture capitalists. Instead of “betting the company” on one strategy, you diversify your portfolio with many small experiments. Only the bets that show promise earn the right to receive more investment (doubling down).
• 🧠 Expected Value (EV) Thinking — Fisher emphasizes calculating Expected Value — the probability of success multiplied by the payoff. Small bets allow you to take risks on high-reward ideas that might have a low probability of success, simply because the cost of the bet (the downside) is negligible if it fails.

That’s all for this week’s edition

I hope you liked it, and you’ve learned something — if you did, don’t forget to give a thumbs-up, add your thoughts as comments, and share this issue with your friends and network.

See you all next week 👋

Oh, and if someone forwarded this email to you, sign up if you found it useful 👇