Write the content collaboratively 

‍

With your defined goals and  robust structure in place, you are ready to bring in your group of volunteer content creators to flesh out the details of your EGF.

Without these prerequisites, your writers have no guidelines and will establish them by committee organically, which will take months to hash out to a point where everyone is satisfied: by which time energy and positivity for the project wains and it derails. 

Now it's time to work together to 

1. Define categories (or competencies/skills) for performance evaluation 
2. Describe how an engineer should perform in each category at each level
3. Collate examples for how engineers can (or have!) demonstrate that performance level described. 

‍

Define categories for performance evaluation 

As mentioned in Creating A Structure, I find categories that are skills, bring a higher level of clarity to EGFs, so I will base my example on this. 

In this step you want to define all the skills people must use to meet expectations of the role. 

Mistakes and misconceptions:

• Not everyone can or should contribute to all skills 

I know. You have a rockstar developer that believes their coding skills are all that’s necessary to be high-performing. Unfortunately for them, this is about creating a high-performing team, not a high-performing individual that gets away with creating a toxic work environment for others. You may need to re-set expectations around role performance with your rockstars when you roll this out (more on that later in the series) but expecting them to improve communication and collaboration skills will help you create an inclusive successful team, and actually set them up for greater career success.   

You can write your skills or categories that allow for various neurodiverse profiles or personality types giving people options for contribution. As an example, a “Community” skill could encompass contributing to open source, or public speaking, or participating in the internal community in an impactful way.    

‍

• Some Categories are not relevant until later career 

To set your juniors up for success it's important to show a pathway towards achieving growth in all areas. If you really dig in, you will realize we begin developing certain skills early in our careers, by shadowing, participating, contributing ideas and giving feedback. All this has impact and can be recognised and rewarded. 

An example of this is Delivery. Engineers may not be planning and running sprints until they are at a senior level, but juniors will be estimating and delivering smaller well-defined tasks. In later career, this skill evolves into long-term strategy formation and execution.  

‍

• The categories must define everything for everyone 

Yes, that is the idea, but rarely possible. You will find you can achieve a great impact by delivering something that caters for 90% of your engineering organization, allowing you to manage the edge cases and exceptions. Most companies have a few bespoke roles that are on (equally-bespoke) career trajectories, or individual’s circumstances that necessitate a more flexible approach. When you encounter outliers or edge-cases, try not to agonize over how to incorporate them in for the majority: document them for later guideline-writing, and move on. 

What is important is to ensure that certain levels or roles are attainable for those that are outside of the homogeneous profile of the company's leaders (usually, white men). This means, there are clear pathways to senior technical roles, such as Principal Developer, Lead Engineer, Staff Engineer and Architect.  

Selecting your Skills

Here are some tips for defining skills that lead to high-performing engineering teams

1. Cap it at 10 (ok, 12 at most) categories or skills. Any more can be overwhelming for people trying to navigate the expectations of their role. 
2. Half your skills should be around technical and delivery, and half around teamwork and growing self and others. The expectations would be that Engineers contribute equally across these 2 buckets: with no one Engineer over-indexing either way.
3. Think about what are necessary skills for your Engineering organization, now and for the next stage of company growth. 

‍

One approach to compiling your list would be to whiteboard all the different skills, and have the group rank them in order of importance via dot-voting. Take the top 5 Tech & Delivery categories, and the top 5 Team & Collaboration categories. 

Keep referring back to your goals and measures of success. Will these categories enable you to achieve the goals you set out with? Will they really codify what it means to be a well-rounded Engineer at your company?  

‍

Here is a collection of competencies or skills, I have used in the past: 

• Coding
• Delivery
• Communication
• Hire & Retain
• Customer
• Security
• Team Building
• Coaching
• DevOps 
• Craft
• Mentoring
• Feedback
• Architecture
• Data
• Collaboration
• Inclusion. 

‍

At the end on this stage you will 

1. Understand the scope, impact and complexity of work for each level.
2. Have a defined set of skills, ready for you to flesh out the detail.

‍

Describe how an engineer should perform in each category at each level

If you have been on roll up to this point, it's no time to get comfortable and take your foot off the pedal - this can be the most difficult part of the whole process. Getting this right means you bring harmony and clarity to the engineering team. Though, conversely, it's also a good time to remember that perfection is the enemy of done. Our goal at this stage is to get something done-enough so we can iterate on it. I have found that setting an artificial delivery date for this step creates a sense of urgency and also ensures that you don't iterate on it in perpetuity. 

General guidelines I follow to keep things clear, concise and not overwhelming are:

1. Keep your descriptions succinct: only 1-2 sentences. Remove all flowery language.
2. Use words that make this contribution observable. As an example, “Understands xyz” is not observable.
3. Describe the impact, scope, breadth or complexity of the work.
4. Each level should build on the last, and levels should have an ever-increasing scope and impact. 

Collect actual examples    

Engineering will love you for it! Once you have a description of how each engineering is expected to perform each competency at each level, we want to compile a list of real-life examples of how this happens in your company. Include the names of internal systems and tools, communities of practice or guilds. This can help clarify what  sometimes ambiguous phrases, like “delivers systems of medium-complexity” mean.

Anti-behaviours: to include or not? 

Some teams feel very strongly about including behaviors to avoid. This happens when there is a strong negative culture in one particular aspect. An example could be “actively refuses to pair-program with junior developers”. Whether I would recommend going to this or not depends on how ingrained the adverse-behavior is across the engineering team, and whether you have already tried and failed to shift it with well-communicated feedback. I generally don’t encourage including them, as often it is done as a way to deal with a few outliers who have not had the courtesy of direct feedback on the impact of their actions: you end up needing to create a lot more content to indirectly manage a few poor performers. 

‍

At the end of this stage you will have a complete Engineering Growth Framework, ready to roll out across your Engineering organization.  The next step is rolling it out with robust change management practices.

‍

Keep an eye out each week as we publish a blog on each of these steps.

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 5: Roll out with robust change management practices 

BONUS: Enable data collection and feedback loops

‍

‍

Contact Us

Follow us on LinkedIn

‍