Debugging Titles: Part I

What makes a Senior Engineer a Senior Engineer? When you ask that question, you’ll get a lot of different answers. Some think it’s writing excellent code. Some think it involves leadership. Others believe it requires the ability to mentor others or be product-minded. As we’ll discuss later in the article, everyone is probably right. But if everyone is right, the path to Senior Engineer is murky and unclear, not to mention really hard. How do I become an amazing programmer, and an amazing leader, and an amazing mentor, and more? Can one person really optimize their development in all those areas at once? This creates frustration for people highly invested in developing themselves. It makes figuring out how to grow your scope and your impact difficult.

Several years ago, we noticed a theme among Riot engineers. People wanted a clearer definition of how to advance to the next level. Being gamers, and highly driven individuals, we naturally want to know how to “level-up.” We had a problem though: at Riot, we dislike hierarchy that stifles ideas and creates positional authority.

Let me illustrate with an example. Consider a team developing a new in-game feature dealing with competitive, ranked play. This hypothetical team is comprised of two Senior Engineers and an Associate Engineer. The Associate Engineer is a die-hard, competitive, Platinum player. The rest of the team, while avid players, just aren’t as into the competitive components of League. As the team begins designing the feature, they debate a technical choice that could affect the player experience. One of the Senior Engineers feels strongly about one path, but the Associate, knowing how this will feel to highly competitive players, doesn’t agree. At Riot, we expect that Associate to have the courage to speak her mind. Even though she’s “junior” by many common definitions of the term, she has way more context and expertise about competitive play. We also expect the Senior Engineers to value the input from the more “junior” engineer.

Good ideas can come from anywhere, and we want the best ideas to surface, regardless of the person’s perceived “authority.” Even someone with little experience can be a highly capable problem-solver and critical thinker. They may also bring a unique perspective that increases the diversity of thought on the team. Discounting their skills or perspective based on their experience robs the team of solutions not previously considered. So how does this relate to becoming a Senior Engineer? We needed a way to think about career growth that emphasized value delivered and player impact over authority and title. It also had to clearly articulate a path from good to great. Titles weren’t the right system to capture all the nuance and complexity of our thinking.

So What’s Wrong With Titles?

In a nutshell, titles are too one-dimensional. I’m going to use another gaming analogy here. Let’s say you’re forming a raiding party and you decide to interview your friends to find the perfect hero for the raid. One of your friends tells you, “I’m a Level 40 Ranger, so I should definitely be on your team.” Do you want that person in your raiding party? Most people would agree there’s not enough information. How much damage do they do? How much health do they have? What kind of a raid is this? Where is it? What kind of strengths does the team need to face potential threats? Lastly, you don’t know what the makeup of the rest of the team is. What if I already have four other ranged champions? This one-dimensional title of “Senior Ranger” fails to describe all of the components needed to have an effective team.

You can apply this same analogy to League team composition. You need some intentional mix of crowd-control, frontline tankiness, burst damage, and siege ability if you want a well-rounded team. We wanted a system that would capture that same spirit. We wanted to determine the attributes we’d put on our individual character sheets that would define great engineering at Riot. If we did that effectively, we would have a way to construct balanced teams and give people concrete areas they could focus their development on… all independent of their title. Eighteen months ago, we decided to develop that system.

Flavors of Great

First, we had to decide what our attributes were going to be. While damage, health, dexterity and intelligence are great for your favorite RPG character, they don’t apply so well to being an awesome engineer at Riot (well, maybe intelligence?). I won’t go into the details of how we decided on the attributes we landed on, because it was mostly hours and hours of conversation and discussion with engineers, managers, product owners, and nearly anyone who would listen to our crazy idea for 10 minutes. Whatever we came up with, we knew we wanted the attributes to be comprehensive, meaning they could effectively describe every role within Engineering. We started with these:

  1. Craft

  2. People Leadership

  3. Craft Leadership

  4. Product Focus

  5. Development Process

Craft was the easiest one, or so we thought, as it represented how good you were at core engineering skills. We’ll come back to that one in a second. People Leadership is the ability to manage people, build and lead teams and organizations, and coach and develop those around you. Craft Leadership is the ability to mentor people in their craft and drive alignment on technical vision across the organization. Product Focus represented how much you contributed to the overall product design and vision. Development Process covered the fundamentals of engineering processes, like Continuous Delivery, Agile, and others.

We then took these five attributes and decided to socialize them with all of engineering using our RFC process. We quickly learned that Craft was too ambiguous and didn’t really define what we valued as engineers. We have several different flavors of engineering at Riot that represent different focuses or areas of concentration, all of which are essential - examples are software, infrastructure, and security. As we socialized the attributes to people with those specialties, Craft didn’t capture what great looked like for everyone. After much debate, we aligned on splitting craft into Programming and Subject Matter Expertise. Perhaps in a future article, I can dive into this more, but we felt that Programming was the definition of what it meant to be an engineer at Riot - we want all engineers to develop proficiency there, regardless of their other focus areas. We also changed some verbiage on Product and Process to more accurately convey their meaning, so we ended up with:

  1. Programming

  2. Subject Matter Expertise

  3. People Leadership

  4. Craft Leadership

  5. Product Sense

  6. Delivery Methods

With these six attributes, we could effectively describe, in plain terms, what kinds of engineers we had at Riot filling all of our roles. Here are a few examples of some archetypes that are possible:

The Guru

 

The Product Owner

 

The Agile Coach

 

Here’s the best part: all of these definitions of great are completely void of title. We can (and in many places we do) have Senior Engineers, Associate Engineers, and a diverse list of other titles that easily fill any of these archetypes. We now had a way to think about composing teams, defining roles, and showing our engineers what the bar was in each category. Other archetypes certainly exist as well.

Only the Beginning

Defining the attributes was a hugely valuable way for us to start thinking about career development within Engineering. But, we still had to define “the path.” Essentially, what does it look like to be a Level 1 Craft Leader or a Level 5 People Leader? We discovered that even the term “level” had severe implications. We’ll talk about how we approached that problem in our next article.

For more information, check out the rest of this series:

Part I: Titles (this article)
Part II: Levels and Attributes
Part III: The Future of Masteries

Posted by Mike Seavers