Note from the author: this post was written in collaboration with Justin Cowperthwaite, engineering manager, with additional input from Jeff Palmer, VP Engineering.

We want CircleCI to be a place that all engineers can learn and grow, and be supported no matter what level they join us at, or how they want to shape their careers. To support this, we use an engineering competency matrix, a framework that outlines expectations and growth paths for engineers. This matrix is a tremendously useful tool for us: it informs the structure of our job descriptions and our interview processes. It helps us set expectations together with our engineers, is a basis for goal setting as well as conversations about learning and development. It helps us have more objective performance conversations which are less susceptible to the biases and skills of an engineer’s manager. Overall, it clarifies the vision of our organization and helps us maintain consistency throughout all stages of hiring and professional development.



We developed our first competency matrix three years ago. In early 2018, we realized it was time to refresh and rebuild our matrix, to better reflect how our engineering org has matured, and what we’ve learned along the way.

Today, we’re publishing our new competency matrix – first of all, because it’s an important part of our engineering culture, and speaks to our engineering and company values. We’re hoping it will help people interested in joining us understand what we value, and how they can grow their careers as engineers at CircleCI. Second, because we hope that other organizations can learn from our experience, and have a starting point for creating a matrix that reflects their own team’s values. Here’s how this system came to be.

Background

When we developed our first engineering competency matrix three years ago, we were a small startup with low overhead that was focused on shipping code as quickly as possible. We had fewer than a third of the developers we have today, and a much tighter band of experience levels.

Since that first matrix, we have grown as an engineering organization and as a company. Our needs have changed, and our understanding of what makes a good engineer has grown to include a wider array of interpersonal skills. Collaboration is now a key tenet of our technical skillset, with many teams utilizing pairing daily. We have also worked to build a culture of feedback, recognizing it as an invaluable tool for personal growth. And as we add teams and departments, the importance of strong communication skills will only continue to increase.

The process of rebuilding our matrix created many questions before it surfaced any answers: we found ourselves assessing and, in some cases, re-defining, the expectations in our industry towards career growth, and what we value in our engineering culture and want to encapsulate and foster in the future.

Laying the foundation

Before we dove into this project, we thought about the process that went into creating it. What was the best way to create something that reflected our values as a team, and that would be meaningful and useful to the individual team members in their career growth?

To address this, our engineering management team stayed in close communication with our engineers throughout the project. We relied on our engineers for feedback in every round of development, using efforts such as feedback workshops at our engineering all-hands, trial performance reviews, and a focus group that consisted of engineers, engineering managers, and HR team members. This approach was really useful for us to ensure we consistently incorporated feedback, and developed a stable, comprehensive, inclusive system.

We also decided on some key outcomes that the matrix should achieve. If we were to be successful, our matrix would adhere to the following attributes:

Consistency. Competencies and the expectations for how to demonstrate them should be consistent within and across levels.

Competencies and the expectations for how to demonstrate them should be consistent within and across levels. Approachability. Even without knowing all details of one level, it should be easy to develop an idea of the area of work and impact that engineers would be focusing on.

Even without knowing all details of one level, it should be easy to develop an idea of the area of work and impact that engineers would be focusing on. Simplicity. The matrix should be sophisticated enough to honor the many factors of a successful career, and yet simple enough to be useful for meaningful career development conversations.

The matrix should be sophisticated enough to honor the many factors of a successful career, and yet simple enough to be useful for meaningful career development conversations. Clear language. Word meanings should be precise and meaningful. Descriptors should be unambiguous and clearly denote shifts in frequency or scope of skills demonstrated. Competencies should utilize active language (“does” instead of “can do”), as it helps focus on activities instead of capabilities.

Word meanings should be precise and meaningful. Descriptors should be unambiguous and clearly denote shifts in frequency or scope of skills demonstrated. Competencies should utilize active language (“does” instead of “can do”), as it helps focus on activities instead of capabilities. Straightforward structure. We wanted to develop a structure that would allow people to see the big picture and dive into details as needed.

Values matter

We were very clear from the start that we wanted our matrix to be opinionated, in line with our beliefs about successful organizations and fulfilling engineering careers. One of our beliefs is that career paths are as diverse as the people that work with us, and we wanted to support everyone in their growth in the best possible ways. In our endeavour to set a standard for setting expectations and supporting people in their growth as engineers, we built in some underlying assumptions that form the basis of this matrix:

We don’t assume that all engineers should (or want to) aspire to becoming managers. Our engineering competency matrix ranges from level E1 for an Associate Engineer to level E6 for a Principal Engineer. We think that the “ultimate goal” of an engineering career path shouldn’t be in management by default – many engineers are happy focusing on growth as engineers, and management work requires an entirely different set of skills. We’re currently developing a unique competency matrix for engineering team leads, managers, and directors. This matrix will be a separate system with transition paths to and from other matrices.

Even junior engineers can be leaders. We firmly believe that leadership can come from everyone, and want to encourage all our engineers to develop leadership skills. This is why we call out leadership skills specifically in our competency matrix, and across every level (the leadership section for junior engineers comprises 17% of overall skills, not including the leadership implications of other sections like feedback, communication, and collaboration). For example, our matrix sees the increase of testing skills going from writing tests at level E2 to driving strategy and helping teams improve their testing at E6. In all areas, the focus of an engineer’s work shifts over time from execution to include facilitating, guiding, and mentoring others, whether or not they are in a management role.

Growth is not linear nor streamlined, therefore we expect that engineers will demonstrate different competencies at different levels. Our competency matrix is not a checklist, it’s a guideline, and smaller deviations are to be expected. We’re using deviations as the basis for conversations about growth opportunities and how we as an organization can support engineers in this growth – as well as to discuss how engineers can use particular strengths for further growth and supporting others, e.g. through mentoring.

Engineers grow over time by expanding their areas of impact, from task to epic, team level, and onwards by working with their team and the team’s business stakeholders, to across several teams and, ultimately, across the organization. The second important aspect of growth is the ability to demonstrate skills more frequently – from frequently to usually to generally.

What makes a good engineer goes far beyond their coding skills. Our experience and our conversations with our engineers at different experience levels confirm this, and often the more experienced engineers are, the less time they spend coding. This is why technical skills currently make up 20% of all competencies we ask engineers to develop, and the same proportion of skills is dedicated to feedback, communication, and collaboration. We think that these skills are fundamental to being a good engineer, and are aligned with the engineering culture we’re striving for. We value good engineering – and we think that teamwork, learning together and giving feedback are what makes all of us better engineers.

The matrix

You can find CircleCI’s engineering competency matrix here. There’s a small set of guidelines which accompanies the matrix and defines how to use it, which you can find in this document. If you’re interested in seeing how you might grow your career at CircleCI, we’re hiring!

What’s next

We’ve been using this competency matrix for over four months now for goal setting in alignment with our OKRs, as well as performance reviews. As we’re getting used to this new system, we’re also collecting feedback about the competency matrix, the guidelines, and processes, which helps us keep track of potential needs for change. Our plan is to review the matrix again as a team and revise it as needed after six months of usage, which will be in early 2019.

We’re hiring! See all open engineering jobs here. Do you have feedback about the matrix? I’d love to hear your comments. Please email me at lena@circleci.com.

Working on our own competency matrix? Read what we wish we’d known when we started: 7 steps to building an engineering competency matrix