A Former Developer’s Guide to Growing Technical People

Being relatively new to management, my primary perspective on developing myself and my career was from the standpoint of an individual contributor, starting as a part-time software developer while attending college and working my way up to a senior developer. While I don’t believe there will ever be a silver bullet to growing and developing people’s careers, my current role as Head of Engineering has presented me with the opportunity to improve some of the career development processes that I had previously been a part of as an individual contributor.

Why Performance Evaluations Fail Technical Teams

I have participated in several different styles of performance evaluations and career development frameworks, ranging from a very informal meeting where I heard, “You’re doing great, keep it up,” to complex, time-consuming surveys and multiple-choice questions. None of these experiences left me thinking, “This is the way it should be done.”

That unsatisfied feeling often arises due to one or more of the following:

1. Lack of constructive feedback – This can stem from several possible sources:
   • No feedback on areas to improve – It can be disheartening and feel like no one is paying attention to you and your work.
   • No input gathered from peers – If collected anonymously, your peers are likely the first ones to identify areas of improvement.
   • Manager reluctance to engage in a potentially tough conversation – This could be due to a manager wanting to avoid conflict or lacking the skills to have difficult conversations around negative feedback for an employee.
2. Inconsistent feedback – Your colleagues give you positive reviews, but your manager gives a conflicting review. Who’s correct?
3. Infrequent feedback – You only hear about how you’re performing once a year or, worse, even less frequently than that.
4. Unexpected or surprising feedback – Your manager informs you that improvement has been needed in an area for a while, but it’s the first time you’ve heard of it. Again, this can be due to a manager being reluctant to have hard conversations.
5. Feedback only related to soft skills, not hard skills – This could sound like, “You’re easy to work with but not quite as experienced as your colleague.” This type of feedback can be confusing because it doesn’t explain how to gain more technical experience or what specific skills to develop.

Building on the last point, a common issue I’ve observed throughout my career is individuals struggling to understand what differentiates a “senior” from a “non-senior” role.  Is it solely based on years of experience? Is it related to the familiarity with the product they work on or their ability to effectively mentor their teammates? It can be confusing to understand why a coworker has been designated as a senior while you have not.

In my experience, this is often the case with performance review processes for technical roles, such as developers, QA analysts, and others, for a few reasons:

• The processes are not well-tailored for the type of people that take on technical roles. As problem solvers, technical people prefer more concrete terms when it comes to identifying areas of improvement.
• The processes are so time-consuming that they become a dreaded burden instead of an opportunity to improve the team. For example, it can be overwhelming to fill out a 45-minute questionnaire for every peer you work with, followed by another lengthy questionnaire specifically for your manager, and then to sit through a 1-2 hour meeting to go over all the feedback.

How to Grow Technical People

While there is no ideal solution to the problem at hand, I believe there are relatively quick improvements that can be implemented. The team will grow accustomed to the process over time and will naturally discover what works well and what doesn’t, leading to further improvements.

1) Create a Growth Framework

To tackle the aforementioned issues, you must first ask yourself and your team a fundamental question: What skills are important to your team and the company?

The first step to answering this is figuring out what your team and company values. Below are a couple of example questions you can ask yourself and your team to better understand what skills are significant:

• What types of personality attributes do we look for in people we hire? (This can also improve your interview process if you’re not currently checking for these traits.)
• What attributes do exceptional colleagues exhibit that we want to encourage?
• What technical skills do you value in your colleagues?
• What technical skills do you need more of as a team?

After much discussion with our team, we determined that it made the most sense to break up competencies for Frogslayer and our engineering practice into three distinct categories:

1. Core Competencies – Non-technical related skills that Frogslayer finds valuable, such as leadership, professionalism, accountability, etc.
2. Development Competencies – Technical skills related to Development and DevSecOps, such as Debugging, Infrastructure, Software System Design, etc.
3. QA Competencies – Technical skills related to Quality Assurance, such as Bug Writing, Manual UI Testing, Automated Functional Testing, etc.

For your organization, try to brainstorm competencies that can be evaluated mostly independently, to minimize confusing overlap.

2) Build the Growth Framework

Development of the framework is the area where most of the work was needed at Frogslayer. To ensure the framework is effective, it must be detailed and comprehensive enough so that individuals in technical roles can use it as a guide to improve their own competencies and, in turn, increase the value they provide to clients and the firm. Here are some helpful tips:

1. Assemble a team of colleagues with varying levels of experience to help build the framework – This not only aids in generating various competency levels but also results in having people who help champion this framework when you’re ready to launch it because they contributed to building it. At Frogslayer, I had part-time developers all the way up to architects help build our developer competencies.
2. Ask your team, “What’s the minimum level of a specific competency we would require in a new hire?” – Make this your baseline. For example, the baseline for the Database competency would be “Must be able to perform basic SQL Queries.”
3. Create levels for your competencies – Avoid associating competency levels with years of experience, as it is not always an accurate gauge of one’s proficiency in a particular area. Additionally, avoid assigning titles like “Senior” or “Associate” as they may limit brainstorming. Start off with 8-12 levels and adjust as necessary. As an example, for our “Quality” Development Competency:
   • Level 1 – Able to run happy path dev tests. Accepts feedback via code reviews. Actively renames variables/functions/classes to be more readable.
   • Level 2 – Follows existing project code style conventions. Strives to follow DRY principles.
   • And so on…

Expect the development of the framework to take some time. For instance, for Frogslayer’s developer competencies, we devised a 9×10 grid of competencies, where each cell was discussed with the team to ensure agreement, along with a considerable amount of discussion beforehand.

3) Test Drive Your Technical Competencies

Once you have developed your growth framework and are comfortable with the initial draft, make a first pass to assess where your colleagues stand based on your current knowledge. This test run will reveal any weak spots or inconsistencies in the framework when combined with other competencies.

Additionally, performing a trial run will also provide insight into potential levels within competencies for various roles in your organization, such as a Senior QA versus a non-Senior QA. This approach helps avoid the issue of pre-assigning roles/titles and associated competency levels, preventing team members from being mismatched with their current position.

4) Launch Framework & Be Open to Feedback

During your performance review process (ideally occurring more than once a year), introduce your growth framework and review the competencies with your technical colleagues. Strive to reach a consensus on where they stand for each competency as best as you can.

While rolling out the framework with colleagues, keep an eye and an ear open for improvements that could be implemented. It is likely that the framework will be continuously evolving as you go through more performance review cycles.

5) Provide Learning Resources

Consider including learning resources alongside your growth framework, such as links to online courses, certifications, and books that individuals can utilize to advance their competencies in specific areas and, ultimately, their career.

Key Takeaways

Performance evaluations are a critical component of career development. As I’ve said, in my experience, they can often fall short and be ineffective, leaving employees feeling unsatisfied and unmotivated.

But it doesn’t have to be this way. I believe that by providing constructive and useful feedback in performance reviews and implementing a growth framework that addresses technical and non-technical competencies, companies can foster the growth and development of their technical colleagues.

• 
  Shaun Maier Head of Engineering

• Tagged In
• Careers
• development practices