One of the most common questions we get asked by interview candidates is around how they can grow within the company and in their careers if they choose to join us.
As a company that is growing its business exponentially every year — dubbed a Soonicorn, listed in the Deloitte Technology Fast 50 UK 2020 and 2021 and Otta’s Rocket List of 100 fastest-growing companies to accelerate your career — we want to enable everyone who works at Beamery to grow in skills, capabilities, roles, responsibilities and impact with the company so that the employees’ success contributes to the business succeeding and vice versa.
This is all easy to say, but when it comes to put it into practice, we need structure, clear expectations and a career framework to not only have constructive and unsurprising conversations around career growth but also to ensure that everyone is holding themselves to the same standards regardless of which team or manager they work with and irrespective of how they personally identify themselves.
🔭 Why we need a Growth Framework
⚖️ Fairness, reducing bias
Different teams and managers have different expectations from people, different priorities that they have learned to focus on through their unique experiences. This means that different people are assessed differently and unconscious bias is at play. For fairness in recognition and reward, i.e. in titles, salaries and promotions, we need a common scale to assess growth and contributions, a way of calibrating expectations held by a diverse set of people. At the same time, this scale needs to inclusively and fairly assess a diversity of people who see and approach problems differently and achieve results in their own unique ways.
🗃 Clear expectations of each role and level
Feedback is hard, but one of the things that often makes it hard is a lack of explicit expectations for a role or level. Outlining these expectations or competencies provides a trellis for growth — people know what they need to do to perform at their current level or grow to the next level. They have a benchmark to be working toward, meeting or exceeding.
🪜 Guidance for growth plans
We aspire to have inspiring growth plans for every person on the engineering team. These growth plans consist of development goals stemming from career aspirations, professional interests, upcoming opportunities, the team’s needs, 360° feedback and self-reflections. The Growth Framework provides the backdrop grid for all of these, lending structure, terminology and alignment to highlight competencies that contribute to meaningful career progression within Beamery and beyond.
🎁 What we wanted from our Growth Framework
🌈 Inclusiveness for all engineers of different shapes and verticals
Our first stab at an alpha version of our Growth Framework got consistent feedback about it being a bit too backend-leaning and lacking relevance, for example, for QA engineers.
We decided as a result that our Growth Framework should be broad, focussing on what makes an effective and impactful engineer no matter their specialization, and yet provide interpretations for different verticals—in our case, Backend (BE), Front End (FE), Quality Assurance (QA) and Site Reliability Engineering (SRE).
We also wanted to be inclusive of different engineering mindsets, like
- 🔸 Shapes: breadth vs depth from T-shaped to V-shaped
- 🧬 Archetypes: from productive coders and problem-solvers to emerging leaders and great communicators
🎚 Simple and discrete distinction between different levels
A common question people try to answer when looking at the Growth Framework is: What’s the difference between one level and the next, what will it take for me to get promoted to the next level?
We wanted to keep the answer to that simple and easy to understand for everyone, make it obvious, limit room for different interpretations and thus bias.
So for each section of the framework, we had a progression of verbs as a brief distinction between levels. E.g. for Agility and Strategy, Observes → Participates → Adds Value → Facilitates → Drives → Enables → Empowers.
These were loosely inspired by Bloom’s Taxonomy.
🥏 Low barriers for career progression
We also wanted to have sufficient levels to lower the barrier for a promotion, giving engineers a closer level to aspire to, and reducing the salary variance at each level. The difference in expectations between a just-promoted Senior Engineer and a Principal Engineer was vast and daunting. Thus we split our Senior Engineer into 2 levels and similarly renamed lower levels to eventually have:
- Associate Software Engineer
- Software Engineer 1
- Software Engineer 2
- Senior Software Engineer 1
- Senior Software Engineer 2
- Principal Engineer
- Senior Principal Engineer
🪴 Examples of positive observable behaviours
The expectations in the Growth Framework and the assessment against it should avoid undemonstrated capabilities, i.e. statements like is able to design a complex system. How we want to frame these statements instead is as positive observable behaviours, like has designed multiple systems spanning more than one team.
The verbs used to distinguish between different levels became ideal verbs to start these statements with: drives projects from ideation through to delivery following up on success metrics. The action verbs from Bloom’s Taxonomy also served as inspiration again.
At the same time, engineers may not have had an opportunity to demonstrate these observable behaviours, especially early in their time at Beamery, e.g. not yet having had the opportunity to lead a project or the lack of capacity to focus on interviewing. We have to be careful not to penalize or demotivate people in these situations, instead use their past career examples as a mark of their capability and note the lack of opportunity so far at Beamery as a circumstantial limitation not affecting their assessment.
⚙️ How we went about it
We organized a workshop with Engineering Management to build our Growth Framework. The icebreaker question for the workshop was, Why do you care about this?
Skeleton with competency sections and levels
The competency sections were inspired by the Knowledge-Skills-Attitudes pyramid of learning categories.
We enhanced the names of these sections and added a fourth one.
- 📕 Knowledge & Best Practices: Foundational and mostly theoretical but acquired relatively quickly through reading, comprehension, application etc., like the syntax of a programming language.
- 🤹🏼 Skills & Expertise: Developed through experience, practise and consistent effort over years, like writing future-proof code.
- 📈 Growth Mindset & Evolution: Values, beliefs and attitudes that evolve through a lifetime of experiences, like pragmatism or knowing when to choose good enough over perfect.
- ⚡ Demonstrated Impact: The sum total result of putting all the above to use, like delivering a project on a predictable timeline and assessing its success in business terms.
Before our workshop, we already had these sections and levels as the row and column headings of our Growth Framework matrix.
✨ Inspiration from existing frameworks
During our workshop, we analysed the Growth Frameworks from multiple other engineering organizations to find the most relevant competencies to have in our framework.
We reviewed frameworks from Medium, Monzo, Buffer, Rent the Runway and Spotify. For each of these, in pairs, we noted down:
- 👍🏼 5+ aspects that’d work great for Beamery
- 👎🏼 2+ aspects not applicable to Beamery context
We particularly liked
- 🛠 Medium’s competency sections called Building, Executing, Supporting and Strengthening, besides their statements exemplifying positive observable behaviours.
- 🧭 Monzo’s focus on outcomes and impact with a simple classification of expectations into Skills and Behaviours.
- 📝 Buffer’s summary for each level.
- 🎨 Rent the Runway’s distinction between skills, execution, impact, communication and leadership.
- 💡 Spotify’s emphasis on organizational scope, DE&I, hiring and usage of verbs for positive observable behaviours like defines, seeks, contributes, identifies.
⏱ After the workshop
This workshop resulted in a collection of competencies for each vertical that were later consolidated and categorized into our 4 sections of competencies with some special interpretations (we call them “lenses”) for BE, FE, QA and SRE. E.g. Non-Functional Requirements as a competency has
- 🔍 Generic Lens: Security, Privacy, Reliability, Resiliency
- 🚧 BE Lens: Performance, Load, Stress, Scale
- 🖥 FE Lens: Performance, Responsiveness, A11y, i18n, Localization
- 🔬 QA Lens: Testing Performance, Load, A11y, i18n; Subject Matter & Domain Expertise
- 🎛 SRE Lens: Compute, Memory, Storage, Networking
We delegated fleshing out the descriptions of each competency with examples of positive observable behaviours to different groups of EMs and reviewed them once completed.
Then we revealed it to the organization, sought feedback openly and in 1:1 reviews of the framework and its usage.
Some of the feedback we’ve got is around having more real world examples of how people have leveraged the framework to make their case for promotion, of what kind of work and impact has led to their positive assessment.
A revision of the Growth Framework is underway with Patrick McDonnell’s leading the initiative to make the framework easier to interpret and apply in day to day work.
Besides that, for some of our specific competencies:
- Non-Functional Requirements: People often lack opportunity to work on these areas actively until they become a problem, e.g. security, performance, i18n, scalability etc.
- Managing Complexity Spans both software/system complexity and project management complexity, where the latter also has a significant overlap with the Business Impact competency.
- Strategy needs a better description and more detailed examples. This area also sometimes suffers from a lack of opportunity as not all teams are working on strategic projects at all times.
🙌🏼 What has made this work successful and valuable is all the input and feedback we’ve received from people using the framework, and many peer coaching sessions where managers have shared experiences and approaches for development talks and growth conversations using this framework.
💭 It’s truly a team effort! And guess what — you can help too! We’d love to hear your thoughts and feedback in the comments. Do share your ideas and stories about progression frameworks and career growth also. They will help us in how we evolve our Growth Framework and career progression practices, and we’ll report back on our learnings!
🤩 It’s a great feeling for both engineer and manager when you walk out of a development talk with meaningful inspiring goals emerging from a comprehensive and thought-through Growth Framework.
We’re looking for Software Engineers Front & Back Mid/Senior/Director, SRE Platform Engineers, Engineering Managers, Tech Leads, Product Operations/Managers/Designers across all levels and even more roles across London, Remote & Berlin! to join us — apply here!