Dog escapes containment, hacks neighbor's yard

Joe Groff

Your Team Is Not a School

• 🏫 Misguided analogies — Viewing a team as a "school" encourages a culture of dependency where members wait for instructions rather than taking ownership of outcomes.
• 🏗️ The builder’s mindset — High-performing teams function like construction crews, where every individual is expected to know their trade and contribute directly to the finished product.
• 📉 The cost of development — Prioritizing constant "learning" and "mentorship" over actual execution risks turning your business into an expensive hobby that fails to deliver market value.
• 🎯 Results-driven focus — Leaders should hold team members accountable for their output and effectiveness, shifting the emphasis from "did you grow today?" to "did we reach our objective?"
• 🛠️ Competence as a prerequisite — Hiring should focus on bringing in people who already possess the necessary skills to perform, rather than relying on the manager to serve as a teacher or coach.
• 🛡️ Professional maturity — True leadership respects team members by treating them as adults who are responsible for their own professional evolution, rather than students needing constant oversight.

Vibe Coder vs Software Engineer

• 🎯 Identity vs. Tool — The core issue is not whether AI can code, but how developers define themselves by tools rather than thinking broadly about problem-solving and the entire software lifecycle.
• ⏱️ Wrong Metric — "Time to first working version" (vibe coder metric) differs from "time to safe merge" (software engineer metric), which includes review, testing, rollout, rollback, and maintenance costs.
• 📦 Output ≠ Progress — AI-generated code should be better and narrower, not larger. If the tool generates excess, humans must constrain it or risk creating downstream maintenance debt.
• 👤 Ownership Required — A vibe coder attributes code to the model; a software engineer says "I own it." Authors must convert generated output into engineering decisions before requesting review.
• 🗺️ Limited Context — Models cannot access the full engineering context living in incidents, migrations, operational pain, team conventions, and compliance rules. Experienced engineers get more value by giving models less freedom, not more.
• 🔄 Discovery vs. Delivery — Vibe coding belongs in prototyping and exploration where costs of failure are low. Engineering discipline is required for production systems where correctness is mandatory.
• 🧑‍🎓 Apprenticeship Risk — Junior engineers using AI to avoid understanding systems may appear productive short-term while weakening their learning and judgment development. Code review is how projects identify future leaders.
• 🎓 The Real Skill — The difference is operational and contextual, not fixed. Good engineers should vibe code during discovery and switch to engineering discipline for delivery, knowing which mode they're in.

How to Stay Technical as a Manager in AI era?

• 🎯 Managers shouldn't code to ship features, but should spend 5–10% of their working week (~4 hours) actually working with their team's codebase — to understand daily technical pain points and frustrations, not to become experts or deliver roadmap items.
• 🤖 AI makes it easier than ever for managers to stay technical, even in unfamiliar stacks — it excels at teaching through analogy, mapping unfamiliar languages and concepts back to what you already understand.
• 📋 Structure your technical work with clear boundaries: pick tasks with no deadline pressure, no dependencies, no downstream consequences, and build a small backlog from one project to accumulate depth instead of scattering attention.
• 🔧 Block a fixed calendar slot (e.g., four hours every other Friday) for technical work — recurring slots survive busy quarters, and even partial sessions yield surprising productivity with AI support.
• 📚 Follow a six-step learning framework: (1) learn the project through intensive Q&A before touching code, (2) run the project and understand the flow, (3) brainstorm implementation plans and challenge them against the codebase you studied, (4) self-review with AI explaining feedback through analogies, (5) run it and verify it works, (6) go through real team code review to feel the actual process.
• ⚡ Never let your AI context window exceed 60–70% usage — past that threshold, code quality drops noticeably due to "context rot" (accumulated history crowding out reasoning space).
• 🔄 Start a new AI session for every distinct task (planning, implementation, requirements, review) rather than chaining work together — isolation keeps context clean and prevents accumulated weight from degrading output.
• 🎛️ Use different models for different jobs: Haiku for learning and analysis (cheap, fast), Sonnet for planning and implementation, Opus for complex reasoning — bigger doesn't always mean better for your specific task.
• 💾 Name and archive each AI session after what it's doing and which feature it touches — this saves time hunting through old threads and creates a searchable record of your work.

Nine Questions I Now Ask in Interviews That I Wish I'd Asked Five Years Ago

• 🎯 Interviews are nominally two-way conversations but candidates often treat them as exams — reframe the dynamic by refusing to be passively assessed and instead actively interview the company.
• 🔍 The "do you have any questions?" portion is underutilized and underpriced — companies drop their guard at this point, allowing you to learn things unavailable on career pages or Glassdoor.
• 📈 Ask about the last promotion in the team — specific answers signal a legible path forward, while vague or absent answers suggest promotions depend on invisible factors.
• 👥 Inquire about tenure in the role — longest-serving person tenure reveals trajectory patterns and whether internal progression actually happens or people leave.
• 🚩 Ask what the team is "genuinely bad at" — humblebrags reveal coaching but real answers reveal both actual weaknesses and whether leadership will be honest with you.
• 💬 Question how teams handle disagreement with leadership — "always aligned" teams are either lying or not thinking; you want to hear about actual processes for dissent.
• 📊 Probe headcount plans for the next twelve months — uncertainty about future hiring signals your role's future is being debated above your hiring manager.
• 🤝 Request to speak with your closest collaborators — friction in arranging these meetings signals the company gates introductions, which is itself a red flag.
• ⚠️ Ask what failure looks like at six months — unscripted failure answers reveal actual challenges like ambiguity, politics, or burnout risk.
• 🔄 Explore reorg frequency and triggers — reorgs reveal organizational instability and whether changes stem from strategy, leadership shifts, or underperformance.
• ❓ Ask why the role is open — listen for pauses; hesitation signals a story about the previous person that deserves follow-up.
• 🚪 Companies that punish these questions have shown you their culture cheaply — "do not want to be interviewed" companies have not earned your time.

How Successful Companies Go Blind

• 👁️ Successful companies often develop "competence blindness" — they stop recognizing and rewarding engineering excellence because their environment no longer selects for it, similar to how cave fish lose functional eyes in stable cave environments.
• 📈 Rapid hiring during growth phases can inadvertently lower standards — engineers without outside experience become hiring panels, selecting for comfort with existing mess rather than actual competence, creating a self-reinforcing cycle.
• 🔧 Strong external metrics (brand, margins, headcount) can mask internal decay — fragile deployments, undocumented systems, and tribal knowledge replace sound foundations, but leadership doesn't see the problem because the numbers still look fine.
• 🏛️ "Centres of excellence" often backfire — by centralizing and controlling engineering standards, companies suppress the very motivation and distributed excellence they claim to cultivate.
• 🌍 Stable market conditions enable stagnation — when barriers to entry are high, incumbents can tolerate bureaucracy and waste without competitive pressure to improve.
• 👥 Talented engineers leave not from generational fickleness, but because they watch their skills regress in dysfunctional environments — those who stay gradually adapt and lose the ability to imagine working elsewhere.
• 🚪 Staying at a dysfunctional company is a form of slow adaptation ("apoptosis"), not loyalty — people become blind to problems through long exposure rather than consciously choosing to accept them.

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 👇