How a Team Lead Thinks: The Questions Behind "Why?"

Picture a code review. You added a new package, and your lead writes: "Why this package?" Or you picked a different language for a small service, and the lead asks: "Why this language?" Or you went quiet for an hour, and the lead asks: "What are you thinking?"

These are not traps. They are the normal questions of a team that wants to stay healthy. A lead asks them because they will own the result with you, long after the code is merged. If you can answer them calmly, you sound like someone who can be trusted with bigger work. If you become the lead, these are the questions you will start asking others.

This is the first lesson of a separate series about the team-lead and development mindset. It gives you the basic answer shape, how to think out loud, and the map of the questions that come next: packages (Lesson 1), languages and frameworks (Lesson 2), estimates and reviews (Lesson 3), and incidents and people (Lesson 4). For stories from your own past work see Experience round, Full-Stack Lesson 14. For salary and offers see Behavioural, salary and offers, Full-Stack Lesson 38 (coming soon).

Everything here is common practice and opinion, not law. Teams differ. Use the ideas, not the exact words, and always use your own true examples.

Words used in this lesson

• A trade-off is when you get one good thing by giving up another. Faster to build, but harder to change later. There is almost never a choice with no cost.
• An assumption is something you believe is true but have not checked. Good thinkers say their assumptions out loud.
• A risk is something that might go wrong. Think of two numbers: how likely it is, and how bad it would be.
• A reversible decision is one you can undo cheaply (change a variable name, try a library on one page). A hard-to-reverse decision is one that is expensive to undo (database choice, public API shape, a language for the whole backend). Spend more thinking on the second kind.
• A spike is a short, time-limited experiment to learn something ("one afternoon to try this library on a real page"). You throw the code away afterwards if needed.
• A proof of concept (PoC) is a small version that shows an idea can work. It is not production code.

What a team lead is really checking

When a lead asks "why", they usually want one of these five things. Know which one it is:

The answer shape: six short steps

You can answer almost any "why" question in about 30 seconds with this shape. Say it in plain words:

1. Goal. "We needed to ..." (the real need, not the tool).
2. Options. "I looked at A, B and writing it ourselves."
3. Choice. "I chose B."
4. Reason. "Because ..." (one to three facts, not feelings).
5. Risk. "The risk is ..., and I reduce it by ..."
6. Plan B. "If it does not work, we can ... and it costs about ..."

Example for a date library:

Notice what is missing: no "everyone uses it", no "it is the best", no long speech. Just reasons a teammate can check.

"What are you thinking?"

This question has two very different meanings:

• Friendly: "You look stuck. Can I help?"
• Doubtful: "This change looks odd. Explain it."

In both cases, the best response is to think out loud in a simple, tidy way. Silence makes people guess, and guesses are usually worse than the truth. Use this small pattern:

Example while debugging:

Why this works: you show a method, not a mood. The lead can correct a wrong assumption in ten seconds ("the API is cached, check without cache") instead of watching you spend two hours.

Other questions a lead asks (and what they mean)

You will hear many versions of these. The meaning is almost always the same: "Did you think about the cost and the bad day?"

What good decision makers say (from well-known lists)

The most-starred engineering-management reading list I found, charlax/engineering-management, has a "Decisions" and a "Mentoring" section. The ideas it points to, in simple words:

• A good-enough decision that you can live with beats a perfect decision that arrives late. One article it lists (from Doist) argues that waiting for total agreement adds its own risk. Ask: "Can everyone live with this option?" and not "Does everyone love it?".
• No decision is also a decision. The list quotes Andy Grove's High Output Management: the lack of a decision works like a negative one.
• Teach people to not need you. An article from Rands in Repose, listed there, puts it as: "My job is to teach you not to need me."
• Give context, not only answers. In the mentoring section, a piece by Gergely Orosz suggests giving context and letting people learn by finding the answer themselves.

Treat these as ideas to test, not as rules. I summarise the list's own description of each article, not the articles themselves.

Interview questions

Key takeaways

• Treat every "why" as a chance to show your thinking, not as an attack.
• Use the six steps: goal, options, choice, reason, risk, plan B. Keep it to about 30 seconds.
• "Because it is popular" is not a reason by itself. Say what popularity gives you here.
• "What are you thinking?" is answered with: goal, what I know, what I don't know, my guess, my next step.
• Say when you are stuck, early, and bring notes of what you tried.
• Spend more thinking on hard-to-reverse decisions than on reversible ones.
• When the team disagrees, put the options and trade-offs side by side, test cheaply if you can, and support the final decision.
• This is common practice and opinion. Adapt it to your team.

What's next

Next: Why this package? Choosing and carrying dependencies, Lesson 1. Practise first: pick three choices from your last project and answer "why?" with the six steps in 30 seconds each.