I am fairly convinced that for many of us who create software products, putting the words "backend" or "frontend" into the titles of our developers can be a pretty damaging thing to do to our organizations, and via Conway's law, to our software products.

Doing so inevitably creates backend/frontend teams, backend/frontend chapters, backend/frontend channels in our communication tools, and the list goes on and on. Silos emerge, people are blocked, and our products suffer as individuals make technical decisions which often prioritize not having to deal with “the other people's stuff” rather than the best solution for the product.

At the end of the day, we’re all working towards the same goal and the ownership of that can be shared. Instead, organizations often end up asking questions like:

• How many backend developers should we hire per frontend developer?
• (During Sprint planning): is there enough frontend/backend work in this sprint to match our capacities? (Note the plural here)
• Who can fix [extremely minor frontend issue] now that [frontend dev] is on vacation?

I am not arguing that everyone should be masters of everything. People should still be able to specialize in the focus areas they want to engage in. But I think it’s important to assess whether problems like the above arise as self-made problems by an organization which tells their developers that they’re supposed to be backend or frontend (only) developers - especially when the reality can be much more fluid and dynamic than that.

There exist no developers who - given the right culture - can’t obtain the technical ability to change the color of a button or rename an API endpoint with relative ease, unless our organizations create and enforce boundaries that disallow this. Developers in turn internalize such boundaries and believe them to be identifiers of their position and responsibilities, and the divide grows over time.

These days it’s easier than ever to bridge the technical part of this divide. Full-stack solutions like tRPC or openAPI/Swagger-generated types can be great enablers of reducing the divide between layers of architecture. You can utilize these tools to pull a so-called inverse Conway maneuver; letting the technology influence the design of the organization, rather than the other way around.

Of course there are exceptions to the above; if you’re working with microservices or building an API which gets consumed by many different external clients, and you've designed your team around something like the x-as-a-service model, you're probaly good to go. In fact, so long as you're actively evaluating whether a given structure works for your organization, you are probably going to be fine in the long run.

But I have seen many organizations that build one product, consisting of one API, which is consumed by one client, who still divide their architecture, people and culture along the lines of "frontend" and "backend". Not because of an active decision, but because it’s the way we’re used to.

The result is inefficient - and if you ask me - uninspiring to partake in.

On the other hand, I've now worked in a few organizations which came to a point of actively deciding to break down these barriers, including stripping the words "frontend" and "backend" from the titles of developers, leaving us with... just developers doing development. And the results have been amazing. Questions like the ones listed above seem to vanish, and the vast majority of developers start growing in all kinds of interesting ways as they realize that they themselves can eliminate bottlenecks that used to hold them back.

It takes work though - it's paramount that your developers get the support they need to bridge the gap, and that such a change is done with them, not to them. But if you succeed, you will see benefits for both the engineering department and the larger organization in places you weren't even expecting.

And more importantly - to me as a developer anyway - it's way more fun. Or as one of my fellow developers put it during one such transition:

"I've spent the last few months working on things I didn't feel good enough at to be doing. And... I don't know, it just keeps on working."

Over the years, I've spoken to quite a few teams about psychological safety. Some teams embrace it immediately, but others are more hesitant.

The latter often come to me with similar approaches after learning about psychological safety. Below, I've outlined these common reactions, and given the answers I've found most helpful in addressing them.

The purpose is this list is not to defend psychological safety, or to refute those who might oppose it, but rather a guide to help teams understand what psychological safety is, and what it isn't.

The questions addressed below are:

• Psychological Safety is just another buzzword
• We don't have a problem with our Psychological Safety
• Is Psychological Safety about being nice or careful?
• Is Psychological Safety just about speaking my mind? Should I always say everything I think?

Psychological Safety is just another buzzword​

Many people have been in organizations that over the years have tried to implement many frameworks for collaboration, communication, team building and so on - often with varying degrees of success. With this background in mind, it is no surprise that an introduction to Psychological Safety might be met with skepticism.

What is beautiful about Psychological Safety as a concept is that it is not a framework, but rather a lens through which to view the world. It is a way to understand the dynamics of a team, and a way to understand how to improve them. Psychological Safety already affects your team, whether it is visible or not.

The term Psychological Safety does come with a well-researched background, but to your team, that probably doesn't matter. However, the concept is ever-present and giving it a name enables your team to first notice it, and then talk about it.

A team I worked with in the past excitedly shared with me a fantastic way to describe this.

It was always there, we could just never put a finger on it. Now we have a hat to put on the monkey!

We don't have a problem with our Psychological Safety​

Chances are that if you are reading this, you're already doing pretty well in terms of psychological safety. In fact, the software industry at large is pretty invested into Psychological Safety - as an example, it was included heavily in Google's 2019 State of Devops.

Most teams I have worked with were also doing pretty well in their (and my own) estimation.

However, I have never found that this meant there was nothing to talk about. In fact, the more Psychological Safety you have, the more you can talk about it. And the more you talk about it, the more you can improve it.

To give you an example, I once worked with a team, which used the tool checking in from the Toolbox presented here. In the team, they assessed the following question:

It is safe to take a risk in this team.

They rated it anonymously from strongly disagree (1) to strongly agree (5), and came to the conclusion that given their team's overall high scoring, it meant that there was no issue here.

However, once discussion started, they came to find that some members had answered 5 because they felt that taking a risk should be encouraged as a part of experimenting and learning, while others had answered 5 because they thought: "Well, I shouldn't take risks, but if I did, I don't think the others would be upset with me for my mistake".

This realization resulted in the team having an open discussion about what taking risks meant to them, and how it related to their daily work. This moved them team from an unspoken individual understanding to a shared explicit one, which is one of the benefits of working with Psychological Safety.

The take-away here is that even if your team is "probably fine", there might be many unspoken and different perceptions as to what that actually means. This might not be a problem - but it is an opportunity for learning and growth.

Is Psychological Safety about being nice or careful?​

Sometimes the immediate reaction to Psychological Safety is that it is just about being nice to each other. That we should be careful in our teams, and not say anything that might offend someone else.

Similarly, many people are worried that tending to Psychological Safety will slow them down, either simply due to spending time on it, or because they're afraid they will have walk on eggshells around their colleagues.

The opposite is actually true.

Psychological Safety is about removing the brakes of impression management - the instinct to protect ourselves through managing the way our surroundings might perceive us. And the most common form of protection is silence.

Theese are brakes most of us have learned to have down for most of our life. However, when we establish a culture of Psychological Safety within a group, it enables us to worry less about impressions, and instead speak more freely. And in fact, this is needed mostly when you have to address the harder topics.

In this way, Psychological Safety is actually far more about being able to say the not so nice things, than it is about being nice.

Is Psychological Safety just about speaking my mind? Should I always say everything I think?​

I am sure we've all been in a meeting with a colleague who said everything that came to mind, or had to refute every point other speakers were making. Such scenarios can result in the team's valuable time being spent mostly on the input of one individual - and this individual might even prevent others from chiming in.

I am also sure that we've all been that person sometimes. Or maybe just a person who has spoken up with good input, but where the response from the team was apathetic or even negative.

The point is that Psychological Safety is a group construct. You can't have Psychological Safety on your own, and you can't bring it into a team if the team's culture is not conducive to it.

Additionally, Psychological Safety shouldn't be used to justify bad behavior. It is not a free pass to say whatever you want, whenever you want. In fact, once you have good Pscyhological Safety, a key point of maintaining it is to sanction clear violations. With good Psychological Safety, you should also be able to inform that colleague that they are dominating the conversation in a way which makes it unproductive.

However, people are different, and expecting Psychological Safety to result in everyone speaking up in the same way (or indeed the same amount) should not be the goal.

The goal of Psychological Safety should be to get as much valuable input from your team as possible, by reducing the barriers of entry to participate.