The right building blocks for a robust Career Architecture Framework
Genesis of an organization
Organizations start up by building specialized Functions like Finance, Technology, Marketing, etc. Gradually, as the organizations grow, sub-teams emerge within functions. And within these sub-teams, specialized roles start to evolve. Let’s take an example of a technology product organization which is starting up. It starts with hiring programmers/developers for its core engineering function. Initially a developer would be involved in the entire product life cycle, namely designing, writing code, testing and releasing the product. But as the team and business grows, sub-roles within the engineering team starts to sprout, as the need for specialization increases. For example, specialized roles within the Engineering team can be Development, QA, Dev-Test, Release Management, Product Management, UI/UX, Analytics, etc. Each specialized role can be bucketed as one “Job family”, which basically represents a set of similar jobs requiring similar knowledge, skills and abilities. For e.g. all Software Development jobs fall under one job family.
As an organization you would have to give your employees a sense of growth, as they progress in their careers. This is important to ensure employees are motivated and put additional effort to grow the business, and in turn also see themselves growing with the organization. Two theories come to my mind when I write this — Vroom’s theory and Tournament theory. Vroom’s expectancy theory states that an employee will increase efforts, if that leads to improved performance; and if that improved performance leads to improved results, and subsequently if the improved results are meaningful to the employee. Let’s analyse the above statement in our current context. We understand that employees will go that extra mile if they get “improved results that are meaningful to them”. When the employee does well, the organization might provide additional monetary rewards, but the question here is, if only monetary rewards are enough motivation? Hence, it is also important to reward the employee by expanding her roles and responsibilities and by promoting her to the next level.
According to Tournament theory, the high salary differential, higher benefits and perks between a employee and her manager exists to motivate the employee to seek that higher level role and in the process put more effort at the current job.
Coming back to our initial discussion on career paths, let’s consider the case of our hypothetical startup organization, where the career path for an employee in the Software Development team typically would be — Software Engineer I (SE I), Software Engineer II (SE II), Software Engineer III (SE III), Architect I/Lead Software Engineer.
From SE I till SE III, the employee is primarily an individual contributor and is responsible for technical work responsibilities. For an employee at SE III level seeking a promotion, she is at a career cross-road, where a decision has to be made on which path to take next. She has to decide if she would like to contribute on the technical side of work or take on more people management responsibilities. Here comes the concept of “career tracks”. The employee has to make a choice to take on either a technical track or a managerial track. This choice, of course, is based on the interests, aspirations and skill sets of the employee.
For example, an employee in the technical track would have a career path that looks like this — SE I, SE II, SE III, Architect I, Architect II, Senior Architect, Distinguished Architect. And the career path in the Managerial track could be on these lines— SE I, SE II, SE III, Lead SE, Manager, Sr Manager, Director, Sr Director, VP.
Similar career tracks should be created for the other job families like QA, Dev-Test, etc. and for other Functions as well.
Career Architecture: Integrating Career Paths and Job Levels
The above Career Tracks helps employees have visibility to the available career paths for them in the organization. However, there might be cases where an employee in one job family would like to move to a role in another job family. For example, a Sr Analyst in the Data Sciences team wants to move to the Software Development team. To aid cross-team mobility, assigning levels/grades to jobs becomes critical. This process is called Job leveling. Job leveling measures the relative worth of jobs in an organization and grades jobs accordingly. The primary purpose of the job leveling exercise, though, is to align and group jobs based on their worth, and subsequently make compensation decisions based on that.
Considering, for e.g. that our tech startup has two job families — Software Development and Data Sciences. A job leveling exercise would yield a result that looks like the below:
Now, if an employee from the Data Sciences team wants to move to the Development team, the transition becomes much easier, based on the levels/grades. If it is a lateral movement of a Senior Analyst, which is Grade 3, to the Software Development team, the employee will move to the corresponding Grade 3 role in the Software development job family, which is SE III.
Job leveling and Career tracks can be integrated together to give a holistic view of a Career Architecture. The below snapshot helps us in visualizing both progression within job families and mobility across teams.
The career architecture framework is a great tool for employee career management. I have worked with quite a few organizations so far, and I have noticed that most organizations have a well defined grade/band structures, however, standardized career paths/tracks are not in place in majority of the organizations. Tech organizations in particular, and all organizations in general, should work towards creating, documenting and informing employees about their career management framework. This will help organizations manage their employees’ careers better, and in turn result in higher engagement and retention.