Tessian has just finished building our first-ever Growth Framework for our Engineering team. At the same time, we’ve also introduced Internal Levels to represent different stages of progression and identify key milestones as our Engineers develop and grow.
We see this framework as a guiding North Star for Tessians to trail blaze their own career. Tessian’s values ensure we achieve against the expectations outlined in the framework in the right way, and they are embedded throughout.
Why did we do it?
We’ve had feedback in the past about not having clear progression paths for our current team and – at the same time – it’s critical we understand what “good” looks like at each level for new team members.
So, what problems is this new framework going to solve for us?
- Our Engineers know what their career at Tessian could look like.
- Introducing levels means we can celebrate promotion more formally.
- It will support future hiring so we can find the best people to join us.
What does it look like?
There are levels which show the milestones of development at Tessian. As our engineers develop and grow, they progress through these levels.
How do they know what it takes to get to the next level? Well, that’s where our Growth Framework comes in! The framework defines competency clusters which are then broken down into further competencies that outline the key behaviors expected at each level.
Let us introduce you to our Competency Clusters (and Competencies)
How did we do it?
Our Engineering and People team partnered on this and garnered insights not only from Tessians, but also by exploring best practice in our industry.
We have a culture of collaboration so it was important for us to hear directly from our Engineering team to learn more about their perspectives. We spoke to as many engineers as possible to find out what makes a great engineer and a great framework. We also reviewed successful frameworks in other tech companies to get a strong sense of what has and hasn’t worked for others.
Here’s a step-by-step of our actions:
We researched open sources and, by comparing and coding, we found that there are similar core competencies that appear in the majority of frameworks. We whittled it down to seven possible competencies; Craft, Impact, Execution, Leadership, Advocacy, Continuously Improves, and Communication.
We ran a series of workshops with our Eng leaders to really dig into what’s important for them. In the first workshop, we shared the seven possible competencies and, in breakout groups, we discussed the competencies. We asked ourselves two key questions:
- For Tessian: How important is this in helping us achieve our business goals?
- For our Tessians: How meaningful is this for individuals in their careers?
We then brought everyone back for a group discussion and shared our thoughts from the breakout groups. As expected, we found there was a lot of cross-over amongst the competencies and what they mean to us.
From this first session, we had two main takeaways:
- We needed to ensure that we created clear competency cluster definitions that describe exactly what that competency means to Tessian.
- We could chop and merge some of the 7 possible competencies clusters to identify our core competencies.
In our second workshop, we shared our findings and introduced the rescoped and refined competencies. This was where the idea of Competency Clusters with Competencies within them were born.
Our four clusters became: Craft, Impact, Delivery, and Communication.
From this session, we gained better understanding about our competencies, but had feedback that perhaps the names of the clusters didn’t feel quite right.
We wanted our clusters to be action statements, so:
- Craft became “Master your Craft” – broken down into Technical Skills, Continuous Improvement and Security.
- Impact became “Make an Impact”– broken down into Teamwork, Influence, Accountability and Customer-Centricity.
- Delivery became “Get Stuff Done” – broken down into Delivery and Autonomy.
- Communication became “Communicate” – broken down into Information and Feedback.
Building the behaviors
At this point, we were in a good place with our competency clusters, competencies, and definitions. It was time to build the specific behavioral indicators that sit under each competency and each level.
We knew from our previous workshops that – while we were getting some really useful comments – it was sometimes quite difficult to capture them all verbally. So, we tried out a live commenting activity. It worked brilliantly and captured the diversity of thought amongst all of our engineering leaders.
We shared the draft framework with our managers before the session. Then, during the session, we asked managers to spend the first 20 minutes making live comments on our Google sheet. Afterwards, and as a group, we went through each of the comments, discussed further, and made notes for action.
But, we didn’t stop there. We had a few more manager workshops where we had cycles of gaining feedback > making amends > sharing back.
When we got to what we’d call a ‘final draft’, we asked the wider Engineering team for volunteers to join a focus group to get their feedback. This was an energizing session and was the first time the wider team was able to see the framework and overall, the response was really positive. People really cared about understanding how this tool could be used to support their growth at Tessian.
One nugget of feedback that came from this group was that our Competency Framework sounded very formal and not very inspiring, and so, this became our Growth Framework. This really felt like it was more representative of what we want to use it for.
Defining our levels
While we were finalzing our Growth Framework, we were also identifying what levels and job titles would make sense for Tessian. Again, we looked at what our peers were doing (using progression.fyi), so that whatever we landed on spoke the same language as the rest of tech. This also ensures that it’s on par with appropriate expectations in the market so it’s easily comparable with other companies.
This is arguably the most important part. We had to see if the framework actually worked in practice.
We had meetings with individual managers to work through what level each of their team members were currently delivering to. And, to ensure a fair and transparent process, we had a group calibration session to discuss the larger team.
In an effort to ensure the same approach was being applied to every assessment, we asked managers to use a traffic light system to review their direct reports against each competency. The traffic light colors indicate:
- “They are consistently demonstrating this behavior” (green)
- “They demonstrate this behavior from time to time, but not all the time” (yellow)
- “They are currently not demonstrating this behavior” (red)
The final tweaks were done, wordsmithing complete, and design decisions made. Finally, our framework was published on our internal Wiki for everyone to view.
All managers had discussions with their direct reports to understand where they think they currently sit against the framework, and we will finalize trial levels over the coming weeks. The word “trial” here is important. We’ll explain more below.
What comes next?
Collaboration and shared accountability are critical to our engineering culture at Tessian. So, for the next few months, our team will have what we’re calling “trial levels”.
This means that we won’t confirm final levels until we’ve used the framework in practice for a couple of months, and our team has really had the opportunity to see how this works for them before providing feedback. It’s a process!
We’re beyond excited to see how this framework will continue to support Tessian to create a world class engineering organization that not only builds amazing products, but that enables engineers to thrive and grow in their careers. Watch this space as we share more news about how this has worked for us in practice and key insights gained!
And, if you’re interested in joining our team, see our open roles here.