In my previous entry I talked about establishing a career path for developers in your organization. Now I will talk about using that career path to then create a framework for advancement.

Create Framework for Advancement
You've taken the initiative and created a real career path for your developers, now how do you guide them down one of these paths?

First you ask them what their interests are. Work with them so that they fully understand the implications of each career path. You then work together to create level specific goals and expectations.

For example, say one of your developers aspires to senior level. You need to have a clear definition of what the responsibility of a senior developer is and be able to quantify the differences between mid-level and senior. Maybe senior developers begin to take on leadership roles by mentoring more junior team members and becoming a point of reference for domains of the code base. You would then create goals for your developer around this data point.

This is creating a framework for success: having a clear definition of requirements and an implementation plan for achieving success. This is a pattern that you should run into innumerable times not only in your career but your life. But just like running a project, just having a plan is not enough.

Once the goals are created to give a path to success there must be intermediary milestones and regular check points.

Intermediary milestones can be quarterly reviews of the goals you established. Things change over the course of a year and these reviews give you a chance to re-evaluate the goals that you had established. This is important because at the end of the year when you give annual reviews the goals give you a clear and objective template to base your review score on, and the more accurate and topical the goals are the more accurate and topical your review will be.

Regular checkpoints are opportunities to mentor and guide your reports as they work on their goals, usually in the form of weekly, or bi-weekly one on one meetings with your direct reports. You can gauge their progress, give feedback and correct the coarse as needed. In agile terms think of these as daily scrums and your quarterly reviews as sprint reviews.

The concepts outlined in this series should be familiar to most readers, if not as something that they have orchestrated themselves then at least as experiences that they have gone through. The important part is to recognize them as organizational patterns and apply them to the benefit of your reports and your organization as a whole.

Read more from Tom Barker.