We Built A Tool To Help Us Foster Growth In Our Engineers
And we want to share it with the world
Warning: it might be a spreadsheet
When someone joins Bench engineering, we commit to fostering their growth. This isn’t something we take lightly. It requires hard work, tons of trust, and no small amount of compassion.
Growth happens when an individual accepts the monumental challenge of continuously asking themselves: “is this the best I can do?” As managers, it is our job to create an environment where this question can be asked over and over again without judgment, without penalty, and without fear. This doesn’t mean that this environment is comfortable. Growth isn’t comfortable — for it to happen, we must redefine our limitations by pushing beyond our existing ones. This is hard, and scary, and hugely rewarding.
An individual can choose thousands of directions for their growth. While this seems like a cheery statement, it can actually be overwhelming. With so many options, what should they prioritize? What areas will move them forward in their career? Left unmanaged, this proliferation of growth opportunities can actually be demotivating; without a clear vision of their next level, why bother with the discomfort of growth?
We found ourselves struggling through such unstructured growth conversations. They were fundamentally dissatisfying for both the engineer and the manager, and they weren’t consistent with our commitment to fostering growth. So, we took action.
We hypothesized that a clearly defined set of competencies for each engineering role would give us a framework to have deeply honest conversations about current ability and future growth. We actually had an early version of this already, but it had been brought in from another company, and we didn’t feel like we owned it. We wanted to wipe the slate clean and create something unique to Bench. The rest of this post is about how we did it.
At this point, we recommend opening up the public version of our competencies to reference as you read the rest of this post.
Moving to numbered job titles
Like a lot of Engineering orgs, Bench used Junior, Intermediate, and Senior when describing engineers. We were dissatisfied with these job titles for a number of reasons. First, these titles mean wildly different things at different companies. For example, someone might be a CTO at a small startup, and an intermediate at a larger company. This created all sorts of strange conversations when both hiring and promoting — almost as though we needed to look at their past job titles to figure out what to call them. Second, “junior” and “senior” imply some form of age- or tenure-based system of measurement. Age and tenure do not map to competency, so we wanted to move away from language that suggested otherwise. Finally, the “intermediate” title had the potential to span many years of growth. It was therefore very difficult to define competencies for such a broad range in ability and experience.
Because of the reasons above, we decided to move to a number system for our job titles: we now use Engineer 1 through Engineer 5. These titles are intentionally meaningless. The only thing that can be inferred from them is that there is a sequence. This is the blank slate we needed. The next step was to define each role within the context of Bench.
Defining the competencies
Blog posts have a nasty habit of using hindsight to make complicated processes seem simple. Let it be known that while a post like this may make setting competencies seem relatively straightforward, it wasn’t. It took many, many revisions, and still has areas that aren’t quite right.
Discover categories and use them to build a progression
We started with three high-level categories: People, Process, and Technology. Within each of these, we began listing competencies. This was pretty unstructured — the important part was to get something on paper. Eventually subcategories began to emerge. For example, the People category has subcategories including Team player, Owning their growth, and Contributing to culture. As these subcategories solidified, we began the process of defining the progression of expectations for each. We asked ourselves: what does “owning their growth” look like for an Eng 1? An Eng 3? An Eng 5? Sometimes these came quickly. Sometimes they didn’t. Sometimes you end up with annoying word progressions like “working knowledge” =>“solid grasp” => “deep knowledge” => “expertise”. These are all okay. What’s important is that the managers understand what they mean, and can converse about them with consistency.
Make each competency a real challenge
It’s really easy to write vague competencies like “participates in code reviews” and “contributes to culture”. It’s a lot harder to write competencies that foster growth by clearly defining our high standards. Consider the following competency from the Non-technical Communication category for Engineer 3:
Facilitates effective communication within small groups. Helps keep conversations of small groups on track and is effective at communicating objectives and outcomes.
With competencies like this, we can have real conversations about growth. They’re actually quite simple. “Are you doing this? If so, let’s talk about your successes and failures in this area, and develop a plan for how you get to the next level. If not, let’s talk about how we can support you in starting.” There’s no vagueness in these conversations, and the more challenging the competency, the more likely that a conversation about it will foster growth. (Of course, the competency can’t be too hard for its level or else it’s demotivating. Did I mention this was hard?)
Test the system
Competencies written in a management vacuum are useless. They need input from the people they’re designed to motivate. To test our system, we immediately began using it as the rubric for our salary review process. This will be covered in depth in a subsequent post, but here’s the high level:
- For each competency, the engineer self-assesses themselves out of 5
- Separately, their manager did the same
- They then met and talked through each competency line by line, compared scores, and aligned on a “final” score
- We then used a transparent formula to convert their average score to their salary.
In bullet form, this process looks cold and scientific. In reality, this process has created some of the best growth conversations we’ve had in Engineering. We’ve been trialing this for about 8 months now, and overall the feedback from both managers and engineers has been overwhelmingly positive.
We aren’t done yet
We have high standards. We know that our competency grid is a useful tool, and we also know that it can be significantly improved. As we use it to frame growth conversations, we continually review the competencies themselves. Are they specific enough? Do they actually push for growth? Are we missing categories? Do the competencies as written resonate with the engineers?
We began this journey to create a framework for better growth conversations with our reports. It turns out that creating the system also fostered our growth as engineering managers. We highly recommend implementing a similar system. Please, feel free to use ours as a reference. Our only request is that you don’t copy paste it into your organization. Every engineering organization is unique — its list of competencies should be too.
—
Written by Blake Turner, Head of Engineering at Bench.
If you are interested in learning more about Bench Accounting or a career with our Engineering team, apply here: https://bench.co/careers/
