The most effective software development teams need to be made up of a variety of different and complementary archetypes. You need deep technical experts, glue engineers, and those who are excellent communicators, mentors, and teachers.

With that being said:

• Hiring an expert developer is not the best way to improve the output of your team.
• And learning from the best is not the best learning.

If either of those statements feel controversial to you, I’m here to try to change your mind.

After much trial and error as a CTO, and tirelessly learning about how people learn, I believe that the key to improving engineering team performance is a balance between two different types of engineers who set the tone for the rest of the team: The ’maven’ and the ’guru’. Let me explain.

What are mavens and gurus? 

Etymology is the study of the origin of words and the way in which their meanings have changed throughout history. Take the word "guru" as an example.

Guru is an ancient Sanskrit word, and seems to mean something like "dispeller of ignorance", but over its long history has come to mean  mentor or teacher. The person you go to for guidance.

Today, the way we use the word in modern English has an extra meaning. It can now mean an educator or an expert. But what’s the difference?

Now take the word  "maven", which comes from the Yiddish word "meyvn" – or "one who understands".

On the one hand we have the guru, the "dispeller of ignorance" – outward-facing, focused on the learnings of others. On the other hand we have the maven, the "one who understands" – inward-facing, the person who can learn and achieve brilliance themselves.

Mavens and gurus in software teams 

In software teams, the maven is the individual high performer that companies compete for. They are the person who goes deep into a certain  programming language, or knows a framework inside out. They live and breathe the topic, stay up to date with new developments, and can easily navigate the codebase they work on. They’re the people who will take a new feature request and fit it into the existing architecture in their head before their hands even touch the keyboard. They might have the makings of a fantastic staff engineer or architect.

The guru, by contrast, is a good developer, but  an even better teacher. They have the instincts to see the roots of misunderstandings, the imagination to captivate with vivid and memorable examples, and the ability to support learning without just ’telling’. Knowing your thing and teaching your thing are different skills, and we should take care to remember that.

In development teams, the ’guru’ is the developer who spends most of their time pair programming with more junior devs. They explain, answer questions, help people solve their problems and, crucially, help them understand why and how that solution is the right one. They level up everyone around them.

The (distinct) roles of the maven and the guru

When you ask the guru to be an individual contributor – and not a coach – you limit their impact on the team. And when you ask the maven to be a coach, you may find that the ability to teach is a completely distinct skill from being an expert in a topic. 

Consider elite sports, where very few coaches were elite athletes themselves. Or Carmine Caruso – recognised as a great teacher of trumpet and other brass instruments in New York in the 20th Century, and author of "Musical Calisthenics for Brass" … who didn’t even play a brass instrument himself. 

How do we make the most of the maven and the guru?

That depends on what you’re learning. I’ve written before on the differences between learning knowledge, skills, and wisdom. Briefly: knowledge (facts, data, information) is cheap to access, and readily available on the internet. You can learn it effectively from videos, books, and tinkering.

If you want to do something new then you’re learning a skill. This is where the guru shines. To learn a skill you need to practice it and get feedback. The guru is the person you need to give feedback, provide pointers for improvement, and resolve misunderstandings. What you don’t need when learning a skill is to be simply told or shown what to do, without an opportunity to probe, question, and get feedback.

Wisdom – the ability to make good, contextual decisions – is harder to gain. Typically, wisdom is hard-won from experience. However, the right guru can construct scenarios to demonstrate similar problems with different, contextual solutions, so others can grow their own wisdom.

Another way that people pass on wisdom is through lore. By lore, I’m including rules of thumb, best practices, and frameworks. These are learnable ways of approaching a problem, where a maven has managed to condense their contextual, hard-won judgment down into a set of rules that others can follow. That takes wisdom and makes it conveniently transmissible as knowledge.  These people are the best kind of maven – wise and self-aware enough to be able to examine and explain their own wisdom.

Mavens can answer the "How do I?" questions of your team, and can answer the "Why do we do it this way rather than that way?" questions. You still need a guru if you want your team to learn that wisdom for themselves, but they can get the benefit of that wisdom from the maven.

As engineering leaders, do we want gurus or mavens? Ideally both. But when it comes to learning, and leveling up the abilities of the team as a whole, you don’t need the expertise of a maven, you need the coaching skills of a guru – a dispeller of ignorance.

How to get the most from gurus and mavens

To really capitalize on these folks in your teams, you first need to identify the gurus and the mavens. We’re already good at making the most of the mavens, in that they tend to become architects and staff engineers. These folks may be best placed for helping others through leading lunch and learn sessions, rather than as mentors. Be cautious not to overload them with mentorship or pairing work unless they also show the characteristics of a guru. 

When you find a guru, focus their time on upskilling others or pair programming. Their work time should be the least individual of all your individual contributors. Then, if you can, give your team access to external gurus to learn from and bring in fresh capabilities.