As a company evolves its engineers tend to devolve into code monkeys.
A code monkey is not an actual monkey, it’s an engineer who sees nothing, does nothing, and understands nothing except for code.
This is not the engineer's fault, the evolutionary pressures are too great to resist: getting pushed farther away from customers, being sucked deeper into a growing codebase and engineering organization, and becoming part of a code production line.
Crucially, some startups experience this problem from day one and some never do. What makes the difference is hiring, culture, org structure, and autonomy.
Hire Builders
There are two main reasons that drive someone to become an engineer:
They enjoy the technical aspects of engineering (coders)
They want to build stuff that others enjoy and value (builders)
Both reasons are great. What’s not great are engineers whose drive is 100% technical – you want to avoid those.
Identifying the drive to build for the benefit of others is not hard once you bother looking. I like to ask engineers about the hardest project they’ve worked on in recent years. If all they tell me is technical stuff then that’s a yellow flag to be followed up with:
Why was this project important?
What was the goal of the project?
Did the project succeed or fail? How do you know?
If they can’t answer these questions then the yellow flag becomes red.
Hire engineers who see beyond the code and understand that the finish line is not shipping, it is delivering value to people.
Builders Culture
I once asked my lead engineer to write his own job description. His English is a bit off but his mind is spot on.
The intense focus on value over code is what makes this beautiful. And your goal is for every member of the team, starting with yourself, to view engineers as builders of value, not mere code producers.
How can you tell if your culture is too code-focused?
Engineers come into the picture when the project is ready to be implemented
Engineers leave the picture the moment the project is shipped
There’s an obsession with protecting the engineers' time so that they can code for 10 hours/day without interruption
When your engineers are treated like code monkeys, don’t expect them to behave any better, or to stick around for too long.
Org Structure
If you’re not an engineer you will never be able to see 5 engineers alone in a room. All they can talk about is tech, tech, and tech. Add a designer and a PM to the mix, and the conversation will shift towards users, value, and pop culture.
This is why my startup never had an engineering team. We have a tech team that includes design and product. Weekly planning and standups are happening with everyone and we have no scheduled engineering-only meetings.
This exact structure breaks down at scale, but even at Facebook while I was a part of an engineering team we couldn’t get away from my PM and designer for a second. The 3 functions must be fused together.
Autonomy Breeds Empathy
There is a Hebrew saying, “far from sight from the heart.”
The tendency to shield your engineers from everything so that they can be productive quickly backfires. It comes at the expense of empathy.
Your engineers should be on customer calls and hear a customer complaining. They must read user research, and see why sales are struggling to close a deal.
Your engineers need to hear about problems, come up with solutions, and challenge product and design to account for technical challenges and opportunities.
Your engineers want to know how a feature is being used, whether it is working as expected, and whether it is making an impact.
Give your engineers the freedom to move the needle however they see fit to and watch them as they move the needle.
Conclusion
Three bricklayers were asked “What are you doing?” to which the first replied, “I’m laying bricks.” The second responded, “I’m repairing a wall.” And the third replied, “I’m building a cathedral to The Almighty.”
You don’t want engineers who merely lay code or repair bugs, you need engineers who build a valuable product for your almighty users. This can be achieved with 4 principles:
Hire Builders - look for engineers who build for people rather than code for themselves
Builders Culture - create a culture where engineers are treated as powerful builders of value and not mere code producers
Org Structure - fuse product, design, and engineering together to encourage more conversations about users and less about tech
Autonomy Breeds Empathy - give your engineers the freedom to leave the codebase and see users, problems, and opportunities
Then take it to the next level, think about the metrics you track, the things you celebrate, how you compensate, and the words you say.
Don’t miss the forest for the code.