Rambos

A one-person army, alone, in the jungle of software, fighting against the peskiest, complex, and soul-eating bugs. He (or she) can work for hours, with a tenacity of a human-hunter machine coming from the future, and his value is sometimes considered 10 times the standard engineer. Your organization depends on this individual. You cross your fingers and pray to your deity to not make you loss this prolific, highly-valued and know-it-all individal contributor.

Rambos? What do you mean by that? You mean John Rambo?

A million years ago I read a post in a blog (or maybe it was in one of his talks?) written by one of the main figure in the Agile movement in Spain, Javier Garzás about the Rambos of software development.

I think it was a talk yes, he was talking about companies that had personnel that were essential to the company. They team was completely dependant on them. They were not organized, nor maybe create good software, but they solved issues and create the features the product owners wanted. Usually they were not good in teams, and liked to work alone, hence why Garzás was using the name of the famous soldier that fought against his enemies alone.

The problem with these Rambos

While the idea of haing an experienced figure that could provide more value than the average developer sounds tempting, usually having this kind of unbalanced dynamics in a team has its own disadvangates:

Rambos tend to be undisciplined

If they feel like they are above other and have too much ego, they can feel they are above rules, and not work on the tasks the company need.

Bad code quality

If it works, it is good code or I understand it, how many times have I heard these sentences in the mouth of a Rambo…

No documentation

Documentation is no needed for them as I understand it is their uttered sentence by excelence. A code without documentation is incomplete.

Difficult to work with

Related to all the issues above we can conclude that Rambos are difficult to work with. Ego-driven, not keen on receiving feedback (unless it is good), they do not care for other developers. They simply do not empathize with other team members that will inherit the code.

Of course, do not expect them to mentor or guide another members of the team.

Excesive dependence on Rambos

Apart from these faults, economically the most damaging thing a company can suffer is the loss of a Rambo. If this Rambo that leaves the team is the only one that is capable of maintain and develop a project. The organization is going to need to use many resources in untangle the project code. Most of the time is much easier to share knowledge during the developing than after everything is all set in stone.

Have you met with some Rambos?

I have met several several Rambos in my life.

I remember several, but most of the Rambos I have dealt with were not technically amazing, were just people that have an acceptable set of skills but they had a great confidence in their work.

The problem is that they have a confidence in their work, not because they haver perfected their skills, but the resolution of tasks. i.e. they have mastered the business knowledge so they feel confident that they are good in what they do. But that is not true, they know the lingo, understand the flows, but they are not perfecting their what it should be their main skill: developing software.

You need to be humble and acknowledge your own limitations, and most Rambos do not consider those. They suffer a self-confidence malaise that makes them rarely doubt their work.

How to avoid having Rambos in your team

First you need to distribute the knowledge of the inner workings of your projects to the rest of the members of the team. Relying on a long Enginneer is risky.

So, if you detect a Rambo, make it clear that the distribution of knowledge must be a priority for him/her. The Rambo must not do any task alone from now on, always have one partner, and several reviewers.

This way, the rest of the team would start understand the issues with your team projects, and also a culture of comunication among them will start.

Of course, once they have had more information about the projects, the next step should be write it down. Documentation should be a priority for the company, but not enforced documentation that reads good on paper but is unuseful, no, documentation that could make easy to onboard a new Engineer in a couple of months.

Conclusion

Do not rely on Rambos, it is better to have a team of 1.5x engineers than to have one 10x engineer that work alone, and whose code is not understood by anybody but them.