Why Crafting Better Questions is the Ultimate Life Skill

The older I get, the more time I spend, as a percentage of each day , crafting better questions.

When we are young, we are obsessed with finding the right answers. We study, we memorize, and we grind to get the "10/10" on the test. But as time goes on, we observe and think about our actions and look at things in retrospect from time to time. A realization sets in: the quality of your life is determined by the quality of the questions you ask. 

I’ve found that the difference between incremental progress and a true step-change in business, health, or relationships is rarely the product of just working harder. It is almost always the product of asking better questions.

Here is why shifting your focus from answers to questions is the highest-leverage thing you can do.

A Problem Well Put is Half-Solved

The philosopher and educational reformer John Dewey famously said, "A problem well put is half-solved."

Think about the last time you were stuck on a complex issue at work or in your personal life. Chances are, you were spinning your wheels because you were trying to solve the wrong problem.

When you take the time to meticulously craft the question, the answer often reveals itself. The question acts as a spotlight in a dark room; if you point it in the wrong direction, you’ll only see shadows. But when you aim it perfectly, the path forward is illuminated.

The History and Geography of Conscious Thought

We often treat thinking as this mystical, abstract process, but it isn't. Conscious thinking is largely just asking and answering questions in your own head.

Your mind is wired to solve the puzzle you give it. If you feed it a vague prompt, it will return vague, unhelpful ideas. But if you feed it a highly specific, well-crafted question, it will work tirelessly in the background to find the exact answer you need. 

A Tip - It's also the best route to Self Awareness. 

 

Life Punishes the Vague Wish

There is a simple, mechanical reality to how we process information: Life punishes the vague wish and rewards the specific ask. It’s just basic input and output.

 

If you want confusion and heartache, ask vague questions.

● "Why am I so unhappy?"

● "How do I get rich?"

● "Why is my business failing?"

These questions are too broad. They overwhelm the brain and lead to paralysis.

But if you want uncommon clarity and uncommon results, you must ask uncommonly clear questions.

● "What specific daily habit is draining my energy and joy?"

● "What rare and valuable skill can I master in the next six months that the market will pay a premium for?"

● "Which specific customer segment is no longer finding value in our product, and why?"

When you get specific, you get actionable. When you get actionable, you get results.

 

The Power of the Reframe 

To see this in practice, consider a situation I witnessed a few years ago. A senior team member I was working with was pulling his hair out over his team's results and attrition rate. His people would leave just around the time he felt they had gotten to learning some skills he wanted them to work with. His default question was, "How do we get people to care more about the company's mission?"

It was a vague wish disguised as a question. It led to forced pep talks and superficial team-building exercises, usually lunches.

We sat down and reframed it. We asked: "What is the specific, daily friction our best people are experiencing that makes them look at other job offers?"

The answer wasn't about the company mission; it was about a broken, multi-layered approval process that was slowing his top performers down and was driving them crazy. We fixed the process. Team work increased, and personal accountability went up. The quitting stopped. The question didn't just clarify the problem; it solved it.

 

The Ultimate Leverage

Crafting a great question takes time. It requires you to pause, reflect, and strip away the noise until only the core issue remains. It might feel like you are slowing down, but in reality, you are accelerating. Spending 20 minutes to craft the perfect question will save you 200 hours of executing the wrong solution.

As you go about your week, pay attention to your internal dialogue. Catch yourself when you are asking vague, unhelpful questions. Stop, reframe, and ask something sharper, clearer, and more specific. You might just find that Lady Luck is waiting for you on the other side of a really good question.

 

But don't just wait for it to happen.

Take five minutes right now. Write down the biggest problem currently sitting on your desk or in your head. Now, rewrite it as a question. Then, rewrite that question to be 10x more specific.

 

That’s where you start.

 

Here are my favorite notebooks I use for my daily writing 

For Personal Journal-ling : I love these refillable cloth/leather/paper diaries

For my work , business and research : I love these notebooks which I title and keep around

From Coder to Orchestrator: Best Practices for Tech Leads Using Claude Code

The era of the Tech Lead as the "fastest coder in the room" is over.

"Beginners use Claude to avoid thinking. Intermediate users use Claude to think faster. Power users use Claude to think better."  

 

Today’s top engineering leaders aren't just writing code—they’re orchestrating AI agents that can generate it at superhuman speeds. The new core competency? Writing detailed prompts, reviewing massive amounts of code, and investing in shared tooling.

Claude Code has emerged as a powerhouse in this new landscape (crossing $1B in annualized revenue within six months of launch). But raw AI power without discipline is dangerous. Left unchecked, it can easily destroy a working codebase.

Here is a comprehensive guide to using Claude effectively across the entire software development lifecycle, synthesized from top engineering managers and the Claude Code team.

 

Part I: The Mindset Shift 

You Are the Tech Lead; Claude is Your Genius Junior The single most important shift is understanding your new role. Claude is your genius junior engineer: fast, brilliant, but requiring constant coaching and explicit rules. It can generate thousands of lines of code in minutes, but it needs clear specifications and architectural guardrails.

Think in Roles, Not Just Code Most developers open Claude and immediately ask it to build something. This is a mistake. Think of Claude in four roles: Architect, Tech Lead, Senior Engineer, and QA. Most people jump straight to Senior Engineer. A production-ready workflow requires Claude to act as the Architect and Tech Lead before writing a single line of code.

 

Part II: Architecting with Claude 

 

Start with Documentation, Not Code Before generating code, create a persistent foundation of documentation:

• 
  
  CLAUDE.md: Your project's persistent context (tech stack, standards, testing, security).
  
• ARCHITECTURE.md: System components, data flow, and security boundaries.
• FEATURES.md: Explicit feature definitions to prevent Claude from assuming a feature is "done" when it isn't.

Use Claude as Your Architect Your first prompt shouldn't be "Build the app." It should be:

"Read CLAUDE.md, ARCHITECTURE.md, and FEATURES.md. Act as a Principal Architect. Review the architecture. Identify design flaws, scalability concerns, and missing components. Do not write code."

This single step often saves days of rework. Always design database schemas and API contracts before implementation.

 

Part III: Implementation Planning 🗺️

The Plan-Act Loop Your mantra must be: Plan first, ship in slices. Let speed amplify good process—never replace it.

1. Plan: Force Claude to think through the approach.
2. Review: Check the plan across multiple axes (architecture, dependencies, scaling, single points of failure).
3. Act: Once approved, let Claude execute.

Use Plan Mode for Complex Tasks Using Plan mode is like repeatedly aligning requirements with a PM before development. Once the plan is confirmed, execution can be handed over to the AI to run automatically with minimal supervision.

 

Part IV: Code Implementation at Scale 

Run Multiple Sessions in Parallel The biggest productivity unlock is running 3–5 Claude sessions in parallel, each in its own git worktree. Use claude --worktree in the CLI. This breaks the traditional linear development mindset.

Multi-Agent Orchestration For large projects, use a lead-agent model. Prompt Claude to create a team, spin up teammate agents in isolated worktrees, and assign tasks (e.g., Backend API, Frontend React, DB migrations).

Delegate Research to Sub-Agents Context dilution is real. Keep your main thread focused by delegating heavy research and file-reading to sub-agents.

Implement Institutional Memory Set up a 'memory' folder for agents to automatically store important findings. This creates institutional memory that persists across sessions, preventing agents from redoing trivial research.

 

Part V: Code and Technical Reviews 

 

Verification is the #1 Practice The Claude Code team emphasizes that the most impactful tip is verification—giving Claude a way to check its own output. Use automated tests, CI/CD pipelines, and review agents. If you only adopt one practice from this article, make it this one.

Don't Let Claude Touch Git Directly Allow Claude to do most things, but reserve Git privileges for yourself. Do frequent diffs, commits, and pushes. Comprehension ≠ compliance. In one documented case, an agent pushed directly to main despite explicit instructions to open a PR—and then pushed its own apology directly to main!

 

Part VI: Security and Production Readiness

• Containerize Everything: Claude might attempt privilege escalation (like writing to /etc/shadow). Docker with no host mounts and restricted networks is non-negotiable.
• Use Bot Accounts: Give each agent instance its own GitHub bot account for transparency and fine-grained permissions.
• Make Tests Reliable: Flaky tests are worse than no tests. If CI is unreliable, the agent will use every failure as an excuse. Force the test harness to be reliable so it has to actually fix its bugs.
• Define Hard Rules: Encode critical rules in CLAUDE.md (e.g., "Every function gets a test," "Never use global mutable state," "Insist on descriptive error messages").

 

Part VII: Team Standardization

Left to their own devices, developers will build fragmented Claude setups. A team with a shared configuration is 3-5× more effective than devs working individually.

Standardize your CLAUDE.md, permission configs, and security practices across the team. Regularly let Claude update CLAUDE.md itself—it's essentially reinforcement learning through agent feedback.

 

Conclusion: The Elevated Tech Lead

The technical lead's role in the age of AI is not diminished—it is elevated. You are no longer just writing code; you are:

1. Framing the constraints and plans.
2. Teaching agents how work should be done.
3. Orchestrating parallel agents across worktrees.
4. Reviewing plans and code rigorously.
5. Standardizing team configurations.

Sometimes, it's more satisfying to watch the agents operate than to ship the feature yourself. But satisfaction aside, the real measure is impact. With the right practices, a single tech lead can orchestrate what once required entire teams.

Discipline is the only thing that makes AI coding reliable. Plan first, verify always, and never confuse speed with quality.

 

Over to you: What has been your biggest challenge in transitioning from writing code to orchestrating AI agents? Have you experimented with git worktrees or multi-agent setups yet? Let me know in the comments below! 👇

(If you found this valuable, consider subscribing to my Twitter or Plus91's AI Academy for more insights on engineering leadership and AI orchestration.)

 

When using Claude as a TL to carry out a Technical Lead Code Review, how do you review each Plan andImplementation Cycle on a separate chat?

The crux of this post is not just "How do you pass Context between chats?", but also how do you ensure relevant context is provided and nothing more. There is no need to waste tokens. 

For carrying out a technical review for every work package, i would like to open a new chat instead of keeping one huge thread open for days, my typical development cycle can last 6-7 days and runs across 25+ work packaged. What all should I add to the beginning of the chat for continuity. Is the 1st prompt enough or should I add the SRS and PRD and the original implementation plan or something else, or none of these

My Main Question --> When using Claude as a Reviewer, how do you review each Plan and execution on a separate chat?  

Here is what Claude guides us to do

Short answer: the full SRS and PRD — no, not needed. The specific WP's approved implementation plan — yes, that's the one document that actually matters every time. Here's the breakdown of what's load-bearing versus what's just bulk.

Include every time

1. The final approved implementation plan for that specific WP. This is the actual contract the code is being checked against — everything else is secondary to this. Attach it as a file. 
2. Repo access + exact branch/commit. State the branch name and current HEAD SHA up front, and confirm the repo is public (or however you're granting access). This alone would have saved several rounds of back-and-forth in this conversation.
3. The git add -N . step, stated as a given, not discovered. Just open with "diff generated via git add -N . && git diff --binary --no-ext-diff" from message one. We only found this was necessary after two rounds of incomplete diffs — no reason to relearn that per WP.
4. A one-line list of what's already merged and proven, e.g. "WP-01A (outbox fencing, rate limiter, scheduler lock), WP-01B-1 (RBAC, session ambient-transaction guard), WP-01B-2a (sealed delivery, confirmation contexts) are merged and their patterns are the baseline to match." This is a cheap sentence that saves me from re-deriving "is this consistent with prior work" from scratch.
5. The specific review ask, with this structure: numbered focus areas, the mandatory invariants unique to this WP, the Blocker/Important/Follow-up classification, and the exact verdict options. This has been doing real work — it's what keeps my reviews from wandering.

Don't bother re-attaching

• The full SRS or PRD. They're large, mostly stable between WPs, and pasting them wholesale risks me reasoning against a possibly-stale copy instead of the authoritative repo version. If a specific WP genuinely turns on an SRS clause, quote or link that one section instead.
• AGENTS.md / DECISION_LOG.md / the Technical Architecture doc, in full. These live in the repo and are the actual source of truth — if you give me a repo link (or raw file links, same pattern as the code), I can fetch the specific section I need rather than working from a copy you pasted that might already be one commit behind reality.
• Prior WPs' full review transcripts. The outcome of those reviews is now just... the merged code. I don't need the argument that got us there; I need the result, which is sitting in the repo.

One structural suggestion

Since AGENTS.md is apparently the living home for cross-WP invariants (transaction rules, fencing patterns, logging rules), it might be worth treating it as the one document that's always worth a fresh read at the start of each new WP chat — not because I need to be told about it, but because if it's been updated between WPs (which it should be, given how many corrections we've folded back into "the pattern" over this project), I want the current version, not my memory of an earlier one.

So, in practice: a short kickoff message (branch, HEAD, what's merged, the plan attached, the review ask) rather than a document dump. That's roughly the size of your very first message in this chat, just repeated per WP instead of accumulated.