Every engineering leader I know says they want psychological safety on their team. Far fewer can tell you what they actually changed to get it. The phrase has become a kind of leadership wallpaper, repeated in offsites and printed on values posters, and along the way it has lost most of its operational meaning. In a regulated fintech business, where a missed control or a quietly swallowed concern can turn into a regulatory finding or a production incident that moves real money the wrong way, that vagueness is expensive.
I have spent the better part of fifteen years building payments and lending platforms, and I have learned that psychological safety is not a mood you cultivate. It is a set of conditions you engineer, observe, and maintain, the same way you engineer reliability. This post is my attempt to be specific about what those conditions are, what I have done to create them, and where I have gotten it wrong.
What Psychological Safety Actually Is
Amy Edmondson, who originated the research, defines psychological safety as a shared belief that the team is safe for interpersonal risk-taking. I find that definition useful precisely because it is narrow. It is not about being comfortable, being friends, or avoiding conflict. It is about whether a person can say an uncomfortable thing, ask an obvious-seeming question, or admit a mistake without expecting punishment or humiliation.
The distinction matters because the two ideas pull in opposite directions. A team that optimizes for comfort will avoid the hard conversations that good engineering requires. A team that is psychologically safe will have those conversations more often, not less, because the cost of raising a concern has dropped close to zero. In my experience the safest teams I have run were also the ones that argued the most, just productively and without residue.
In a fintech context, the stakes are concrete. The engineer who notices that a reconciliation job is silently dropping records, the analyst who suspects a model is drifting, the junior developer who does not understand why a payment is being retried three times, all of these people are holding information the organization needs. Safety is simply the question of whether that information reaches you before it reaches your incident channel or your regulator.
Why It Is a System, Not a Vibe
The most common mistake I see is treating safety as something you declare. You say at an all-hands that there are no stupid questions, and you believe you have done the work. But people do not calibrate their behavior on your words. They calibrate it on what happens to the last person who spoke up.
This is why I think of safety as a system with inputs and feedback loops rather than a personality trait of a nice manager. The inputs are the small, repeated moments where someone takes a risk and observes the consequence. If the consequence is good, or at least neutral, the behavior reinforces. If the consequence is a public correction, a visible eye-roll, or a quiet downgrade in how seriously they are taken, the behavior extinguishes fast. People are extremely efficient learners about social risk.
The team does not believe what you say about safety. It believes what it watches happen to the person who just took a risk in front of everyone.
Because it is a system, you can measure it, and you can degrade it through neglect. A team can have high safety in March and low safety in September because two senior engineers left, a reorg landed, or a single botched response to a mistake taught everyone a new lesson. Treating it as a permanent achievement is how leaders lose it without noticing.
The Incident Review as the Proving Ground
If you want to know whether your team is safe, watch a post-incident review. Nothing reveals the real culture faster. When something has gone wrong and money or data was affected, the pressure to find a person to blame is enormous, and it often comes from above. How you handle that moment is the single highest-leverage thing you do for safety.
I run blameless reviews, but I am careful about what blameless actually means. It does not mean no accountability. It means we accept that competent people, acting reasonably with the information they had, produced the outcome, and we direct our energy at the conditions that made the error likely rather than at the individual. The engineer who pushed the change that caused the outage is the person who understands the failure best. If I punish them, I lose my best source of learning and I teach everyone else to obscure their involvement next time.
A few practices I hold to in these reviews:
- The person closest to the failure narrates the timeline themselves, rather than having it reconstructed and presented at them.
- We ask what made the wrong action seem reasonable in the moment, because that points at the real systemic gap.
- We separate the review from any performance conversation entirely, in time and in document, so the two never contaminate each other.
- Action items target tooling, alerting, and process, and we accept that very few incidents are solved by telling someone to be more careful.
How Leaders Leak Fear
Most damage to safety is unintentional. I have done all of these things at some point. You ask a question in a tone that sounds like an accusation. You respond to a status update by immediately listing everything that is behind, with no acknowledgment of what shipped. You react to bad news with a flash of visible frustration before you catch yourself, and the room reads that flash with perfect accuracy.
Seniority amplifies every signal you send. As a CTO, a casual comment that I have forgotten by lunch can occupy an engineer for a week. A skeptical face during a design review can quietly kill an idea that should have been pursued. I have had to accept that my emotional state is not a private matter at work; it is a broadcast, and people make decisions about what to tell me based on it.
The practical correction is to slow down my first reaction, especially to bad news. When someone brings me a problem, my first sentence sets the price of bringing me the next one. If I lead with curiosity rather than judgment, I keep the channel open. If I lead with frustration, I have just made the channel more expensive to use, and the next problem will reach me later and larger.
Hiring and Onboarding for Safety
Safety is partly a property of who is in the room. I have learned to screen for it during hiring, both in candidates and in myself. I want to know whether a candidate can describe a real mistake without either crumbling or deflecting all responsibility onto others. Someone who has no failures to describe is either inexperienced or not honest, and neither is what I want in a senior role.
Onboarding is where new hires learn the local rules, and they learn them fast in the first few weeks. A new engineer is watching constantly to figure out what gets you respect and what gets you mocked. If their first questions are met warmly, they keep asking. If they sense that asking marks them as weak, they go quiet and start guessing, which in a payments system is how small misunderstandings become production defects.
I make a deliberate point of having senior people ask basic questions in front of new joiners, and of admitting when I do not know something. When a staff engineer says in a meeting that they do not understand how a particular settlement flow works and asks someone to walk them through it, that single act gives every junior person in the room permission to do the same. Modeling ignorance from a position of strength is one of the cheapest and most effective tools I have.
Psychological Safety in a Regulated Environment
There is a tension specific to fintech that deserves honesty. We operate under real obligations: controls that must be followed, audit trails that must be complete, separation of duties that is not optional. Some people hear psychological safety and assume it means a soft environment with loose standards. The opposite is true, and the relationship is worth being explicit about.
Strong controls are precisely what make safety affordable. When the rules are clear, written down, and applied consistently, an engineer knows the difference between an honest error inside the guardrails and a deliberate circumvention of them. The first is a learning event. The second is a serious matter. Ambiguity is the enemy of safety, because when people cannot tell which category they are in, they default to silence to protect themselves.
I tell my teams plainly that raising a compliance concern is never the thing that gets you in trouble; failing to raise one is. The engineer who halts a release because they are not sure a data flow is permitted has done their job correctly even if they turn out to be wrong about the specifics. I would far rather absorb a few false alarms than train people that flagging a risk is career-limiting. In a regulated business, the cost asymmetry is overwhelming, and your culture should reflect it.
Dissent and the Disagree-and-Commit Discipline
Safety without a decision-making discipline turns into paralysis. If every voice must be satisfied before anything moves, you have not built a safe team; you have built a team that cannot ship. The pairing I rely on is genuine, encouraged dissent during the decision, followed by real commitment once the decision is made.
For that to work, people have to trust that their dissent was actually heard and not just tolerated. I try to make the reasoning behind a decision explicit, including which objections I weighed and why I went the other way. When an engineer can see that their concern was understood and consciously overridden for a reason they can follow, they will commit even while disagreeing. When they suspect they were never really heard, the dissent goes underground and resurfaces as quiet non-cooperation, which is far more corrosive.
I also keep a record of significant disagreements and their outcomes, informally. When the dissenter turns out to have been right, I say so out loud and credit them. This does two things: it improves our calibration as a group, and it proves that disagreeing with leadership is a survivable, even valued, act. A team that has seen a junior engineer be publicly right against the CTO is a team that will keep telling you the truth.
Measuring Something That Resists Measurement
I am suspicious of reducing culture to a dashboard, but flying entirely blind is worse. I look at a small set of weak signals and treat them as prompts to investigate rather than as scores to optimize. None of them is reliable alone, but together they tell me something.
I watch how often people bring me bad news early versus how often I learn about problems only when they have become unavoidable. I watch who speaks in meetings and who has gone silent, and whether the quiet people are quiet everywhere or just around certain individuals. I read the texture of our incident reviews and pull requests: are people asking real questions, or just rubber-stamping? On engagement surveys I pay attention to the specific items about admitting mistakes and raising concerns, not the aggregate happiness number, which measures something else entirely.
The most honest measure I have found is the lag between when a problem becomes knowable and when it reaches me. As safety improves, that lag shrinks. When it grows, something has gone wrong with the channel, even if everyone seems content on the surface. Contentment and safety are not the same thing, and conflating them is how leaders get blindsided.
Conclusion
Psychological safety is not a perk you grant your team or a tone you adopt in meetings. It is an engineered property of a system, sustained through hundreds of small moments where someone takes an interpersonal risk and learns whether it was safe to do so. As a leader, you are the highest-leverage variable in that system, because your reaction to the last risk sets the price of the next one. Build it deliberately, watch it the way you watch your error budget, and treat any erosion as the operational problem it is. In a business where the unspoken concern can become a regulatory finding or a financial loss, the teams that tell each other the truth early are not just nicer places to work; they are the ones that keep you out of trouble.