Psychological Safety During Early Startup Teams

The first time one of your engineers decides not to tell you something, you won’t know it happened. That’s the whole problem.

When you’re three or four people, the culture isn’t written down anywhere. It’s whatever you reward and whatever you punish in the first few months. How you react to the first missed deadline, the first bug that reached a customer, the first “I don’t actually know how to do this.” Those moments teach everyone whether honesty is safe here or whether it costs them.

Researchers call this psychological safety. The term matters less than the habit behind it: people will only tell you the truth if telling you the truth has gone well for them before.

I learned this as an architect, not a founder. I came in ready for hard technical problems and got blindsided by the human ones. The strongest engineer on a team would sit quietly through a meeting, knowing a plan was flawed, because the last person who spoke up got steamrolled. The information I needed most was the information people had quietly learned not to share.

For a founder this is more dangerous than any architecture call. You’re not in the code every day. You depend almost entirely on your team telling you the truth about what’s working and what isn’t. If they’ve learned that bad news gets met with blame, they’ll soften it or sit on it, and you’ll meet the real problem when it’s expensive instead of when it’s cheap.

You build the opposite in small moments. When someone admits a mistake, the first thing out of your mouth matters. Thank them for catching it early. Ask what we learn from it, not whose fault it was. Say “I don’t know” yourself, out loud, so everyone sees it’s allowed.

You can’t add this later. The way your first few people learn to treat mistakes becomes the way the whole company treats them.

What’s something a founder did early that made you comfortable telling them hard truths?