“This actually makes me feel less confident about my role here. If we can’t define what we think senior is, how am I supposed to know if I’m working toward it?”

At Frontside, we gather every Tuesday afternoon for our company meeting, where we talk through our accomplishments and plans for the coming week.

In a recent meeting, we talked about our search for a senior developer to join the team, and you could see passions flare. No decision we can make impacts the company quite like bringing on a new team member, so naturally we all had strong opinions about the qualifications we were looking for.

However, not one person in the room could crystallize our thoughts on what qualifies as “senior” above a general gut feeling.

One person chimed in with the quote above, and I realized that we’d stumbled onto one of the biggest problems in our entire company: we had no idea how to define the role we’re trying to hire for and grow our developers toward.

The problem of defining “Senior Developer”

For my part, I’ve come to distrust the term “Senior Developer”, particularly after being given that title after 9 months of professional programming experience to fit into a salary band.

In fact, if you ask two experienced developers to specify their definition of “senior”, I guarantee you will find serious conflicts between their answers.

The question of what qualifies as a “Senior Developer” is both context-dependent and so malleable that our industry squishes it into whatever shape fits their current needs.

Here are some actual, real-world definitions I’ve seen used to justify the label “Senior Developer”

• 15+ years of programming experience
• 2 years of programming experience and decent leverage
• 1 year of experience in a hot new 1-year-old framework
• Having authored a technical book
• Writing Comp Sci algorithms on a whiteboard
• Writing an open source library used within the company

That’s a pretty broad range of definitions. But lots of stuff in life is hard to define, so what’s the problem?

Why bother defining it? What’s wrong with a gut feeling?

In our meeting, when our team member pointed out their confusion, they were pointing out that we are hiring, firing, and promoting people based on criteria we can’t define or defend. They’re right, that is bananas.

Worse, we were failing at our core mission of growing developers by not clearly marking the path we’re trying to help them travel.

There’s another, larger problem with “I’ll know a senior developer when I see one”: “Senior Developer” is a profoundly effective vector for bias.

“Senior Developer” as a way to enshrine bias

When we picture a wise senior developer, we each have our own experiences and preferences that color this picture in for us. That means the term is already spring-loaded with a bunch of our own baggage.

When we take a “gut feeling” sense of someone’s seniority without specific criteria, there is basically no way to counteract our own biases, but we still make a judgement. It’s completely possible for a person applying to multiple dev jobs to be evaluated as junior at one, mid-level at another, and even senior at another, with very little feedback as to why.

And as hiring managers, we all feel correct when making these judgements, even as we reach vastly different conclusions.

The result is a reinforcement of existing biases that keeps some people from progressing, while resulting in “title inflation” for others. Since existing biases in tech are strongly and undeniably tilted toward white males, the existing “gut feeling” system disproportionately harms women and people of color.

Why haven’t we solved this?

This definition is an extremely hard problem, since it’s heavily dependent on the context of the work environment. Most business owners are just making this stuff up as they go along, and the solution we tend to wind up with seems to be “good enough”.

There’s also no incentive, because defining criteria takes a lot of the “gut decision” power away from founders/owners and adds accountability. Who sits around asking for less power and more accountability for themselves?

Injecting accountability

I like accountability. I take comfort in it. I’ve learned that being held accountable for something is quite liberating. For instance, being clear about the criteria we use to hire someone leads to less regret than “going with my gut”, which can be affected by everything from someone’s ability to riff on Simpsons quotes with me to whether I skipped breakfast that day.

Accountability also opens the door for improvement. As the hiring manager, I’m responsible for fostering a safe, capable, happy, diverse team. Improving and working toward those goals can either happen by gut feelings and dumb luck, or we can define, measure, and hold ourselves accountable for iterating toward those goals.

Accountability moves us from being passengers to drivers of our own future.

It starts with responsibilities

The question becomes: How can we create and use quantifiable criteria for seniority without creating a deeply flawed, highly game-able system?

The only fair way I can think of to judge a candidate is asking a few key questions: What are this person’s responsibilities? How likely are they to be able to fulfill them? How much help will they need?

We started by defining our environment. When we examine the key attributes of the environment at Frontside, it starts to become clear:

• Being small means that people need to take the lead in several roles to solve problems from start to finish. There are no “cogs” in this machine.
• We rely and build on the strength of our internal community and the larger communities we participate in, particularly in open source.
• We have extremely ambitious technical goals and standards for the maintainability and usability of the code we write.

The resulting responsibilities are then pretty easy to determine:

• Provide clear technical and project guidance for their teammates and our clients
• Mentor, teach, and contribute internally and in larger programming communities
• Ship software that is a joy to its users and to the developers who extend and maintain it

Together, these responsibilities form the basis of the criteria we use to assess seniority.

The Conjoined Triangles: The simple explanation

I recently had a chance to dig into the definition of “senior” at a number of companies, large and small, and came away with only one common denominator.

The simplest explanation of seniority across companies is this: How much direction will this person need, and how much will they be able to provide to others?

I stand by the Conjoined Triangles of Senior-Level Development as a nice idea, but like Action Jack’s “Conjoined Triangles of Success”, it’s enough of an oversimplification to shed its intrinsic meaning.

Even with this understanding, the door is wide open to inject bias, miss important criteria, and overvalue higher-visibility things like public notoriety or the ability to speak computer science lingo.

In the meeting, a new framework emerges

A really cool thing happened during the heated meeting. As I was describing this simple “unified field theory”, another employee put forward a new mental model to organize our thinking around this.

She described the framework we use to determine seniority at Frontside as a Venn diagram, the intersection of how well a person works independently and leads, how technically capable they are, and how well they connect and contribute to a larger community.

The Venn diagram: The more complex explanation

Our evaluation of seniority does, in fact, roll up to the higher definition: “How much direction will this person need, and how much will they be able to provide to others?” But as our employees pointed out, when we stop there, there’s a ton of room for confusion.

So how can we decide how well a candidate is likely to perform their responsibilities? How do we anchor our evaluation criteria to something concrete, without killing it by turning it into a mathematical formula?

When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.

I’ll break the 12 traits down in detail in the next post, but for now, we’ll just hit the high points.

The tracks

Technical capability: A person with high technical capability is technically curious, tackles problems without giving up, and produces solutions that less-experienced folks can use, maintain, and learn from.

Leadership: A person with leadership skills knows how to develop and follow a sense of purpose, in themselves and in others. They are willing to point out, own, and fix things that are broken about our company and in their own career tracks.

Community/Connectedness: A person with community skills has a sense of being part of a larger whole, a desire to contribute, a sense that the other people (i.e. coworkers, users, clients) are not simply characters in his or her own movie, but fully-realized individuals.

What about “culture fit”?

We initially almost called the Community & Connectedness track “culture fit”, but I have come to be highly suspicious that this term is a thought-terminating cliché. “Culture fit” is a junk drawer for all the stuff you want to see in a developer that you can’t otherwise define, and it’s an ideal hiding place for intrinsic biases.

When we defined the criteria that make Frontside’s culture unique, the common trait is the idea of connectedness as defined above.

Measuring seniority across 3 disparate tracks

Remember the three areas, technical capability, leadership, and community? Each of these tracks has a junior-to-senior path all its own.

It’s now common for a person to switch careers and come out of a code bootcamp with seniority in leadership and connectedness, while being junior in technical capability. Conversely, a skilled, formally-trained technician may be missing experience in both leadership and connectedness.

Very few qualify as senior in all three categories. In fact, it’s unlikely a person will even be interested in becoming senior in all three categories. At Frontside, we define seniority as a blend of these tracks and work to help people level up where they feel like they want to improve.

Artifacts: The only measuring tape you’ve got

The measure of seniority in each track requires evidence. If you’ve done something, you likely have some kind of artifact as a result.

The 12 traits we’ll discuss in the next post each come with concrete artifacts a candidate can point to to show that yes, they have developed those traits over time and with practice.

But taken as a whole, a couple of well-developed and deeply-practiced traits in an area are likely to qualify a person as senior in that area.

For instance, if a person can talk you through the code they’ve written across various programming languages, they probably peg the “curiosity” trait pretty high. Combine that with the rigor to write thorough, high-quality tests for the majority of their projects and hook it up to Continuous Integration, you’re probably looking at someone we’d consider technically senior.

Or, if someone has a long history of mentoring others, organizing meetups, or creating tools that make others’ lives easier, it’s likely we’d consider them senior on the community track.

If a person has managed a few teams before, they have likely learned and developed processes to handle the very real challenges there. Combine that with the ability to get to the purpose or root of an issue, and you have someone we’d call senior on the leadership track.

How we define “Senior”

Our measure is that if someone is senior on the technical track and either the leadership or community track, they’re senior to us. We can help level them up on the remaining track if they want.

If they’re senior on the community and leadership side, we consider them senior if they are high-mid-level on the technical track.

As a real-life example: About a year ago, we hired a new employee as a junior developer, because we knew on the technical side they needed a ton of direction for at least the first six months.

At six months, they were solidly mid-level technically, and within their first year, by our estimation, they were already senior. I can say this with confidence because when they left, we realized that to fulfill their job functions, we’d need to hire a senior developer.

This happened because when they started with us, they were already senior on the community and leadership tracks, so all they needed was a boost on the technical side to perform the job of a senior dev on our team.

Technical skills aren’t enough

For someone with technical skills but little experience in community or leadership, “You don’t qualify as senior by our standards” is not music to their ears. But for the job responsibilities they’ll have with us, we would consider that person mid-level until we can help strengthen one or both of the remaining tracks for them.

Many shops only measure along the technical axis, but it simply doesn’t work for a company of our small size and collaborative work style. I also worry that those who only measure technical skill are buying into the dangerous “lone genius developer” myth, cheating the developer out of the serious boost they’d gain by adding leadership or community-oriented skills to their technical savvy.

Even in larger companies with more focused roles, I’d like to see a broader definition of “Senior Developer” that encompasses the code and non-code skills we use and that allow us to work effectively, particularly in teams and with real customers.

How long does it take to become senior?

Does “Senior developer” mean “X years of experience”? Well, I don’t see it happening inside of 5 years for anyone. It would be difficult or impossible to develop the traits needed to reach senior-level in any of these tracks in less than several years, much less along multiple tracks.

But “5 years of experience” doesn’t necessarily mean “5 years of software development experience”. A person who has already climbed the Leadership and/or Connectedness tracks need only hook that up to their increasing technical skills to provide a tremendous amount of value as a software developer.

Our hiring “secret sauce” largely stems from the fact that it seems to take significantly less time for someone with leadership and community skills to develop technical skills than the other way around. I’m seeing a large number of people who graduated from code bootcamps 3 and even 2 years ago now handily and gracefully filling the role of senior developer.

There’s more to discuss

This leaves many questions unanswered. What are the specific artifacts we use to evaluate skills and traits in the three areas? How can you evaluate for these before and during an interview? How do we tie these evaluations to something as concrete as someone’s salary?

How does this framework apply to non-senior developers? How and when do developers advance? What’s the difference between a Junior, Mid, and Senior? What exists between them? Are these terms devoid of meaning and in need of replacement?

Lastly, how does this framework apply (if it applies at all) to other companies with vastly different cultures and needs from Frontside?

In the next post, we’ll dive into specifics to answer these.

Moving past “gut feelings”

Defining “senior” is an ongoing and surprisingly difficult process, but we do it because it’s business-critical for us. Without a clear definition of “senior developer", we have no clear path for our own employees to get there. We have no concrete way to evaluate people joining the team, no way to hold ourselves accountable, and no way of improving the process.

As an industry, it’s time to graduate from the “I’ll know it when I see it” definition toward something we can define and share. Let’s bring open source thinking to how we hire and grow our people.

I hope to answer the major lingering questions in the next post. If you have questions or a different definition, you can find me on Twitter (@tehviking) or better yet, write a post with your own thoughts and I’ll link to it.