Culture first company

There are many product companies that call themselves “engineering first company”, which sounds pretty cool, but then when you look deeper or usually get hired by their promises, you realise that the culture does not fit what their marketing department advertised. Maybe engineers have better salaries and perks, but that is not an engineering culture or an engineering first company, and in the long run it is bound to fail when it comes to retaining good talent.

When internalized properly, the “Engineering first” culture has proven to succeed in every direction, from retaining talent and keeping your engineering teams happy, to having a successful and profitable product with very happy customers while also keeping great work life balance and performance altogether.

Are you searching for ways to shift your company culture to prioritize engineering and innovation?

Let’s dive down into the different cultures that usually live within these software engineering companies where processes are settled and it is hard to switch from whatever culture they had adopted to a proper engineering culture.

The business only culture

The business culture is the one that prioritizes business decisions from non technical departments against engineering advice as a de facto rule. It is true that some of these companies might succeed in appealing to investors and be a profitable business, but at what cost?

If software companies cannot achieve a balance, engineering teams will not be very happy, and it will eventually lead to great talent leaving the company.

The constant pressure and bad metrics will create an environment that thrives on other problems and toxic cultures, and the reputation of the developers will go down drastically from non technical departments.

Taking decisions only based on business goals will make the path to success harder. If your company has been succeeding the hard way, imagine what easing and smoothing the process could help you achieve.

Identifying this culture:

Problems that arise from this culture:

The God decission culture

There are many software engineering companies that rely on a single person to architect the entire solution and take the hard decisions on technology stack and tooling all around. Some may over-engineer and some may under-engineer it depending on the context and constraints.

Sometimes it is not just a single person but a small team of architects who take all the decisions and without including any other smart engineer in the company.

It does not come as a surprise that most of those engineers will feel mistreated in such software teams, if the architects fail to share authority and delegate, ignoring any challenge or solution proposed by other team members.

Identifying this culture:

Problems that arise from this culture:

The shit funnel culture

This culture emerges if the communication between the company and tech management is one sided and there is a tendency to avoid discussions. It is great to have a harmonious team that agrees on decisions but if the management surrounds themselves with “yes people”, they carry the risk of losing innovation and diversity.This is natural as the human psyche is prone to seeing what’s familiar first but if we create an environment where people challenge each other for the better, the software teams can thrive with innovation.

When managers just agree with everything their superior says, he is just proxying the orders through a chain of command, and not flagging possible issues upfront they may end up blocking the path towards a quick solution and causing lot’s of frustration.

Identifying this culture:

Problems that arise from this culture:

The asslicker culture

This culture is very common in the spectrum, it is also natural that sympathy buys promotions, even if that sympathy is not generated with technical goals in mind. This culture is quite similar to “the shit funnel”, as team members would avoid disagreeing as much as they can with higher levels, and avoid damaging their personal relationship, endangering further promotions.

The bigger challenge is that promoting such team members allows this to settle in as a culture because they have seen it work and they will make it work for themselves.This can lead to bad leadership being inherited, because aspirations for personal growth can hinder the technological growth of your product or team as a whole. . As google proved big egos aren’t part of the traits that make a good manager.

Identifying this culture:

Problems that arise from this culture:

The blame culture

This culture is also very common, despite the fact that it does not help at all. It happens when the software engineers blame not only others, but themselves for errors and mistakes caused by human hands. These mistakes will always happen, we are human at the end of the day. If we create a supportive environment, we can not only avoid but also learn from these mistakes. If people do not need to resort to blame shifting, they will openly work on figuring out how they can prevent such mistakes from happening again.

Sometimes we blame developers for bugs, but reward QAs from finding them, sometimes we blame the sysadmin or DBA who wrote the wrong command and broke production. We should have a culture where there is no blame for mistakes, but opportunities for learning.

Identifying this culture:

Problems that arise from this culture:

The micromanagement & minute counter culture

These are very common in consultancy companies, where managers are just counting the time resources (aka engineering teams) spent on tasks and projects, micromanaging the work to control every detail with a strong lack of trust and delegation to different levels.

Identifying this culture

Problems that arise from this culture

The monkey resource culture

This culture is tightly coupled with micromanagement, as engineering teams are heavily consisting of junior developers, who need guidance and do not mind being micromanaged while they grow.. The issue is that in such a team culture, the teams do not evolve, because they rely on the superiors for next steps and lose the inquisitive touch.

Identifying this culture:

Problems that arise from this culture:

The untrained culture

This is one of those cultures where training is not even a thing or the budget is very tight. It is clear that if the company does not invest in training of any kind, two things will happen, people’s skills will get outdated and the work they do will not be merely as high level or innovative.

We know tech companies are concerned:

 What if we train them and then they leave ? 

But the better question is:

 What if we do not train them, and they stay ?

Identifying this culture:

Problems that arise from this culture:

The fake agile culture

This sadly happens to be hidden common practice, as tech companies oversell and put buzz words around their agile process and how well they follow it. Adopting agile methodologies not only mean adopting to the processes but also to the mindset and the ways it changes the way we used to develop software. Otherwise, the agile process can become a burden and fails to deliver good software.

Identifying this culture:

Problems that arise from this culture:

A healthy product engineering culture

There is a lot of debate on what a good engineering culture might look like, which is good, as it could reveal different approaches work simultaneously, and create room for both improvement and flexibility.

A good engineering culture is very hard to achieve, and very hard to keep up with, but tech companies have a lot to gain from it as it puts your company straight on the path for success. Identifying all the symptoms that might make your culture sick and addressing that soon is a key factor into keeping a healthy environment.

Let’s focus on the key factors that create a good engineering culture in a company, keeping in mind that there might be different ways to implement them.

Identifying Good Engineering Culture:


If you want to keep good culture and retain great talent on product engineering teams, train them and treat them with honesty and respect. Avoid asslickers and shit funnelers and promote healthy relationship between product and engineering. Focus on the outcomes, not on silly metrics and most importantly, do not lie.


comments powered by Disqus