… Recap
Some people thrive at Tech companies without doing any meaningful work. They cheat their way through. As part of the blog series, we discuss this phenomenon.
Such people use tricks to game the system. We refer to these tricks as cheatcodes.
Until now, we’ve talked about:
Now we discuss – how to avoid the cheatcode culture from getting established.
Cheatcode can take many forms. So, the below list is more of a recommendation set than a solution template. User discretion is advised.
Lets get prepared !
Awareness
Let us recall the ‘Invisible Ships’ phenomenon. Natives weren’t able to see the first Europeans coming to their lands. Once natives realized that people can float on water ( sea ), they were able to see the incoming fleets.
Similarly, by knowing that Cheatcoding is real ! We take the first step towards preventing the problem.
City of Troy did not imagine that the wooden horse standing outside could house invasive forces. The concept of such trickery did not register in their minds. This led to their downfall.
Be aware that there is a cheatcode trojan, trying to gain entry into your system. Simple awareness will help organizations to put checks to stop any such intruders.
I was once almost hired by an organization. The CTO ( Chief Tech Officer ) explained the challenges their team faced:
Our techies are very smart and they tend to fool any manager who is not really technical. Therefore, we want to hire a hardcore techie, as their manager !
The CTO was aware of the cheatcode problem. Once he realized that his techies were fooling their manager – he fired the old MBA manager, and started working on hiring someone who could manage the cheatcode problem.
Another manager might’ve tried:
Such solutions do not work OR work to the benefits of the cheatcoder.
To avoid cheatcode menace – First thing we can do is to be aware of the phenomenon.
Make the Invisible, Visible
Information technology is virtual in nature. Since software exists in the virtual world, humans are not naturally equipped to evaluate technology.
To lessen the disadvantage organizations can:
Display Tech details ( Make visible – literally )
True story :
An organization newly implemented a CICD pipeline. It’s a fancy word automatic code release. ( Continuous Integration Continuous Deployment )
Engineers were not habitual to using the new technology; the CICD pipeline. So, they brought up tricks to avoid using the new tool. Result – code quality was only “slightly” better than before the tool was used.
A new Lead came in. He started publishing the failure rates of each programmer’s code, across the organization. Within the next 10 days failure rates fell from around 80% to less than 20%. Eventually reaching less than 5% after another month …
What changed ?
A BIG red line showed across an engineer’s name. Individual failures which were hidden till now. These failures were suddenly on display for the whole organization.
His friends started poking him during coffee times, his managers gave him the “looks”, the directors joked around him. Humans are social animals. Most of us will go the extra mile to secure out status. That is what happened.
Failed programs, error reports, emails, messages existed in the virtual world. This virtual data was suddenly available for everyone to see in Red, Green and Yellow. But we are equipped to evaluate visual cues.
Therefore, visual cues will change behaviour. This is a form of increasing Transparency.
The problem withered away without any external pressure or any dis-incentives. No developer lost any bonus or worked more than normal hours.
Organizations can make the “invisible” visible. This will avoid cheatcode issues from creeping up.
Encourage Visibility/ Transparency
Organizations designed on a factory system give visibility in one direction. Only the supervisor knows about the subordinate’s work. Also, the visibility is 1-2 layers deep. Supervisor does not know about subordinates, further down the chain. And subordinates do not know the work the supervisor does.
This creates opacity across a system. Software is a virtual product. Opacity around an already virtual product is bad.
I recommend:
All teammembers should have clear and displayed work. My subordinates and superiors should know the work I do.
If everyone knows, then I might easily get caught. I will be discouraged from using any cheatcode tricks. Therefore, transparency increases accountability.
Everyone is troubled by dictators. But, no one wants to bell the cat ! Because no-one wants to become a martyr.
Same goes for cheatcoders. Everyone wants to highlight cheatcode issues, but no-one wants to face the side-effects of doing so. Unless individuals are assured of their job security, they will not come up to highlight cheatcode issues.
Once security has been handled, following can be done.
A subordinate ‘skips’ his boss from the meeting, and meets his boss’s boss or someone even higher up. This helps the individual bring up any cheatcode issues related to his supervisors.
Allowing feedback to superiors and peers, not just to subordinates.
Free communication builds a self-correcting system. Such a system does not allow itself to fall below standards.
An organization was known for its “open” culture. Techies were encouraged to ask questions. Only problem – we could discuss requirements and designs till the cows came home. But, talking about people was a “sacred cow” subject.
If a topic is protected, then it will receive less feedback. The topic will be easily abused. It will have less chances of improvement.
Increasing transparency is logical; it seems simple. But beware – it is a lot of hard work. First reactions are to resist transparency. Especially in patriarchal cultures or long established systems.
Superiors are not accountable to subordinates at most places. This is an established habit. Adopting new habits is discomforting and takes effort.
The idea of Transparency – is to both discourage cheatcodes and allow the visibility of a cheatcode as soon as possible, from any layer within an organization.
Dig to the root
True story :
During one of my projects, I was bombarded with requests. Analysis requests, meetings, ad hoc messages, tech groomings, story discussions and more. The situation got overwhelming.
Truth be told – I believed that some teammembers weren’t putting their best foot forward. After taking time to calm down, I backward-reasoned the problem. Here it is …
Is ‘too many questions’ the root cause of the problem or just the symptom ? Should people stop asking questions ?
I found out that – Lack of information was the root cause.
No one person in the team really understood the end to end picture; except myself ( with humility ). The overall responsibility fell on my shoulders.
Since the problem was – Lack of information.
The solution was – A big training session.
I conducted a big training session. Next thing I see:
This was a BIG turnaround for a single KT session.
The turnaround proved something i felt was true … problems are sometimes “symptoms” of the real problems. ( better explained in the book called Principles )
All problems came my way because – People initiating the problems did not know any better. The only person they knew could help was me. People weren’t lazy, just ignorant.
So, training and NOT reprimanding was the solution.
This is what happens at tech organizations. Most problems are symptoms of a deeper problem. We need to dig to the root of the problem.
In cheatcode context, this might look like …
Root causes turn out to be: Lack of training and poor supervision
Therefore – the solution is to train the new team member and fix the lethargic Manager. Hard hitting programmers will simply not solve the problem.
Similarly a technical issue might really be:
Learn to dig to the root of problems. It will lead you to the cheatcoders.
Listen
Cheatcoders create trouble for others. Some folks facing such troubles will always bring the issues forward; sometimes at their own peril.
Mostly, the aptitude to recognize the issue will be lacking. This brings us to the next point – LISTEN.
Simple objective listening goes a long long way. It helps in understanding the issues, resolving them and avoiding them in future.
Cheating is beneficial only when not getting caught. If chances of getting reported are high, then it’s a dis-incentive for me to cheat. I will end up:
Either ways – organization wins.
Listening is a simple and useful tool. It helps keep cheatcoders away.
Skin in the game
Nasim Taleb wrote a book by same name. The book explains the concept in detail.
Loosely the phrase means – Someone doing a work, should have a disincentive for doing it poorly. Let’s apply it to our situation.
Cheatcoding is lucrative until there is no punishment for doing poor quality work. If my mess can be cleaned up by others … I will be happy.
Real examples:
If another person needs to solve my issues. Then the cheatcoder is encouraged.
What is your opinion about the below scenarios ?
Skin in the game, immediately creates a disincentive for poor quality work. Therefore, it therefore discourages cheatcoding.
Common Sense
Anyone working with a Tech team needs to understand certain simple ‘common sense’ ideas.
A saying in hindi goes “Jiska kaam usi ko sajhe, aur kare to danda baaje“. Loosely translates to – Person suited for the job is the best person to do the work, others are almost certain to mess up.
Managing technical work requires a deep understanding of technology. Superficial knowledge does not help. Techies will be able to fool anyone not tech enough. Also, someone familiar with the work will easily recognize any inefficiencies.
When people with fancy qualifications, but little knowledge of technology are asked to manage a Tech team – they create a mess. Techies are able to easily cheat. More complex the technical work, the easier cheating becomes.
Allow a techie to manage technical work.
Business practices are tools for getting the work done, and not the work itself. They need to be valued as such.
Meetings are frequent and valued at tech organizations. I hold nothing against meetings. They are enablers to produce code. At the same time, meetings are not deliverables themselves. Same goes for all business practices.
More leaders ought to realize that requirement documents, software lifecycles, deployment tools are just tools to deliver the code. The tools aren’t the deliverables. Code is !
Engineering work does not prosper with ambiguity.
Ideas start vaguely. They become loose business requirements. Business analysts, Managers and Architects are responsible for translating the vague business requirements to clear tech requirements. Doing so, is the crux of their job.
If techies are given vague requirements (unfortunately happens a lot), the resulting code will always be half ready. Also, techies will be easily able to cheat the work.
Clear concrete work, with fixed timelines will keep most ( if not all ) techies accountable.
Conclusion
We wanted to learn about vaccinating oneself ( COVID time vocab ), from cheatcode virus. We discussed many of them. Starting with simply being aware, to being clear and using common sense.
These practices will keep most teams healthy !
But once someone has been infected, a vaccine is no longer sufficient. They need a dose of medicine. This is what we do in the next blog.
In the final blog of the series we discuss – the antidote for an already infected organization.
Lets go …
Write back, in case you have an opinion. Like what you read – do like, comment and share.