We all know that creating a team filled with code monkeys is a bad thing. Paying a small fortune for engineers to merely follow precise orders doesn’t make sense, and most of them object to being micromanaged and being deprived of any autonomy. Your intent is to form an engineering team that has ownership and agency. Nevertheless, I’m witnessing an evolution where teams get stuck in a weird spot and often fail to recognize that. It is the formation of code apes.
Code apes are not your regular everyday primates. Explicitly robbing them of freedom wouldn’t fly. Rather, they are faced with a situation where they believe they have a better status than they genuinely do. In my quest to help code primatologists, here are some telltale signs:
Tool and Tech Obsession
Just because they’ve got opposable thumbs doesn’t mean they should only focus on their own tools. I see teams that go on and on about their high-quality code, lowering debt, and k8s in the browser setups. This often means that the team does not have a way to affect the actual product plans and roadmap, and therefore has to let their agency be expressed by too much focus on the latest shining software packages.
It might feel like the team is doing valuable and intelligent stuff. After all, no one will say that amassing tech debt is a good thing. Still, it often means that the team is following the path of least resistance.
Caging From the Real World
If the team has no real connection to the company’s customers, it becomes isolated. This disconnect means that they will be more likely to focus on tech (see the previous point) and will not possess product mastery (see chapters 2 and 10 in The Tech Executive Operating System).
Exposure to the real world is a requirement for helping the team calibrate its beliefs and efforts. Without it, they won’t push back on things that don’t make sense or suggest their own ideas.
Feeding
How do your roadmaps and objectives look? Code monkeys are not privy to actual goals and objectives but are fed Jira tickets. With apes, it’s a bit different. They might get some bigger resolution requirements, but those do not come with genuine delegation and autonomy. For example, I’ve seen teams where objectives were more significant so as not to be “micromanagement,” but they were also overly prescriptive.
When leadership thinks that they have to “feed the beast,” there is a focus on providing the team with tasks to occupy them. Too much feeding is counterproductive. You should give them the freedom to hunt on their own from time to time.
Overprotection
Creating an environment that keeps the team completely “safe” where nothing wrong can happen is destructive in the long term. A team that always hits all of its goals and never tries something that might fail is a team that spends all of its time within its comfort zone. Team members who are never given the option to explore and roam will never get hurt, but also will never make any meaningful discoveries.
Cultivating innovation and creativity is a must for world-class engineering teams (which, BTW, is the topic of the sample chapter of The Tech Executive Operating System that you can get below). Let them make mistakes and try new things. That’s how we get evolve!