In my thinking, these different development methods also extend to the culture and work environment; if you’re in the cathedral, you’re surrounded by rigid boundaries, but if you’re in the bazaar, you can wander around and exchange ideas with others.
How the Toxic Cathedral Can Affect Your Development Team
A few years ago, I read an essay about two different, free software development methods called The Cathedral & The Bazaar, by Eric S. Raymond. The basic premise is that the Cathedral method describes software that is only open-source post-release, meaning only a small group of developers have access to the code pre-release (corporate software). In the Bazaar method, the code is developed online and is open-source throughout the development process.
Another way to think about it is that the cathedral has many layers of hierarchies, architects, and the accompanying bureaucracy, just like the corporate structure, while the bazaar is flat and everyone can see everything laid before them. In my thinking, these different development methods also extend to the culture and work environment; if you’re in the cathedral, you’re surrounded by rigid boundaries, but if you’re in the bazaar, you can wander around and exchange ideas with others.
I don’t believe that the size of the organization dictates which development method is used. It might be tempting to think that larger, more established companies use the cathedral method, while the bazaar method lends itself more to startups. But, a lot may depend on the mindset of who’s running the company, rather than its size. There are large companies that adopt the bazaar method and startup companies that use the cathedral method. A lot of it comes down to the people.
The problem with hierarchy
So, what’s the problem with hierarchy? Hierarchy is the organization of skill sets, aligned with job titles and salaries. You can see hierarchy at work in a traditional organizational (org) chart. In theory, less experienced, junior developers are on the bottom of the org chart and more seasoned developers and managers are on the top. Hierarchy is all about structure and levels and follows an upward progression. The goal of a junior developer is to become an intermediate level developer; the goal of the intermediate developer is to become a senior developer, and the senior developer aspires to being a manager of a development team.
One issue with hierarchy is that it instills the need to compete with others in order to advance to the next level. In some cases, one developer may look for fault in another’s code just to get promoted. At many companies, another problem arises for the senior developer. If the senior developer wants to advance, they need to become a manager, but many technical people prefer to stay that way and don’t want to be bogged down with managerial responsibilities. Many are happy to act as mentors to other developers and to challenge themselves technically, but this mindset is not rewarded in a hierarchical structure. The lack of upward mobility can lead to frustration and then attrition, leaving only underachievers or people who may bring negative energy to the team.
Money talks
Money and salaries can muddy the water. Of course, it’s common practice to pay a junior developer less than a senior developer. Junior developers have less experience and may require more time to do tasks. Senior developers are compensated for their experience and ability to solve complex problems. In order to get a product to market, it often takes long hours of work by all members of the development team, and unlike salespeople, they’re not compensated for all that “sweat equity.”
The impact of a software engineer on the earnings of a company is hard to calculate. However, a company can calculate the losses of bugs or downtimes. On the flip side, a salesperson’s compensation is based on a base salary and additional compensation based on sales performance. . But that does not happen with engineers, and there is the possibility to create a blame culture when mistakes are made if this type of pay structure was implemented. But, this also means that a company loses a calculated amount of money because of engineer mistakes. So it is important not to have a blame culture because money is lost, unless lessons are not learned from mistakes.
The unnecessary middle managers
In the beginning of my career when I was a junior developer, I had an issue and I consulted my manager for advice. I wasn’t satisfied with the manager’s response, so I made the daunting decision to involve their manager in the conversation. My issue was resolved, but I paid a price; my manager felt I usurped their authority when I went “over their head.” My manager warned me to not do it again, and toxicity was born.
The role of the middle manager isn’t a happy one; they get to deliver messages from upper management and listen to issues from their subordinates as well. Companies that use a hierarchical structure have many middle managers. The middle manager can never make everyone happy, and they are essentially rendered powerless by this tug of war. If an employee doesn’t have faith in their manager’s abilities to solve problems and assist them in their careers, it breeds frustration and more toxicity.
Bullying in peer reviews
The peer review is a great tool which allows developers to review one another’s code and suggest changes and improvements. When used properly, peer reviews catch bugs, streamline code, and help educate junior developers on best practices, because multiple sets of eyes (with different levels of experience) are examining the same block of code.
Where the peer review can become toxic is when it’s used as a weapon rather than a mechanism for constructive criticism. Sometimes more senior developers use it as an opportunity to flex their technical muscles, embarrassing, or even bullying, a junior developer in the process. More junior developers who want to ascend that org chart may also take advantage of the platform in order to showcase their skills, while downplaying the skills of others. The peer review then becomes more of a contest than a development tool, and negativity in a peer review can bleed into other processes.
Keeping Toxicity Out of a Remote Workplace
The COVID-19 pandemic has forced many companies and employees to work remotely, which poses some communication challenges. Without face-to-face interaction, it’s important to maintain communication using an array of technology tools. While texts, direct messages, and emails can be great communication tools, not having face-to-face contact can lead to misunderstandings and toxicity. Accordingly, it’s important to weave video calls into your daily or weekly routine as much as possible.
Think of it this way - you’re messaging back and forth with a teammate, but they don’t seem to be understanding your point. This might frustrate you and you could end up typing a response in frustration that you later regret. People tend to be less confrontational and negative when they can actually see one another; that’s why the video call is so important. It can help to nip a miscommunication in the bud and promote healthy, productive communication.
According to psychology studies, the impact of a message is 7% verbal (text), 38% vocal (voice and sounds) and 55% nonverbal (visual). So if we only communicate through chat or email we are missing 93% of a message. Making a phone call we reduce that number to 45% and making video calls we get closer to 100%, although it isn’t the same as being in-person.
The Alternative to the Cathedral: The Bazaar
The cathedral method with its hierarchical structure tends to breed competition and toxicity. If you’ve ever seen the film, Office Space, you understand the implementation of the cathedral method and its downfalls. While the cathedral method is most often embraced by larger companies, there are some startups that use the methodology because it's what is most familiar to their management.
The answer lies in the bazaar - the physical manifestation of open-source software. Because the bazaar has a flat structure rather than a hierarchical one, every developer is equal. Junior team members can contribute to the team while learning from their more senior colleagues, and senior colleagues benefit from hearing a fresh perspective and having to explain answers to questions.
The idea behind the bazaar in software development is to have many bazaars in the company, each working on something different. This structure allows the developers to be more autonomous, and eliminates middle managers by having only one manager who reports directly to the Chief Technology Officer (CTO). This “open source” environment fosters collaboration and creativity between team members, where toxicity is reduced and everyone learns from one another. And, I believe that this can only improve the final product, as well as create happier and more productive employees.
