Inspired by Simon Sinek's Circle of Safety: practical leadership lessons on honest feedback, accountability, and trust for founders and small teams.

A developer tells you on Tuesday that Friday's release won't be ready. You can make them regret telling you, or help them work out what happens next.

Your response will shape when you hear about the next problem.

It's a small moment, but it says more about leadership than a presentation about company values. When a deadline is at risk and a client is expecting delivery, people find out how much honesty their team can tolerate.

Simon Sinek's Leaders Eat Last offers a useful starting point. His concept of the Circle of Safety describes an environment where people can rely on each other rather than spend their energy protecting themselves from colleagues or management.

For founders and small teams, there's a practical way to apply that idea: make it easier to tell the truth while there's still time to do something about it.

Your reaction sets the rules

Most leaders say they want problems raised early. The difficulty comes when someone raises a problem the leader doesn't want to hear.

Imagine the release conversation continues like this:

"We already promised the client. Why am I only hearing about this now?"

The question might be reasonable. Perhaps the developer should have flagged the risk sooner. But if the conversation immediately becomes an interrogation, the work itself gets pushed aside. Everyone starts explaining why the situation isn't their fault.

A more useful first response is:

"What's left, and what makes Friday unrealistic?"

You still need to understand why the estimate changed. First, though, you need enough information to decide whether to reduce scope, move the date, or find help.

The order matters. Deal with the problem, then examine how it developed. You can hold someone accountable without making the act of reporting bad news feel like a mistake.

Safety doesn't remove accountability

A supportive team still needs standards. Missed commitments affect colleagues. Careless work creates costs. Repeated problems need more than reassurance.

Suppose a developer breaks production. Restoring service comes first. Afterwards, the team needs to understand what happened: Was the review rushed? Were tests missing? Did someone ignore an agreed procedure?

Those explanations call for different responses. Treating every failure as an individual attitude problem leaves broken processes untouched. Treating every failure as a process problem lets people avoid responsibility for their decisions.

A fair conversation can be direct:

"This check was your responsibility, and it didn't happen. We need to understand why and agree on what changes before the next release."

That's uncomfortable. It doesn't have to be humiliating.

The point of safety is that people can participate honestly in that conversation, including when their own judgment was poor.

Purpose has to change a decision

A shared sense of purpose can help a team choose between competing demands. It becomes less useful when it exists only in the company introduction.

Consider an agency that says it builds software clients can depend on. A client asks for an extra feature just before launch. Adding it would mean skipping testing or asking the team to work through the weekend.

This is where the stated purpose should have consequences.

The founder might explain the risk and offer a later delivery date. Or cut another feature to make room. There may be a genuine reason to accept the extra work, but that decision should include an honest account of its cost.

If every request becomes an emergency, the team has little reason to believe that reliability guides the business.

People need to see which trade-offs their leader is willing to make, especially when keeping a promise to the team means having an awkward conversation with a client.

Asking for feedback creates an obligation

"Please challenge me" is easy to say when nobody is challenging you.

Now imagine someone points out that the unrealistic deadline came from your estimate. You committed before asking the people doing the work.

You might have had good reasons. You might also have been wrong.

A useful response would be:

"I committed too early. I'll speak to the client. Next time, we'll check the estimate together before I confirm a date."

That gives the team something concrete to judge. At the next deadline discussion, do you involve them?

You don't have to accept every suggestion or let every decision turn into a vote. You do owe people a serious hearing and an explanation. Feedback becomes pointless when it disappears into a meeting and nothing is ever heard of it again.

Try it in the next difficult conversation

Sinek's work is a useful prompt, but agreement with a leadership idea doesn't tell you whether you practise it.

For the next conversation about a mistake or missed deadline, pay attention to your first response. Ask for the facts before defending the plan. Separate the immediate decision from the later discussion about responsibility.

If your own decision contributed, name it specifically. Then agree on a change someone can actually observe.

Return to the developer who warned you on Tuesday. Friday's release may still move. The client may still be unhappy, and there may be a difficult performance conversation ahead.

But you have time to make a decision on Tuesday. That's worth protecting.

Inspired by Simon Sinek's Leaders Eat Last and his Circle of Safety concept. The workplace examples and practical recommendations above are this article's application of those ideas.