Many software engineers are put off of leadership. And performance management is one reason why. Yet growing other engineers can be one of the most rewarding aspects of leadership. It’s critical engineers take on management responsibilities because research shows that the best leaders and managers are technical experts. And their effectiveness in performance management is the main reason:
If your boss understands the nature of the work, then they can actually help you. They can assess you well, and they can encourage you in the right direction to advance in your career, and that is a very important element for job satisfaction - Dr Amanda Goodall
In my role as a technology leader, I avoided the concept of performance management for far too long. The very word performance put me off. “People aren’t engines,” I thought “you can’t simply tune them in order to get better outputs”.
Eventually it became a responsibility I couldn’t avoid. I couldn’t rely alone on motivating presentations, visions and sharing my past experience. I realised great engineering organisations had leaders who had the skills to guide and grow their engineers. And that was what people meant when they said “performance management”.
Over the years I found an approach to performance management built on a philosophy of cultivation and quality research and it has become one of the most satisying parts of my job!
Performance management is coaching
People who make great performance managers are good coaches who can guide their team through their journey as they grow. Performance managers need to answer two key questions for their people “What do I need to do to be more successful?” and, “What does my future look like?”.
To help people answer these questions they need a performance manager that can act as a credible guide. Where guidance means providing direction, feedback and as objective assessment as possible. I’ve made the word credible bold for a reason. If the manager providing guidance isn’t seen as credible by the person they are managing then they will not be successful. This was something clearly demonstrated by Dr Goodall’s research.
For most people they need to trust their guide is credible in answering the two key questions for:
- Their role/craft and seniority/grade
- Their contribution to the team and organisational mission
Putting this in the context they must have someone who would give them credible guidance when asked:
- What do I need to do to be more successful as a senior (grade) software engineer (role)?
- What does my future as a software engineer look like?
- What do I need to do to help our team be successful for our customers?
- What does my future in this team and this organisation look like?
These things are all very closely related. Being more successful in your role needs to be aligned to being more successful for the team and organisational mission. And the success of the mission is dependent on growing people in their craft and seniority.
My first bit of advice, for any new engineering managers, is to focus on how you provide credible guidance to engineers in their role and grade.
Build Shared Awareness
We have established you as a credible guide whom the software developer sees as a valuable mentor for their role and grade. The first step in your role as a coach is to foster a mutual understanding and shared awareness with the developer. This involves aligning your perspective (as the guide) with that of the developer, ensuring a shared view of the role and grade expectations and how the developer is doing against those expectations.
This shared view has to also be aligned with the organisation’s view too. The guide and developer can’t decide their own version of role and grade. If they are going to talk about what makes a good software engineer, then it needs to be based on your organisation’s collective understanding of a good software engineer.
This shared awareness, between the organisation, the guide and the developer, forms the foundation of the relationship. The role of the guide is essentially this! To guide the developer towards this shared understanding by providing direction, feedback and assessment.
So how do we achieve this?
The Trading Card Game
When it comes to growth everyone must choose their own path. Whilst this is incredibly empowering, it can also be overwhelming if we don’t have the tools to be able to do that.
This is where the idea of the trading game comes into play. People who play trading games have large collections of cards. These cards provide a limitless number of possibilities and styles. However, the player can’t use all the cards. They select those which best suit their playing style to make their own customised decks. A collector has to select from the cards they have whilst they work hard to collect the cards they really want to become a stronger player.
This is the same with growth. The cards are skills and competencies. Just like trading cards, we have a very large selection of competencies and no one person can have them all! And just like trading card games, the developer has to collect new competencies. The developer collects the card by demonstrating that they have consistently applied that capability on their team.
In Trading Card games there are base sets which provide a ready mix of cards required to play. These base sets are like roles (data engineer, software engineer, back-end, UI etc.). You don’t need every single skill as long as you have the right mix to enable you to play the role.
Roles aren’t the only way of understanding collections of cards. As people take on more responsibilitiy there are other sets of general leadership skills which overlap across roles. For example Stakeholder Management is important for many different roles (tech leads, business analysts, designers). These overlaps can help us see which competencies are more powerful and worth investing in acquiring. Just like in a card game.
Skills, roles and leader expectations are what provide us with the collective understanding of what people need to be successful in their teams. Guides and Thoughtworkers can use these to begin their journey of shared awareness.
Don’t try to be good at everything
Many people look at all of these expectations and quickly become overwhelmed. If you’ve ever tried to complete the skills section of your LinkedIn profile you’ll know what I mean! The more you read the long list of skills and what each one requires it can quickly lead to a feeling of lacking.
It’s essential that these expectations are not seen as targets. People musn’t feel that the goal is to collect the complete set. Nobody (really, nobody) has the complete collection. Everybody has a group of competencies they are strong in and others they will never develop beyond the basic needs. This is why teams are special. If we had a base set of capabilities that everyone had to achieve, then we would become mediocre.
This where your role of the guide is very important. By building this shared awareness you learn which areas the developer is strong in and should accelerate to become more impactful and which ones are fine to leave. There is no hard rule that says you are “now playing the role” or that you “achieve this grade” when you reach the right level 60, 70 or 80% of the competencies, so we have to use our own judgement.
Understanding the level
In trading card games, two characters may have the same skills but not at the same level. Scaling skills is not easy, and a model like the Dreyfus model can help (novice, advanced beginner, competent, proficient, expert).
The easiest way to do this is through a self-assessement. For each competency start at the bottom. Ask “what would a novice doing this look like?” and then ask “do you at least three examples where you did this in the last 6 months?”. If you get three convincing examples then ask the question again, but for the next level up.
Once you’ve done this quick assessment you can decide together if the competency is a strength, if it needs to be a learning priority or perhaps they don’t need to focus on it at all.
It’s a Team Game
Not only is nobody good at everything, it would be quite wasteful if they were. This is a team game and the competencies in the team need to complement each other.
The next level of shared awareness is knowing the shape of the whole team and where the developer fits in. For example, Front End Web Development may be a competency for the Engineer role. Whilst it is reasonable to expect most developers in the team to do some front end development, there may be some team members who are particularly good at it and can lead. However, there may be less expertise in Pipeline Design and Automation. This would trigger a conversation about whether Pipeline Design should be a learning priority, given the gaps in the overall team’s competencies.
Context is Key
Players need to choose which deck they’ll play with based on the type of gameplay and the style of their opponents. This is true for us too.
Beyond knowing the team, we need to understand the context of the organisation. And we need to match the desired competencies to that context. If you are working for a trading company and building a high frequency trading platform, then you’d want to be focussing heavily on Performance and scalability engineering. Front End Web Development is probably irrelevant for this context.
Likewise, working in heavily regulated environments might mean everyone needs to focus on Change and release governance and compliance to be successful.
This builds an even broader shared awareness, helping the developer focus on the essential competencies they need to be more successful.
A more accurate view
Doing a self assessment, with the aid of a guide, is a really great starting point. But self-assessments suffer from bias. Dunning-Kruger plays a big role and we often over assess ourselves when we are starting to learn and under assess ourselves as we become more of an expert.
To help build a better shared awareness we need to find ways of including the perspectives of the people we work with day-to-day. This is why we collect feedback.
We can use feedback to provide evidence that we are demonstrating a competency at a specific level. The more feedback which correlates to the competency, the more confident we can be.
It is also important to get feedback from a range of roles. For example, whilst a Project Manager may not feel qualified to tell a developer if they are good at Test Driven Development, they will have a much more relevant opinion on how well they do Estimation. If we only hear from developers, then we may miss these insights.
Playing the game
Remember the two key questions:
- What do I need to do to be more successful (in my role and grade)?
- What does my future (in my role) look like?
By thinking in capabilities, and approaching it like a trading card game, performance partners have the tools they need to guide their developers through these questions. By bringing in the wider context of the team and the organisation it is possible to narrow down the wide range of competencies to the ones which would be most impactful to develop. This process creates a shared awareness between guide and developer which forms the foundation of their relationship.
These expectations won’t tell you everything though. There are many things which aren’t captured in the capability model which will still need to be explored. Hopefully though it will provide 80% of the picture with only 20% of the effort.