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:

• Sales and marketing departments are the ones establishing hard deadlines and priorities as well as new features to be built.
• Product departments have limited technical knowledge, and know very little about formal languages used to write user stories and probably nothing about technical debt, code quality and testing.
• Product often says not only what to build and why, but also how and how much it should take to do so
• There is no technical vision established vertically on the company.
• The features usually do not come with non functional requirements like performance, volumes, testing coverage, etc.
• There is limited time to fix technical debt items because it may not be part of the main considerations for the business team.
• Time constraints are very tight, so one feature comes right after the other with limited time for discussing different solutions and approaches.
• Weak technical leadership style in which the pressure and items are proxied to the engineering teams.

Problems that arise from this culture:

• The performance of engineering teams degrades over time, it will require more and more resources to be added just to keep up with the changing business requirements.
• Engineering teams are always complaining about definition of ready, technical debt, time constraints, lack of testing, and vague requirements.
• It is hard to retain talent, as the good engineers leave or they stay unmotivated with low performance.

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:

• The decision making is done by a limited number of engineers, commonly, the architects.
• The solutions and choices are rarely consulted or discussed with engineering teams, not allowing them to challenge or bring about different approaches.
• Future problems that arise from any bad decision often need to be fixed by the engineering teams who could have predicted such outcomes and avoid time loss.
• Communication of the reasons behind technical decisions is usually poor, as the culture here is not prioritizing the engineer’s perspective.
• Decisions makers often do not work closely with the product, designing solutions to preconceived ideas or assumptions that are hard to attain.

Problems that arise from this culture:

• Lack of trust between the engineering teams and the architecture.
• Even the best decisions will be considered bad or problematic in the future due to the process of taking them
• Engineers will have low morale and motivation due to the lack of a proper decision making process.
• When the number of people taking important and broad decisions is very small with limited discussion around it, the outcome is often immature.

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:

• Intermediate levels or managers always agree and don’t challenge superior for better processes.
• Pressures and orders are proxied to lower levels, but inquiries from below do not flow upwards.
• These managers will often take the credits for the good things while blaming the team for the bad ones.

Problems that arise from this culture:

• Frustration among engineering teams.
• Misuse of the chain of command, and intermediate managers usually being considered highly by superiors but very badly by subordinates.

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:

• Personal relationships are stronger with people at higher levels while remaining formal with lower levels.
• Shifting friends based on promotions or new hires on higher levels can become a pattern.
• Middle management usually agreeing as much as possible with those at higher ranks, and waiting for their input before weighing in.

Problems that arise from this culture:

• Creates toxic environments, as the peers can notice such behavior easily.
• Management starts being an issue, and friendship is a hard motivator hindering change.
• Great ideas or people can get passed by because of a limited perspective.

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:

• There is no follow up regarding errors and mistakes other than finding the responsible developer and letting him deal with it.
• Teams tend to hide their mistakes and errors which cause problems that could be avoided.
• Team members can hide knowledge from others, so they become a valued resource due to their insights.

Problems that arise from this culture:

• Creates toxic environments, where blame is forwarded.
• Creates fear for innovation and change.
• Teams will demand less responsibility where mistakes can be shadowed.

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

• Managers work with excel files where time is measured to the nitty gritty.
• Engineering teams are treated as a mere resource.
• Lack of trust for engineering teams where the manager needs to know what is everyone doing at all times and how much time is spent on every task
• Pressure to meet expectations on given estimations from above flow through the entire software team.

Problems that arise from this culture

• Unhappy engineering teams, frustration and low morale.
• This type of management is a hidden cost that affects productivity and quality negatively on different levels.
• Too much focus on project metrics, leaving less room for creative solutions.

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:

• Too many junior developers around the team, neither evolving nor learning

• Tasks are very unfulfilling, leaving almost no room for innovation

• Tasks are very detailed on the “how to do”, when they should just be defining “what to do”

• Sometimes even non technical people will try to tell software engineers how to do things

Problems that arise from this culture:

• Smart engineers will end up leaving due to lack of self realisation.

• Tasks definitions are rarely discussed so the best solution is not achieved.

• Telling developers how to do something will cause them to stop researching for best practices.

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:

• There is no real policies set up for training or career growth.
• The learning budget is very low and there is not enough resources for everyone.
• There is no time allowance for training during working hours.Self-training is promoted as a free time activity.

Problems that arise from this culture:

• Engineering teams’ skills will get outdated.
• They will not perform as good as they could, if they were trained on the tools (even the Seniors).
• The company will become a legacy software company with employees unable to modernize the tech stack.The good developers who were self trained will leave.

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:

• Useless standups. After a standup, ask each team member what other teammates are doing and what are their issues / blockers.
• There is no time for retrospectives, and not everyone jumps in.
• Retrospective results are ignored from one session to the next, and no actions are really taken.
• Useless groomings and refinement, with no whiteboarding or design solutions, but just trying to gather information.
• Pressures to show results in short sprints intoxicates the process.
• Agile is not vertical which leads to:
  • Process overcomes individuals and interactions
  • Signed contracts from marketing overcomes customer collaboration
  • Plan is marked and there is very little change other than adjusting some requirements
  • Working over sales direction, rather than working on delivering great software

Problems that arise from this culture:

• Companies not only fail to become agile, the agile process becomes a burden.
• Engineers leave as they feel cheated into believing the company culture was truly agile.
• The speed of innovation falls due to failure to adapt to modern software practices.

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:

• Technical vision is key and vertical in the company, and all surrounding decisions are taken considering the technical necessities of the product.
• Product owners are aware of the technical aspects of the product, and have in consideration the technical quality of the deliverables, always leaving room for ownership to the team to decide if a feature is done or needs refactoring.
• Decision making is inclusive, and design discussions and whiteboarding are key factors of it, involving engineering teams.
• Technical quality is measured and kept, it is always on the top of the priorities.
• There are no hard deadlines, and feature roadmap is product centric, rather than customer derived
• KPI measurements focus on the outcomes not on outputs, making the whole vertical company responsible for bad outcomes.
• Engineering teams hour tracking is not used other than for legal terms, if any.
• Sales and Marketing departments work with engineering outputs, not with future work to be done or roadmaps. Their work starts where engineering work ends.
• Teams are fully empowered through ownership of pieces of the product, where they also rely on and communicate with other teams for providing and receiving support.
• Training is at the core, engineering teams are fully trained on the tooling and also on soft skills such as communication and emotional intelligence.
• Architects may still exist on this culture, and they would act as knowledge sharer, coaches, support and decision managers, taking decision design process across the engineering teams receiving inputs and challenges and doing whiteboard sessions with them to thrive a final shared decision
• Managers have an enabling role, where keeping the team focus, coaching, supporting and empowering collaboration is key.
• Transparency and honesty is key, not adding sugar coats nor avoiding to state the problems

Summary

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.