Create a structure for your Engineering Growth Framework

In this series, we have looked at getting started, defining your measures of success and engaging the right stakeholders. Now we come to defining a structure, or framework, for you Engineering Growth Framework (EGF).
‍
Many just begin by writing what it looks to be a, say, mid-level full stack engineer and believe this process is repeatable up, down and across the ladder. Very quickly it becomes apparent it's not so obvious when you get to the edges. 

The goal here is to codify how people are truly being evaluated now, and what you hope will happen, in terms of cultural shifts or capability uplifts. Everything is codifiable: there are no magic levels or roles. If people are promoted to Staff due to “the Vibe”, dig in, and find out what assumptions and ideas people are attributing to the vibe. Vibe and gut feel are also known as unconscious bias - Don’t trust your gut, codify it!

‍

‍

Key-learnings from implementing EGFs

‍

It’s important to codify Glue work or core skills. 

We know that strong collaboration, coaching, mentoring, teamwork, pair-programming, facilitation, planning and communication lead to higher-performing teams; yet, contributions in these areas happen by accident rather than by design. It requires someone to step up and take on this additional labor with no recognition or expectation that is equally shared across a team. Your EGF must encourage behaviors that lead to better business outcomes, so don’t forget to add these in! 

It's important to define the outcomes, scope and complexity of the work expected at each level.

This can be challenging, but essential. Doing this essentially creates a unit test for your levels that you can refer back to later as you build out the content. When we say scope, this can refer to the number of people you collaborate with, the seniority of those people, the number of customers impacted by the work. It can also look at the size of work items, starting with tasks, features, epics and up to whole products. Complexity can refer to a depth of domain or technical knowledge necessary to deliver certain systems, the breadth of those systems, or the interconnections between systems.  

‍

It's important to be hyper-specific so Engineers can understand what their day-to-day tasks should look like. 

Your structure will need to bring this clarity. Most of the Engineers I’ve led and worked with are relieved when they have structured guidance that eliminates the guesswork.   
A structure I have found that works most of the time is to break the required outcomes and expectations into different skills: with a clear description of expected outcomes, and a list of examples.
Skills work well as a structure because they set clear boundaries: they can be mutually exclusive. I have seen EGFs that assess performance based on Impact, Attitude or Behaviour: and it's often very unclear to Engineers how to achieve the impact or improve the behavior. It feels like an innate ability that you either have, or you don’t. People know they can train to learn skills. 

‍

Whatever structure you decide on, make sure it allows for examples of how people can attain the skills and perform to meet the expectations of the role.   

Keep an eye out each week as we publish all of the steps involved

Other blogs in this series:

‍

Part 1:Getting started with your EGF, and defining your measure of success

Part 2: Engage the right stakeholders

Part 3: Create a structure for your EGF

Part 4: Write the content collaboratively

Part 5: Roll out with robust change management practices 

BONUS: Enable data collection and feedback loops 

‍

Contact Us

Follow us on LinkedIn