The Better You Know Yourself, the Better You Can Lead

A developer misses a deadline. Before you ask what happened, you already have an explanation.

They weren’t focused. They should have warned you. You probably should have handled it yourself.

Then the conversation reveals something you hadn’t considered. The requirements changed. A dependency failed. Or the developer got stuck and waited too long to ask for help.

The missed deadline is a fact. Your explanation still needs checking.

That gap between what happens and what we think it means is where a surprising amount of leadership takes place.

Between 2003 and 2010, I spent seven years in psychoanalytic psychotherapy because I wanted to know myself better. I wanted to understand my reactions, my patterns, and the things I couldn’t easily see on my own.

After more than twenty years of building businesses and working with teams, I see a practical connection between that personal work and leadership. When you recognise your need for control, your discomfort with conflict, or your attachment to an idea, you have a better chance of noticing when it influences a decision.

Critical thinking gives you a way to examine that decision: check the evidence, consider another explanation, compare the options, and learn from what happens next.

For the illustrations in this article, I’ve given my cat, Scârț, an imaginary job alongside me. She will be inspecting evidence, occupying equipment, and supervising decisions with the confidence of someone who has never had to explain a quarterly result.

The workplace situations below are illustrative too. Their purpose is to make the decisions concrete.

1. Investigate the missed deadline before assigning a motive

Imagine a developer agrees to deliver a checkout update by Thursday. On Friday morning, it still isn’t ready.

Your first message might be:

“We agreed on Thursday. I need you to take deadlines seriously.”

You’ve identified the delay and immediately attributed it to attitude.

Before sending that message, separate what you know from what you’ve inferred.

You know the delivery date was missed. You may also know that no warning arrived. You don’t yet know why either happened.

A more useful opening would be:

“The update was due yesterday, and I didn’t receive a warning that it was slipping. What changed during the work?”

Suppose the developer explains that a small interface change exposed a payment problem affecting returning customers. They spent two days trying to solve it alone.

That explanation is worth investigating. Ask to see the blocker, when it appeared, and what they tried. An explanation can be plausible without being complete.

You might discover that the technical difficulty was genuine and the escalation was poor. Those call for two different actions:

“Review the payment issue with Alex this morning, then give me a revised estimate. Next time a blocker threatens the date, raise it that day, even if you haven’t found the solution.”

You can then check whether the change helps. On the next task, does the developer flag uncertainty earlier? Does the estimate improve after a technical review?

If communication improves but delays continue, your initial diagnosis may still be incomplete.

Self-awareness helps you notice the urge to blame. Critical thinking helps you test what actually went wrong. Together, they give accountability a much more precise target.

2. Check whether the work is wrong—or simply different

A colleague sends you a client proposal. You dislike the opening, rearrange the sections, and rewrite several paragraphs.

Twenty minutes later, it looks right.

The next proposal receives the same treatment. Soon, the team waits for your edits before sending anything, and you wonder why nobody takes ownership.

Before rewriting the next document, ask yourself:

“Which agreed requirement does this fail to meet?”

That question can expose an important distinction.

Perhaps the proposal omits the client’s central problem. That is a substantive weakness. Perhaps it explains the problem well but uses a structure you wouldn’t have chosen. That may be a preference.

If both receive the same correction, your team has to learn your taste through repeated rejection.

Imagine the client wants to reduce the number of customers abandoning onboarding, but the proposal opens with three pages of product features. You could give this feedback:

“The opening needs to show that we understand where customers drop out. Start with their problem, describe the change we propose, and explain how we would measure improvement. Send me that part before revising the rest.”

Now the colleague has a standard they can use independently.

There’s also a decision to make about your own time. Rewriting may be quicker today. Explaining the standard may reduce the number of revisions needed over the next ten proposals.

You can test that rather than simply hoping for it: agree on a short checklist and see whether future drafts meet it with less intervention.

Taking over feels productive because the improvement is immediate and visible. Developing someone else’s judgement takes longer to reveal its value.

This is where knowing yourself matters. Are you protecting the quality of the work, or seeking the relief of having everything done your way?

Scârț’s contribution to this problem would be to sit on the keyboard. At least her intervention would be easy to identify.

3. Decide what evidence would change your mind

You announce a launch date. A team member responds:

“I don’t think we’re ready. We haven’t tested the migration.”

You’ve already discussed the date with a partner. Moving it would be awkward, and the objection is happening in front of everyone.

You feel defensive.

Before responding, identify the decision you actually need to make. “How do I defend this date?” leads to a different conversation from “What can we responsibly launch by this date?”

Ask the colleague to make the concern concrete:

“What remains untested? What could fail, who would be affected, and how quickly could we recover?”

Then compare the available options.

Option	What it preserves	What needs checking
Launch everything on the planned date	The original commitment and scope	Whether the unresolved migration risk is acceptable
Launch to a smaller group	Some progress and earlier feedback	Whether exposure can be contained and support is ready
Move the launch	More time to test and resolve issues	The cost of delay and the commitments that must change

The table doesn’t make the decision for you. It stops one consideration—such as an uncomfortable conversation with a partner—from silently becoming the whole argument.

A particularly useful question is:

“What result from testing would make us change our plan?”

Agreeing on that before the results arrive makes it harder to dismiss inconvenient evidence afterwards.

You can acknowledge your own constraint openly:

“I’ve already communicated the date, so changing it has consequences. I still need us to understand the risk before we commit.”

That response gives the team a reason to bring you evidence. Overruling the concern without examining it gives them a reason to keep the next one to themselves.

4. Make the expectation clear enough to check

A colleague has submitted three reports late. You know they’re under pressure, so you try to be considerate:

“There’s a lot going on. Let’s try to be a bit more organised next month.”

You leave believing you’ve addressed the problem. They may leave believing you offered general encouragement.

When the next report is late, you feel ignored.

But did you establish a clear expectation, or assume that your meaning was obvious?

A more useful conversation begins with observable details:

“The last three reports arrived after the deadline, which delayed the finance review. What is preventing you from getting them ready on time?”

Suppose the colleague says another department sends the figures late. Look at the timeline together. If the figures arrived on Monday and the report was due Tuesday, the dependency may explain the delay. If they arrived a week earlier, you need to understand what happened after that.

This is a way to find the part of the process you can improve.

Once the obstacle is clear, agree on responsibilities:

“Send the draft on Monday afternoon and mark any missing figures. I’ll help resolve those that day. The final report needs to reach finance by Tuesday at noon.”

Then check that the plan is shared:

“Does that work with your other commitments? What could still prevent it?”

You now have something to review next month. If the report is late again, you can examine the specific agreement instead of arguing about whether someone was sufficiently organised.

Empathy helps you understand the pressure the person is under. Clarity gives them a fair chance to meet the expectation.

Your own discomfort deserves attention too. Sometimes a message becomes vague because you’re trying to avoid the other person’s reaction. Unfortunately, they still have to live with the consequences of an expectation they never properly understood.

5. Treat a new responsibility as something to learn

Your strongest developer becomes a team lead.

They know the product, solve difficult problems, and have everyone’s respect. Six weeks later, code reviews are piling up, junior developers are waiting for answers, and the new lead is working late to finish tasks personally.

You tell them to delegate more.

They agree. Nothing changes.

Before concluding that they refuse to let go, consider another explanation: they may not know how to delegate well.

Choosing a suitable task, explaining the outcome, setting boundaries, and deciding when to intervene are skills. Technical expertise doesn’t automatically provide them.

You could choose one assignment together:

“Give the next integration to Maria. Agree on the expected behaviour and constraints. Ask her to explain her approach before implementation, then arrange a checkpoint. She owns the work; you help her think through obstacles.”

Make the boundaries clear. Which decisions can Maria make? Which risks should she escalate? What must be checked before release?

Afterwards, review the experience:

• Did she have enough context to begin?
• Did the checkpoint happen early enough to be useful?
• Did the lead take over something she could have resolved?
• What should they repeat or change on the next assignment?

One successful task won’t prove that the new lead has mastered delegation. One difficult task won’t prove that delegation was a mistake. Look for a pattern over several attempts.

That applies to your judgement of the person as well. If clearer boundaries and practice improve the situation, update your view. What looked like a fixed personality problem may have been an undeveloped skill.

Your role includes making that learning possible without removing responsibility for the result.

A better decision than your first reaction

In each of these situations, the first impulse is understandable.

A missed deadline creates uncertainty. Rewriting a proposal produces an immediate improvement. Defending a launch date protects a commitment. Softening feedback avoids an awkward exchange. Expecting a strong performer to cope seems reasonable.

The question is whether the impulse fits the problem in front of you.

Before an important response, give yourself enough space to work through five questions:

1. What am I actually deciding? Define the problem precisely enough to act on it.
2. What do I know? Separate observations from interpretations and identify missing information.
3. What else could explain this? Consider a credible alternative to your first conclusion.
4. What are the consequences of each option? Include the cost of waiting as well as the risks of acting.
5. What will I check afterwards? Decide how you’ll know whether the response helped.

You won’t have complete information every time. Sometimes you need to make a decision today and arrange a review for tomorrow. The point is to make your reasoning clear enough that you can revise it when reality gives you something new.

Knowing yourself helps you recognise when pride, anxiety, impatience, or the wish to be liked is influencing that reasoning. Those feelings contain information about your experience; they don’t establish someone else’s motives.

The practical result might be modest: one better question before assigning blame, one standard explained instead of another document rewritten, one concern investigated before a commitment becomes a crisis.

Repeated over time, those choices shape whether people can think independently, tell you the truth, and take responsibility for their work.

Scârț will, of course, remain confidently opposed to any decision that requires her to leave the laptop. The rest of us can keep learning.