Code Smells for Engineering Managers

Every developer probably have heard the term code smells which was popularized in Martin Fowler’s refactoring book from 1999. According to wikipedia, a code smell is “any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology”.

In every software development organization, there are also signs and characteristics that can possibly indicate a deeper, more fundamental problem. Just like the code smells, it is subjective and it depends on the environment, the seniority of the team, the tech stack being used, how embedded the software is, if it is safety-critical or not, etc. I decided to start capturing a few of those engineering management “code smells” that I came across and discuss what is the problem behind. I will call those types of smell a “Team Smell”. Here is the first team smell:

The Spec Abyss Smell - ‘‘…just give us the spec and we will implement it”

The first thing I will say is that I have nothing against specs, not at all. The problem this smell brings to surface is not whether or not a specification or documentation exists. The problem is not about what is the format of the documentation. The underlying problem is the CULTURE OF COLLABORATION between the group of people that will build the product and another group of people that defines/designs it (this group has different names in different organizations). This smell reveals that the interest from one group of people to work together with the other group of people is relatively low, and that might happen for different reasons. Let’s dig deeper on some possible reasons:

1. Silos: The two different group of people mentioned before are not necessarily a TEAM. They are not yet one ENGINE but rather many smaller engines trying to work in-sync. That involves a lot of effort, hand-offs, overhead. This frustrates people. Great People normally want to be productive and optimize their work environment. The more silos you add, the bigger the chances to have competing and conflicting goals in the mix.
2. Conflicting goals: Human interaction is many times driven by the goals different individuals have. Example: If one group has the goal to deliver something, and there is group with the goal to come up with the most flexible and modular architecture ever, there will be conflicts and the human interactions will start to get tense. Every time this happens, humans have a tendency to calibrate their perception on how much value the other group is bringing to the table.
3. Reduced perception of value: When people start diminishing the contributions coming from other groups due to the reduced perception of value, they automatically will try to fill the gaps and come up with things on their own, even for things that they are no experts at and this is dangerous. This leads to inflated egos and the false impression that they can do everything alone.
4. Inflated Egos: If a group believes they are the most important group, and they can take all the decisions, they will perpetuate the notion that this should be a “separate group”, because others are not capable of doing what they are doing. This separates even more. Go back to point 1: Silos.

As a human leader, it is important to understand the context and actively try shape the culture in a way where people can break free from this spiral. The goal is to have different groups acting as ONE engine. One team. All people having a healthy sense of responsibility for the entire ENGINE and looking beyond their area of responsibility. There is no recipe to reach this goal. Sometimes this can be achieved by tweaking the org hierarchy, sometimes this can be achieved by rotating people, sometimes it can be solved by simply talking to individuals and encourage them to be ONE engine. But one thing is for sure, a true leader will continuously communicate the DESIRED state and help the team getting there.